- Pharo-dev - lists.pharo.org

Re: [Pharo-project] So...we freeze 1.1 ? (next steps?)

by Geert Claes

Adrian Lienhard wrote: > > One thing that bothers me is the network code. Although nobody reported > problems I cannot believe that it suddenly works without that we fixed it. > The new implementation that is in 1.1 has been reverted in 1.0 and since > then we haven't had any complaints. Now in 1.1 I guess that there are not > that many people using it yet. > I can't seem to connect using a proxy server with network authentication. I have now successfully saved the HTTP proxy server and port number as well as the user name and password. I am using 1.1 using the new Settings browser and updated the settings in "MyOwn" settings style, but I don't think it is actually using those settings? -- View this message in context: http://forum.world.st/So-we-freeze-1-1-next-steps-tp2218533p2220919.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 18, 2010

[Pharo-project] Collection arithmethic method category

by Fernando olivero

In Pharo1.0 Collection organization listAtCategoryNamed: 'arithmethic' #() In PharoCore1.1 Collection organization listAtCategoryNamed: 'arithmetic' #(#* #+ #- #/ #'//' #'\\' #raisedTo:) And the arithmethic is not an extension of any Package. Why are all the methods in that category no present in PharoCore? How and when are they added into Pharo ? Fernando

May 18, 2010

Re: [Pharo-project] So...we freeze 1.1 ? (next steps?)

by Alexandre Bergel

I will tell you probably today or tomorrow. Alexandre On 18 May 2010, at 04:46, StÃ©phane Ducasse wrote: > Alex > > Can you tell me the french time of the sprint because I would like to help people focusing on > some good fixes to produce > I want to try to be online. > > Stef > > On May 18, 2010, at 2:49 AM, Alexandre Bergel wrote: > >> Mariano, Stef, Adrian, >> >> I would like to focus the Pharo sprint this week end on helping Pharo 1.1. >> In addition to reviewing and fixing the issues tagged as 1.1, are there some particular actions you want to see realized this Saturday? >> >> Cheers, >> Alexandre >> >> >> On 16 May 2010, at 18:26, Alexandre Bergel wrote: >> >>>> - Integegrate the remaining fixes and crates a PharoCore-11XXX-alpha1.zip and put it in gforge >>> >>> >>> I will go over some this week. >>> >>> Alexandre >>> >>> >>> _______________________________________________ >>> 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 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 18, 2010

Re: [Pharo-project] how to change the default size of the Pharo host windows?

by Mariano Martinez Peck

On Tue, May 18, 2010 at 9:52 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > 2010/5/18 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > this is cool > > We could then build tools for you :) > > Boxes are packages, little squares are classes > > > > > > Blue: classes with no instances > > Green: classes with instances, but no used > > Red: classes with instances and at least one used > > > > just brainstorming with mariano > > > Interesting. > Could it draw with pink, the ones who has no instances, but having a > methods invocations > (an abstract superclasses can have no instances, but can be under heavy > use). > Sorry I forgot to change the colors. Look above to see the references. Cheers Mariano > > > > > > > > > > > > > On May 17, 2010, at 10:40 PM, Eliot Miranda wrote: > > > >> > >> > >> On Mon, May 17, 2010 at 11:30 AM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> > >> On Ma > >> > > >> > bytes 28 to 31: image flags, conventional VMs use only bit 0, Cog also > uses bits 1 through 4 > >> > bit 0: 1 => open full screen, 0 => open using width & > height > >> > bit 1: 1 => image floats are in little-endian format, > 0=> image floats are in big-endian format > >> > bit 2: 1 => Process's 4th inst var (after myList) is > threadId to be used by the VM for overlapped calls > >> > > >> > bit 3: 1 => set the flag bit on methods that the VM will > only interpret (because they're considered too big to JIT) > >> > bit 4: 1 => preempting a process does not put it to the > back of its run queue > >> > >> > >> I was not clear how to read > >> bit 3: 1 > >> this information is not in the compiledMethods? > >> > >> For the Cog JIT I want to measure which methods get interpreted to > determine the threshold at which to decide to JIT methods. It makes little > sense to JIT methods that are large and only executed once, typically class > initialization methods. A simple criterion is to set a limit on the number > of literals in a method. But I still need to know whether my threshold is > affecting frequently used methods. So I added the option of setting the > flag bit in any method which the JIT refuses to compile because it has too > many literals. Since I need to see which methods are interpreted on > start-up putting a flag in the image header was convenient. The effect is > that the JIT will set the flag bit on any method it refuses to JIT. I can > then browse these in the image and decide whether any are important and > adjust the threshold accordingly. Arguably this should be a command line > argument, not an image header flag. > >> > >> > >> 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 > > > > > > _______________________________________________ > > 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 >

