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

Re: [Pharo-project] what expectedfailures expected to do?

by Peter Hugosson-Miller

On Wed, Apr 21, 2010 at 1:37 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > On Apr 21, 2010, at 11:47 AM, Peter Hugosson-Miller wrote: > > > On Wed, Apr 21, 2010 at 11:34 AM, Tudor Girba <tudor.girba(a)gmail.com> > wrote: > > Basically yes. > > > > It's not just for giving it to someone else, but also for yourself. The > idea is to quickly notice when tests change color (from green to red), so > instead of remembering how many failed before and comparing with the current > number of failures, you simply mark them as expected failures and your bar > becomes green. > > > > Thanks, I think I get it now. > > > > So really, I shouldn't expect to see any expected failures in Pharo 1.0, > but since Pharo 1.1 is still in alpha, it would be OK to have some there > until it's ready for release. > > in a perfect world now in pharo we have tests that are red and we could not > fixed easily. > Ah, OK. I guess it's really a question of perception. The world in which I work is a bit different from the wonderful world of Pharo (no sarcasm intended!), in that we can't ship *anything* unless *all* our tests are green. The concept of "expected failures" just has no place, because as long as there are failures we still have work to do. I can understand Doru's description of an expected failure as a kind of bookmark, to be added and discarded during the day, but I get a bit nervous that the sight of too much green might make me miss the fact that I'm not finished yet :-p > -- > > Cheers, > > Peter > > > > Doru > > > > > > > > On 21 Apr 2010, at 11:28, Peter Hugosson-Miller wrote: > > > > Thanks for answering, Doru! > > > > So if I've understood you correctly, expected failures are useful when > one wants to give some code to someone else, with all the tests running > green, but at the same time let that person know that some specific tests > are really still red, but known about. In other words, are they simply a way > of documenting "work in progress", and not for production code? > > > > -- > > Cheers, > > Peter > > > > On Wed, Apr 21, 2010 at 11:12 AM, Tudor Girba <tudor.girba(a)gmail.com> > wrote: > > Hi, > > > > The idea behind this is that you can use unit tests to document things > you have not done yet, or bugs that you know about but you do not want to > spend time working on right now. > > > > Simply reverting the assertion in your test does make the test runner > green, but it fails to document the intention, and a newcomer might get to > the false conclusion that the answer is not 42. By marking the test as > expected failure, you make the test runner green, but you also explicitly > say that the answer should be 42, but the machine is not quite perfect yet. > > > > Cheers, > > Doru > > > > > > > > On 21 Apr 2010, at 11:06, Peter Hugosson-Miller wrote: > > > > I'm trying to follow along with this discussion, but now I feel really > stupid :-( > > > > I've been using SUnit since 1998 (when it was still called > "BeckTestingFramework"), and ever since "expected failures" showed up, I've > never understood them. So I wonder if some kind guru-like person could > please explain to me what they are useful for? I mean, to my way of > thinking, if one writes a test that is expected to fail, then why not invert > the test and call it a success instead? > > > > for example: > > > > self should: [answer = 42] > > > > ...as an expected failure could simply be re-written as > > > > self should: [answer ~= 42] > > > > ...right? No, obviously I've missed something really obvious and > important, and that's why I'm asking the question now. Please be gentle ;-) > > > > -- > > Cheers, > > Peter > > > > On Wed, Apr 21, 2010 at 10:30 AM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > > We should have a look at what adrian did now the problem is that > understanding a large set of changes is more difficult than a couple of > simple ones. > > If somebody want to help we are open. > > Stef > > > > > > > I think Adrian Kuhn did that in his SUnit work. I also remember he also > introduced a difference between expectedFailures and expectedErrors. > > > > > > Doru > > > > > > > > > On 21 Apr 2010, at 10:16, StÃ©phane Ducasse wrote: > > > > > >> > > >> On Apr 21, 2010, at 9:51 AM, Adrian Lienhard wrote: > > >> > > >>> Yea, I agree, the GUI is suboptimal. > > >>> > > >>> I still think, though, that treating this case as a failure is > correct. For instance, consider the case where you had added a workaround to > a known bug and when the bug is fixed you need to remove the workaround > again. Maybe it even leads to a wrong behavior now that the bug is gone. In > this case you really want to know that the test does not fail anymore. > > >> > > >> yes > > >> Now I have the impression that expectedFailures should be like passes, > failed, errors: a state of the tests. > > >> > > >> Stef > > >> > > >>> In any case, I think that tagging methods as expected failures should > be done with pragmas and not with #expectedFailures. Like this it would also > be much easier to understand what's going on when you have a failure in this > test although all assertions pass. > > >>> > > >>> Adrian > > >>> > > >>> On Apr 21, 2010, at 08:22 , StÃ©phane Ducasse wrote: > > >>> > > >>>> > > >>>> On Apr 20, 2010, at 11:20 PM, Adrian Lienhard wrote: > > >>>> > > >>>>> Yes, if a test that is expected to fail does not fail, this is > treated as a failure. I think that makes sense. > > >>>> > > >>>> well it depends about the scenario. > > >>>> you put on expectedfailures something that gets in your way now, so > after if it works even better. > > >>>> of course you should get notified that the test is green while > expected it to failed. > > >>>> > > >>>> Now it leads to a UI problem where you have a failure that passes so > when you click on it nothing happens: no debugger. > > >>>> And you can wonder why the hell do I have a failure when my tests > pass. > > >>>> > > >>>> So I think that this implementation of expectedFailures is a hack. > > >>>> > > >>>>> > > >>>>> Adrian > > >>>>> > > >>>>> On Apr 20, 2010, at 21:57 , StÃ©phane Ducasse wrote: > > >>>>> > > >>>>>> Hi > > >>>>>> > > >>>>>> I tagged some tests as expected failures and I got a strange > behavior. > > >>>>>> On the the tests which was passing was listed under the failures. > > >>>>>> When I renamed the method without updating the expected failures > my bar was green. > > >>>>>> So expected failures really expect that the tests failed? We > cannto have green tests in there? > > >>>>>> > > >>>>>> 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 > > >>> > > >>> > > >>> _______________________________________________ > > >>> 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 > > > > > > -- > > > www.tudorgirba.com > > > > > > "Live like you mean it." > > > > > > > > > _______________________________________________ > > > 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 > > > > -- > > www.tudorgirba.com > > > > "Reasonable is what we are accustomed with." > > > > > > > > _______________________________________________ > > 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 > > > > -- > > www.tudorgirba.com > > > > "Beauty is where we see it." > > > > > > > > > > > > _______________________________________________ > > 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 > -- Cheers, Peter

