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

Re: [Pharo-project] 'primitive has failed' in MultiByteFileStream while running update

by StÃ©phane Ducasse

Thanks boris which image did you use? A pharo core or a pharo-dev? Stef On Jul 22, 2009, at 7:20 PM, Boris Popov wrote: > Iâm new to Pharo, so one of the first things I tried was to go > System->Software update, which results in the attached error after a > while, > > Pharo0.1 > Latest update: #10379 > Squeak VM 3.11.3 (beta) from Jul 10 2009 > > Also, why is debug.log using Mac EOL convention on a Windows machine? > > Thanks! > > -Boris > > -- > +1.604.689.0322 > DeepCove Labs Ltd. > 4th floor 595 Howe Street > Vancouver, Canada V6C 2T5 > http://tinyurl.com/r7uw4 > > boris(a)deepcovelabs.com > > CONFIDENTIALITY NOTICE > > This email is intended only for the persons named in the message > header. Unless otherwise indicated, it contains information that is > private and confidential. If you have received it in error, please > notify the sender and delete the entire message including any > attachments. > > Thank you. > > <debug.log><systeminfo.txt> > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 22, 2009

Re: [Pharo-project] Show stopper network bug on Windows

by Igor Stasenko

This is a squeakdebug.log lines: (again, it fails for me only if i never issue the #initializeNetwork after image startup before using #localHostName) ------- Error: a primitive has failed 22 July 2009 10:41:57 pm VM: Win32 - IX86 - NT - Squeak3.10.2 of '5 June 2008' [latest update: #7179] Image: Pharo0.1 [Latest update: #10371] SecurityManager state: Restricted: false FileAccess: true SocketAccess: true Working Dir **** Trusted Dir **** Untrusted Dir **** NetNameResolver class(Object)>>error: Receiver: NetNameResolver Arguments and temporary variables: aString: 'a primitive has failed' ... <snip> ... NetNameResolver class>>primHostNameSize -------------- 2009/7/22 Igor Stasenko <siguctua(a)gmail.com>: > Okay, then i think it is better to move this thread on vm-dev list (to > notify VM devs about this bug), because it seems a VM bug, not > image-side bug. > > I just tested it on my WinXP + VM (dated 27 march 2009 - not sure what > version is) > and it indeed failing if i do > NetNameResolver localHostName > and not do: > NetNameResolver initializeNetwork > before. > > But once i did initialization, all subsequent requests is ok. > > 2009/7/22 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: >> Sig, >> >> Respectfully, I do not agree that the current situation is elegant. Â There are other ways to cope with a disabled plugin (see #useOldNetwork), and littering code with #initializeNetwork is error prone and wasteful in its own way, no matter how lean the method might be. >> >> This looks to me like an anachronism. Â There was no better mechanism, so a workaround had to suffice. Â Now with weak collections and events, it should be possible to do better. Â If those things do not work well, then they need to be challenged and fixed as appropriate. >> >> The lack of fully qualified names could easily be a windows stupidity. Â My Dolphin code for lookups has long been a little complicated: look up this, clear that, do it again, and it always seemed that I was fighting lack of imagination from the general direction of Redmond WA - who would have thought that possible? :) Â My favorite was win2k from (IIRC) pre-sp3: the only machine one could not find by name was the local host! >> >> Bill >> >> >> -----Original Message----- >> From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko >> Sent: Tuesday, July 21, 2009 11:02 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Show stopper network bug on Windows >> >> 2009/7/22 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: >>> Sig, >>> >>> Queue veryLoudHeadSlap.wav - however, that is not a fix for it on Linux. Â Also, on Windows, I am not getting the fully qualified name, which is another problem. Â It also helps make the case for formalized session management, as the image should know when it has had its first cup of coffee (the vm can inform it). >>> >> Usually, all code , working with sockets , sending #initializeNetwork, to be sure it is initialized: >> >> Socket>>newTCP: family >> Â Â Â Â "Create a socket and initialise it for TCP" >> Â Â Â Â self initializeNetwork. >> Â Â Â Â ^[ super new initialize: TCPSocketType family: family ] >> Â Â Â Â Â Â Â Â repeatWithGCIf: [ :socket | socket isValid not ] >> >> --------- >> Socket>>initializeNetwork >> Â Â Â Â "Initialize the network drivers and the NetNameResolver. Do nothing if the network is already initialized." >> Â Â Â Â "Note: The network must be re-initialized every time Squeak starts up, so applications that persist across snapshots should be prepared to re-initialize the network as needed. Such applications should call 'Socket initializeNetwork' before every network transaction. " >> >> Â Â Â Â NetNameResolver initializeNetwork >> ---------- >> another way could be just add the #startUp method and initialize network there. >> But i think that current solution is more elegant, because if your image never using the network, it will never initialize the plugin and in this way, preserve some resources. >> And , of course , there could be the cases, where VMs built without network support, or running with disabled networking security setting (for sandboxing). In these cases this primitive (as well as rest of socket prims) will fail. >> >> As for retreiving a fully qualified name - can't give you answer right now. I think it can be answered by Andreas, who added the ipv6 support recently to Windoze VM platform code. >> >>> Bill >>> >>> >>> >>> -----Original Message----- >>> From: pharo-project-bounces(a)lists.gforge.inria.fr >>> [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor >>> Stasenko >>> Sent: Tuesday, July 21, 2009 6:53 PM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] Show stopper network bug on Windows >>> >>> Guys, see my comment on that issue.: >>> #localHostName should not be used before #initializeNetwork. >>> >>> Hope it helps. >>> >>> _______________________________________________ >>> 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 >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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 >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

July 22, 2009

[Pharo-project] Fwd: New version of FastSets released

by StÃ©phane Ducasse

So soon in our nice smalltalk :) Begin forwarded message: > From: Ralph Boland <rpboland(a)gmail.com> > Date: July 22, 2009 8:31:36 PM CEDT > To: stephane.ducasse(a)inria.fr > Cc: henrik.s.johansen(a)veloxit.no > Subject: New version of FastSets released > > I have released a new verion of FastSets. > > I changed noCompareAdd: to noCompareOrGrowAddAll:. > Basically this is the modification proposed by Henry J. > Not only is it faster but it is simpler too. > I did not modify the addAll: method though. > I don't believe this change should be part of FastSets > and state no opinion as whether it is a good idea. > > The previous version did not apply FastSets to MethodDictionary. > This is now fixed. > > The previous did not apply FastSets to most of the rehash > methods. This is now fixed. > > I also added the public method nastyAddNew:. > > I also wrote an intersection: method for Sets which uses > nastyAddNew: > and, partly because of this, is faster than the method inherited from > Collection. > > I added some additional SUnit tests but did not attempt to add the > many missing SUnit tests for subclasses of Set. > > Of course I can no longer state that I have used this code since > Squeak 3.6 > so testing is much more of an issue. I filed my project (100,000 > lines of code) > into a clean image and ran it without problems and ran the > SUnit tests. That's about it for my testing. > > I will delay announcing the release for a day or two. > If you want to check it out and propose further changes then > I can make them or give permission for Henry or someone else > to make them. > > By the way, to see the perfomance improvement in terms of the number > of compares try: "ComparesCountingSet example". > There is a comment in class FastSetsComment useful for anyone > wanting to use FastSets or integrate it into a base image. > > Back to my own project (which uses FastSets of course). > > Ralph Boland