May 18, 2010

Re: [Pharo-project] So...we freeze 1.1 ? (next steps?)

by Adrian Lienhard

Yes, we should probably do that. It requires some work because of changes in 1.1. Adrian On May 18, 2010, at 09:24 , Michael Roberts wrote: > I am surprised too. would it not be safer to just apply the same > reversion of the code so that 1.1 is the same as 1.0? Then when > someone has the time to do a full review, a "new" network can be > applied to the start of a dev cycle, with some form of integration > tests. > > cheers, > Mike > > On Tue, May 18, 2010 at 6:31 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: >> Hi Alex, >> >> One thing that bothers me is the network code. Although nobody reported problems I cannot believe that it suddenly works without that we fixed it. The new implementation that is in 1.1 has been reverted in 1.0 and since then we haven't had any complaints. Now in 1.1 I guess that there are not that many people using it yet. >> >> If there are people at the sprint with different OS and configurations (Linux vs Mac; IPv4 vs. IPv6), you could try to reproduce the problems that were reported earlier (check the issue tracker). >> >> Another valuable help would be to (manually) test the tools, especially the ones loaded into Pharo to make sure we don't have any obvious problems there. >> >> Hope you have a productive weekend! >> >> Cheers, >> Adrian >> >> On May 18, 2010, at 02:49 , Alexandre Bergel wrote: >> >>> Mariano, Stef, Adrian, >>> >>> I would like to focus the Pharo sprint this week end on helping Pharo 1.1. >>> In addition to reviewing and fixing the issues tagged as 1.1, are there some particular actions you want to see realized this Saturday? >>> >>> Cheers, >>> Alexandre >>> >>> >>> On 16 May 2010, at 18:26, Alexandre Bergel wrote: >>> >>>>> - Integegrate the remaining fixes and crates a PharoCore-11XXX-alpha1.zip and put it in gforge >>>> >>>> >>>> I will go over some this week. >>>> >>>> Alexandre >>>> >>>> >>>> _______________________________________________ >>>> 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 >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 18, 2010

Re: [Pharo-project] how to change the default size of the Pharo host windows?

by Igor Stasenko

2010/5/18 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > this is cool > We could then build tools for you :) > Boxes are packages, little squares are classes > > > Blue: classes with no instances > Green: classes with instances, but no used > Red: classes with instances and at least one used > > just brainstorming with mariano > Interesting. Could it draw with pink, the ones who has no instances, but having a methods invocations (an abstract superclasses can have no instances, but can be under heavy use). > > > > > > On May 17, 2010, at 10:40 PM, Eliot Miranda wrote: > >> >> >> On Mon, May 17, 2010 at 11:30 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >> On Ma >> > >> > bytes 28 to 31: image flags, conventional VMs use only bit 0, Cog also uses bits 1 through 4 >> > Â Â Â Â Â Â Â bit 0: 1 => open full screen, 0 => open using width & height >> > Â Â Â Â Â Â Â bit 1: 1 => image floats are in little-endian format, 0=> image floats are in big-endian format >> > Â Â Â Â Â Â Â bit 2: 1 => Process's 4th inst var (after myList) is threadId to be used by the VM for overlapped calls >> > >> > Â Â Â Â Â Â Â bit 3: 1 => set the flag bit on methods that the VM will only interpret (because they're considered too big to JIT) >> > Â Â Â Â Â Â Â bit 4: 1 => preempting a process does not put it to the back of its run queue >> >> >> I was not clear how to read >> Â Â Â Â bit 3: 1 >> this information is not in the compiledMethods? >> >> For the Cog JIT I want to measure which methods get interpreted to determine the threshold at which to decide to JIT methods. Â It makes little sense to JIT methods that are large and only executed once, typically class initialization methods. A simple criterion is to set a limit on the number of literals in a method. Â But I still need to know whether my threshold is affecting frequently used methods. Â So I added the option of setting the flag bit in any method which the JIT refuses to compile because it has too many literals. Â Since I need to see which methods are interpreted on start-up putting a flag in the image header was convenient. Â The effect is that the JIT will set the flag bit on any method it refuses to JIT. Â I can then browse these in the image and decide whether any are important and adjust the threshold accordingly. Â Arguably this should be a command line argument, not an image header flag. >> >> >> 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 > > > _______________________________________________ > 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.

