December 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] default fonts changed in Pharo 4.0

by stepharo

It would be good to avoid to duplicate the font description as binary and the font description as object. It would be nice to also have a nice way to import font from the ttf description files. This is what we should put on a server not pharo method containaing binary that after creates object and create duplication. Stef

Dec. 5, 2014

How can I specify the bindings when evaluating an expression?

by stepharo

I would like to be able to express Compiler new bindings: { a -> 3. b -> 4}; evaluate: 'a + b'; result and get 7 How can I do that? Stef

Dec. 5, 2014

Re: [Pharo-dev] Monticello and Fuel

by Sven Van Caekenberghe

> On 05 Dec 2014, at 14:09, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > Mariano > http://marianopeck.wordpress.com Hey Mariano, Welcome back ! (Not that you left, but I read your latest blog entry) We miss(ed) your expertise and your work. Regards, Sven

Dec. 5, 2014

Re: [Pharo-dev] Monticello and Fuel

by Mariano Martinez Peck

On Fri, Dec 5, 2014 at 10:07 AM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Fri, Dec 5, 2014 at 6:55 AM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> I will summon Martin and Mariano here :). >> >> Introducing fuel in the loading infrastructure had so far AFAIK two >> different experimental setups: >> - tanker: a package completely written in fuel >> > > This one is the one I explain below. > > >> - mixing tanker/fuel with monticello. >> >> > I think here you mean an experiment where we serialized the little thing > MC serializes currently in the data file... > We found that that serialization/materialization is INSIGNIFICANT in the > export/import process. > > > Ok... so.. > > Indeed: Tanker. > Fuel is able to serialize methods, classes etc... (but not by default). So > what Tanker does it kind of serialize a whole package (with internal > classes, extension methods, etc) as a fuel file. And then, at the import, > it materializes and then runs a lot of stuff besides the materialization > itself. The idea was NOT to use the Compiler at all at import time, because > that is/was one of the bottleneck when importing packages with Metacello. > The compiler was not needed most of the times, so performance was much > better. However, there were cases (like instVars changed in superclasses > where we are importing) etc.. that causes that we needed to RE-Compile or > stored methods because otherwise the instVar offsets were wrong. This, > COULD be solved this the intermediate representation of Opal and to avoid a > normal compilation. However, I don't remember us doing that. I think we > ended up using the compiler for that scenario. But I am not sure. > > >> However, the results were not so promising I remember. Apparently when >> loading a package, most of the time is spent not in the >> deserialization/recompilation but in the update of the system (system >> dictionary, categories, rpackages, update the corresponding subclass >> relationships). >> > > Exactly. The ones we found that took most of the time was: > > 1) Compiling (could be solved with Fuel and even more if we can fix some > scenarios with Opal) > 2) Notification of created methods/classes. One way to solve this is by > having bulk notifications where we notify a list rather than a single > object. But we should also adapt the observers. > 3) #become: when updating/migrating existing instances. > I forgot to said...this one could be improved once the new VM Eliot is doing has the lazy become.. So.... adapting Tanker to use Opal to avoid compilation in special cases, having a bulk notification and update a few observers (like test runner or nautilus), and a lazy become... that would bring a incredible change. > > But...just to see that there is a light in the tunnel, I showed at... mmm > ESUG or PharoConf or.. how to load WHOLE seaside in 10 seconds...which in > my machine takes like 20 minutes. > > Tanker was originally called "FuelPackageLoader" and was then renamed. > Some useful links with details: > > > http://marianopeck.wordpress.com/2012/08/11/tanker-transporting-packages-wi… > http://marianopeck.wordpress.com/2012/09/28/new-tanker-current-status/ > > http://marianopeck.wordpress.com/2012/04/28/building-pharo-from-pharokernel… > http://marianopeck.wordpress.com/tag/tanker/ > > http://vimeo.com/63122424 > > > >> >> Just try the following: load a monticello package with (a) no Nautilus >> opened, and with (a) 10 Nautilus opened. >> >> > Exactly!!! Sometimes the slowdown of the notifications is not in the > observable but on the observers ;) > > > > > >> I let Martin and Mariano give the details :). >> >> On Fri, Dec 5, 2014 at 9:28 AM, Thierry Goubier < >> thierry.goubier(a)gmail.com> wrote: >> >>> >>> >>> 2014-12-05 8:35 GMT+01:00 Max Leske <maxleske(a)gmail.com>: >>> >>>> >>>> > On 05 Dec 2014, at 08:02, Norbert Hartl <norbert(a)hartl.name> wrote: >>>> > >>>> > >>>> > >>>> > >>>> >> Am 04.12.2014 um 23:31 schrieb Thierry Goubier < >>>> thierry.goubier(a)gmail.com>: >>>> >> >>>> >> Hi all, >>>> >> >>>> >> I'm just wondering. >>>> >> >>>> >> Would it work to have a package format based on Fuel? >>>> >> >>>> > I doubt it would work cross platform. I don't know how fuel >>>> serializes WideString, LargePositiveInteger, BoxedFloat64. These differ >>>> between smalltalk platforms. The source as string solves that. Strings are >>>> written as unicode string and numbers as certain number format etc. >>>> >>>> True. Cross dialect loading isnât something we encourage to do with >>>> Fuel. >>>> >>>> @Thierry >>>> You said something about partial loading: that will never be possible >>>> with Fuel because of its pickle format. To select any partial graph you >>>> have to first read the entire file and rebuild the graph first (ok, you >>>> donât strictly have to build the graph but you still need to read the >>>> entire file). >>>> >>> >>> Hum. I was thinking of partial loading at the application level, not at >>> the marshalling level. >>> >>> The process of cutting out Monticello packages versions ancestry in >>> Pharo releases come to mind as a ... how should I say that ... We >>> can/should do better (additionally, because if the mcz isn't available >>> somewhere, having its ref its useless). >>> >>> Thierry >>> >>> >>>> >>>> > >>>> > Norbert >>>> > >>>> >> Would that make loading faster? >>>> >> >>>> >> Does it already exist? >>>> >> >>>> >> Thanks, >>>> >> >>>> >> Thierry >>>> > >>>> >>>> >>>> >>> >> > > > -- > Mariano > http://marianopeck.wordpress.com > -- Mariano http://marianopeck.wordpress.com

