- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Pharo needs you

by Robert Withers

Here's the fixed Crypto mcz for Pharo 5. I have not had a chance to submit it but I'm working that item. Here's the old link: http://www.squeaksource.com/Cryptography, with the Plugins code. I lost the link to the Pharo repo Cryptography page. thanks, Robert On 10/13/2015 05:44 PM, Robert Withers wrote: > Hey Stef, > > This discussion got me to thinking about fonts and system-dependent > resources. I wrote SSH and SSL long time back because though there were > both performance issues and validation issues, it was all in the image > and totally platform-independent. I still hold this opinion, in belief > that a few different styles of optimizations are available: JIT, crypto > plugins, shared data. The reasoning is that comm data is platform > independent. > > The situation with fonts is different. Fonts are licensed and I smile in > the thought that they are types, the only types you could ever possibly > want. :) Different platforms have different sets of these types and > they should be available to us, in image. > > Now, that's a lot of work that you may want to spent on other > activities. Ok, could we combine font work with another value? Yeah, I > think so, at least if I were in your shoes. My burning question is "What > is the best way/structure/form to differentiate platforms specifics from > polymorphic interfaces?". I think it is much easier when the form & > structure of the content is platform-independent and is your data-driven > case. Yet in the access, this is platform-dependent and you want it to > be so. Therefor the upper interface - of the access classes - ought to > pass platform-independent instances. > > The conclusion I come to is that the platform-dependent code must > translate across that semantic barrier and talk Smalltalk. Implementing > a case study is highly useful, I would think. An in-image font builder > could publish annotated platform-independent glyph definitions, our > fonts, through platform-dependent libraries, reading these assets off > the system. > > NB: regarding crypto plugins: I'll attach the Cryptography mcz again > along with a CryptographyPlugins mcz. If anyone wanted to try to get > those working in Pharo, that would be educational. This has an > interesting example how to plug platform-dependent plugins in. In fact, > Fuel validation could be used on crypto plugins and different > implementations could be tried using other languages. What's the best? > May be Haskel, right? If some students got into writing crypto plugins > that would also be high value, to me anyways, but I feel it's for us all. > > Thanks so much ^^ > Robert > > On 10/13/2015 05:14 PM, stepharo wrote: >> Thanks Aliaksei. >> >> I think that in the future we should be radically with hardcoded fonts >> and color. >> I think that a widget should have color and font as variables that we >> can set up from the outside. >> What is your take on this. >> >> Stef >> >> >> Le 12/10/15 23:34, Aliaksei Syrel a Ã©crit : >>> >>> Thanks for pointing out such usecase, Stef! This is indeed important >>> >>> On Oct 12, 2015 9:16 PM, "stepharo" >>> <<mailto:stepharo@free.fr>stepharo(a)free.fr> wrote: >>> >>> Hi guys >>> >>> We are working like mad on the mooc and I'm stuck because to >>> produce cool videos I cannot get the correct fonts >>> because the widgets are not using font size :( >>> Look at the attachment. >>> This is how one day we pay our sloppiness. >>> So I will reduce the font size but it sucks. >>> Stef >>> >>

Oct. 13, 2015

Re: [Pharo-dev] Pharo needs you

by Robert Withers

Hey Stef, This discussion got me to thinking about fonts and system-dependent resources. I wrote SSH and SSL long time back because though there were both performance issues and validation issues, it was all in the image and totally platform-independent. I still hold this opinion, in belief that a few different styles of optimizations are available: JIT, crypto plugins, shared data. The reasoning is that comm data is platform independent. The situation with fonts is different. Fonts are licensed and I smile in the thought that they are types, the only types you could ever possibly want. :) Different platforms have different sets of these types and they should be available to us, in image. Now, that's a lot of work that you may want to spent on other activities. Ok, could we combine font work with another value? Yeah, I think so, at least if I were in your shoes. My burning question is "What is the best way/structure/form to differentiate platforms specifics from polymorphic interfaces?". I think it is much easier when the form & structure of the content is platform-independent and is your data-driven case. Yet in the access, this is platform-dependent and you want it to be so. Therefor the upper interface - of the access classes - ought to pass platform-independent instances. The conclusion I come to is that the platform-dependent code must translate across that semantic barrier and talk Smalltalk. Implementing a case study is highly useful, I would think. An in-image font builder could publish annotated platform-independent glyph definitions, our fonts, through platform-dependent libraries, reading these assets off the system. NB: regarding crypto plugins: I'll attach the Cryptography mcz again along with a CryptographyPlugins mcz. If anyone wanted to try to get those working in Pharo, that would be educational. This has an interesting example how to plug platform-dependent plugins in. In fact, Fuel validation could be used on crypto plugins and different implementations could be tried using other languages. What's the best? May be Haskel, right? If some students got into writing crypto plugins that would also be high value, to me anyways, but I feel it's for us all. Thanks so much ^^ Robert On 10/13/2015 05:14 PM, stepharo wrote: > Thanks Aliaksei. > > I think that in the future we should be radically with hardcoded fonts > and color. > I think that a widget should have color and font as variables that we > can set up from the outside. > What is your take on this. > > Stef > > > Le 12/10/15 23:34, Aliaksei Syrel a Ã©crit : >> >> Thanks for pointing out such usecase, Stef! This is indeed important >> >> On Oct 12, 2015 9:16 PM, "stepharo" >> <<mailto:stepharo@free.fr>stepharo(a)free.fr> wrote: >> >> Hi guys >> >> We are working like mad on the mooc and I'm stuck because to >> produce cool videos I cannot get the correct fonts >> because the widgets are not using font size :( >> Look at the attachment. >> This is how one day we pay our sloppiness. >> So I will reduce the font size but it sucks. >> Stef >> >