May 18, 2010

[Pharo-project] Fwd: [squeak-dev] I really miss a binary bitOr: selector for integers

by StÃ©phane Ducasse

> > > send code with a nice comments and a test and it will be in 1.1 :) > > Stef > > On May 18, 2010, at 3:26 AM, Igor Stasenko wrote: > >> Hello, >> C world using bitor-s extensively for passing various flags and options. >> >> And porting the code looks really awful with #bitOr: , because it >> requires braces when you combining more than 2 flags. >> >> Can we , please , please, include #| as an alternative selector for >> bitor-ing integers into a kernel? >> >> Btw, Alien alredy adds it as extension. But i would really like to get >> it into the core, so any other may use it. >> >> Meanwhile, i defined own awfull extension selector - #++ >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > >

May 18, 2010

Re: [Pharo-project] So...we freeze 1.1 ? (next steps?)

by StÃ©phane Ducasse

Alex Can you tell me the french time of the sprint because I would like to help people focusing on some good fixes to produce I want to try to be online. Stef On May 18, 2010, at 2:49 AM, Alexandre Bergel wrote: > Mariano, Stef, Adrian, > > I would like to focus the Pharo sprint this week end on helping Pharo 1.1. > In addition to reviewing and fixing the issues tagged as 1.1, are there some particular actions you want to see realized this Saturday? > > Cheers, > Alexandre > > > On 16 May 2010, at 18:26, Alexandre Bergel wrote: > >>> - Integegrate the remaining fixes and crates a PharoCore-11XXX-alpha1.zip and put it in gforge >> >> >> I will go over some this week. >> >> Alexandre >> >> >> _______________________________________________ >> 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

May 18, 2010

Re: [Pharo-project] how to change the default size of the Pharo host windows?

by StÃ©phane Ducasse

this is cool We could then build tools for you :) Boxes are packages, little squares are classes Blue: classes with no instances Green: classes with instances, but no used Red: classes with instances and at least one used just brainstorming with mariano On May 17, 2010, at 10:40 PM, Eliot Miranda wrote: > > > On Mon, May 17, 2010 at 11:30 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Ma > > > > bytes 28 to 31: image flags, conventional VMs use only bit 0, Cog also uses bits 1 through 4 > > bit 0: 1 => open full screen, 0 => open using width & height > > bit 1: 1 => image floats are in little-endian format, 0=> image floats are in big-endian format > > bit 2: 1 => Process's 4th inst var (after myList) is threadId to be used by the VM for overlapped calls > > > > bit 3: 1 => set the flag bit on methods that the VM will only interpret (because they're considered too big to JIT) > > bit 4: 1 => preempting a process does not put it to the back of its run queue > > > I was not clear how to read > bit 3: 1 > this information is not in the compiledMethods? > > For the Cog JIT I want to measure which methods get interpreted to determine the threshold at which to decide to JIT methods. It makes little sense to JIT methods that are large and only executed once, typically class initialization methods. A simple criterion is to set a limit on the number of literals in a method. But I still need to know whether my threshold is affecting frequently used methods. So I added the option of setting the flag bit in any method which the JIT refuses to compile because it has too many literals. Since I need to see which methods are interpreted on start-up putting a flag in the image header was convenient. The effect is that the JIT will set the flag bit on any method it refuses to JIT. I can then browse these in the image and decide whether any are important and adjust the threshold accordingly. Arguably this should be a command line argument, not an image header flag. > > > 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

