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

Re: [Pharo-project] CogVM as official Pharo VM?

by Martin McClure

On 07/30/2010 11:28 AM, Eliot Miranda wrote: [...] > > Excellent!! Just by curious, your idea, or what you did in VW, was > to be able to put SmallFloats directly inside the address ? just > like we do nowadays with SmallInteger ? > > > Yes. The scheme provides IEEE double precision but with a smaller > exponent so the range is the same as the 32-bit single-precision range. > i.e. 3 bits are used as tag bits to distinguish SmallInteger > SmallFloat Character and objects. That leaves 1 bit for sign, 52 bits > for the mantissa and 8 bits for the exponent. The use of 3 tag bits > comes from 64-bit pointers being 8-byte aligned and so having the least > significant 3 bits 0. I don't want to defend that choice now just to > give you a flavour of the representation: > > | 8-bit exponent | 52 bit mantissa | sign | tags | A few more words on the VW SmallDouble implementation: We also use this representation in GemStone; it works very well. This representation exactly represents a subset of the possible IEEE doubles. It's the "common" 1/8th of the total range, with the addition of +-0.0. Non-zero numbers very close to zero or very far from zero overflow to normal Float objects in a manner very similar to the way SmallInteger/LargeInteger work. The infinities and NaNs also must be represented as normal Floats. Because between SmallDouble and Float all IEEE doubles can be represented, all floating-point computations give the correct (per IEEE) result, but you save memory and computation is generally faster because you don't access as many bytes in main memory. Regards, -Martin

July 30, 2010

Re: [Pharo-project] CogVM as official Pharo VM?

by Tudor Girba

Hi, I can give a hand in testing on Mac as I am using it everyday. Cheers, Doru On 30 Jul 2010, at 05:26, Serge Stinckwich wrote: > 2010/7/29 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> Hi folks. Hope Eliot is reading this thread. >> >> It is time to think in Pharo 1.2 and we need to discuss if we want >> to have >> CogVM as the standard Pharo VM. > > Thank you Mariano this important issue for the future of Pharo. > >> Most of us have tried it and found it incredible fast. So it would >> be very >> good to take advantage of it. But I think there are a couple of >> things to >> be discussed: >> >> 1) Cog VM seems to be aimed for x86 and 32 bits. You can read Eliot >> quotes: >> "The Cog VM is a just-in-time compiler that currently supports only >> x86 >> >> No effort has been made to maintain 64-bit compatibility. >> Apologies, this >> was unaffordable." >> >> So...how much important is this for us? do we care? and if we want >> to do it, >> is it "doable" ? is it less doable than the normal squeak VM ? >> >> I really would like to have 64bits VM + 64bits images in a near >> future...but >> hat's just my thoguhts. >> >> 2) The status of the external plugins. Are they working with Cog ? >> Not only >> the "core plugings" but FFI, OSProcess (I read some problems with >> it), >> TrueType, etc... >> >> 3) Is it stable for production use? For example, I read that with >> seaside >> there are some crashes. > > For crashed related to socket, i know that Noury and Luc are working > on a new implementation of sockets, so maybe if it is ready it could > be included in 1.2 version. > >> 4) Depends on heroes. I never liked this idea. It has nothing to do >> with >> Eliot. He is very cool and helpful. But I wonder, do we understand >> the new >> VM and the changes? are we able to handle and fix it even without >> eliot ? >> >> 5) Integration to VMMaker. I saw that they started to merge cog >> (actually, I >> think only stack vm?) to the trunk of VMMaker. This is really good >> news. I >> hope everything is there and merged. >> >> 6) Binaries. It seems the official released didn't come with >> binaries. So we >> should compile it for each OS. > > I think both binaries should be provided for 1.2 and also OneClick > images with standard and Cog VM, in order to maximize > the number of tests for the new VM. If we really want to push this, > someone should take care of all of this. > > Regards, > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Every DSL ends up being Smalltalk > http://doesnotunderstand.org/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Don't give to get. Just give."