Oct. 13, 2015

Re: [Pharo-dev] Pharo needs you

by stepharo

Thanks Aliaksei. I think that in the future we should be radically with hardcoded fonts and color. I think that a widget should have color and font as variables that we can set up from the outside. What is your take on this. Stef Le 12/10/15 23:34, Aliaksei Syrel a Ã©crit : > > Thanks for pointing out such usecase, Stef! This is indeed important > > On Oct 12, 2015 9:16 PM, "stepharo" <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > Hi guys > > We are working like mad on the mooc and I'm stuck because to > produce cool videos I cannot get the correct fonts > because the widgets are not using font size :( > Look at the attachment. > This is how one day we pay our sloppiness. > So I will reduce the font size but it sucks. > Stef >

Oct. 13, 2015

Re: [Pharo-dev] [Moose-dev] Syntax highlighting is missing in Playground and examples

by stepharo

Thanks Andrei :) We were focusing on all the other users of PlugTextMorph :) Stef Le 13/10/15 21:48, Andrei Chis a Ã©crit : > The two issue are not related. This bug appeared because the > 'Playground' view was using PluggableTextMorph which no longer works > on in Pharo. > I replaced the editor with rubric and it should work now. > > We should deprecate the renderers based on PluggableTextMorph in glamour. > For that we need to: > - deprecate GLMCompositePresentation>>#smalltalkCode and replace it > senders with #pharoMethod and #pharoPlayground > - switch the the rubric renderer in > GLMCompositePresentation>>#text; Or do we deprecate #text and keep > just #rubricText ? > - deprecate all classes that are linked to the PluggableTextMorph > renderer. > > Cheers, > Andrei > > > > > On Tue, Oct 13, 2015 at 6:35 PM, Alexandre Bergel > <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>> wrote: > > Done > https://pharo.fogbugz.com/f/cases/16781/Syntax-highlighting-is-missing-in-P… > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >> On Oct 13, 2015, at 12:54 PM, Tudor Girba <tudor(a)tudorgirba.com >> <mailto:tudor@tudorgirba.com>> wrote: >> >> Indeed, that is a bug. Could you open a Pharo issue for this? >> >> Cheers, >> Doru >> >> On Tue, Oct 13, 2015 at 4:51 PM, Alexandre Bergel >> <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>> wrote: >> >> Hi! >> >> I see there is a great battle involving Rubric and all its >> friends is taking place. >> When I browse an example, I do not have the syntax >> highlighting. I am using the last version of Moose. >> >> <Screen Shot 2015-10-13 at 11.49.53 AM.png> >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch <mailto:Moose-dev@list.inf.unibe.ch> >> https://www.list.inf.unibe.ch/listinfo/moose-dev >> >> >> >> >> -- >> www.tudorgirba.com <http://www.tudorgirba.com/> >> >> "Every thing has its own flow" > >

Oct. 13, 2015

Re: [Pharo-dev] binary serialization

by Mariano Martinez Peck