April 21, 2010

Re: [Pharo-project] setting a custom header for HTTP via CurlPlugin

by StÃ©phane Ducasse

On Apr 21, 2010, at 1:48 PM, Saris Hein wrote: > Hi, > > I am trying to get some stuff done with REST using Pharo. > So far, I am able to do GETs, but I am unable to do PUTs because the REST service expects the content sent to be JSON. > For this to work, I need to set the Content-Type of the request to 'application/json'. > I have successfully installed the CurlPlugin via Gofer (version 25 from dao), and thanks to John (M. McIntosh), who provided me with a new version of the bundle for Mac, I was able to pass all the tests, except for the testApiOptions test, which fails on the timeout: test. > The version John provided me with is 2.0.0. I first tried with version 1.1.0, but that failed on 13 tests due to a primitive that failed constantly (<primitive: 'primSetOptLong' module: 'CurlPlugin'>). > There is a method addHeader: in the plugin, but it does not seem to do anything useful. > > I have found a blog (Jazz Programming) by Giovanni Corriga, who claims to have a version of the plugin that allows for custom headers to be set, but the link to his version gives a 304 error. Plus the blog dates from 2007. > > Having a version of the CurlPlugin that allows me to set a custom header would be great, so if anybody has one, please let me know. But what I would really like to have is a good implementation of the HTTP protocol in Squeak/Pharo, so that we are not dependent on a plugin. me too. Did you discuss with janko? Because he was proposing a project on exactly this topic. > The standard HTTP client in Squeak/Pharo is based on HttpSocket, and is only a partial implementation of the HTTP protocol (it only supports GETs as far as I can tell). > > Does anyone know of another way to do basic HTTP in Squeak/Pharo? > > Regards, > > Hein > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 21, 2010

[Pharo-project] setting a custom header for HTTP via CurlPlugin

by Saris Hein

Hi, I am trying to get some stuff done with REST using Pharo. So far, I am able to do GETs, but I am unable to do PUTs because the REST service expects the content sent to be JSON. For this to work, I need to set the Content-Type of the request to 'application/json'. I have successfully installed the CurlPlugin via Gofer (version 25 from dao), and thanks to John (M. McIntosh), who provided me with a new version of the bundle for Mac, I was able to pass all the tests, except for the testApiOptions test, which fails on the timeout: test. The version John provided me with is 2.0.0. I first tried with version 1.1.0, but that failed on 13 tests due to a primitive that failed constantly (<primitive: 'primSetOptLong' module: 'CurlPlugin'>). There is a method addHeader: in the plugin, but it does not seem to do anything useful. I have found a blog (Jazz Programming) by Giovanni Corriga, who claims to have a version of the plugin that allows for custom headers to be set, but the link to his version gives a 304 error. Plus the blog dates from 2007. Having a version of the CurlPlugin that allows me to set a custom header would be great, so if anybody has one, please let me know. But what I would really like to have is a good implementation of the HTTP protocol in Squeak/Pharo, so that we are not dependent on a plugin. The standard HTTP client in Squeak/Pharo is based on HttpSocket, and is only a partial implementation of the HTTP protocol (it only supports GETs as far as I can tell). Does anyone know of another way to do basic HTTP in Squeak/Pharo? Regards, Hein

