September 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Status of Alien FFI

by Ken Treis

On Sep 16, 2009, at 1:06 AM, Johan Brichau wrote: > I separated the extensions to the Parser (necessary to load the > primitive methods) into a separate package Alien-Prereqs. > If you load Alien-Prereqs before Alien-Core, it will work. Thanks Johan, that's good news here. I appreciate it. Given that Alien requires modifications to the core parser, and that the Alien-modified parser is backwards-compatible with the base parser... is there any chance we can get the Alien modifications into the base? Without that, Pharo software updates that touch parser code will end up reverting the code in Alien-Prereqs, right? -- Ken Treis Miriam Technologies, Inc.

Sept. 16, 2009

[Pharo-project] [ANN] New Pharo based on core 10453 - Win32 Installer

by astares＠gmx.de

is up on the download page. So it is easy to walk on the beach, see: http://www.dzone.com/links/walk_on_the_beach_in_10_minutes.html Have fun T. -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

Sept. 16, 2009

Re: [Pharo-project] Morph extension

by Gary Chambers

Hopefully I've not missed anything... I have noticed that a fileout from the change sorter doesn't appear to write out any methods that are in *-override categories... at least that's how it seems (might be another problem!). Regards, Gary ----- Original Message ----- From: "Henrik Johansen" <henrik.s.johansen(a)veloxit.no> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Wednesday, September 16, 2009 3:56 PM Subject: Re: [Pharo-project] Morph extension > Me too! > Both actorState and player in MorphExtension are now unused btw, if > you decided to put them there you might as well remove those two at > the same time :) > > Cheers, > Henry > > On Sep 16, 2009, at 4:43 43PM, Marcus Denker wrote: > >> >> On 16.09.2009, at 10:29, Gary Chambers wrote: >> >>> I get a different "top offenders" list of course. >>> I've managed to refactor the worst offenders. >>> >>> Benchmarks for the "opening system browser" below show an >>> improvement. >>> >>> Going from patched to unpatched shows that the unpatched takes >>> between 15% >>> and 20% longer to complete depending on fonts/theme. >>> >>> (Benchmark code) >>> >>> | saveMorphs time | >>> [saveMorphs := World submorphs. >>> World removeAllMorphs."heh, heh" >>> time := [1 to: 10 do: [:i | >>> MorphicToolBuilder new open: >>> (Browser new setClass: SystemDictionary selector: nil). >>> World doOneCycleNow]. >>> World submorphs do: [:m | m delete. World doOneCycleNow]. >>> ] timeToRun] ensure:[World addAllMorphs: saveMorphs]. >>> SystemWindow noteTopWindowIn: World. >>> time >>> >>> (end of benchmark code) >>> >>> I can make a changeset available for the brave who want to try. >> >> Yes, I would like to try! >> >> Marcus >> >> >> >> >> -- >> Marcus Denker - http://marcusdenker.de >> PLEIAD Lab - Computer Science Department (DCC) - University of Chile >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 16, 2009

Re: [Pharo-project] Morph extension

by Henrik Johansen

Me too! Both actorState and player in MorphExtension are now unused btw, if you decided to put them there you might as well remove those two at the same time :) Cheers, Henry On Sep 16, 2009, at 4:43 43PM, Marcus Denker wrote: > > On 16.09.2009, at 10:29, Gary Chambers wrote: > >> I get a different "top offenders" list of course. >> I've managed to refactor the worst offenders. >> >> Benchmarks for the "opening system browser" below show an >> improvement. >> >> Going from patched to unpatched shows that the unpatched takes >> between 15% >> and 20% longer to complete depending on fonts/theme. >> >> (Benchmark code) >> >> | saveMorphs time | >> [saveMorphs := World submorphs. >> World removeAllMorphs."heh, heh" >> time := [1 to: 10 do: [:i | >> MorphicToolBuilder new open: >> (Browser new setClass: SystemDictionary selector: nil). >> World doOneCycleNow]. >> World submorphs do: [:m | m delete. World doOneCycleNow]. >> ] timeToRun] ensure:[World addAllMorphs: saveMorphs]. >> SystemWindow noteTopWindowIn: World. >> time >> >> (end of benchmark code) >> >> I can make a changeset available for the brave who want to try. > > Yes, I would like to try! > > Marcus > > > > > -- > Marcus Denker - http://marcusdenker.de > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 16, 2009