Dec. 5, 2014

Re: [Pharo-dev] Monticello and Fuel

by Mariano Martinez Peck

On Fri, Dec 5, 2014 at 6:55 AM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > I will summon Martin and Mariano here :). > > Introducing fuel in the loading infrastructure had so far AFAIK two > different experimental setups: > - tanker: a package completely written in fuel > This one is the one I explain below. > - mixing tanker/fuel with monticello. > > I think here you mean an experiment where we serialized the little thing MC serializes currently in the data file... We found that that serialization/materialization is INSIGNIFICANT in the export/import process. Ok... so.. Indeed: Tanker. Fuel is able to serialize methods, classes etc... (but not by default). So what Tanker does it kind of serialize a whole package (with internal classes, extension methods, etc) as a fuel file. And then, at the import, it materializes and then runs a lot of stuff besides the materialization itself. The idea was NOT to use the Compiler at all at import time, because that is/was one of the bottleneck when importing packages with Metacello. The compiler was not needed most of the times, so performance was much better. However, there were cases (like instVars changed in superclasses where we are importing) etc.. that causes that we needed to RE-Compile or stored methods because otherwise the instVar offsets were wrong. This, COULD be solved this the intermediate representation of Opal and to avoid a normal compilation. However, I don't remember us doing that. I think we ended up using the compiler for that scenario. But I am not sure. > However, the results were not so promising I remember. Apparently when > loading a package, most of the time is spent not in the > deserialization/recompilation but in the update of the system (system > dictionary, categories, rpackages, update the corresponding subclass > relationships). > Exactly. The ones we found that took most of the time was: 1) Compiling (could be solved with Fuel and even more if we can fix some scenarios with Opal) 2) Notification of created methods/classes. One way to solve this is by having bulk notifications where we notify a list rather than a single object. But we should also adapt the observers. 3) #become: when updating/migrating existing instances. But...just to see that there is a light in the tunnel, I showed at... mmm ESUG or PharoConf or.. how to load WHOLE seaside in 10 seconds...which in my machine takes like 20 minutes. Tanker was originally called "FuelPackageLoader" and was then renamed. Some useful links with details: http://marianopeck.wordpress.com/2012/08/11/tanker-transporting-packages-wi… http://marianopeck.wordpress.com/2012/09/28/new-tanker-current-status/ http://marianopeck.wordpress.com/2012/04/28/building-pharo-from-pharokernel… http://marianopeck.wordpress.com/tag/tanker/ http://vimeo.com/63122424 > > Just try the following: load a monticello package with (a) no Nautilus > opened, and with (a) 10 Nautilus opened. > > Exactly!!! Sometimes the slowdown of the notifications is not in the observable but on the observers ;) > I let Martin and Mariano give the details :). > > On Fri, Dec 5, 2014 at 9:28 AM, Thierry Goubier <thierry.goubier(a)gmail.com > > wrote: > >> >> >> 2014-12-05 8:35 GMT+01:00 Max Leske <maxleske(a)gmail.com>: >> >>> >>> > On 05 Dec 2014, at 08:02, Norbert Hartl <norbert(a)hartl.name> wrote: >>> > >>> > >>> > >>> > >>> >> Am 04.12.2014 um 23:31 schrieb Thierry Goubier < >>> thierry.goubier(a)gmail.com>: >>> >> >>> >> Hi all, >>> >> >>> >> I'm just wondering. >>> >> >>> >> Would it work to have a package format based on Fuel? >>> >> >>> > I doubt it would work cross platform. I don't know how fuel serializes >>> WideString, LargePositiveInteger, BoxedFloat64. These differ between >>> smalltalk platforms. The source as string solves that. Strings are written >>> as unicode string and numbers as certain number format etc. >>> >>> True. Cross dialect loading isnât something we encourage to do with Fuel. >>> >>> @Thierry >>> You said something about partial loading: that will never be possible >>> with Fuel because of its pickle format. To select any partial graph you >>> have to first read the entire file and rebuild the graph first (ok, you >>> donât strictly have to build the graph but you still need to read the >>> entire file). >>> >> >> Hum. I was thinking of partial loading at the application level, not at >> the marshalling level. >> >> The process of cutting out Monticello packages versions ancestry in Pharo >> releases come to mind as a ... how should I say that ... We can/should do >> better (additionally, because if the mcz isn't available somewhere, having >> its ref its useless). >> >> Thierry >> >> >>> >>> > >>> > Norbert >>> > >>> >> Would that make loading faster? >>> >> >>> >> Does it already exist? >>> >> >>> >> Thanks, >>> >> >>> >> Thierry >>> > >>> >>> >>> >> > -- Mariano http://marianopeck.wordpress.com