April 21, 2010

Re: [Pharo-project] FEATURE: User chooses preferred location for MC directory repositories

by StÃ©phane Ducasse

cool! On Apr 21, 2010, at 1:26 PM, laurent laffont wrote: > Here http://book.pharo-project.org/book/TipsAndTricks/PharoRC > > Can someone adapt it for Windows ? > > Cheers, > > Laurent Laffont > > > On Wed, Apr 21, 2010 at 8:56 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Cool I will do that too. > Can you create a book entry with that because this is cool :) > > Stef > > On Apr 21, 2010, at 8:40 AM, laurent laffont wrote: > > > > > > > On Tue, Apr 20, 2010 at 11:21 PM, Michael Roberts <mike(a)mjr104.co.uk> wrote: > > i'm not sure what either of you mean. I want there to be no UI choice > > and the system just looks higher up in the file system hierarchy. > > > > certainly environment variables or a .pharorc style file would solve this. > > > > > > On my machine I've written these files: > > ~/.pharorc.st > > > > Author fullName: 'LaurentLaffont'. > > > > MCRepositoryGroup default addRepository: > > (MCDirectoryRepository new directory: > > (FileDirectory on: '/home/laurent/pharo/repository')). > > > > Then > > > > ~/bin/pharo: > > > > #!/bin/sh > > squeak $1 ~/.pharorc.st > > > > > > Then I launch my image with: > > pharo /path/to/my.image > > > > Author and repository always set for every image. Very emacs-like :) > > > > Cheers, > > > > Laurent Laffont > > > > > > > > thanks, > > Mike > > > > On Tue, Apr 20, 2010 at 6:33 PM, Chris Muller <asqueaker(a)gmail.com> wrote: > > > Whether the user is required to specify a "default directory" or a > > > directory to a repository, it's the same task isn't it? > > > > > > Once you add it once to MC, it can be "added" to any other package. > > > So this defaultDirectory would seem to be a feature not worth its > > > weight.. > > > > > > > > > On Mon, Apr 19, 2010 at 6:00 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > >> > > >> http://code.google.com/p/pharo/issues/detail?id=2329 > > >> > > >> Pharo image: Pharo 1.0 > > >> > > >> In Monticello Browser, when I click "+Repository" and select "directory," > > >> I'd love to be taken right to the directory where I keep my local > > >> repositories, instead of having to click to the same place over and over. > > >> > > >> I changed the following method: > > >> MCDirectoryRepository class>>morphicConfigure > > >> ^ (UIManager default chooseDirectoryFrom: (FileDirectory on: > > >> '/path/to/my/Repositories')) ifNotNil: > > >> [:directory | > > >> self new directory: directory] > > >> > > >> How should I store the default repository directory? Would anyone else find > > >> this helpful? > > >> > > >> Sean DeNigris > > >> -- > > >> View this message in context: http://n4.nabble.com/FEATURE-User-chooses-preferred-location-for-MC-directo… > > >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > >> > > >> _______________________________________________ > > >> 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 > > > _______________________________________________ > 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

April 21, 2010

Re: [Pharo-project] what expectedfailures expected to do?

by StÃ©phane Ducasse