Re: [Pharo-project] Morph extension

by Andres Valloud

OOoohhh... I remember doing similar hacks in Squeak... it's been quite a while since I was familiar with the code, but I thought I'd mention this in case it helps. Today, I get the impression that, more than properties, what morphs need are policy objects. In that way, acting as a response to a property becomes an unconditional message send to a policy object (as opposed to retrieve + valueOrNil check + ifTrue:ifFalse: + and then do something). Particularly with a PIC-capable VM, this should speed up execution (even without PICs, I'd guess even an IC-capable VM should have no problem making this run reasonably fast). But... I am not that familiar with Morphic right now. Would policy objects be a good idea for today's state of affairs? Andres. StÃ©phane Ducasse wrote: > Gary I would love to see morphic goes faster so we are ready to try :) > > Stef > > >> I've managed to refactor the worst offenders. >> >> Benchmarks for the "opening system browser" below show an improvement. >> >> Going from patched to unpatched shows that the unpatched takes >> between 15% >> and 20% longer to complete depending on fonts/theme. >> >> (Benchmark code) >> >> | saveMorphs time | >> [saveMorphs := World submorphs. >> World removeAllMorphs."heh, heh" >> time := [1 to: 10 do: [:i | >> MorphicToolBuilder new open: >> (Browser new setClass: SystemDictionary selector: nil). >> World doOneCycleNow]. >> World submorphs do: [:m | m delete. World doOneCycleNow]. >> ] timeToRun] ensure:[World addAllMorphs: saveMorphs]. >> SystemWindow noteTopWindowIn: World. >> time >> >> (end of benchmark code) >> >> I can make a changeset available for the brave who want to try. >> I have developed a workspace script that (finally) appears to load it >> correctly, >> waas a lot of hung-image before getting there... >> >> (loading tested on 10451-BETA) >> >> Regards, Gary >> >> ----- Original Message ----- >> From: "Henrik Johansen" <henrik.s.johansen(a)veloxit.no> >> To: <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Tuesday, September 08, 2009 7:01 PM >> Subject: Re: [Pharo-project] Morph extension >> >> >> >> >> StÃ©phane Ducasse skrev: >> >>> On Sep 8, 2009, at 5:32 PM, Gary Chambers wrote: >>> >>> >>> >>>> After some experimenting I can get over 10% perfromance improvement >>>> with >>>> window operations when fillStyle; borderStyle; hResizing; vResizing >>>> are >>>> made as instance variables of Morph, rather than going through >>>> extension. >>>> >>>> >>> this is a lot. >>> You really mean Morph or we could get them in subclasses too. >>> >>> >>> >> Inspect this in an image with some windows open, it will give you the >> percentage of morphs with otherProperties containing any given >> property: >> >> |propBag noMorphs| >> propBag := Bag new: 50. >> noMorphs := 0. >> Morph allSubInstances do: [:each | each otherProperties ifNotNil: >> [:props | propBag addAll: props keys. >> noMorphs := noMorphs +1]] . >> noMorphs := noMorphs asFloat. >> propBag sortedCounts collect: [:each | each key: each key / noMorphs; >> yourself] >> >> >> otherProperties is heavily abused. with respectively 98 and 125 >> senders >> of valueOfProperty: / valueOfProperty:ifAbsent:... >> In my case there were _57_ different distinct otherProperties in >> use, an >> average of three, a maximum of 15, and four of them present in over a >> quarter of morphs defining any (80% for the most common one)... >> If moving directly to Morph is a bit extreme, at least _some_ of these >> qualify for promotion to direct access in MorphExtension imho, it >> seems >> to have some "free" instvars anyways after the removal of players. >> >> In the interest of seeing which would benefit the most from moving, I >> did a small profile: >> - Dragging a window and switching some between different ones with 2 >> browsers, a monticello browser, a workspace and a Method search open. >> I had the following access numbers: >> 105586->#clipSubmorphs (about 4.5 per millisecond) >> 66029->#layoutProperties >> 62783->#layoutPolicy >> 55556->#theme >> 41312->#hasDropShadow >> 41310->#hasRolloverBorder >> 36817->#fillStyle >> 19241->#cornerStyle >> 13239->#highlightedForDrop >> 13239->#highlightedForMouseDown >> 11945->#roundedCorners >> 11911->#borderStyle >> 10644->#edgeToAdhereTo >> 9020->#paneColor >> 8885->#lastPaneColor >> [rest below 5000 accesses] >> >> Cheers, >> Henry >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > . > >

