- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] GetOpt

by stepharo

IMO all that needs to be fine is to take a careful look at start-up and eliminate costly but unnecessary activities. You should easily be able to get startup times down to tens if milliseconds on modem hardware. I always wanted to have a pharoDaemon.

Dec. 5, 2014

Re: [Pharo-dev] GetOpt

by stepharo

Can you be more concrete because I like what Camillo designed. Le 2/12/14 16:06, Sean P. DeNigris a Ã©crit : > EstebanLM wrote >> is cool. >> I would like to explore the possibility to replace our command line parser >> with getopt. You knowâ¦ is more compatible at the end :) > I find the implementation of our command line handlers very confusing. It > seems like it grew organically from a smaller idea and the design got out of > control. There are many assumptions that can make it hard to extend, > especially to combine multiple options, as Ben and I discovered when > implementing the "don't run startup scripts" handler. It would be nice to > revisit starting from a behavioral specification. > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/GetOpt-tp4793474p4793621.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

Dec. 5, 2014

Re: [Pharo-dev] Glamour-core maybe missing from Pharo40/main

by stepharo

Le 3/12/14 10:08, Marcus Denker a Ã©crit : > Yes, seemingly we lost again the repos of external packages... this is > a bug, something in the integraton process resets the reopsitories. Yes because else we can have dangling refs (you remember the mess in Squeak3.9). Now this is why we should have package metadata in the image because we could just reset the repo to their package. > > On Sat, Nov 29, 2014 at 7:53 AM, Ben Coman <btc(a)openinworld.com > <mailto:btc@openinworld.com>> wrote: > > > Sometimes when I am hacking around the system, I use Monticello to > review just what I've changed. > > In build 40390, I did a <Changes> > of Glamour-Core (BernardoContreras.286) against Pharo40/main and > got _lots_ of changes. Then it seems that this package is not in > Pharo40/main. Should it be? > > Maybe this is because its an external package - but then its > repository is not listed? > > cheers -ben > > > >

Dec. 5, 2014

Re: [Pharo-dev] 12854 TestRunner>>categorySelected hard coded zero

by stepharo

sometimes this is because when you click on the other list you need to reset or something like that? Le 2/12/14 16:07, Ben Coman a Ã©crit : > > Anyone know why TestRunner>>categorySelected was hard coded to return > zero? It breaks shift-click multiple selection in TestRunner. > > Seems we've lived with it a long time... > * Version info --> "lr 10/31/2005 15:11" > > btw, SystemReporter>>categorySelected method is identical > * Hardcoded to return zero > * Version info --> "lr 10/31/2005 15:11" > > maybe one class was copied to the other? > > cheers -ben > > Fix submitted... > https://pharo.fogbugz.com/default.asp?12854 > >

Dec. 5, 2014

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

by stepharo

Hi Juraj Excellent. I would like to have a nice way to import ttf and install not an horrible method full of binary data but a method that load a ttf and that creates font description directly. And as Pharo we should have a simple font ttf file server. Stef Le 2/12/14 15:02, Juraj Kubelka a Ã©crit : > I am not sure if I follow the discussion, but next week I am planning to extract embedded fonts and make a new embedded provider. The current solution I have made recently is too tight, there are cyclic dependencies between free font type provider and embedded fonts and it causes problems. > > Cheers, > Juraj > >> On Dec 2, 2014, at 9:36 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> Esteban, >> >> Did you look/read what Juraj Kubelka did ? >> >> Like this issue, but there are others too: >> >> https://pharo.fogbugz.com/f/cases/13967 >> >> I vaguely remember he found something wrt initialization, maybe Marcus remembers. >> >> Sven >> >>> On 02 Dec 2014, at 13:10, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>> â¦ and I lost fonts again :( >>> I made an integration and fonts got lostâ¦ Iâm reviving issue, and working on it :( >>> >>> Esteban >>> >>>> On 02 Dec 2014, at 12:47, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>> >>>>> On 02 Dec 2014, at 12:12, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>>> >>>>>> On 02 Dec 2014, at 12:02, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>>> >>>>>> >>>>>>> On 02 Dec 2014, at 11:46, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>>>>> >>>>>>> There is no Source Code Sans :). There is only "Source Sans Pro" or "Source Code Pro". >>>>>> Yes, right now in the latest 4.0. >>>>>> >>>>>> But there used to be a different one, that is the one I am using, see screenshot (http://www.google.com/fonts/specimen/Open+Sans) I don't remember where I got it from (Igor is the author), but I have been using it for months. >>>>> no, it was me the authorâ¦ and it was a mistake I made first time thatâs why I removed it (but I can package it and put it somewhere anywayâ¦ I was even thinking on create a âFont Repositoryâ where put different fonts, until I found this: http://smalltalkhub.com/#!/~girba/FreeFonts which is a cool repo, but does not works completely along our versionâ¦ we will need to merge :P) >>>> Maybe it would be even better if there was code in the image to make these embedded fonts yourself (or a comment). >>>> >>>>>> My question was, why choose one above the other ? >>>>> I replaced it with the Source Sans Pro because same family fonts works better together (Source * Pro) >>>> OK. It seems to have a smaller width, we'll see. >>>> >>>>> cheers, >>>>> Esteban >>>>> >>>>>> <Screen Shot 2014-12-02 at 11.57.13.png> >>>>>> >>>>>>> Doru >>>>>>> >>>>>>> On Tue, Dec 2, 2014 at 11:35 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>>>> What is the difference between 'Open Sans' and 'Source Code Sans' ? >>>>>>> >>>>>>> I am using the former in my 3.0 image, and I like it a bit more, it seems a bit wider. >>>>>>> >>>>>>>> On 02 Dec 2014, at 11:27, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>>>>>> >>>>>>>> Great! >>>>>>>> >>>>>>>> Doru >>>>>>>> >>>>>>>> p.s. Finally :) >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Dec 2, 2014 at 9:48 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> We changed the default fonts in Pharo for the ones that are used normally in Moose. >>>>>>>> They are: Source Sans Pro and Source Code Pro. >>>>>>>> We needed to do it for several reasons: >>>>>>>> >>>>>>>> 1) TxText (the new text model) is cairo based, and cairo just can work with real fonts, so we need them as default (now we will be able to integrate TxText and start the replace of old editors) >>>>>>>> 2) Current fonts takes too much space and do not scales fine (at least that Iâve been told) >>>>>>>> >>>>>>>> So, well, thatâ¦ you will see âsomething differentâ when you download latest image version :) >>>>>>>> >>>>>>>> cheers, >>>>>>>> Esteban >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> www.tudorgirba.com >>>>>>>> >>>>>>>> "Every thing has its own flow" >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> www.tudorgirba.com >>>>>>> >>>>>>> "Every thing has its own flow" >> > >

Dec. 5, 2014

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