On Apr 21, 2010, at 11:47 AM, Peter Hugosson-Miller wrote: > On Wed, Apr 21, 2010 at 11:34 AM, Tudor Girba <tudor.girba(a)gmail.com> wrote: > Basically yes. > > It's not just for giving it to someone else, but also for yourself. The idea is to quickly notice when tests change color (from green to red), so instead of remembering how many failed before and comparing with the current number of failures, you simply mark them as expected failures and your bar becomes green. > > Thanks, I think I get it now. > > So really, I shouldn't expect to see any expected failures in Pharo 1.0, but since Pharo 1.1 is still in alpha, it would be OK to have some there until it's ready for release. in a perfect world now in pharo we have tests that are red and we could not fixed easily. > -- > Cheers, > Peter > > Doru > > > > On 21 Apr 2010, at 11:28, Peter Hugosson-Miller wrote: > > Thanks for answering, Doru! > > So if I've understood you correctly, expected failures are useful when one wants to give some code to someone else, with all the tests running green, but at the same time let that person know that some specific tests are really still red, but known about. In other words, are they simply a way of documenting "work in progress", and not for production code? > > -- > Cheers, > Peter > > On Wed, Apr 21, 2010 at 11:12 AM, Tudor Girba <tudor.girba(a)gmail.com> wrote: > Hi, > > The idea behind this is that you can use unit tests to document things you have not done yet, or bugs that you know about but you do not want to spend time working on right now. > > Simply reverting the assertion in your test does make the test runner green, but it fails to document the intention, and a newcomer might get to the false conclusion that the answer is not 42. By marking the test as expected failure, you make the test runner green, but you also explicitly say that the answer should be 42, but the machine is not quite perfect yet. > > Cheers, > Doru > > > > On 21 Apr 2010, at 11:06, Peter Hugosson-Miller wrote: > > I'm trying to follow along with this discussion, but now I feel really stupid :-( > > I've been using SUnit since 1998 (when it was still called "BeckTestingFramework"), and ever since "expected failures" showed up, I've never understood them. So I wonder if some kind guru-like person could please explain to me what they are useful for? I mean, to my way of thinking, if one writes a test that is expected to fail, then why not invert the test and call it a success instead? > > for example: > > self should: [answer = 42] > > ...as an expected failure could simply be re-written as > > self should: [answer ~= 42] > > ...right? No, obviously I've missed something really obvious and important, and that's why I'm asking the question now. Please be gentle ;-) > > -- > Cheers, > Peter > > On Wed, Apr 21, 2010 at 10:30 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > We should have a look at what adrian did now the problem is that understanding a large set of changes is more difficult than a couple of simple ones. > If somebody want to help we are open. > Stef > > > > I think Adrian Kuhn did that in his SUnit work. I also remember he also introduced a difference between expectedFailures and expectedErrors. > > > > Doru > > > > > > On 21 Apr 2010, at 10:16, StÃ©phane Ducasse wrote: > > > >> > >> On Apr 21, 2010, at 9:51 AM, Adrian Lienhard wrote: > >> > >>> Yea, I agree, the GUI is suboptimal. > >>> > >>> I still think, though, that treating this case as a failure is correct. For instance, consider the case where you had added a workaround to a known bug and when the bug is fixed you need to remove the workaround again. Maybe it even leads to a wrong behavior now that the bug is gone. In this case you really want to know that the test does not fail anymore. > >> > >> yes > >> Now I have the impression that expectedFailures should be like passes, failed, errors: a state of the tests. > >> > >> Stef > >> > >>> In any case, I think that tagging methods as expected failures should be done with pragmas and not with #expectedFailures. Like this it would also be much easier to understand what's going on when you have a failure in this test although all assertions pass. > >>> > >>> Adrian > >>> > >>> On Apr 21, 2010, at 08:22 , StÃ©phane Ducasse wrote: > >>> > >>>> > >>>> On Apr 20, 2010, at 11:20 PM, Adrian Lienhard wrote: > >>>> > >>>>> Yes, if a test that is expected to fail does not fail, this is treated as a failure. I think that makes sense. > >>>> > >>>> well it depends about the scenario. > >>>> you put on expectedfailures something that gets in your way now, so after if it works even better. > >>>> of course you should get notified that the test is green while expected it to failed. > >>>> > >>>> Now it leads to a UI problem where you have a failure that passes so when you click on it nothing happens: no debugger. > >>>> And you can wonder why the hell do I have a failure when my tests pass. > >>>> > >>>> So I think that this implementation of expectedFailures is a hack. > >>>> > >>>>> > >>>>> Adrian > >>>>> > >>>>> On Apr 20, 2010, at 21:57 , StÃ©phane Ducasse wrote: > >>>>> > >>>>>> Hi > >>>>>> > >>>>>> I tagged some tests as expected failures and I got a strange behavior. > >>>>>> On the the tests which was passing was listed under the failures. > >>>>>> When I renamed the method without updating the expected failures my bar was green. > >>>>>> So expected failures really expect that the tests failed? We cannto have green tests in there? > >>>>>> > >>>>>> 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 > >>> > >>> > >>> _______________________________________________ > >>> 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 > > > > -- > > www.tudorgirba.com > > > > "Live like you mean it." > > > > > > _______________________________________________ > > 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 > > -- > www.tudorgirba.com > > "Reasonable is what we are accustomed with." > > > > _______________________________________________ > 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 > > -- > www.tudorgirba.com > > "Beauty is where we see it." > > > > > > _______________________________________________ > 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

April 21, 2010

Re: [Pharo-project] what expectedfailures expected to do?

by StÃ©phane Ducasse

