[Pharo-project] About long tests.
Hi jorge did you publish the cleans for the tests you did during the sprint? Thanks Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About long tests.
Btw, I am running the Pharo tests in my builds now too: http://hudson.lukas-renggli.ch/job/Pharo/lastCompletedBuild/testReport/(root)/ Click on duration twice to see the tests sorted by run-time. I feel a bit bad that the slowest test case is one that I wrote. I'll see if I can speed that up some more. Lukas On 15 March 2010 20:56, stephane ducasse stephane.duca...@free.fr wrote: Hi jorge did you publish the cleans for the tests you did during the sprint? Thanks Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About long tests.
Yes, it would be very good to have faster tests. In my experience, if tests take too long to run, you don't use them. During the sprint in Lille, Jorge started to sort out long running tests from the rest and make them subclass from SlowTestCase (or something similar). Cheers, Adrian On Mar 16, 2010, at 09:13 , Lukas Renggli wrote: Btw, I am running the Pharo tests in my builds now too: http://hudson.lukas-renggli.ch/job/Pharo/lastCompletedBuild/testReport/(root)/ Click on duration twice to see the tests sorted by run-time. I feel a bit bad that the slowest test case is one that I wrote. I'll see if I can speed that up some more. Lukas On 15 March 2010 20:56, stephane ducasse stephane.duca...@free.fr wrote: Hi jorge did you publish the cleans for the tests you did during the sprint? Thanks Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About long tests.
Hi, No, I have to finish that. Is still in my todo list. I'll try to make some time today to look into that. Cheers, Jorge On Tue, Mar 16, 2010 at 9:32 AM, Adrian Lienhard a...@netstyle.ch wrote: Yes, it would be very good to have faster tests. In my experience, if tests take too long to run, you don't use them. During the sprint in Lille, Jorge started to sort out long running tests from the rest and make them subclass from SlowTestCase (or something similar). Cheers, Adrian On Mar 16, 2010, at 09:13 , Lukas Renggli wrote: Btw, I am running the Pharo tests in my builds now too: http://hudson.lukas-renggli.ch/job/Pharo/lastCompletedBuild/testReport/(root)/ Click on duration twice to see the tests sorted by run-time. I feel a bit bad that the slowest test case is one that I wrote. I'll see if I can speed that up some more. Lukas On 15 March 2010 20:56, stephane ducasse stephane.duca...@free.fr wrote: Hi jorge did you publish the cleans for the tests you did during the sprint? Thanks Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About long tests.
Name: Gofer-Tests-lr.117 Author: lr Time: 16 March 2010, 10:12:10 am UUID: 884f7d2b-6035-4f66-9ec3-28371a77beac Ancestors: Gofer-Tests-lr.116 - made tests run faster in the Pharo inbox is about 30% faster. Lukas On 16 March 2010 09:13, Lukas Renggli reng...@gmail.com wrote: Btw, I am running the Pharo tests in my builds now too: http://hudson.lukas-renggli.ch/job/Pharo/lastCompletedBuild/testReport/(root)/ Click on duration twice to see the tests sorted by run-time. I feel a bit bad that the slowest test case is one that I wrote. I'll see if I can speed that up some more. Lukas On 15 March 2010 20:56, stephane ducasse stephane.duca...@free.fr wrote: Hi jorge did you publish the cleans for the tests you did during the sprint? Thanks Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli http://www.lukas-renggli.ch -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About long tests.
On Mar 16, 2010, at 9:13 AM, Lukas Renggli wrote: Btw, I am running the Pharo tests in my builds now too: http://hudson.lukas-renggli.ch/job/Pharo/lastCompletedBuild/testReport/(root)/ Click on duration twice to see the tests sorted by run-time. I feel a bit bad that the slowest test case is one that I wrote. I'll see if I can speed that up some more. lol :) It is on my todo to read the mail of yanni on hudson. Stef Lukas On 15 March 2010 20:56, stephane ducasse stephane.duca...@free.fr wrote: Hi jorge did you publish the cleans for the tests you did during the sprint? Thanks Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About long tests.
cool! On Mar 16, 2010, at 10:16 AM, Lukas Renggli wrote: Name: Gofer-Tests-lr.117 Author: lr Time: 16 March 2010, 10:12:10 am UUID: 884f7d2b-6035-4f66-9ec3-28371a77beac Ancestors: Gofer-Tests-lr.116 - made tests run faster in the Pharo inbox is about 30% faster. Lukas On 16 March 2010 09:13, Lukas Renggli reng...@gmail.com wrote: Btw, I am running the Pharo tests in my builds now too: http://hudson.lukas-renggli.ch/job/Pharo/lastCompletedBuild/testReport/(root)/ Click on duration twice to see the tests sorted by run-time. I feel a bit bad that the slowest test case is one that I wrote. I'll see if I can speed that up some more. Lukas On 15 March 2010 20:56, stephane ducasse stephane.duca...@free.fr wrote: Hi jorge did you publish the cleans for the tests you did during the sprint? Thanks Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli http://www.lukas-renggli.ch -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About long tests.
focus on the paper jorge coding only for the fun :) We have time. Stef On Mar 16, 2010, at 9:35 AM, Jorge Ressia wrote: Hi, No, I have to finish that. Is still in my todo list. I'll try to make some time today to look into that. Cheers, Jorge On Tue, Mar 16, 2010 at 9:32 AM, Adrian Lienhard a...@netstyle.ch wrote: Yes, it would be very good to have faster tests. In my experience, if tests take too long to run, you don't use them. During the sprint in Lille, Jorge started to sort out long running tests from the rest and make them subclass from SlowTestCase (or something similar). Cheers, Adrian On Mar 16, 2010, at 09:13 , Lukas Renggli wrote: Btw, I am running the Pharo tests in my builds now too: http://hudson.lukas-renggli.ch/job/Pharo/lastCompletedBuild/testReport/(root)/ Click on duration twice to see the tests sorted by run-time. I feel a bit bad that the slowest test case is one that I wrote. I'll see if I can speed that up some more. Lukas On 15 March 2010 20:56, stephane ducasse stephane.duca...@free.fr wrote: Hi jorge did you publish the cleans for the tests you did during the sprint? Thanks Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about long tests
I read a few Pharo posts lately about long tests. In this regard allow me to describe briefly some code I am now writing. I will eventually release this code to SqueakSource and, if the Pharo group is interested, I will port it to run on Pharo as well. I use long tests a lot in development. These tests are not really suitable as SUnit tests because they are too slow and some of them are parameterizable. These tests are meant for finding bugs during development; less so for verifying code still works before a release. However, I decided to use the SUnit idea and code to enhance running these tests. First, I refactored TestCase by giving is a superclass and moving all the TestCase code into its superclass. I then created a class RunnCase which has the same parent class as TestCase. The reason for refactoring TestCase this way is so that if TestRunner is run the classes under RunnCase DO NOT SHOW UP. I now put my long tests into RunnCase subclasses. Note that I believe that TestCase should be so refactored even if you are not interested in using the tools I am building because it allows others to build their own tools just as I am doing. I then subclassed TestRunner with subclass TestPlusRunner. TestPlusRunner allows running the same tests as TestRunner. TestPlusRunner is like TestRunner with a few minor changes including: 1) an extra window that displays individual test case methods when only one class is selected. Subsets of test cases from an single class can be selected and run. 2) (Ignore this paragraph is you like) it has as some additional buttons. Currently the buttons are there but not the functionality. The intent of the buttons is to be able distribute the running of a set of tests over a number of computers and return to one computer only the tests that failed so they can be debugged. Specifically, the intent is to be able to file out a set of tests, send them to another user/computer, have that user/computer run those tests and send back a file containing all the tests that fail, and then be able to load the failed test and debug them. I then subclassed TestPlusRunner with subclass RunnRunner. RunnRunner runs tests of subclasses of RunnTest. RunnRunner is like TestPlusRunner with the ability to set parameters that can affect the running of tests. Currently the only parameter that can be set are a list of size values. For example, if this parameter is set to '3-5,7,9-12' then the tests that are run will be given this parameter and then use this parameter however they want but presumably either ignore it or run the test once with each of the size values: 3,4,5,7,9,10,11,12. Several other parameters are also planned: 1) seed. The seed is a value with which to initialize a random number generator that the tests can optionally use in the generation of test data for the tests. 2) number of subtests. A test may have the ability to generate and run a number of subtests (probably using 1)). This parameters indicates how many subtests to run. 3) subtest start. If a test runs 1000 subtests and then detects a failure then the user may not want to rerun the first 999 subtests before running subtest 1000 again. This parameter allow the subtests to be run starting at subtest #1000. Feedback on this work is most welcome either positive or negative (but constructive). Regardless of opinions, it would be great if the refactoring of TestCase described above were done. It is the way it should have been written in the first place. Note that some additional minor refactoring of TestCase and TestRunner is required. Email me if you want details. Regards, Ralph Boland ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about long tests
On Mar 16, 2010, at 6:28 PM, Ralph Boland wrote: I read a few Pharo posts lately about long tests. In this regard allow me to describe briefly some code I am now writing. I will eventually release this code to SqueakSource and, if the Pharo group is interested, I will port it to run on Pharo as well. did you check the work of adrian kuhn on Sunit? I'm interested in your work but I have to get into it. What I would like is also a better way to which class I want to compute the coverage I use long tests a lot in development. These tests are not really suitable as SUnit tests because they are too slow and some of them are parameterizable. These tests are meant for finding bugs during development; less so for verifying code still works before a release. However, I decided to use the SUnit idea and code to enhance running these tests. First, I refactored TestCase by giving is a superclass and moving all the TestCase code into its superclass. I then created a class RunnCase which has the same parent class as TestCase. The reason for refactoring TestCase this way is so that if TestRunner is run the classes under RunnCase DO NOT SHOW UP. I now put my long tests into RunnCase subclasses. Note that I believe that TestCase should be so refactored even if you are not interested in using the tools I am building because it allows others to build their own tools just as I am doing. I then subclassed TestRunner with subclass TestPlusRunner. TestPlusRunner allows running the same tests as TestRunner. TestPlusRunner is like TestRunner with a few minor changes including: 1) an extra window that displays individual test case methods when only one class is selected. Subsets of test cases from an single class can be selected and run. 2) (Ignore this paragraph is you like) it has as some additional buttons. Currently the buttons are there but not the functionality. The intent of the buttons is to be able distribute the running of a set of tests over a number of computers and return to one computer only the tests that failed so they can be debugged. Specifically, the intent is to be able to file out a set of tests, send them to another user/computer, have that user/computer run those tests and send back a file containing all the tests that fail, and then be able to load the failed test and debug them. I then subclassed TestPlusRunner with subclass RunnRunner. RunnRunner runs tests of subclasses of RunnTest. RunnRunner is like TestPlusRunner with the ability to set parameters that can affect the running of tests. Currently the only parameter that can be set are a list of size values. For example, if this parameter is set to '3-5,7,9-12' then the tests that are run will be given this parameter and then use this parameter however they want but presumably either ignore it or run the test once with each of the size values: 3,4,5,7,9,10,11,12. Several other parameters are also planned: 1) seed. The seed is a value with which to initialize a random number generator that the tests can optionally use in the generation of test data for the tests. 2) number of subtests. A test may have the ability to generate and run a number of subtests (probably using 1)). This parameters indicates how many subtests to run. 3) subtest start. If a test runs 1000 subtests and then detects a failure then the user may not want to rerun the first 999 subtests before running subtest 1000 again. This parameter allow the subtests to be run starting at subtest #1000. Feedback on this work is most welcome either positive or negative (but constructive). Regardless of opinions, it would be great if the refactoring of TestCase described above were done. It is the way it should have been written in the first place. Note that some additional minor refactoring of TestCase and TestRunner is required. Email me if you want details. Regards, Ralph Boland ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About long tests.
Sorry Stef, couldn't resist :) Now there is a distinction between unit tests and the rest of them. Unit tests are depicted as fast and model oriented tests. Later we will have to introduce more kinds of test for enriching our build and development process, tests like functional, architectural, lint, etc. 6942 unit tests run in 34 secs instead than 2:25 min running all tests. I think this will encourage developers to run the tests a little more often. I implemented a fix in the next slice. Name: SLICE-FastAndSlowTestDisociation-JorgeRessia.1 Author: JorgeRessia Time: 16 March 2010, 8:50:41 pm UUID: 9c44289b-bccb-4198-9a98-6dd9979e9bdd Ancestors: Dependencies: Gofer-Tests-JorgeRessia.117, KernelTests-JorgeRessia.164, SUnit-JorgeRessia.86, SUnitGUI-JorgeRessia.45, Tests-JorgeRessia.48 Test cases now answer the message isUnitTest in order to differentiate the unit test from the rest of the tests. - The tests that take too long are no more considered unit tests. - Some test were functional test so there are not considered unit tests. - The TestRunner was modified. A new menu entry can be found in the class pane for selecting all unit tests. Some more fixes here: Name: SLICE-FastAndSlowTestDisociation-JorgeRessia.2 Author: JorgeRessia Time: 16 March 2010, 8:58:11 pm UUID: 86461af2-534b-4091-8f2e-973b650db098 Ancestors: SLICE-FastAndSlowTestDisociation-JorgeRessia.1 Dependencies: Gofer-Tests-JorgeRessia.117, KernelTests-JorgeRessia.164, SUnit-JorgeRessia.87, SUnitGUI-JorgeRessia.45, Tests-JorgeRessia.48 - test fixed Cheers, Jorge On Tue, Mar 16, 2010 at 3:18 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: focus on the paper jorge coding only for the fun :) We have time. Stef On Mar 16, 2010, at 9:35 AM, Jorge Ressia wrote: Hi, No, I have to finish that. Is still in my todo list. I'll try to make some time today to look into that. Cheers, Jorge On Tue, Mar 16, 2010 at 9:32 AM, Adrian Lienhard a...@netstyle.ch wrote: Yes, it would be very good to have faster tests. In my experience, if tests take too long to run, you don't use them. During the sprint in Lille, Jorge started to sort out long running tests from the rest and make them subclass from SlowTestCase (or something similar). Cheers, Adrian On Mar 16, 2010, at 09:13 , Lukas Renggli wrote: Btw, I am running the Pharo tests in my builds now too: http://hudson.lukas-renggli.ch/job/Pharo/lastCompletedBuild/testReport/(root)/ Click on duration twice to see the tests sorted by run-time. I feel a bit bad that the slowest test case is one that I wrote. I'll see if I can speed that up some more. Lukas On 15 March 2010 20:56, stephane ducasse stephane.duca...@free.fr wrote: Hi jorge did you publish the cleans for the tests you did during the sprint? Thanks Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About long tests.
On Mar 16, 2010, at 9:06 PM, Jorge Ressia wrote: Sorry Stef, couldn't resist :) I know the syndrom (noooI do not want to open latex to write . ..) I saw the picture on your board :) Ok once your oopsla paper is done, I would do discuss with you how we integrate - adrian kuhn changes - have a look at SUnit Extension made by Keith I will start to look at that (once I'm with some other papers to write :) Stef Now there is a distinction between unit tests and the rest of them. Unit tests are depicted as fast and model oriented tests. Later we will have to introduce more kinds of test for enriching our build and development process, tests like functional, architectural, lint, etc. 6942 unit tests run in 34 secs instead than 2:25 min running all tests. I think this will encourage developers to run the tests a little more often. I implemented a fix in the next slice. Name: SLICE-FastAndSlowTestDisociation-JorgeRessia.1 Author: JorgeRessia Time: 16 March 2010, 8:50:41 pm UUID: 9c44289b-bccb-4198-9a98-6dd9979e9bdd Ancestors: Dependencies: Gofer-Tests-JorgeRessia.117, KernelTests-JorgeRessia.164, SUnit-JorgeRessia.86, SUnitGUI-JorgeRessia.45, Tests-JorgeRessia.48 Test cases now answer the message isUnitTest in order to differentiate the unit test from the rest of the tests. - The tests that take too long are no more considered unit tests. - Some test were functional test so there are not considered unit tests. - The TestRunner was modified. A new menu entry can be found in the class pane for selecting all unit tests. Some more fixes here: Name: SLICE-FastAndSlowTestDisociation-JorgeRessia.2 Author: JorgeRessia Time: 16 March 2010, 8:58:11 pm UUID: 86461af2-534b-4091-8f2e-973b650db098 Ancestors: SLICE-FastAndSlowTestDisociation-JorgeRessia.1 Dependencies: Gofer-Tests-JorgeRessia.117, KernelTests-JorgeRessia.164, SUnit-JorgeRessia.87, SUnitGUI-JorgeRessia.45, Tests-JorgeRessia.48 - test fixed Cheers, Jorge On Tue, Mar 16, 2010 at 3:18 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: focus on the paper jorge coding only for the fun :) We have time. Stef On Mar 16, 2010, at 9:35 AM, Jorge Ressia wrote: Hi, No, I have to finish that. Is still in my todo list. I'll try to make some time today to look into that. Cheers, Jorge On Tue, Mar 16, 2010 at 9:32 AM, Adrian Lienhard a...@netstyle.ch wrote: Yes, it would be very good to have faster tests. In my experience, if tests take too long to run, you don't use them. During the sprint in Lille, Jorge started to sort out long running tests from the rest and make them subclass from SlowTestCase (or something similar). Cheers, Adrian On Mar 16, 2010, at 09:13 , Lukas Renggli wrote: Btw, I am running the Pharo tests in my builds now too: http://hudson.lukas-renggli.ch/job/Pharo/lastCompletedBuild/testReport/(root)/ Click on duration twice to see the tests sorted by run-time. I feel a bit bad that the slowest test case is one that I wrote. I'll see if I can speed that up some more. Lukas On 15 March 2010 20:56, stephane ducasse stephane.duca...@free.fr wrote: Hi jorge did you publish the cleans for the tests you did during the sprint? Thanks Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
