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

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

by Peter Hugosson-Miller

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 >

April 21, 2010

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

by Tudor Girba

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."

April 21, 2010

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

by Peter Hugosson-Miller

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 >

April 21, 2010

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

by StÃ©phane Ducasse

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

April 21, 2010

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

by Tudor Girba

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."

April 21, 2010

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

by StÃ©phane Ducasse

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

April 21, 2010

[Pharo-project] Next smalltalk meetup cologne in june

by Norbert Hartl

Please join us on the 10th of June for the next Cologne Smalltalk User Meetup. Anyone interested in Smalltalk is invited, regardless if you only recently discovered the magic of doing things the Smalltalk way, are a die hard VM-Hacker, want to share your experience on web-development in Seaside or like to chit-chat while enjoying a KÃ¶lsch. Weâre gonna meet at 7pm at Vision Factory GmbH SÃ¶mmeringstr. 75 50823 KÃ¶ln (across the yard at the rear house) If you would like to do a presentation just let us know. Further information you'll find on http://colstme.selfish.org/ regards, Norbert

April 21, 2010

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

by Adrian Lienhard

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. 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

April 21, 2010

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

by Michael Roberts

That's cool but we should look to resolve the rc file or env variables in the image then it doesn't rely on correctly configuring the command line invocation. shouldn't be too hard. I appreciate I hijacked this thread somewhat.... Cheers mike On Wednesday, April 21, 2010, 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 >> >> ______________________________________________

April 21, 2010

Re: [Pharo-project] FFI in 1.1

by StÃ©phane Ducasse

On Apr 21, 2010, at 9:06 AM, StÃ©phane Ducasse wrote: > > On Apr 21, 2010, at 12:09 AM, Eliot Miranda wrote: > >> Hi All, >> >> 2010/4/20 John M McIntosh <johnmci(a)smalltalkconsulting.com> >> Well I asked for it... >> >> (a) you can get graphic cut/copy/paste of complex data on the macintosh and windows. >> >> (b) I'd rather have people learn FFI & Alien so they can build their own api to Rome, Pango, & Curl instead of waiting on about 4 people in the world to get around to building and distributing *official* plugins . >> >> I agree with this, but I also understand the security and modularity concerns of those who want to deploy without FFI and with plugins only. I think it might be worth-while, and would certainly be feasible and fun, to write an automatic plugin generator, e.g. above David's SmartSyntaxPlugin, that would take a set of FFI methods and shrink-wrap them into a plugin. So the natural development cycle for plugins could become prototype and extend using the FFI and deploy via the generator and a plugin compilation step. That would be analogous to the approach taken to produce the VM itself. > > Thanks this is good to get a vision in that area. We go in that direction now this is more a problem of knwoledge than will so we will work on making > the VM knowledge more spread in the community. >> >> I hope this approach would make it easier for people to produce plugins, since more of the gubbins would be hidden. That might be naive given complications with mapping object and memory references across the boundary, but it might also be an easier way to integrate things like Andreas' proposed handle framework. > > Sounds good. I do not get anything but trying to learn. :) anything/everything hopefully :) > >> (c) When your curl, rome, etc FFI call freaks and toasts your image why you can do debugging, versus relying on a handful of people in the world to grind thru some compiler, gnu debug session to figure out why that register move results in a fatal Virtual memory page fault. >> >> Certainly we got some good mileage out of catching external errors in FFI calls and returning these as primitive error codes. Basically it helps you find which FFI calls cause crashes, because the system will typically stay up long enough for you to open the debugger and identify which FFI call failed and what its arguments were. Why the call failed isn't so easy. The errr codes are an address and some OS-specific exception identifier. One then either has to think hard (infer from the args why the call might fail) or decamp to a low-level debugger, rerun the call and use any additional info it provides to debug the call. >> >> This is easy to add to the current VM which already has fatal signal handlers and primitive error codes. The FFI must set a flag "in FFI call" (clearing on callback, resetting on return from callback) which is tested in the fatal signal handlers and cause the exception info to be squirrelled away and the FFI call to fail. If the VM has enough state to take a callback it typically has enough state to cause the current FFI callout to fail and from the fatal signal handler longjmp to somewhere that can continue execution through the primitive failure. (and if it doesn't now, it can be made to, and not on every FFI call either, e.g. the interpreter can call setjmp prior to entering the interpreter loop, Cog does this to be able to switch between native code and interpreted code) > > well when will we get more Cog improvements in the vm? >> >> 2Â¢ >> >> Eliot >> >> >> On 2010-04-19, at 11:41 PM, Torsten Bergmann wrote: >> >>>> I wouldn't include neither FFI or Alien FFI in neither PharoCore or PharoDev >>>> image. >>> >>> +1 >>> >>>> That's only my opinion. >>> >>> Maybe Stef should tell us more about why he thinks it should be included. >>> >>> Bye >>> T. >>> >>> -- >>> GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! >>> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> =========================================================================== >> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 >> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.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

April 21, 2010