On Apr 21, 2010, at 11:06 AM, Peter Hugosson-Miller wrote: > I'm trying to follow along with this discussion, but now I feel really stupid :-( > > I've been using SUnit since 1998 (when it was still called "BeckTestingFramework"), testingFramework on VW :) > and ever since "expected failures" showed up, I've never understood them. So I wonder if some kind guru-like person could please explain to me what they are useful for? I mean, to my way of thinking, if one writes a test that is expected to fail, then why not invert the test and call it a success instead? > > for example: > > self should: [answer = 42] self assert: answer = 42 because [] are for self should: [] raise: Error and friend > > ...as an expected failure could simply be re-written as > > self should: [answer ~= 42] > > ...right? No, obviously I've missed something really obvious and important, and that's why I'm asking the question now. Please be gentle ;-) > > -- > Cheers, > Peter > > On Wed, Apr 21, 2010 at 10:30 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > We should have a look at what adrian did now the problem is that understanding a large set of changes is more difficult than a couple of simple ones. > If somebody want to help we are open. > Stef > > > > I think Adrian Kuhn did that in his SUnit work. I also remember he also introduced a difference between expectedFailures and expectedErrors. > > > > Doru > > > > > > On 21 Apr 2010, at 10:16, StÃ©phane Ducasse wrote: > > > >> > >> On Apr 21, 2010, at 9:51 AM, Adrian Lienhard wrote: > >> > >>> Yea, I agree, the GUI is suboptimal. > >>> > >>> I still think, though, that treating this case as a failure is correct. For instance, consider the case where you had added a workaround to a known bug and when the bug is fixed you need to remove the workaround again. Maybe it even leads to a wrong behavior now that the bug is gone. In this case you really want to know that the test does not fail anymore. > >> > >> yes > >> Now I have the impression that expectedFailures should be like passes, failed, errors: a state of the tests. > >> > >> Stef > >> > >>> In any case, I think that tagging methods as expected failures should be done with pragmas and not with #expectedFailures. Like this it would also be much easier to understand what's going on when you have a failure in this test although all assertions pass. > >>> > >>> Adrian > >>> > >>> On Apr 21, 2010, at 08:22 , StÃ©phane Ducasse wrote: > >>> > >>>> > >>>> On Apr 20, 2010, at 11:20 PM, Adrian Lienhard wrote: > >>>> > >>>>> Yes, if a test that is expected to fail does not fail, this is treated as a failure. I think that makes sense. > >>>> > >>>> well it depends about the scenario. > >>>> you put on expectedfailures something that gets in your way now, so after if it works even better. > >>>> of course you should get notified that the test is green while expected it to failed. > >>>> > >>>> Now it leads to a UI problem where you have a failure that passes so when you click on it nothing happens: no debugger. > >>>> And you can wonder why the hell do I have a failure when my tests pass. > >>>> > >>>> So I think that this implementation of expectedFailures is a hack. > >>>> > >>>>> > >>>>> Adrian > >>>>> > >>>>> On Apr 20, 2010, at 21:57 , StÃ©phane Ducasse wrote: > >>>>> > >>>>>> Hi > >>>>>> > >>>>>> I tagged some tests as expected failures and I got a strange behavior. > >>>>>> On the the tests which was passing was listed under the failures. > >>>>>> When I renamed the method without updating the expected failures my bar was green. > >>>>>> So expected failures really expect that the tests failed? We cannto have green tests in there? > >>>>>> > >>>>>> 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 > >>> > >>> > >>> _______________________________________________ > >>> 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 > > > > -- > > www.tudorgirba.com > > > > "Live like you mean it." > > > > > > _______________________________________________ > > 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

April 21, 2010

Re: [Pharo-project] FEATURE: User chooses preferred location for MC directory repositories

by laurent laffont

