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

Re: [Pharo-dev] GetOpt

by stepharo

I liked that you propose yourself also to edit the zeroConf chapter. Thanks. I must admit that I'M FED UP to feel the only one with Sven that seems to be able to write a documentation in our wonderful community. So at least changes should be retrofitted in the available doc. Do not worry LaTex is easy and we will probably convert Deep into Pharo into Pillar. Stef Le 2/12/14 09:37, Esteban Lorenzano a Ã©crit : > 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 :) > > thanks phil. > > Esteban > >> On 02 Dec 2014, at 08:45, phil(a)highoctane.be >> <mailto:phil@highoctane.be> wrote: >> >> I have made Ian Piumarta's GST GetOpt work in Pharo 3.0 >> >> See: >> >> http://www.smalltalkhub.com/#!/~philippeback/GetOpt >> <http://www.smalltalkhub.com/#%21/%7Ephilippeback/GetOpt> >> >> Nice tool even if we have some other support in CommandLineHandlers. >> But for a quick parameters setting in your own CommandLineHandler, it >> is fast to use and easy to debug. >> >> Phil >> >> >> >

Dec. 5, 2014

[pharo-project/pharo-core]

by GitHub

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

Dec. 5, 2014

[pharo-project/pharo-core] d5c6eb: 40400

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: d5c6eb2010fdff8d389e4a67eaa9cd586142c93c https://github.com/pharo-project/pharo-core/commit/d5c6eb2010fdff8d389e4a67… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-12-05 (Fri, 05 Dec 2014) Changed paths: A Collections-Strings.package/String.class/class/instance creation/loremIpsum.st A Collections-Strings.package/String.class/class/instance creation/loremIpsum_.st A CollectionsTests.package/StringTest.class/instance/testing - instance creation/testLoremIpsum.st A CollectionsTests.package/StringTest.class/instance/testing - instance creation/testLoremIpsum2048.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script400.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40400.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Examples.package/ScrollSyncExample.class/instance/private/loremIpsum.st Log Message: ----------- 40400 14571 Add String class>>#loremIpsum constant and dynamically sized filler text feature https://pharo.fogbugz.com/f/cases/14571 http://files.pharo.org/image/40/40400.zip

Dec. 5, 2014

RBSmalllintContext>>primitiveComputerLiterals

by Ben Coman

I just noticed RBSmalllintContext>>primitiveComputerLiterals doesn't seem to follow the typical pattern for that naming convention. Without digging to really understand it, I just wondered if it maybe should be called #computeLiteralsForPrimitive, or #basicComputerLiterals, or something else... cheers -ben

Dec. 5, 2014

Re: [Pharo-dev] Monticello and Fuel

by Thierry Goubier

2014-12-05 14:07 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > 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. > > > 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. > What is the state of that for, say, Pharo 4? > > >> 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. > They can be adapted. You can also pile up notifications (well, you can't at the moment, but it would be nice) and have a way to merge them. Such optimisations are also usefull for heavy code generators such as SmaCC. > > 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. > Which is what I wanted to know :) > > 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/ > Thanks for the links! > > 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 ;) > When, in the profile, the observers appear and you can optimize that. One of the way is to have a single central point (i.e. whatever the number of Nautilus instances opened, you send to a singleton), then memoize all queries you do on RPackage and friends before firing again notifications for the views (relevant package, class, etc..). In short, you have the thing. Thierry

Dec. 5, 2014

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