July 30, 2010

Re: [Pharo-project] CogVM as official Pharo VM?

by Eliot Miranda

2010/7/30 Mariano Martinez Peck <marianopeck(a)gmail.com> > > > 2010/7/29 Eliot Miranda <eliot.miranda(a)gmail.com> > > >> >> 2010/7/29 Mariano Martinez Peck <marianopeck(a)gmail.com> >> >> Hi folks. Hope Eliot is reading this thread. >>> >> >> Yes, I'm reading :) >> > > > THanks Eliot for all the answers. It seems they are all good news :) > > >> >> >>> It is time to think in Pharo 1.2 and we need to discuss if we want to >>> have CogVM as the standard Pharo VM. >>> >>> Most of us have tried it and found it incredible fast. So it would be >>> very good to take advantage of it. But I think there are a couple of things >>> to be discussed: >>> >>> 1) Cog VM seems to be aimed for x86 and 32 bits. You can read Eliot >>> quotes: >>> "The Cog VM is a just-in-time compiler that currently supports only x86 >>> >> >> It is only initially aimed at x86. That's the most important platform by >> far from Teleplace's perspective and I suspect the majority of the community >> is on x86. But Cog was designed form the outset to be portable. The Cogit >> is architected to support other ISAs. See CogAbstractInstruction and its >> one subclass CogIA32Compiler. To port to another ISA you should >> subclass CogAbstractInstruction and implement the same protocol >> as CogIA32Compiler. >> >> I would love to see a CogARMCompiler and a CogPPCCompiler and encourage >> anyone with low-level expertise on those platforms to have a go. I'm always >> here to answer questions. >> >> >> > This is great Eliot. I thought that Cog was completly aimed to x86 and > that would be difficult to port. That was my concern, but now with what you > said it is much clear :) > > > > >> No effort has been made to maintain 64-bit compatibility. Apologies, this >>> was unaffordable." >>> >>> So...how much important is this for us? do we care? and if we want to do >>> it, is it "doable" ? is it less doable than the normal squeak VM ? >>> >>> I really would like to have 64bits VM + 64bits images in a near >>> future...but hat's just my thoguhts. >>> >> >> I'm also thinking abut 64-bits but want to do 64-bits with a new object >> representation based on my 64-bit objrep for VisualWorks, which would >> include SmallFloat. Realistically this is a year out, because the 32-bit >> version of the new objrep and the pinning GC need to be implemented before >> I'll be able to do a 64-bit VM. But it's an obvious and logical direction >> to go in. >> > > > Excellent!! Just by curious, your idea, or what you did in VW, was to be > able to put SmallFloats directly inside the address ? just like we do > nowadays with SmallInteger ? > Yes. The scheme provides IEEE double precision but with a smaller exponent so the range is the same as the 32-bit single-precision range. i.e. 3 bits are used as tag bits to distinguish SmallInteger SmallFloat Character and objects. That leaves 1 bit for sign, 52 bits for the mantissa and 8 bits for the exponent. The use of 3 tag bits comes from 64-bit pointers being 8-byte aligned and so having the least significant 3 bits 0. I don't want to defend that choice now just to give you a flavour of the representation: | 8-bit exponent | 52 bit mantissa | sign | tags | > >> 2) The status of the external plugins. Are they working with Cog ? Not >>> only the "core plugings" but FFI, OSProcess (I read some problems with it), >>> TrueType, etc... >>> >> >> ReentrantFFIPlugin (a.k.a. src/plugins/SqueakFFIPrims/SqueakFFIPrims.c) >> should work. But people need to build and test. >> >> 3) Is it stable for production use? For example, I read that with seaside >>> there are some crashes. >>> >> >> Well, it is the production VM at Teleplace so at least for one context the >> answer is certainly yes. There must be something obviously broken with >> sockets (is it all platforms or only linux?) because we use sockets >> intensively at Teleplace and only see problems on a single customer's >> machine which looks to be to do with virus protection. I'm on holiday next >> week and am rather busy right now, but perhaps later in August I can work >> with Lukas to try and sort out the socket issues. >> > > ok... > > >> >> 4) Depends on heroes. I never liked this idea. It has nothing to do with >>> Eliot. He is very cool and helpful. But I wonder, do we understand the new >>> VM and the changes? are we able to handle and fix it even without eliot ? >>> >> >> THis is a serious issue. I need to be nagged to document the system on my >> blog. I mean to get to this (perhaps in September?). Alas a Smalltalk JIT >> is a complex beast, significantly more complex than the interpreter, and is >> not the easiest thing to understand or debug. So even if it is well >> documented it'll be more difficult to fix than the interpreter, but that's a >> price one has to pay for this kind of performance. >> >> > > I agree. That's why my concern. > > > >> >>> 5) Integration to VMMaker. I saw that they started to merge cog >>> (actually, I think only stack vm?) to the trunk of VMMaker. This is really >>> good news. I hope everything is there and merged. >>> >> >> Cog is a fork of VMMaker. We may be able to merge at some stage, and >> Cog's Slang should still work with the old Interpreter. But for now, >> inevitably, it's a fork. I needed to add a lot of functionality to Slang to >> write Cog, and I didn't have the cycles to keep Interpreter up to date. >> That's life :) >> >> > ok > > > >> 6) Binaries. It seems the official released didn't come with binaries. So >>> we should compile it for each OS. >>> >> >> There is /no/ official release. Until Cog has stabilized and the VM >> maintainers have taken it up it's definitely unoffficial :) >> > > Ok...forget the "official" word....where should we get the sources (svn) > and the VMMaker code in order to compile the latest and build binaries? > > > >> >> Ok..that's all my thoughts. I would really like to have a discussion here >>> and see what to do.....grrrrrr you are all in holidays, aren't you? hahah >>> >> >> two days to go :) >> > > > enjoy ;) > > > >> >> >>> >>> cheers >>> >>> Mariano >>> >> >> best >> Eliot >> >> >>> >>> _______________________________________________ >>> 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 30, 2010