No, unfortunately, as far as I can remember, we do not have that. There are another hooks you may use but only in certain scenarios (#fuelNew, #fuelAfterMaterialization, global sends, etc). But everything is listed in http://rmod.inria.fr/web/software/Fuel/Version1.9/Documentation/Customizing… so if you didn't find anything of help in there there are chances there isn't anything. Cheers, On Tue, Oct 13, 2015 at 5:30 PM, Robert Withers <robert.w.withers(a)gmail.com> wrote: > Yes, I meant dynamic substitution on materialization, to use the correct > terminology. > > thanks, > Robert > > > On 10/13/2015 11:40 AM, Max Leske wrote: > >> >> On 13 Oct 2015, at 17:16, Robert Withers <robert.w.withers(a)gmail.com> >>> wrote: >>> >>> Every extra source helps, thank you. I see how to do non-stream >>> substitutions on materializations, but the documentation did not indicate a >>> way to do non-stream substitutions on serialization. Is it possible? >>> >> >> I donât understand what you mean by ânon-streamâ. Could you give an >> example? >> >> >>> thanks, >>> Robert >>> >>> On 10/13/2015 09:00 AM, Mariano Martinez Peck wrote: >>> >>>> Hi Robert, >>>> >>>> As for the documentation, you have LOTS of tests, you have the chapter >>>> Torsten pasted, you have this documentation: >>>> http://rmod.inria.fr/web/software/Fuel >>>> >>>> But also, as for internals, there is a journal paper we wrote: >>>> http://rmod.lille.inria.fr/archives/papers/Dias12a-SPE-Fuel.pdf >>>> >>>> Let us know how it goes, >>>> >>>> >>>> On Tue, Oct 13, 2015 at 6:00 AM, Torsten Bergmann <astares(a)gmx.de >>>> <mailto:astares@gmx.de>> wrote: >>>> >>>> Hi Robert, >>>> >>>> Also checkout the chapter on Fuel in Pharo Enterprise book: >>>> >>>> >>>> https://ci.inria.fr/pharo-contribution/view/Books/job/EnterprisePharoBook/l… >>>> >>>> Bye >>>> Torsten >>>> >>>> > Gesendet: Dienstag, 13. Oktober 2015 um 09:44 Uhr >>>> > Von: "Robert Withers" <robert.w.withers(a)gmail.com >>>> <mailto:robert.w.withers@gmail.com>> >>>> > An: pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org> >>>> > Betreff: Re: [Pharo-dev] binary serialization >>>> > >>>> > Yes, I have to do object substitutions. Thanks for the link! >>>> > >>>> > thanks, >>>> > Robert >>>> > >>>> > On 10/13/2015 03:43 AM, Max Leske wrote: >>>> > > >>>> > >> On 13 Oct 2015, at 09:40, Robert Withers >>>> <robert.w.withers(a)gmail.com <mailto:robert.w.withers@gmail.com>> >>>> wrote: >>>> > >> >>>> > >> Sven and Torsten, that's a binary serialization library! It >>>> will take time to learn it and how to use mappers. >>>> > >> >>>> > >> What is the format; is it language neutral? >>>> > > >>>> > > For quick serialization you donât need to do anything. It works >>>> for (almost) all objects. Only if you want to exclude things or >>>> treat some objects in a special way, you will need to do some stuff. >>>> > > >>>> > > Documentation: http://rmod.inria.fr/web/software/Fuel. >>>> > > >>>> > > >>>> > >> >>>> > >> thanks, >>>> > >> Robert >>>> > >> >>>> > >> On 10/13/2015 01:21 AM, Sven Van Caekenberghe wrote: >>>> > >>> Yes, it is called FUEL and it is a standard part of the >>>> image. See FLSerializer and FLMaterializer. >>>> > >>> >>>> > >>>> On 13 Oct 2015, at 06:59, Robert Withers >>>> <robert.w.withers(a)gmail.com <mailto:robert.w.withers@gmail.com>> >>>> wrote: >>>> > >>>> >>>> > >>>> Does Pharo have stream classes to binary de/serialize an >>>> object, such that the protocol accepts an object as an argument and >>>> converts it to a byteArray? >>>> > >>>> >>>> > >>>> -- >>>> > >>>> thanks, >>>> > >>>> Robert >>>> > >>>> >>>> > >>> >>>> > >>> >>>> > >> >>>> > > >>>> > > >>>> > >>>> > >>>> >>>> >>>> >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.com >>>> >>> >>> >> >> > -- Mariano http://marianopeck.wordpress.com

Oct. 13, 2015

Re: [Pharo-dev] binary serialization

by Robert Withers

Yes, I meant dynamic substitution on materialization, to use the correct terminology. thanks, Robert On 10/13/2015 11:40 AM, Max Leske wrote: > >> On 13 Oct 2015, at 17:16, Robert Withers <robert.w.withers(a)gmail.com> wrote: >> >> Every extra source helps, thank you. I see how to do non-stream substitutions on materializations, but the documentation did not indicate a way to do non-stream substitutions on serialization. Is it possible? > > I donât understand what you mean by ânon-streamâ. Could you give an example? > >> >> thanks, >> Robert >> >> On 10/13/2015 09:00 AM, Mariano Martinez Peck wrote: >>> Hi Robert, >>> >>> As for the documentation, you have LOTS of tests, you have the chapter >>> Torsten pasted, you have this documentation: >>> http://rmod.inria.fr/web/software/Fuel >>> >>> But also, as for internals, there is a journal paper we wrote: >>> http://rmod.lille.inria.fr/archives/papers/Dias12a-SPE-Fuel.pdf >>> >>> Let us know how it goes, >>> >>> >>> On Tue, Oct 13, 2015 at 6:00 AM, Torsten Bergmann <astares(a)gmx.de >>> <mailto:astares@gmx.de>> wrote: >>> >>> Hi Robert, >>> >>> Also checkout the chapter on Fuel in Pharo Enterprise book: >>> >>> https://ci.inria.fr/pharo-contribution/view/Books/job/EnterprisePharoBook/l… >>> >>> Bye >>> Torsten >>> >>> > Gesendet: Dienstag, 13. Oktober 2015 um 09:44 Uhr >>> > Von: "Robert Withers" <robert.w.withers(a)gmail.com >>> <mailto:robert.w.withers@gmail.com>> >>> > An: pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org> >>> > Betreff: Re: [Pharo-dev] binary serialization >>> > >>> > Yes, I have to do object substitutions. Thanks for the link! >>> > >>> > thanks, >>> > Robert >>> > >>> > On 10/13/2015 03:43 AM, Max Leske wrote: >>> > > >>> > >> On 13 Oct 2015, at 09:40, Robert Withers >>> <robert.w.withers(a)gmail.com <mailto:robert.w.withers@gmail.com>> wrote: >>> > >> >>> > >> Sven and Torsten, that's a binary serialization library! It >>> will take time to learn it and how to use mappers. >>> > >> >>> > >> What is the format; is it language neutral? >>> > > >>> > > For quick serialization you donât need to do anything. It works >>> for (almost) all objects. Only if you want to exclude things or >>> treat some objects in a special way, you will need to do some stuff. >>> > > >>> > > Documentation: http://rmod.inria.fr/web/software/Fuel. >>> > > >>> > > >>> > >> >>> > >> thanks, >>> > >> Robert >>> > >> >>> > >> On 10/13/2015 01:21 AM, Sven Van Caekenberghe wrote: >>> > >>> Yes, it is called FUEL and it is a standard part of the >>> image. See FLSerializer and FLMaterializer. >>> > >>> >>> > >>>> On 13 Oct 2015, at 06:59, Robert Withers >>> <robert.w.withers(a)gmail.com <mailto:robert.w.withers@gmail.com>> wrote: >>> > >>>> >>> > >>>> Does Pharo have stream classes to binary de/serialize an >>> object, such that the protocol accepts an object as an argument and >>> converts it to a byteArray? >>> > >>>> >>> > >>>> -- >>> > >>>> thanks, >>> > >>>> Robert >>> > >>>> >>> > >>> >>> > >>> >>> > >> >>> > > >>> > > >>> > >>> > >>> >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >> > >

Oct. 13, 2015

Re: [Pharo-dev] binary serialization

by Robert Withers

Hi Max, Yes, I was referring to this page: http://rmod.inria.fr/web/software/Fuel/Version1.9/Documentation/Customizing…, though I had it backwards (and thought I might have) and got confused as the example is about a stream. I meant that this page demonstrates a way to register a substitution rule with the analyzer on serialization, rather than implement #fuelAccepts: with a mapper. I do not see a use with the analyzer on materialization. Is there such? thanks, Robert On 10/13/2015 11:40 AM, Max Leske wrote: > >> On 13 Oct 2015, at 17:16, Robert Withers <robert.w.withers(a)gmail.com> wrote: >> >> Every extra source helps, thank you. I see how to do non-stream substitutions on materializations, but the documentation did not indicate a way to do non-stream substitutions on serialization. Is it possible? > > I donât understand what you mean by ânon-streamâ. Could you give an example? > >> >> thanks, >> Robert >> >> On 10/13/2015 09:00 AM, Mariano Martinez Peck wrote: >>> Hi Robert, >>> >>> As for the documentation, you have LOTS of tests, you have the chapter >>> Torsten pasted, you have this documentation: >>> http://rmod.inria.fr/web/software/Fuel >>> >>> But also, as for internals, there is a journal paper we wrote: >>> http://rmod.lille.inria.fr/archives/papers/Dias12a-SPE-Fuel.pdf >>> >>> Let us know how it goes, >>> >>> >>> On Tue, Oct 13, 2015 at 6:00 AM, Torsten Bergmann <astares(a)gmx.de >>> <mailto:astares@gmx.de>> wrote: >>> >>> Hi Robert, >>> >>> Also checkout the chapter on Fuel in Pharo Enterprise book: >>> >>> https://ci.inria.fr/pharo-contribution/view/Books/job/EnterprisePharoBook/l… >>> >>> Bye >>> Torsten >>> >>> > Gesendet: Dienstag, 13. Oktober 2015 um 09:44 Uhr >>> > Von: "Robert Withers" <robert.w.withers(a)gmail.com >>> <mailto:robert.w.withers@gmail.com>> >>> > An: pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org> >>> > Betreff: Re: [Pharo-dev] binary serialization >>> > >>> > Yes, I have to do object substitutions. Thanks for the link! >>> > >>> > thanks, >>> > Robert >>> > >>> > On 10/13/2015 03:43 AM, Max Leske wrote: >>> > > >>> > >> On 13 Oct 2015, at 09:40, Robert Withers >>> <robert.w.withers(a)gmail.com <mailto:robert.w.withers@gmail.com>> wrote: >>> > >> >>> > >> Sven and Torsten, that's a binary serialization library! It >>> will take time to learn it and how to use mappers. >>> > >> >>> > >> What is the format; is it language neutral? >>> > > >>> > > For quick serialization you donât need to do anything. It works >>> for (almost) all objects. Only if you want to exclude things or >>> treat some objects in a special way, you will need to do some stuff. >>> > > >>> > > Documentation: http://rmod.inria.fr/web/software/Fuel. >>> > > >>> > > >>> > >> >>> > >> thanks, >>> > >> Robert >>> > >> >>> > >> On 10/13/2015 01:21 AM, Sven Van Caekenberghe wrote: >>> > >>> Yes, it is called FUEL and it is a standard part of the >>> image. See FLSerializer and FLMaterializer. >>> > >>> >>> > >>>> On 13 Oct 2015, at 06:59, Robert Withers >>> <robert.w.withers(a)gmail.com <mailto:robert.w.withers@gmail.com>> wrote: >>> > >>>> >>> > >>>> Does Pharo have stream classes to binary de/serialize an >>> object, such that the protocol accepts an object as an argument and >>> converts it to a byteArray? >>> > >>>> >>> > >>>> -- >>> > >>>> thanks, >>> > >>>> Robert >>> > >>>> >>> > >>> >>> > >>> >>> > >> >>> > > >>> > > >>> > >>> > >>> >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >> > >

Oct. 13, 2015

Re: [Pharo-dev] building the pharo-vm failed

by Robert Withers

Alright, I'll keep that in mind. thanks, Robert On 10/13/2015 09:58 AM, Ben Coman wrote: > On Tue, Oct 13, 2015 at 6:29 AM, Robert Withers > <robert.w.withers(a)gmail.com> wrote: >> I am trying to build the vm and I got an error during make, listed at the >> bottom is one item that had error, but there were many conflicting types >> errors. > > hi Robert, > > Good to see your success building the vm. btw, for any vm related > discussion, its a good idea to also copy to [vm-dev] list. > http://lists.squeakfoundation.org/mailman/listinfo/vm-dev > > cheers -ben >

Oct. 13, 2015

Re: [Pharo-dev] [Reflectivity] Object invalidate now works

by Marcus Denker

> On 09 Oct 2015, at 13:47, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hi, > > The mechanism that is behind the MetaLinks is now working for Object 50378: > > Object methods do: #createTwin. > Object methods do: #invalidate. > > This means we are very close on having that working on the whole image. > > Next steps: > > -> invalidate the whole kernel. Done. in 50384: Object package methods do: [ :method | method createTwin. method invalidate]. Marcus

Oct. 13, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50384 Home: https://github.com/pharo-project/pharo-core

Oct. 13, 2015