Dec. 5, 2014

Re: [Pharo-dev] Pharo+Git cons?

by Ben Coman

Thierry Goubier wrote: > > 2014-12-04 23:59 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com > <mailto:eliot.miranda@gmail.com>>: > > I'm also delighted that work like Chris Muller's version server is > out there. This is very nicely integrated to allow me to find out > which package versions contain versions of a particular method or > class definition. > > > I know that this version server exists, and I hoped that you would point > it out, because I believe it is significant. Even if it is not usable in > many professional settings, such as mine. My google fu didn't turn up anything on this in the first few pages. Could you provide a pointer? cheers -ben

Dec. 5, 2014

Re: [Pharo-dev] Semaphore seems to timeout prematurely

by Ben Coman

Jan Vrany wrote: > Hi there, > > I have encountered a situation where semaphore timeouts > prematurely when run in "non-interactive" mode (eval cmdline handler). > > Setup (script prepare.sh) > > 1) Fresh Pharo image (3.0 / 4.0, both exhibits the same behaviour) > 2) Evaluate: > == > Smalltalk at: #WaitBlock put: [:sema :tout | (sema waitTimeoutSeconds: > tout) ifTrue:[ Halt now ] ]. > == > 3. Save image > > Run 1: > 1) Run the image, open workspace > 2) Evaluate: > == > | sema | > sema := Semaphore new. > [ 100 factorial. sema signal ] fork. > (Smalltalk at: #WaitBlock) value: sema value: 60*60. > 'OK' > == > Returns 'OK' as expected (100 factorial should not take more than > hour :-) > > > Run 2 (script test.sh) > 1) The same, but evaluate using command line handler: > ./pharo Test.image eval "\ > | sema |\ > \ > sema := Semaphore new.\ > [ 100 factorial. sema signal ] fork.\ > (Smalltalk at: #WaitBlock) value: sema value: 60*60.\ > 'OK'\ > " > Halt triggers, which is what I would not expect. > > Why is that? Bug? Or Am I missing something obvious? > > Best, Jan Is it like the thread on "Super fast delay" ? http://forum.world.st/Super-fast-delay-td4787257.html I have a fix for Pharo 4 ready to be reviewed... https://pharo.fogbugz.com/default.asp?14353 cheers -ben

Dec. 5, 2014

Re: [Pharo-dev] Monticello and Fuel

by Thierry Goubier