Here http://book.pharo-project.org/book/TipsAndTricks/PharoRC Can someone adapt it for Windows ? Cheers, Laurent Laffont On Wed, Apr 21, 2010 at 8:56 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Cool I will do that too. > Can you create a book entry with that because this is cool :) > > Stef > > On Apr 21, 2010, at 8:40 AM, laurent laffont wrote: > > > > > > > On Tue, Apr 20, 2010 at 11:21 PM, Michael Roberts <mike(a)mjr104.co.uk> > wrote: > > i'm not sure what either of you mean. I want there to be no UI choice > > and the system just looks higher up in the file system hierarchy. > > > > certainly environment variables or a .pharorc style file would solve > this. > > > > > > On my machine I've written these files: > > ~/.pharorc.st > > > > Author fullName: 'LaurentLaffont'. > > > > MCRepositoryGroup default addRepository: > > (MCDirectoryRepository new directory: > > (FileDirectory on: > '/home/laurent/pharo/repository')). > > > > Then > > > > ~/bin/pharo: > > > > #!/bin/sh > > squeak $1 ~/.pharorc.st > > > > > > Then I launch my image with: > > pharo /path/to/my.image > > > > Author and repository always set for every image. Very emacs-like :) > > > > Cheers, > > > > Laurent Laffont > > > > > > > > thanks, > > Mike > > > > On Tue, Apr 20, 2010 at 6:33 PM, Chris Muller <asqueaker(a)gmail.com> > wrote: > > > Whether the user is required to specify a "default directory" or a > > > directory to a repository, it's the same task isn't it? > > > > > > Once you add it once to MC, it can be "added" to any other package. > > > So this defaultDirectory would seem to be a feature not worth its > > > weight.. > > > > > > > > > On Mon, Apr 19, 2010 at 6:00 PM, Sean P. DeNigris < > sean(a)clipperadams.com> wrote: > > >> > > >> http://code.google.com/p/pharo/issues/detail?id=2329 > > >> > > >> Pharo image: Pharo 1.0 > > >> > > >> In Monticello Browser, when I click "+Repository" and select > "directory," > > >> I'd love to be taken right to the directory where I keep my local > > >> repositories, instead of having to click to the same place over and > over. > > >> > > >> I changed the following method: > > >> MCDirectoryRepository class>>morphicConfigure > > >> ^ (UIManager default chooseDirectoryFrom: (FileDirectory on: > > >> '/path/to/my/Repositories')) ifNotNil: > > >> [:directory | > > >> self new directory: directory] > > >> > > >> How should I store the default repository directory? Would anyone > else find > > >> this helpful? > > >> > > >> Sean DeNigris > > >> -- > > >> View this message in context: > http://n4.nabble.com/FEATURE-User-chooses-preferred-location-for-MC-directo… > > >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > >> > > >> _______________________________________________ > > >> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 21, 2010

Re: [Pharo-project] [Vm-dev] Running Alien on Windows

by David T. Lewis

On Tue, Apr 20, 2010 at 09:23:36PM -0700, Andreas Raab wrote: > > On 4/20/2010 10:24 AM, Torsten Bergmann wrote: > > > >Dont know what should be the next steps to get Alien > >into the Win32-VM code base. Maybe Andreas could tell > >you more. > > Perhaps David and/or Eliot can help? From my perspective this issue > doesn't really belong with the Windows VM but rather with the VMMaker > package. I just build whatever is in there, so if Alien support is in, > then I'll build it together with everything else. > > Cheers, > - Andreas Yes, I'll be glad to help. I'll look at it as soon as possible (probably not until this weekend though). Dave > > > >[1] > >http://lists.squeakfoundation.org/pipermail/vm-dev/2010-March/003983.html > >[2] http://code.google.com/p/pharo/issues/detail?id=1360 > >[3] http://bugs.squeak.org/view.php?id=7475 > >[4] > >http://lists.squeakfoundation.org/pipermail/vm-dev/2010-March/004034.html > >[5] > >http://lists.squeakfoundation.org/pipermail/vm-dev/2010-March/004037.html > >[6] > >http://lists.squeakfoundation.org/pipermail/vm-dev/2010-March/004054.html > >[7] http://lists.squeakfoundation.org/pipermail/vm-dev/2010- > >March/004103.html > >

April 21, 2010

Re: [Pharo-project] what expectedfailures expected to do?

by Peter Hugosson-Miller