Re: [Pharo-project] cog-based image crashes on mac

by Mariano Martinez Peck

I have a similar problem, with the latest svn version, 2249. (localPrimIndex > 255) && (localPrimIndex < 520) 15376 squeak: could not load plugin `SocketPlugin' [Switching to process 26735] nanosleep: Invalid argument But it is not random. It happens everytime I try to run PharoCore 12069 tests. Cheers MAriano On Mon, Jul 26, 2010 at 8:43 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > 2010/7/26 Eliot Miranda <eliot.miranda(a)gmail.com>: > > There's an update in svn that could fix crashes. > > No sorry, still the same (if I remember correctly I've never seen the > bunch of error messages before the last two though) with the latest > svn code: > > 26.07.10 20:39:33 > [0x0-0x1d3dd3c].com.teleplace.Teleplace[4514] > mprotect(x,y,PROT_READ > | PROT_WRITE): Cannot allocate memory > 26.07.10 20:39:33 > [0x0-0x1d3dd3c].com.teleplace.Teleplace[4514] > mprotect(x,y,PROT_READ > | PROT_WRITE): Invalid argument > 26.07.10 20:39:33 > [0x0-0x1d3dd3c].com.teleplace.Teleplace[4514] squeak: could not > load > plugin `MiscPrimitivePlugin' > 26.07.10 20:39:33 > [0x0-0x1d3dd3c].com.teleplace.Teleplace[4514] squeak: could not > load > plugin `DropPlugin' > 26.07.10 20:39:33 > [0x0-0x1d3dd3c].com.teleplace.Teleplace[4514] squeak: could not > load > plugin `FilePlugin' > 26.07.10 20:39:33 > [0x0-0x1d3dd3c].com.teleplace.Teleplace[4514] squeak: could not > load > plugin `SecurityPlugin' > 26.07.10 20:39:33 > [0x0-0x1d3dd3c].com.teleplace.Teleplace[4514] squeak: could not > load > plugin `BitBltPlugin' > 26.07.10 20:39:33 > [0x0-0x1d3dd3c].com.teleplace.Teleplace[4514] squeak: could not > load > plugin `LargeIntegers' > 26.07.10 20:39:33 > [0x0-0x1d3dd3c].com.teleplace.Teleplace[4514] squeak: could not > load > plugin `B2DPlugin' > 26.07.10 20:39:33 > [0x0-0x1d3dd3c].com.teleplace.Teleplace[4514] squeak: could not > load > plugin `InternetConfigPlugin' > 26.07.10 20:39:33 > [0x0-0x1d3dd3c].com.teleplace.Teleplace[4514] squeak: could not > load > plugin `SocketPlugin' > 26.07.10 20:40:03 > [0x0-0x1d3dd3c].com.teleplace.Teleplace[4514] squeak: could not > load > plugin `DSAPrims' > 26.07.10 20:40:06 > [0x0-0x1d3dd3c].com.teleplace.Teleplace[4514] squeak: could not > load > plugin `JPEGReadWriter2Plugin' > 26.07.10 20:41:33 > [0x0-0x1d3dd3c].com.teleplace.Teleplace[4514] nanosleep: Invalid > argument > 26.07.10 20:41:33 > com.apple.launchd.peruser.501[200] > ([0x0-0x1d3dd3c].com.teleplace.Teleplace[4514]) > Exited with exit code: 1 > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 30, 2010