2014-12-05 10:55 GMT+01:00 Guillermo Polito <guillermopolito(a)gmail.com>: > I will summon Martin and Mariano here :). > > Introducing fuel in the loading infrastructure had so far AFAIK two > different experimental setups: > - tanker: a package completely written in fuel > Oh, I missed that one, yes. I remember the name. > - mixing tanker/fuel with monticello. > > Sort of what I'm thinking about. > However, the results were not so promising I remember. Apparently when > loading a package, most of the time is spent not in the > deserialization/recompilation but in the update of the system (system > dictionary, categories, rpackages, update the corresponding subclass > relationships). > > Just try the following: load a monticello package with (a) no Nautilus > opened, and with (a) 10 Nautilus opened. > I profiled AltBrowser for that use case... It's a bit more vulnerable to that than Nautilus because you may see more of the structure at a given time than Nautilus (such as having a single browser watching the methods of two classes). Still, once a bit optimised, MC loading time dominates. But I haven't looked too closely on exactly what; I was focused on getting the browser bit as small as possible. If anybody has things about the various costs, I'd be interested. Thierry

Dec. 5, 2014

Re: [Pharo-dev] Monticello and Fuel

by Guillermo Polito

I will summon Martin and Mariano here :). Introducing fuel in the loading infrastructure had so far AFAIK two different experimental setups: - tanker: a package completely written in fuel - mixing tanker/fuel with monticello. However, the results were not so promising I remember. Apparently when loading a package, most of the time is spent not in the deserialization/recompilation but in the update of the system (system dictionary, categories, rpackages, update the corresponding subclass relationships). Just try the following: load a monticello package with (a) no Nautilus opened, and with (a) 10 Nautilus opened. I let Martin and Mariano give the details :). On Fri, Dec 5, 2014 at 9:28 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 2014-12-05 8:35 GMT+01:00 Max Leske <maxleske(a)gmail.com>: > >> >> > On 05 Dec 2014, at 08:02, Norbert Hartl <norbert(a)hartl.name> wrote: >> > >> > >> > >> > >> >> Am 04.12.2014 um 23:31 schrieb Thierry Goubier < >> thierry.goubier(a)gmail.com>: >> >> >> >> Hi all, >> >> >> >> I'm just wondering. >> >> >> >> Would it work to have a package format based on Fuel? >> >> >> > I doubt it would work cross platform. I don't know how fuel serializes >> WideString, LargePositiveInteger, BoxedFloat64. These differ between >> smalltalk platforms. The source as string solves that. Strings are written >> as unicode string and numbers as certain number format etc. >> >> True. Cross dialect loading isnât something we encourage to do with Fuel. >> >> @Thierry >> You said something about partial loading: that will never be possible >> with Fuel because of its pickle format. To select any partial graph you >> have to first read the entire file and rebuild the graph first (ok, you >> donât strictly have to build the graph but you still need to read the >> entire file). >> > > Hum. I was thinking of partial loading at the application level, not at > the marshalling level. > > The process of cutting out Monticello packages versions ancestry in Pharo > releases come to mind as a ... how should I say that ... We can/should do > better (additionally, because if the mcz isn't available somewhere, having > its ref its useless). > > Thierry > > >> >> > >> > Norbert >> > >> >> Would that make loading faster? >> >> >> >> Does it already exist? >> >> >> >> Thanks, >> >> >> >> Thierry >> > >> >> >> >

Dec. 5, 2014

Re: [Pharo-dev] Monticello and Fuel

by Thierry Goubier

2014-12-05 8:35 GMT+01:00 Max Leske <maxleske(a)gmail.com>: > > > On 05 Dec 2014, at 08:02, Norbert Hartl <norbert(a)hartl.name> wrote: > > > > > > > > > >> Am 04.12.2014 um 23:31 schrieb Thierry Goubier < > thierry.goubier(a)gmail.com>: > >> > >> Hi all, > >> > >> I'm just wondering. > >> > >> Would it work to have a package format based on Fuel? > >> > > I doubt it would work cross platform. I don't know how fuel serializes > WideString, LargePositiveInteger, BoxedFloat64. These differ between > smalltalk platforms. The source as string solves that. Strings are written > as unicode string and numbers as certain number format etc. > > True. Cross dialect loading isn't something we encourage to do with Fuel. > > @Thierry > You said something about partial loading: that will never be possible with > Fuel because of its pickle format. To select any partial graph you have to > first read the entire file and rebuild the graph first (ok, you don't > strictly have to build the graph but you still need to read the entire > file). > Hum. I was thinking of partial loading at the application level, not at the marshalling level. The process of cutting out Monticello packages versions ancestry in Pharo releases come to mind as a ... how should I say that ... We can/should do better (additionally, because if the mcz isn't available somewhere, having its ref its useless). Thierry > > > > > Norbert > > > >> Would that make loading faster? > >> > >> Does it already exist? > >> > >> Thanks, > >> > >> Thierry > > > > >

Dec. 5, 2014