On Wed, Apr 21, 2010 at 11:34 AM, Tudor Girba <tudor.girba(a)gmail.com> wrote: > Basically yes. > > It's not just for giving it to someone else, but also for yourself. The > idea is to quickly notice when tests change color (from green to red), so > instead of remembering how many failed before and comparing with the current > number of failures, you simply mark them as expected failures and your bar > becomes green. > Thanks, I think I get it now. So really, I shouldn't expect to see any expected failures in Pharo 1.0, but since Pharo 1.1 is still in alpha, it would be OK to have some there until it's ready for release. -- Cheers, Peter > Doru > > > > On 21 Apr 2010, at 11:28, Peter Hugosson-Miller wrote: > > Thanks for answering, Doru! >> >> So if I've understood you correctly, expected failures are useful when one >> wants to give some code to someone else, with all the tests running green, >> but at the same time let that person know that some specific tests are >> really still red, but known about. In other words, are they simply a way of >> documenting "work in progress", and not for production code? >> >> -- >> Cheers, >> Peter >> >> On Wed, Apr 21, 2010 at 11:12 AM, Tudor Girba <tudor.girba(a)gmail.com> >> wrote: >> Hi, >> >> The idea behind this is that you can use unit tests to document things you >> have not done yet, or bugs that you know about but you do not want to spend >> time working on right now. >> >> Simply reverting the assertion in your test does make the test runner >> green, but it fails to document the intention, and a newcomer might get to >> the false conclusion that the answer is not 42. By marking the test as >> expected failure, you make the test runner green, but you also explicitly >> say that the answer should be 42, but the machine is not quite perfect yet. >> >> Cheers, >> Doru >> >> >> >> On 21 Apr 2010, at 11:06, Peter Hugosson-Miller wrote: >> >> I'm trying to follow along with this discussion, but now I feel really >> stupid :-( >> >> I've been using SUnit since 1998 (when it was still called >> "BeckTestingFramework"), and ever since "expected failures" showed up, I've >> never understood them. So I wonder if some kind guru-like person could >> please explain to me what they are useful for? I mean, to my way of >> thinking, if one writes a test that is expected to fail, then why not invert >> the test and call it a success instead? >> >> for example: >> >> self should: [answer = 42] >> >> ...as an expected failure could simply be re-written as >> >> self should: [answer ~= 42] >> >> ...right? No, obviously I've missed something really obvious and >> important, and that's why I'm asking the question now. Please be gentle ;-) >> >> -- >> Cheers, >> Peter >> >> On Wed, Apr 21, 2010 at 10:30 AM, StÃ©phane Ducasse < >> stephane.ducasse(a)inria.fr> wrote: >> We should have a look at what adrian did now the problem is that >> understanding a large set of changes is more difficult than a couple of >> simple ones. >> If somebody want to help we are open. >> Stef >> >> >> > I think Adrian Kuhn did that in his SUnit work. I also remember he also >> introduced a difference between expectedFailures and expectedErrors. >> > >> > Doru >> > >> > >> > On 21 Apr 2010, at 10:16, StÃ©phane Ducasse wrote: >> > >> >> >> >> On Apr 21, 2010, at 9:51 AM, Adrian Lienhard wrote: >> >> >> >>> Yea, I agree, the GUI is suboptimal. >> >>> >> >>> I still think, though, that treating this case as a failure is >> correct. For instance, consider the case where you had added a workaround to >> a known bug and when the bug is fixed you need to remove the workaround >> again. Maybe it even leads to a wrong behavior now that the bug is gone. In >> this case you really want to know that the test does not fail anymore. >> >> >> >> yes >> >> Now I have the impression that expectedFailures should be like passes, >> failed, errors: a state of the tests. >> >> >> >> Stef >> >> >> >>> In any case, I think that tagging methods as expected failures should >> be done with pragmas and not with #expectedFailures. Like this it would also >> be much easier to understand what's going on when you have a failure in this >> test although all assertions pass. >> >>> >> >>> Adrian >> >>> >> >>> On Apr 21, 2010, at 08:22 , StÃ©phane Ducasse wrote: >> >>> >> >>>> >> >>>> On Apr 20, 2010, at 11:20 PM, Adrian Lienhard wrote: >> >>>> >> >>>>> Yes, if a test that is expected to fail does not fail, this is >> treated as a failure. I think that makes sense. >> >>>> >> >>>> well it depends about the scenario. >> >>>> you put on expectedfailures something that gets in your way now, so >> after if it works even better. >> >>>> of course you should get notified that the test is green while >> expected it to failed. >> >>>> >> >>>> Now it leads to a UI problem where you have a failure that passes so >> when you click on it nothing happens: no debugger. >> >>>> And you can wonder why the hell do I have a failure when my tests >> pass. >> >>>> >> >>>> So I think that this implementation of expectedFailures is a hack. >> >>>> >> >>>>> >> >>>>> Adrian >> >>>>> >> >>>>> On Apr 20, 2010, at 21:57 , StÃ©phane Ducasse wrote: >> >>>>> >> >>>>>> Hi >> >>>>>> >> >>>>>> I tagged some tests as expected failures and I got a strange >> behavior. >> >>>>>> On the the tests which was passing was listed under the failures. >> >>>>>> When I renamed the method without updating the expected failures my >> bar was green. >> >>>>>> So expected failures really expect that the tests failed? We cannto >> have green tests in there? >> >>>>>> >> >>>>>> 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 >> >>> >> >>> >> >>> _______________________________________________ >> >>> 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 >> > >> > -- >> > www.tudorgirba.com >> > >> > "Live like you mean it." >> > >> > >> > _______________________________________________ >> > 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 >> >> -- >> www.tudorgirba.com >> >> "Reasonable is what we are accustomed with." >> >> >> >> _______________________________________________ >> 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 >> > > -- > www.tudorgirba.com > > "Beauty is where we see it." > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 21, 2010

Re: [Pharo-project] what expectedfailures expected to do?

by Tudor Girba