May 18, 2010

Re: [Pharo-project] [Metacello] Managing Pharo external packages with Metacello, please read!

by StÃ©phane Ducasse

two points - let us try something simple that we can understand - second the latest only works if nobody publish a broken code in his repository. or you will have to publish the packages tagged 'latest but for stream pharo1.0' So for now let us keep it simple and learn. Stef On May 18, 2010, at 4:17 AM, Miguel Enrique CobÃ¡ Martinez wrote: > El lun, 17-05-2010 a las 09:49 +0200, StÃ©phane Ducasse escribiÃ³: >> I like the idea of tags. >> Now I still would like to be able to freeze a version. This way we could have a pharo10 distribution on a CD >> with all the code included. > > But look at Debian for example. They release a stable release, lets say > 5.0 on January 15th. This is a iso image that includes a given set of > package versions, lets say > > Package A version 1.1 > Package B version 2.0 > Package C version 2.1 > > then they continue working on testing and unstable versions of the > distro. Of course as the software is used all around the world, the > users report bugs and the developers push new versions with the fixes to > the debian repositories. The fixes can be bug fixes, security fixes and > new features. Only the security fixes and severe bug fixes are pushed to > the stable release (as well as to the testing and unstable branches of > course). This security fixes are part of the security updates for stable > installations of the distro. > But.. after a given number of security fixes and severe bug fixes are > collected, they release an update for the stable release, even > generating new .iso files. Suppose that they release an update in May > 1st. They could call it Debian GNU/Linux stable 5.0.1. > > The point is, even if I downloaded the stable release on January 15th, > it is different from the version you download on May 1st. They are both > called debian 5.0 stable and nobody expect that they are bitwise > identical. > > But, when you install from the version from January and after updating > it from the update stream, I get the same packages that the person that > install its server from the version of May 1st. > > I think the same can happen to Pharo. You release a given set of > versions (in the form of configurationOfXXX) but that doesn't means that > those are inmutable. They will be updated to match the packages that fix > bugs in a given external package. > > Now for the generation of the release, you simply script it to use the > latest #released version of a configuration. That is the way that > Metacello works currently, installing the latest released version by > default. > > Cheers > > >> >> Stef >> >> >>> I was thinking about the "folders" to store copies of ConfigurationOfXXX >>> for a given release. I think that this will have problems, for example >>> for the simplest package that load fine in 3 consecutive release we will >>> have exactly 3 copies of the ConfigurationOfXXX package (not that the >>> disk space is a problem). On the other side, if a package has 19 >>> versions for a given release (lets say RFB has 19 version methods in the >>> ConfigurationOfXXX for Pharo 1.0), then when Pharo 2.0 is released, a >>> copy of it will be made. This copy will be full, having the 19 version >>> methods, or you just take the last version method. Also, what about the >>> pre/post do its, they will likely be similar or exactly equal between >>> releases of Pharo. >>> If you delete the methods, you also lost the history and the opportunity >>> that new users can learn or use the previous versions. >>> >>> Some time ago I proposed the idea that Metacello should have tags to >>> mark that a version method has been tested in a given fork/release. As >>> the time pass, the tags in a method will grow to mark the version has >>> been tested on. >>> But for this to work, Metacello or the tools (I would prefer Metacello) >>> must honor this tags and before loading the code in a given image by >>> comparing what image is being installed on. >>> >>> Lets put an example: >>> >>> 1. Initial creation of the configuration for package Package for Pharo >>> 1.0 uploaded to MetacelloRepository: >>> >>> ConfigurationOfPackage>>baseline01 >>> "initial baseline" >>> >>> ConfigurationOfPackage>>version01: spec >>> <version: '0.1'> >>> >>> spec for: #common do: [ >>> spec blessing: #release. >>> spec worksIn: 'Pharo1.0' >>> ... ]. >>> >>> 2. A new version for Pharo 1.0 (lets say a bug fix): >>> >>> ConfigurationOfPackage>>version02: spec >>> <version: '0.2'> >>> >>> spec for: #common do: [ >>> spec blessing: #release. >>> spec worksIn: 'Pharo1.0' >>> ... ]. >>> >>> 3. A new Pharo release is made, no changes to the package are needed, >>> that is, it works correctly in Pharo1.0 and Pharo 1.1 >>> >>> ConfigurationOfPackage>>version03: spec >>> <version: '0.3'> >>> >>> spec for: #common do: [ >>> spec blessing: #release. >>> spec worksIn: #( 'Pharo1.0' 'Pharo1.1' ) >>> ... ]. >>> >>> At this point the ConfigurationOfPackage has four methods: baseline and >>> three versions. Also, before loading, Metacello checks the worksIn: >>> list against a standard release string in the image is working on. If >>> it match it install the package. That is, if I start with a Pharo1.1 >>> image and load the configuration, the only possible candidate version >>> to install is the 0.3, because is the only one marked to work in Pharo1.1. >>> >>> 4. A port to Squeak 5 is made. This likely will need a new baseline >>> because will need squeak specific packages to be included >>> (compatibility packages) and also maybe a Pharo compatibility package >>> will be made. Anyway, a new baseline indicating new packages >>> relationships will be made: >>> >>> ConfigurationOfPackage>>baseline02 >>> "second baseline, it accounts for install in Pharo and Squeak" >>> >>> ConfigurationOfPackage>>version04: spec >>> <version: '0.4'> >>> >>> spec for: #common do: [ >>> spec blessing: #release. >>> spec worksIn: #( 'Pharo1.0' 'Pharo1.1' 'Squeak5.0' ) >>> ... ]. >>> spec for: #squeak do: [ >>> ... ]. >>> spec for: #pharo do: [ >>> ... ]. >>> >>> At this point the ConfigurationOfXXX is capable of install the last >>> version in Squeak and Pharo. >>> >>> If I start on Squeak 4.0 then even if I load the >>> ConfigurationOfPackage, no package will be installed because nobody has tested this. >>> >>> If I start on Squeak 5.0 only version 0.4 can be installed. >>> >>> If I start on Pharo 1.0 versions 0.1, 0.2, 0.3 and 0.4 can be installed >>> >>> If I start on Pharo 1.3 no package will be installed >>> >>> 5. Nobody updates the configuration for the Squeak 6.0 and 7.0 releases >>> but new versions are created for Pharo 1.3 and Pharo1.4. The code no longer works in Pharo 1.0 and Pharo1.1 >>> >>> ConfigurationOfPackage>>baseline08 >>> "second baseline, it accounts for install in Pharo and Squeak" >>> >>> ConfigurationOfPackage>>version09: spec >>> <version: '0.9'> >>> >>> spec for: #common do: [ >>> spec blessing: #release. >>> spec worksIn: #( 'Pharo1.3' 'Pharo1.4' ) >>> ... ]. >>> spec for: #pharo do: [ >>> ... ]. >>> >>> 6. Installing on Squeak 8 is again supported together with support for Squeak 7.0: >>> >>> ConfigurationOfPackage>>baseline04 >>> "third baseline, it accounts for install in Pharo and Squeak" >>> >>> ConfigurationOfPackage>>version10: spec >>> <version: '1.0'> >>> >>> spec for: #common do: [ >>> spec blessing: #release. >>> spec worksIn: #( 'Pharo1.3' 'Pharo1.4' 'Squeak7.0' 'Squeak8.0' ) >>> ... ]. >>> spec for: #squeak do: [ >>> ... ]. >>> spec for: #pharo do: [ >>> ... ]. >>> >>> So the tags come and go as the support for given forks and releases are >>> tested. >>> Different versions of the Package package can work in different forks >>> and in different releases of those forks. >>> It is always the job of the interested parties to add support (that is >>> version methods and baselines, or simply tags to the worksIn: list) for >>> a package in a given combination. >>> >>> What do you think? >>> >>> Cheers >>> >>> -- >>> Miguel CobÃ¡ >>> http://miguel.leugim.com.mx >>> >>> >>> _______________________________________________ >>> 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 > > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 18, 2010