[Pharo-project] About overlapping packages :(

by StÃ©phane Ducasse

Hi I have worked on the integration of the new package implementation and its synchronisation with MC/PackageInfo. Now I have the following problem: Scenario 1: the user have created a package Foo which contains several classes, some like FooObject in the category Foo-Core, others in category Foo-Others. Now if he creates a package Foo-Core, Foo-Core should contain the classes having Foo-Core as category. I have a problem with PackageInfo semantics since here packages Foo and Foo-Core could contain FooObject. Scenario 2: the user have created a class in the category Foo-Core, and after created a package only named Foo. The classes in category Foo-Core should be added to Foo. But some other packages and categories starting with Foo may exist. Now in the new implementation, classes cannot be two packages at the same time. So I will be forced to implement a checker making sure that there is no such situation and also that we should remove first the Foo package and then create two package Foo-Core and Foo-Others. What do you think? May be such a checker should be hooked into MC right now so we detect anyway such bad situations. For the moment I'm fighting within events and announcements to make sure that I could potentially keep the new implementation of Package and PackageOrganizer in sync with PackageInfo but this is not that simple. Stef

July 30, 2010

Re: [Pharo-project] CogVM as official Pharo VM?

by Mariano Martinez Peck

2010/7/29 Eliot Miranda <eliot.miranda(a)gmail.com> > Hi Lukas, > > On Thu, Jul 29, 2010 at 2:00 AM, Lukas Renggli <renggli(a)gmail.com> wrote: > >> > 1) Cog VM seems to be aimed for x86 and 32 bits. You can read Eliot >> quotes: >> > "The Cog VM is a just-in-time compiler that currently supports only x86 >> >> So far I never felt the need for 64-bit images. >> >> > 3) Is it stable for production use? For example, I read that with >> seaside >> > there are some crashes. >> >> Seaside itself is not the problem, Eliot quickly fixed the remaining >> issues with Continuations shortly after the open-source release of >> Cog. > > > and I still need to fix objects-as-methods but have no time right now. > That's probably two to five days work to do right :/ > > Although it is very important for us, it is not that we needed right NOW. Take all the time you need. It is good to see you want to fix it :) > > >> The problem are the sockets, they cause frequent random crashes >> of the VM. >> > > Do we have any more specific information on these socket-related crashes? > (platform, crash reports, test cases, etc?) > That's the idea of the Pharo OneClick with Cog. We can distribute that so that everybody can start to play with it and report problem. But for that, we need to know where to get all Cog sources, and how to compile it. In addition, what kind of flags in configure would help you to debug problems and get as much information as possible. With this we can distribute a VM + image that logs as much as possible. This one click would be experimental, not production. Thus, it shouldn't care if it is a little slower (because of the logging). Cheers Mariano > > best > Eliot > > >> >> Lukas >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> _______________________________________________ >> 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 30, 2010

