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

Re: [Pharo-project] The monkey is back in town

by Camillo Bruni

Sources are in my smalltalkhub repository: http://smalltalkhub.com/#!/~dh83/ci On 2012-12-05, at 06:28, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > Le 05/12/2012 04:43, Camillo Bruni a Ã©crit : >> I had a sudden urge to program something so I revived the monkey (partly) >> >> - full smalltalk implementation (no more ruby) >> - basic command line handler (could be better but works..) > >> - using OSProcess with FileSystem-Legacy in 2.0 > > So that would be the way to have OSProcess in 2.0? more or less: there is another deprecation warning coming from `Smalltalk osVersion` but it works... You can check the ConfigurationOfCI to see how to include it from http://smalltalkhub.com/#!/~dh83/fisleg >> the only thing missing are the couple of changes I proposed for the main image: >> >> - http://code.google.com/p/pharo/issues/detail?id=7097 >> - http://code.google.com/p/pharo/issues/detail?id=7096 >> - http://code.google.com/p/pharo/issues/detail?id=7095 >> >> once they are in, we're ready to roll >> cami on fernet

Dec. 5, 2012

Re: [Pharo-project] [update 2.0] #20428

by Camillo Bruni

thanks marcus! On 2012-12-05, at 03:49, Marcus Denker <marcus.denker(a)inria.fr> wrote: > 20428 > ----- > > Issue 7097: VirtualMachine class improvements > http://code.google.com/p/pharo/issues/detail?id=7097 > > Issue 7095: Add GoferResolvedReference >> #merge method > http://code.google.com/p/pharo/issues/detail?id=7095 > > Issue 7096: Better option protocol for CommandLineHandler > http://code.google.com/p/pharo/issues/detail?id=7096 > > Issue 7094: Removing some Object methods > http://code.google.com/p/pharo/issues/detail?id=7094 > > > Diff information: > http://ss3.gemstone.com/ss/Pharo20/Tools-MarcusDenker.997.diff > http://ss3.gemstone.com/ss/Pharo20/Tests-MarcusDenker.487.diff > http://ss3.gemstone.com/ss/Pharo20/System-Support-MarcusDenker.752.diff > http://ss3.gemstone.com/ss/Pharo20/System-CommandLine-MarcusDenker.65.diff > http://ss3.gemstone.com/ss/Pharo20/Morphic-MarcusDenker.1297.diff > http://ss3.gemstone.com/ss/Pharo20/Kernel-MarcusDenker.1263.diff > http://ss3.gemstone.com/ss/Pharo20/Gofer-Core-MarcusDenker.189.diff > >

Dec. 5, 2012

[Pharo-project] PetitSmalltalk: portable number parsing

by Frank Shearar

I've attached a fix to PetitParser, using Number class >> #readSmalltalkSyntaxFrom: instead of Number class >> #readFrom:. The former selector makes clear the intention of reading a Smalltalk number. The latter selector means something slightly different in at least one Smalltalk: in Squeak, Number class >> #readFrom: is more "user facing" in the sense that it accepts a range of number representations that are not valid syntax. This change has no impact for Pharo because it has this selector: http://code.google.com/p/pharo/issues/detail?id=2063 (thanks to Nicolas Cellier). This fix makes PetitSmalltalk's tests all pass in Squeak. frank

Dec. 5, 2012

Re: [Pharo-project] Some Object methods that could be removed ?

by Sven Van Caekenberghe

On 05 Dec 2012, at 11:05, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > If the same holds true for the % of objects that are methods, you would probably remove around 90% depending on usage pattern during that particular week. Of course, just because there are no users doesn't mean that a method should be removed. But there is just too much cruft on Object, SequenceableCollection, String, Integer, .. that does not belong there. At least many of these less general methods should be packages as extensions. I am also sure that by 'using the image for a week', Camillo also meant running all tests, as well as building and running tests for major Pharo clients (@Stephan). Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Dec. 5, 2012

[Pharo-project] Some Object methods that could be removed ?

by Stephan Eggermont

A better way would be to get all source from all the repositories and extract all method sends and symbols, compare that to the list you'd want to remove and mark the packages you don't want to be able to load anymore. You'd still miss some, but at least get a much better idea of impact Stephan

Dec. 5, 2012