Basically yes. It's not just for giving it to someone else, but also for yourself. The idea is to quickly notice when tests change color (from green to red), so instead of remembering how many failed before and comparing with the current number of failures, you simply mark them as expected failures and your bar becomes green. Doru On 21 Apr 2010, at 11:28, Peter Hugosson-Miller wrote: > Thanks for answering, Doru! > > So if I've understood you correctly, expected failures are useful > when one wants to give some code to someone else, with all the tests > running green, but at the same time let that person know that some > specific tests are really still red, but known about. In other > words, are they simply a way of documenting "work in progress", and > not for production code? > > -- > Cheers, > Peter > > On Wed, Apr 21, 2010 at 11:12 AM, Tudor Girba > <tudor.girba(a)gmail.com> wrote: > Hi, > > The idea behind this is that you can use unit tests to document > things you have not done yet, or bugs that you know about but you do > not want to spend time working on right now. > > Simply reverting the assertion in your test does make the test > runner green, but it fails to document the intention, and a newcomer > might get to the false conclusion that the answer is not 42. By > marking the test as expected failure, you make the test runner > green, but you also explicitly say that the answer should be 42, but > the machine is not quite perfect yet. > > Cheers, > Doru > > > > On 21 Apr 2010, at 11:06, Peter Hugosson-Miller wrote: > > I'm trying to follow along with this discussion, but now I feel > really stupid :-( > > I've been using SUnit since 1998 (when it was still called > "BeckTestingFramework"), and ever since "expected failures" showed > up, I've never understood them. So I wonder if some kind guru-like > person could please explain to me what they are useful for? I mean, > to my way of thinking, if one writes a test that is expected to > fail, then why not invert the test and call it a success instead? > > for example: > > self should: [answer = 42] > > ...as an expected failure could simply be re-written as > > self should: [answer ~= 42] > > ...right? No, obviously I've missed something really obvious and > important, and that's why I'm asking the question now. Please be > gentle ;-) > > -- > Cheers, > Peter > > On Wed, Apr 21, 2010 at 10:30 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > > wrote: > We should have a look at what adrian did now the problem is that > understanding a large set of changes is more difficult than a couple > of simple ones. > If somebody want to help we are open. > Stef > > > > I think Adrian Kuhn did that in his SUnit work. I also remember he > also introduced a difference between expectedFailures and > expectedErrors. > > > > Doru > > > > > > On 21 Apr 2010, at 10:16, StÃ©phane Ducasse wrote: > > > >> > >> On Apr 21, 2010, at 9:51 AM, Adrian Lienhard wrote: > >> > >>> Yea, I agree, the GUI is suboptimal. > >>> > >>> I still think, though, that treating this case as a failure is > correct. For instance, consider the case where you had added a > workaround to a known bug and when the bug is fixed you need to > remove the workaround again. Maybe it even leads to a wrong behavior > now that the bug is gone. In this case you really want to know that > the test does not fail anymore. > >> > >> yes > >> Now I have the impression that expectedFailures should be like > passes, failed, errors: a state of the tests. > >> > >> Stef > >> > >>> In any case, I think that tagging methods as expected failures > should be done with pragmas and not with #expectedFailures. Like > this it would also be much easier to understand what's going on when > you have a failure in this test although all assertions pass. > >>> > >>> Adrian > >>> > >>> On Apr 21, 2010, at 08:22 , StÃ©phane Ducasse wrote: > >>> > >>>> > >>>> On Apr 20, 2010, at 11:20 PM, Adrian Lienhard wrote: > >>>> > >>>>> Yes, if a test that is expected to fail does not fail, this is > treated as a failure. I think that makes sense. > >>>> > >>>> well it depends about the scenario. > >>>> you put on expectedfailures something that gets in your way > now, so after if it works even better. > >>>> of course you should get notified that the test is green while > expected it to failed. > >>>> > >>>> Now it leads to a UI problem where you have a failure that > passes so when you click on it nothing happens: no debugger. > >>>> And you can wonder why the hell do I have a failure when my > tests pass. > >>>> > >>>> So I think that this implementation of expectedFailures is a > hack. > >>>> > >>>>> > >>>>> Adrian > >>>>> > >>>>> On Apr 20, 2010, at 21:57 , StÃ©phane Ducasse wrote: > >>>>> > >>>>>> Hi > >>>>>> > >>>>>> I tagged some tests as expected failures and I got a strange > behavior. > >>>>>> On the the tests which was passing was listed under the > failures. > >>>>>> When I renamed the method without updating the expected > failures my bar was green. > >>>>>> So expected failures really expect that the tests failed? We > cannto have green tests in there? > >>>>>> > >>>>>> 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 > >>> > >>> > >>> _______________________________________________ > >>> 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 > > > > -- > > www.tudorgirba.com > > > > "Live like you mean it." > > > > > > _______________________________________________ > > 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 > > -- > www.tudorgirba.com > > "Reasonable is what we are accustomed with." > > > > _______________________________________________ > 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 -- www.tudorgirba.com "Beauty is where we see it."

April 21, 2010