Sept. 16, 2009

Re: [Pharo-project] Morph extension

by Gary Chambers

Have a go with it (use a fresh image rather than anything you might want to lose...). Stick the .cs in your image directory, open a workspace and do the following... (FileStream readOnlyFileNamed: 'MorphicExtensionPerformance.1.cs') fileInSilentlyAnnouncing: nil. Morph allSubInstances do: [:m | #(fillStyle layoutPolicy layoutFrame layoutProperties borderStyle cornerStyle actionMap clipSubmorphs) do: [:prop | m extension ifNotNilDo: [:extension | extension otherProperties ifNotNilDo: [:otherProperties | extension instVarNamed: prop put: ( otherProperties at: prop ifAbsent: []). otherProperties removeKey: #prop ifAbsent: []]]]] Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Wednesday, September 16, 2009 3:49 PM Subject: Re: [Pharo-project] Morph extension Gary I would love to see morphic goes faster so we are ready to try :) Stef > > > I've managed to refactor the worst offenders. > > Benchmarks for the "opening system browser" below show an improvement. > > Going from patched to unpatched shows that the unpatched takes > between 15% > and 20% longer to complete depending on fonts/theme. > > (Benchmark code) > > | saveMorphs time | > [saveMorphs := World submorphs. > World removeAllMorphs."heh, heh" > time := [1 to: 10 do: [:i | > MorphicToolBuilder new open: > (Browser new setClass: SystemDictionary selector: nil). > World doOneCycleNow]. > World submorphs do: [:m | m delete. World doOneCycleNow]. > ] timeToRun] ensure:[World addAllMorphs: saveMorphs]. > SystemWindow noteTopWindowIn: World. > time > > (end of benchmark code) > > I can make a changeset available for the brave who want to try. > I have developed a workspace script that (finally) appears to load it > correctly, > waas a lot of hung-image before getting there... > > (loading tested on 10451-BETA) > > Regards, Gary > > ----- Original Message ----- > From: "Henrik Johansen" <henrik.s.johansen(a)veloxit.no> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Tuesday, September 08, 2009 7:01 PM > Subject: Re: [Pharo-project] Morph extension > > > > > StÃ©phane Ducasse skrev: >> On Sep 8, 2009, at 5:32 PM, Gary Chambers wrote: >> >> >>> After some experimenting I can get over 10% perfromance improvement >>> with >>> window operations when fillStyle; borderStyle; hResizing; vResizing >>> are >>> made as instance variables of Morph, rather than going through >>> extension. >>> >> >> this is a lot. >> You really mean Morph or we could get them in subclasses too. >> >> > Inspect this in an image with some windows open, it will give you the > percentage of morphs with otherProperties containing any given > property: > > |propBag noMorphs| > propBag := Bag new: 50. > noMorphs := 0. > Morph allSubInstances do: [:each | each otherProperties ifNotNil: > [:props | propBag addAll: props keys. > noMorphs := noMorphs +1]] . > noMorphs := noMorphs asFloat. > propBag sortedCounts collect: [:each | each key: each key / noMorphs; > yourself] > > > otherProperties is heavily abused. with respectively 98 and 125 > senders > of valueOfProperty: / valueOfProperty:ifAbsent:... > In my case there were _57_ different distinct otherProperties in > use, an > average of three, a maximum of 15, and four of them present in over a > quarter of morphs defining any (80% for the most common one)... > If moving directly to Morph is a bit extreme, at least _some_ of these > qualify for promotion to direct access in MorphExtension imho, it > seems > to have some "free" instvars anyways after the removal of players. > > In the interest of seeing which would benefit the most from moving, I > did a small profile: > - Dragging a window and switching some between different ones with 2 > browsers, a monticello browser, a workspace and a Method search open. > I had the following access numbers: > 105586->#clipSubmorphs (about 4.5 per millisecond) > 66029->#layoutProperties > 62783->#layoutPolicy > 55556->#theme > 41312->#hasDropShadow > 41310->#hasRolloverBorder > 36817->#fillStyle > 19241->#cornerStyle > 13239->#highlightedForDrop > 13239->#highlightedForMouseDown > 11945->#roundedCorners > 11911->#borderStyle > 10644->#edgeToAdhereTo > 9020->#paneColor > 8885->#lastPaneColor > [rest below 5000 accesses] > > Cheers, > Henry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 16, 2009

Re: [Pharo-project] Usability improvements for the class browser:buttons

by Gary Chambers

The separation of the window control buttons (red, amber, green) is currently dependent upon the font chosen for the window tiltle. As for the browser buttons it would be relatively little effort to make then look like the attached image. Regards, Gary ----- Original Message ----- From: "Stephan Eggermont" <stephan(a)stack.nl> To: <pharo-project(a)lists.gforge.inria.fr> Sent: Wednesday, September 16, 2009 3:35 PM Subject: [Pharo-project] Usability improvements for the class browser:buttons > Hello, > > When I open a class browser in a Pharo Image (10418 updated to 10451) > with the default Watery 2 theme, the window is visually dominated by the > button bar. Compared to the other parts of the window, it has too much > vertical height and there is not enough white space around the buttons. > > The problem with vertical height can be illustrated by looking at the > precision needed to select a class category versus that needed to click > the browse button. The button has about twice the vertical height. > That would be ok when clicking the button would be the more common > operation, but I don't find that to be the case. > > The kind of button used in Watery 2 only works well visually when it > has a rather large white space around it. The button bar of the > preference > browser already works much better than that of the class browser, > but even that has too little space above and below. > > The buttons in the button bar of the class browser feel very heavy > because > they don't have enough horizontal separation. With the default window > size, there is not enough space for the needed separation. When the > window is grown, instead of growing the separation first, and then the > button width, only the button width is grown. Some operating systems > have introduced a better solution for this problem, a dedicated button > bar. > Attached is an impression of how this could look. I hope you'd agree > that it would provide a cleaner look. I'd be interested in some clues on > what would be needed to add such a button bar. > > The red, orange, and green window buttons used to have a much better > horizontal separation. I am not sure in which update they were put so > close together, but they need at least as much horizontal separation as > the space from left window border to the first (red) button. > > Stephan Eggermont > > > -------------------------------------------------------------------------------- > > > > -------------------------------------------------------------------------------- > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 16, 2009

Re: [Pharo-project] Author name prompt window is too big

by StÃ©phane Ducasse

open a ticket and submit your code. Give two significative example would be good (and we do not want . or _ anyway) This was on my todo but skipped my mind. Stef On Sep 16, 2009, at 4:15 PM, Oscar Nierstrasz wrote: > > Today I was giving a Pharo demo, using a slightly larger than standard > font. > > When I tried to commit a change, the prompt for my user name was > bigger than the available screen space on my laptop. Luckily I could > still type, though I could not see what I was typing. > > Can we please modify Author>>messagePrompt to use a *short* message? > The existing one is ridiculously large. > > Author>>messagePrompt > ^ > 'Please type your name. It will be used to sign the changes you make > to the image. > Try to write an ASCII approximation of your name with only alphabetic > characters > and avoiding, if possible, spaces, accents, dashes and similar > characters. > Examples (The prefered form is the first one of each name): > > Miguel CobÃ¡ -> MiguelCoba > Miguel CobÃ¡ -> miguel.coba > Miguel CobÃ¡ -> miguel_coba > GÃ¶ran Krampe -> GoranKrampe > GÃ¶ran Krampe -> GoeranKrampe > GÃ¶ran Krampe -> goran.krampe > GÃ¶ran Krampe -> goran_krampe > Vincent van Gogh -> VincentVanGogh > StÃ©phane DUCASSE -> StephaneDucasse > StÃ©phane DUCASSE -> stephane.ducasse > Yoshiki Oshima -> YoshikiOshima > Yoshiki Oshima -> yoshiki.oshima > ' > > The first example would be good enough. > > - on > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 16, 2009

Re: [Pharo-project] Morph extension

by StÃ©phane Ducasse

Gary I would love to see morphic goes faster so we are ready to try :) Stef > > > I've managed to refactor the worst offenders. > > Benchmarks for the "opening system browser" below show an improvement. > > Going from patched to unpatched shows that the unpatched takes > between 15% > and 20% longer to complete depending on fonts/theme. > > (Benchmark code) > > | saveMorphs time | > [saveMorphs := World submorphs. > World removeAllMorphs."heh, heh" > time := [1 to: 10 do: [:i | > MorphicToolBuilder new open: > (Browser new setClass: SystemDictionary selector: nil). > World doOneCycleNow]. > World submorphs do: [:m | m delete. World doOneCycleNow]. > ] timeToRun] ensure:[World addAllMorphs: saveMorphs]. > SystemWindow noteTopWindowIn: World. > time > > (end of benchmark code) > > I can make a changeset available for the brave who want to try. > I have developed a workspace script that (finally) appears to load it > correctly, > waas a lot of hung-image before getting there... > > (loading tested on 10451-BETA) > > Regards, Gary > > ----- Original Message ----- > From: "Henrik Johansen" <henrik.s.johansen(a)veloxit.no> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Tuesday, September 08, 2009 7:01 PM > Subject: Re: [Pharo-project] Morph extension > > > > > StÃ©phane Ducasse skrev: >> On Sep 8, 2009, at 5:32 PM, Gary Chambers wrote: >> >> >>> After some experimenting I can get over 10% perfromance improvement >>> with >>> window operations when fillStyle; borderStyle; hResizing; vResizing >>> are >>> made as instance variables of Morph, rather than going through >>> extension. >>> >> >> this is a lot. >> You really mean Morph or we could get them in subclasses too. >> >> > Inspect this in an image with some windows open, it will give you the > percentage of morphs with otherProperties containing any given > property: > > |propBag noMorphs| > propBag := Bag new: 50. > noMorphs := 0. > Morph allSubInstances do: [:each | each otherProperties ifNotNil: > [:props | propBag addAll: props keys. > noMorphs := noMorphs +1]] . > noMorphs := noMorphs asFloat. > propBag sortedCounts collect: [:each | each key: each key / noMorphs; > yourself] > > > otherProperties is heavily abused. with respectively 98 and 125 > senders > of valueOfProperty: / valueOfProperty:ifAbsent:... > In my case there were _57_ different distinct otherProperties in > use, an > average of three, a maximum of 15, and four of them present in over a > quarter of morphs defining any (80% for the most common one)... > If moving directly to Morph is a bit extreme, at least _some_ of these > qualify for promotion to direct access in MorphExtension imho, it > seems > to have some "free" instvars anyways after the removal of players. > > In the interest of seeing which would benefit the most from moving, I > did a small profile: > - Dragging a window and switching some between different ones with 2 > browsers, a monticello browser, a workspace and a Method search open. > I had the following access numbers: > 105586->#clipSubmorphs (about 4.5 per millisecond) > 66029->#layoutProperties > 62783->#layoutPolicy > 55556->#theme > 41312->#hasDropShadow > 41310->#hasRolloverBorder > 36817->#fillStyle > 19241->#cornerStyle > 13239->#highlightedForDrop > 13239->#highlightedForMouseDown > 11945->#roundedCorners > 11911->#borderStyle > 10644->#edgeToAdhereTo > 9020->#paneColor > 8885->#lastPaneColor > [rest below 5000 accesses] > > Cheers, > Henry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 16, 2009