[Pharo-project] about ToolBuilder

by stephane ducasse

Hi guys during the sprint I discussed with Gary about ToolBuilder and we think that it would be better to remove it since a lot of new widgets are not covered so this means that we will be constantly limiting ourselves. Of course ToolBuilder is a nice idea (if we would have several UI framework). So far we got only one and we would have several we would have to take the smallest common denominator. Another idea would be to extend toolBuilder to support new widgets. So what do you think? Stef

July 30, 2010

[Pharo-project] How to remove Monticello?

by Hilaire Fernandes

Dear all, I tried this: (MCPackage named: 'MonticelloGUI') unload. (MCPackage named: 'MonticelloConfiguration') unload. (MCPackage named: 'Monticello') unload. but the third line did not work. Any experiences to share on that topic? Thanks Hilaire

July 30, 2010

Re: [Pharo-project] [Pharo-users] Recent Messages Browser

by Mariano Martinez Peck

On Fri, Jul 30, 2010 at 2:47 AM, Benjamin Van Ryseghem < benjamin.vanryseghem(a)gmail.com> wrote: > Hi everybody, > > > I've rewrited a recent messages browser based on MorphTreeMorph. > > Hi, this is very good idea! > If you can test it and tell me what's do you think about, it will be cool > (I'm a new Smalltalker ^^) > > welcome! > You can download code here : > > Gofer new > squeaksource: 'PharoTaskForces'; > package: 'RecentSubmissions'; > load. > > > To launch it, just click on the World >> Tools >> Recent Messages. > > You can set it up in the Setting Menu >> Code browsing >> Recent Message. > > > Ok...I did it. A few remarks: 1) RecentMessageList >> initialize you do SmalltalkImage current addToStartUpList: self class. but should be SmalltalkImage addToStartUpList: self class. (at least in Pharo 1.1) 2) What is the idea of the Recent Messages? To see the recent MODIFIED methods ? isn't it? If true, maybe would be good to 2.1) directly show the diff with the previous version 2.2) Have a button to see the versions of that method 3) Once you press any button, like collapse all or similar, they become blue and neve grey again 4) When is the list of recen messages clean ? how do you know the recen messages? you store that information somewhere? when is that cleaned? Thank you very much and continue with the good work! Maybe once we can include it by defult in Pharo. Cheers Mariano > > Thank you > > > > Ben > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > >

July 30, 2010

Re: [Pharo-project] CogVM as official Pharo VM?

by Mariano Martinez Peck