July 22, 2009

Re: [Pharo-project] Show stopper network bug on Windows

by Igor Stasenko

Okay, then i think it is better to move this thread on vm-dev list (to notify VM devs about this bug), because it seems a VM bug, not image-side bug. I just tested it on my WinXP + VM (dated 27 march 2009 - not sure what version is) and it indeed failing if i do NetNameResolver localHostName and not do: NetNameResolver initializeNetwork before. But once i did initialization, all subsequent requests is ok. 2009/7/22 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Sig, > > Respectfully, I do not agree that the current situation is elegant. Â There are other ways to cope with a disabled plugin (see #useOldNetwork), and littering code with #initializeNetwork is error prone and wasteful in its own way, no matter how lean the method might be. > > This looks to me like an anachronism. Â There was no better mechanism, so a workaround had to suffice. Â Now with weak collections and events, it should be possible to do better. Â If those things do not work well, then they need to be challenged and fixed as appropriate. > > The lack of fully qualified names could easily be a windows stupidity. Â My Dolphin code for lookups has long been a little complicated: look up this, clear that, do it again, and it always seemed that I was fighting lack of imagination from the general direction of Redmond WA - who would have thought that possible? :) Â My favorite was win2k from (IIRC) pre-sp3: the only machine one could not find by name was the local host! > > Bill > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko > Sent: Tuesday, July 21, 2009 11:02 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Show stopper network bug on Windows > > 2009/7/22 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: >> Sig, >> >> Queue veryLoudHeadSlap.wav - however, that is not a fix for it on Linux. Â Also, on Windows, I am not getting the fully qualified name, which is another problem. Â It also helps make the case for formalized session management, as the image should know when it has had its first cup of coffee (the vm can inform it). >> > Usually, all code , working with sockets , sending #initializeNetwork, to be sure it is initialized: > > Socket>>newTCP: family > Â Â Â Â "Create a socket and initialise it for TCP" > Â Â Â Â self initializeNetwork. > Â Â Â Â ^[ super new initialize: TCPSocketType family: family ] > Â Â Â Â Â Â Â Â repeatWithGCIf: [ :socket | socket isValid not ] > > --------- > Socket>>initializeNetwork > Â Â Â Â "Initialize the network drivers and the NetNameResolver. Do nothing if the network is already initialized." > Â Â Â Â "Note: The network must be re-initialized every time Squeak starts up, so applications that persist across snapshots should be prepared to re-initialize the network as needed. Such applications should call 'Socket initializeNetwork' before every network transaction. " > > Â Â Â Â NetNameResolver initializeNetwork > ---------- > another way could be just add the #startUp method and initialize network there. > But i think that current solution is more elegant, because if your image never using the network, it will never initialize the plugin and in this way, preserve some resources. > And , of course , there could be the cases, where VMs built without network support, or running with disabled networking security setting (for sandboxing). In these cases this primitive (as well as rest of socket prims) will fail. > > As for retreiving a fully qualified name - can't give you answer right now. I think it can be answered by Andreas, who added the ipv6 support recently to Windoze VM platform code. > >> Bill >> >> >> >> -----Original Message----- >> From: pharo-project-bounces(a)lists.gforge.inria.fr >> [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor >> Stasenko >> Sent: Tuesday, July 21, 2009 6:53 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Show stopper network bug on Windows >> >> Guys, see my comment on that issue.: >> #localHostName should not be used before #initializeNetwork. >> >> Hope it helps. >> >> _______________________________________________ >> 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 >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > 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 > -- Best regards, Igor Stasenko AKA sig.

July 22, 2009

Re: [Pharo-project] Author class

by Alexandre Bergel

> This package, in the last core image is modified but not commited so > when following the steps > from the HowToContribute wiki page, in the part of creating a mcz > package with the change the mcz > generate will include the other uncommited changes. Should I use a > changeset instead in order to not > commit changes that I don't want? First, you should update your image. It should be a core. Your change must be produced for Core. Then, implement your fixe. If more than one package is touched, then produce a slice. You should save your fix in PharoInbox using Monticello. Last step, make sure your fix load in a fresh and updated core image; add an issue in the google website; send an email to the mailing list. > What is the goal with the Author class? A reification of author. Authors should not be strings passed around. > Author has name and initials, what will be the intended use of them? It is true that we should not use initials anymore, but essentially for legacy purpose, we cannot remove them. We could envision future version of the class Author that includes email, squeak source account, ... > I can unify all the message sends to Author in the core image, also I > can unify the initials and name usage, but > I need to know the intended goal for this class. The only use of Author is for managing the name/initial used in the .changes and monticello. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

July 22, 2009

[Pharo-project] Author class

by Miguel CobÃ¡

I'm fixing a bug in the world menu -> System -> Preferences -> "set author initials". Questions? The package it is Morphic, the class is TheWorldMenu. This package, in the last core image is modified but not commited so when following the steps from the HowToContribute wiki page, in the part of creating a mcz package with the change the mcz generate will include the other uncommited changes. Should I use a changeset instead in order to not commit changes that I don't want? What is the goal with the Author class? I can see that the Utilities methods that used to be use to set author name and initials are being replaced with calls to Author. Also, they are deprecated in Utilities. Questions: Author has name and initials, what will be the intended use of them? By previous mails in the list I remember that Pharo doesn't want to use initials (like mcm, lr, avi) but full name as hinted by the message prompt in the Author requestName. But then initials will have exactly the same that name in the author class? I can unify all the message sends to Author in the core image, also I can unify the initials and name usage, but I need to know the intended goal for this class. What is the goal? Cheers, Miguel CobÃ¡

July 22, 2009

Re: [Pharo-project] [ANN] Dependency Browser update

by Simon Denier

Hi Hernan That's a pretty neat tool, very professional. I would vote for its inclusion in an extended Pharo for developers. But you know what would be even cooler? If you can take into account the explicit dependencies of Monticello packages and highlight in red those non-system packages which are not explicitly declared as dependencies i.e. packages which would failed if loaded in a fresh image because of missing implicit dependencies. On 4 mai 09, at 01:39, HernÃ¡n Morales Durand wrote: > Dear all, > I've updated the Dependency Browser package and documentation, take > a look here: > > http://cs.hernanmorales.com.ar/projects/dependencyBrowser/DBrowser-en.php > > Quick install if you have OmniBrowser and Installer packages loaded: > > | dwInstaller | > dwInstaller := Installer ss project: 'DependencyWalker'. > dwInstaller > install: 'DependencyWalker'; > install: 'OBDependencyWalker'; > install: 'DWTraitsFix'. > ( Smalltalk version beginsWith: 'Squeak' ) > ifTrue: [ dwInstaller install: 'OBDWMethodNodeFix' ] > > Cheers. > > HernÃ¡n > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Simon

July 22, 2009

Re: [Pharo-project] [ANN] 10388 new core image released

by Esteban A. Maringolo

2009/7/22 Mariano Martinez Peck <marianopeck(a)gmail.com>: > On Wed, Jul 22, 2009 at 5:02 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: >> On Jul 22, 2009, at 19:47 , Mariano Martinez Peck wrote: >> > I wasn't aware of Â ScriptLoader>>cleanUpForProduction Â but looks very >> > useful! >> >> Its just a start. My idea is to have, in addition to >> cleanUpForRelease, an secondary cleanup/shrink procedure that is more >> aggressive. > Wonderful!! something like VAST packager and the reduce feature? After having walked the shrink path both using VAST and Dolphin, I rather choose the explicit packaging method of VisualSmalltalk SLL (Smalltalk Linked Library). It is... to declare what to include, its results are deterministic. However I really celebrate this "production oriented" solutions, it's what Pharo is meant to do. Best regards, Esteban.

July 22, 2009

Re: [Pharo-project] [ANN] 10388 new core image released

by Adrian Lienhard

On Jul 22, 2009, at 20:10 , Mariano Martinez Peck wrote: > On Wed, Jul 22, 2009 at 5:02 PM, Adrian Lienhard <adi(a)netstyle.ch> > wrote: > >> On Jul 22, 2009, at 19:47 , Mariano Martinez Peck wrote: >> >>> I wasn't aware of ScriptLoader>>cleanUpForProduction but looks >>> very >>> useful! >> >> Its just a start. My idea is to have, in addition to >> cleanUpForRelease, an secondary cleanup/shrink procedure that is more >> aggressive. > > > Wonderful!! something like VAST packager and the reduce feature? I don't know VAST. If you have suggestions to further shrink the image, let me know. Adrian ___________________ http://www.adrian-lienhard.ch/

July 22, 2009

Re: [Pharo-project] [ANN] 10388 new core image released

by Mariano Martinez Peck

On Wed, Jul 22, 2009 at 5:02 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > On Jul 22, 2009, at 19:47 , Mariano Martinez Peck wrote: > > > I wasn't aware of ScriptLoader>>cleanUpForProduction but looks very > > useful! > > Its just a start. My idea is to have, in addition to > cleanUpForRelease, an secondary cleanup/shrink procedure that is more > aggressive. Wonderful!! something like VAST packager and the reduce feature? > While cleanUpForRelease just deletes data, > cleanUpForProduction will also remove code, like tests (at the moment > this does not properly work since the tests are not yet well packaged). > Yes, I saw. Right now it is doing this: (MCPackage named: 'Tests') unload. After evaluating this message my image was reduced in 3MB. > > Adrian > > > > > Thanks, > > > > Mariano > > > > On Wed, Jul 22, 2009 at 4:41 PM, Damien Cassou <damien.cassou(a)gmail.com > > >wrote: > > > >> thank you, that was fast. > >> > >> On Wed, Jul 22, 2009 at 6:59 PM, StÃ©phane > >> Ducasse<stephane.ducasse(a)inria.fr> wrote: > >>> Issue 637: Undeclared ProjectNavigationMorph > >>> FFI updated in ScriptLoader > >>> Better comment of the process > >>> - isFontAvailable fix > >>> - Remove check for higherPerformance in doOneCycleFor: (preference > >>> to > >>> be removed in a second step) > >>> Issue 943: fix polymorph cursor > >>> Polymorph > >>> Fix for colouring of submenu markers. > >>> W2K Improvements. > >>> Fix for drop-list button label in W2K theme. > >>> Support for adjustment of label inset for buttons when > >>> pressed. > >>> Added #setColor: to ColorPresenterMorph to enable use > >>> without a > >> model. > >>> > >>> Quit gets back its normal behavior > >>> > >>> Issue 944: SUnit assert:equals > >>> SUnit assert equals + better feedback message > >>> Issue 947: Deprecation is broken after sprint > >>> http://code.google.com/p/pharo/issues/detail?id=947 > >>> > >>> Deprecate some more Utilities methods > >>> - Gofer script loader :) > >>> > >>> - removing some methods of Project and friends (the eternal battle) > >>> - Issue 948: Mantis 7361: bug 0.5 >= (1/2) > >>> > >>> - remove PackageInfo from MessageSet methodsFor: > >>> methodDisplayStringForClass: class selector: sel > >>> - Henrik speedup > >>> > >>> - TextMorph handleInteraction uses self editor > >>> Issue 348: UIManager enhacements 2 - Part one > >>> Issue 348: UIManager enhacements 2 - Part Two > >>> - ClosureTests expectedFailures > >>> - MethodFinder, SelectorBrowser, ThreadSafeTranscript > >>> - Move JoystickMorph to MorphicExtras package > >>> - Remove a couple of references to Squeak in strings (like > >>> SqueakDebug.log -> PharoDebug.log) > >>> - ScriptLoader>>#cleanUpForProduction > >>> - delete unused bitmaps in ScriptingSystem > >>> Issue 443: Adrian and I have spent some time on fixing the bug. A > >>> fix > >>> has been produced: > >>> - Kernel-adrian_lienhard.358 in PharoInbox > >>> - Traits-Alexandre_Bergel.285 contains a test > >>> Missing part > >>> added a test that pinpoint why the checkSanity fails. > >>> Pair programmed with Andreas L.'. > >>> - Issue 962: remove BlockArgsNode KeyWordNode > >>> - Issue 463: SmallDictionary should not be a subclass of Set (and > >>> Dictionary) > >>> cleaner SmallDictionary + more tests > >>> - removing RBSmallDictionaryTests and > >> MethodDictionaryTestBis > >>> - Issue 964: Better Message Tally > >>> Thanks to Juan Vuletich and CUIS > >>> - Detangle MorphicExtras and extract package to external > >>> SqueakSource > >>> project (PharoMorphicExtras). > >>> -Fixing fixing fixing collection tests now they are all greeeeeeen > >>> stef and cyrille > >>> -Fixing message tally ObservedProcess > >>> - fix Host* tests > >>> - integrate hash functions from Cryptography (MIT licensed) > >>> - remove VersionHistory and VersionNumber'. > >>> Issue 937: [fix] remove some unimplemented calls from > >>> BalloonEngine > >>> Issue 888: LongTestCase is unpackaged > >>> Issue 962: remove BlockArgsNode KeyWordNode > >>> Issue 894: Browser>>copyClass is lost > >>> Issue 960: unused methods in MethodDictionary > >>> Issue 898: MessageNotUnderstood: UndefinedObject>>something > >>> > >>> _______________________________________________ > >>> Pharo-project mailing list > >>> Pharo-project(a)lists.gforge.inria.fr > >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >>> > >> > >> > >> > >> -- > >> Damien Cassou > >> http://damiencassou.seasidehosting.st > >> > >> "Lambdas are relegated to relative obscurity until Java makes them > >> popular by not having them." James Iry > >> > >> _______________________________________________ > >> 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 >

July 22, 2009