Re: [Pharo-project] Fwd: Universes? or Metacello meta repository

by StÃ©phane Ducasse

Mike Yes this is a good idea. read the blog of dale. We are starting to manage all our project Moose, Mondrian, Glamour with metacello I'm waiting that doru and dale release a version with fixed api to write a chapter for Pharo by example2 Stef On Sep 16, 2009, at 1:59 PM, Michael Robers wrote: > I am interested in learning how we could use metacello. Not for 1.0. > Before we commit to it for 1.1 I think we would need to conduct an > experiment in parallel to get a feel for it. We should also review the > other proposals. Then commit to one proposal for 1.1 1.2 etc and make > the process work. Or we could stall 1.1 until we have a process in > place but I think we will still have fixes coming in we will not want > a lag. What do you think? > > Cheers > Mike > > On 16 Sep 2009, at 10:24, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > >> Hi >> >> I value the idea that when we look for a software (for example SIXX) >> we can find a version that is working. In the past we used Universes >> and >> if was successful. >> We cannot not have squeakmap and universe at the same time. >> I discussed with damien briefly about that and he told me that we >> coud >> have >> a metacello alternative. >> Now I wonder if for pharo 1.0 it makes sense. >> May be having a nice Universe for pharo would be good and important. >> >> Dale what do you think? >> Do you see metacello working in the story (may be for 1.1)? >> Stef >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 16, 2009