2010/7/29 Eliot Miranda <eliot.miranda(a)gmail.com> > > > 2010/7/29 Mariano Martinez Peck <marianopeck(a)gmail.com> > > Hi folks. Hope Eliot is reading this thread. >> > > Yes, I'm reading :) > THanks Eliot for all the answers. It seems they are all good news :) > > >> It is time to think in Pharo 1.2 and we need to discuss if we want to have >> CogVM as the standard Pharo VM. >> >> Most of us have tried it and found it incredible fast. So it would be very >> good to take advantage of it. But I think there are a couple of things to >> be discussed: >> >> 1) Cog VM seems to be aimed for x86 and 32 bits. You can read Eliot >> quotes: >> "The Cog VM is a just-in-time compiler that currently supports only x86 >> > > It is only initially aimed at x86. That's the most important platform by > far from Teleplace's perspective and I suspect the majority of the community > is on x86. But Cog was designed form the outset to be portable. The Cogit > is architected to support other ISAs. See CogAbstractInstruction and its > one subclass CogIA32Compiler. To port to another ISA you should > subclass CogAbstractInstruction and implement the same protocol > as CogIA32Compiler. > > I would love to see a CogARMCompiler and a CogPPCCompiler and encourage > anyone with low-level expertise on those platforms to have a go. I'm always > here to answer questions. > > > This is great Eliot. I thought that Cog was completly aimed to x86 and that would be difficult to port. That was my concern, but now with what you said it is much clear :) > No effort has been made to maintain 64-bit compatibility. Apologies, this >> was unaffordable." >> >> So...how much important is this for us? do we care? and if we want to do >> it, is it "doable" ? is it less doable than the normal squeak VM ? >> >> I really would like to have 64bits VM + 64bits images in a near >> future...but hat's just my thoguhts. >> > > I'm also thinking abut 64-bits but want to do 64-bits with a new object > representation based on my 64-bit objrep for VisualWorks, which would > include SmallFloat. Realistically this is a year out, because the 32-bit > version of the new objrep and the pinning GC need to be implemented before > I'll be able to do a 64-bit VM. But it's an obvious and logical direction > to go in. > Excellent!! Just by curious, your idea, or what you did in VW, was to be able to put SmallFloats directly inside the address ? just like we do nowadays with SmallInteger ? > > 2) The status of the external plugins. Are they working with Cog ? Not >> only the "core plugings" but FFI, OSProcess (I read some problems with it), >> TrueType, etc... >> > > ReentrantFFIPlugin (a.k.a. src/plugins/SqueakFFIPrims/SqueakFFIPrims.c) > should work. But people need to build and test. > > 3) Is it stable for production use? For example, I read that with seaside >> there are some crashes. >> > > Well, it is the production VM at Teleplace so at least for one context the > answer is certainly yes. There must be something obviously broken with > sockets (is it all platforms or only linux?) because we use sockets > intensively at Teleplace and only see problems on a single customer's > machine which looks to be to do with virus protection. I'm on holiday next > week and am rather busy right now, but perhaps later in August I can work > with Lukas to try and sort out the socket issues. > ok... > > 4) Depends on heroes. I never liked this idea. It has nothing to do with >> Eliot. He is very cool and helpful. But I wonder, do we understand the new >> VM and the changes? are we able to handle and fix it even without eliot ? >> > > THis is a serious issue. I need to be nagged to document the system on my > blog. I mean to get to this (perhaps in September?). Alas a Smalltalk JIT > is a complex beast, significantly more complex than the interpreter, and is > not the easiest thing to understand or debug. So even if it is well > documented it'll be more difficult to fix than the interpreter, but that's a > price one has to pay for this kind of performance. > > I agree. That's why my concern. > >> 5) Integration to VMMaker. I saw that they started to merge cog (actually, >> I think only stack vm?) to the trunk of VMMaker. This is really good news. I >> hope everything is there and merged. >> > > Cog is a fork of VMMaker. We may be able to merge at some stage, and Cog's > Slang should still work with the old Interpreter. But for now, inevitably, > it's a fork. I needed to add a lot of functionality to Slang to write Cog, > and I didn't have the cycles to keep Interpreter up to date. That's life :) > > ok > 6) Binaries. It seems the official released didn't come with binaries. So >> we should compile it for each OS. >> > > There is /no/ official release. Until Cog has stabilized and the VM > maintainers have taken it up it's definitely unoffficial :) > Ok...forget the "official" word....where should we get the sources (svn) and the VMMaker code in order to compile the latest and build binaries? > > Ok..that's all my thoughts. I would really like to have a discussion here >> and see what to do.....grrrrrr you are all in holidays, aren't you? hahah >> > > two days to go :) > enjoy ;) > > >> >> cheers >> >> Mariano >> > > best > Eliot > > >> >> _______________________________________________ >> 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 30, 2010