Re: [Pharo-project] Some Object methods that could be removed ?

by Henrik Sperre Johansen

On 04.12.2012 17:54, Camillo Bruni wrote: > On the same topic. > > Do we have a VM that marks methods as they are executed? > > We should really do a cleaning session by running an image for a week or so > and remove all methods that are unused! > That's an ... overly optimistic view :) http://www.youtube.com/watch?feature=player_detailpage&v=yxqkzSbKhF8#t=270s If the same holds true for the % of objects that are methods, you would probably remove around 90% depending on usage pattern during that particular week. I'd imaging the influx of #doesNotUnderstand issues in the tracker would be quite impressive though :P Cheers, Henry

Dec. 5, 2012

Re: [Pharo-project] Vim Keys?

by Goubier Thierry

Le 03/12/2012 23:17, Sean P. DeNigris a Ã©crit : > Goubier Thierry wrote >> the removal of the global, class-linked maps (it was rejected)... >> This is the only step missing for your vim shortcuts to work. > > Yes!!! That's exactly what was holding me up... From > http://forum.world.st/Keymapping-Class-vs-Instance-Targets-tp4639863p464022… > : What I introduced is kind of what you are asking : - An initialization method in a Morph which adds default maps to the KMDispatcher instance, called #initializeShortcuts:. Its called when the KMDispatcher instance is created. It is used by the focus navigation, which loads the #MorphFocusCtrlNavigation category. But I didn't remember that conversation when I did it :( Thierry > Sean P. DeNigris wrote >> >> Guillermo Polito wrote >>> - static shortcuts (per class) >>> - dynamic category shortcuts ( you build a category and attach it to an >>> instance) >> The thing is that these two conflict. If I add a category to a class in >> the "static shortcuts" (which I consider to be "default shortcuts" - I >> think that's more useful), and then I want to remove that category for an >> instance, I can't. >> >> What I want is: each instance gets its own copy of all its maps. If the >> morph instance doesn't have any per-instance customizations, this can >> point to the class defaults to save space (but I think this would be >> premature optimization). However, as soon as the instance differs at all >> from the class defaults, it /must/ have it's own local copy of all the >> maps. I don't want to have to override each shortcut of a category >> attached to the class. I want to detach the category /for just this >> instance/. > > > > > > -- > View this message in context: http://forum.world.st/Re-Vim-Keys-tp4657381p4657920.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Dec. 5, 2012

Re: [Pharo-project] The monkey is back in town

by Goubier Thierry

Le 05/12/2012 04:43, Camillo Bruni a Ã©crit : > I had a sudden urge to program something so I revived the monkey (partly) > > - full smalltalk implementation (no more ruby) > - basic command line handler (could be better but works..) > - using OSProcess with FileSystem-Legacy in 2.0 So that would be the way to have OSProcess in 2.0? Thierry > the only thing missing are the couple of changes I proposed for the main image: > > - http://code.google.com/p/pharo/issues/detail?id=7097 > - http://code.google.com/p/pharo/issues/detail?id=7096 > - http://code.google.com/p/pharo/issues/detail?id=7095 > > once they are in, we're ready to roll > cami on fernet > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Dec. 5, 2012

Re: [Pharo-project] The monkey is back in town

by Pavel Krivanek

Cool, where can we found source code of the monkey? -- Pavel On Wed, Dec 5, 2012 at 4:43 AM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > I had a sudden urge to program something so I revived the monkey (partly) > > - full smalltalk implementation (no more ruby) > - basic command line handler (could be better but works..) > - using OSProcess with FileSystem-Legacy in 2.0 > > the only thing missing are the couple of changes I proposed for the main image: > > - http://code.google.com/p/pharo/issues/detail?id=7097 > - http://code.google.com/p/pharo/issues/detail?id=7096 > - http://code.google.com/p/pharo/issues/detail?id=7095 > > once they are in, we're ready to roll > cami on fernet

Dec. 5, 2012

Re: [Pharo-project] An excellent news

by Jordi Delgado

Great!! Bests, Jordi > Hi guys > > We mentioned it in the past but now this is really official. To support the consortium, Inria is paying one full year > to Igor Stasenko. > > We want to thank Inria for its continuous support. > > Stef

Dec. 5, 2012