about the closure

> hi guys
>
> we discussed a bit with marcus and we arrived to the conclusion that
> we want to push the changes
> in the stream and that we will fix the problems when they show up.
> Now what it means is that
> - we will do probably today
> -> produce a new image
> with non dirty packages
>
> -> produce some fixes to check if we can load them with MC.
>
> and make it roll :)
>
> BTW having closure is really great. the code is so much nicer.
>
> Stef
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> Hi stef
> Apart from kicking the tyres, how best do we test the closure  
> integration?
>
> Thanks
> Mike
>
> On 3/30/09, Stéphane Ducasse <[hidden email]> wrote:
>> hi guys
>>
>> we discussed a bit with marcus and we arrived to the conclusion that
>> we want to push the changes
>> in the stream and that we will fix the problems when they show up.
>> Now what it means is that
>> - we will do probably today
>> -> produce a new image
>> with non dirty packages
>>
>> -> produce some fixes to check if we can load them with MC.
>>
>> and make it roll :)
>>
>> BTW having closure is really great. the code is so much nicer.
>>
>> Stef
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> Eliots code comes with additional tests.
>
> Furthermore I wrote an set of tests (see attachement). These tests
> especially make sure that none of the optimizations destroy the
> closure behavior. All existing Smalltalk implementations have some
> bugs, even the commercial ones.
>
> Another test is that the image can be completely recompiled and no
> additional test fails.
>
> Then the Seaside tests are another good candidate, they depend heavily
> on block behavior. And continuations extensively stress the context
> implementation.
>
> Lukas
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
> <ClosureTests.st>_______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>> Furthermore I wrote an set of tests (see attachement). These tests
>> especially make sure that none of the optimizations destroy the
>> closure behavior. All existing Smalltalk implementations have some
>> bugs, even the commercial ones.
>
> I should note that these tests were written after a long discussion
> with Oscar on the exact ANSI Smalltalk block semantics.
>
> Lukas
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

>> Attached is a third set of tests, those where written by
>> Rob Wither and Boris Gaertner years ago.
>>
>> And: they don't file in. I think because Eliot's compiler does not
>> support shadowing of variables in some cases. But I did not look to
>> deeply.
>
> I fixed the loading, see attachement. The tests all pass :-)
>
> Lukas
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
>

>
>
>> Did you say it to eliot?
>
> Eliot already fixed the third failure you are observing. Load the
> attached change-set and recompile the tests.
>
> Lukas
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
> <TempVariableNode-
> analyseClosure.st>_______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>
> On Apr 1, 2009, at 11:12 AM, Lukas Renggli wrote:
>
>>> lukas is it normal that we get 3 tests yellow - did you get the same
>>> in your image?
>>
>> #testToDoOutsideTemp and #testWhileModificationBefore are broken. I
>> don't think that should stop us from integrating the closures into
>> Pharo. Most "industrial strength" Smalltalk implementations have many
>> more closure bugs than Pharo.
>
> This is integrated already and this is good to have such great test
> suites.
> I will integrate them this evening.
>

>
> On 01.04.2009, at 11:31, Stéphane Ducasse wrote:
>
>>
>> On Apr 1, 2009, at 11:12 AM, Lukas Renggli wrote:
>>
>>>> lukas is it normal that we get 3 tests yellow - did you get the same
>>>> in your image?
>>>
>>> #testToDoOutsideTemp and #testWhileModificationBefore are broken. I
>>> don't think that should stop us from integrating the closures into
>>> Pharo. Most "industrial strength" Smalltalk implementations have many
>>> more closure bugs than Pharo.
>>
>> This is integrated already and this is good to have such great test
>> suites.
>> I will integrate them this evening.
>>
>
> Lukas' teste should be already in, I think.
>
> Marcus
>
>
> --
> Marcus Denker  --  [hidden email]
> http://www.marcusdenker.de
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> It would be good to document this knowledge of what is expected in our
> test suites. Especially if some are known to fail. Is there a pattern
> already in use?
> E.g. Method comment, pragma, wiki page entry? If not what should we  
> adopt?
>
> Thanks mike
>
> On 4/1/09, Marcus Denker <[hidden email]> wrote:
>>
>> On 01.04.2009, at 11:31, Stéphane Ducasse wrote:
>>
>>>
>>> On Apr 1, 2009, at 11:12 AM, Lukas Renggli wrote:
>>>
>>>>> lukas is it normal that we get 3 tests yellow - did you get the  
>>>>> same
>>>>> in your image?
>>>>
>>>> #testToDoOutsideTemp and #testWhileModificationBefore are broken. I
>>>> don't think that should stop us from integrating the closures into
>>>> Pharo. Most "industrial strength" Smalltalk implementations have  
>>>> many
>>>> more closure bugs than Pharo.
>>>
>>> This is integrated already and this is good to have such great test
>>> suites.
>>> I will integrate them this evening.
>>>
>>
>> Lukas' teste should be already in, I think.
>>
>> Marcus
>>
>>
>> --
>> Marcus Denker  --  [hidden email]
>> http://www.marcusdenker.de
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> I would like to see the pattern "all tests always green" (except for
> expected failures, see below). Maybe this is too rigorous in practice
> since not everybody seems to care that much about tests. It would mean
> that no new updates are pushed in the stream until all tests that were
> broken by the previous update are fixed. Or even better, we would not
> integrate any code as long as it breaks a test.
>
> Anyway, I see the following two possibilities:
> - use SUnit's expected failures feature (see implementors of
> #expectedFailures) to marke tests we know are broken
> - create a wiki page to document currently broken tests
>
> I would use the former only for tests that document a bug that we
> don't know how to fix within the foreseeable future. The drawback of
> the wiki page is that it is prone to get out of date.
>
> Cheers,
> Adrian
>
> On Apr 1, 2009, at 19:00 , Michael Roberts wrote:
>
>> It would be good to document this knowledge of what is expected in our
>> test suites. Especially if some are known to fail. Is there a pattern
>> already in use?
>> E.g. Method comment, pragma, wiki page entry? If not what should we
>> adopt?
>>
>> Thanks mike
>>
>> On 4/1/09, Marcus Denker <[hidden email]> wrote:
>>>
>>> On 01.04.2009, at 11:31, Stéphane Ducasse wrote:
>>>
>>>>
>>>> On Apr 1, 2009, at 11:12 AM, Lukas Renggli wrote:
>>>>
>>>>>> lukas is it normal that we get 3 tests yellow - did you get the
>>>>>> same
>>>>>> in your image?
>>>>>
>>>>> #testToDoOutsideTemp and #testWhileModificationBefore are broken. I
>>>>> don't think that should stop us from integrating the closures into
>>>>> Pharo. Most "industrial strength" Smalltalk implementations have
>>>>> many
>>>>> more closure bugs than Pharo.
>>>>
>>>> This is integrated already and this is good to have such great test
>>>> suites.
>>>> I will integrate them this evening.
>>>>
>>>
>>> Lukas' teste should be already in, I think.
>>>
>>>      Marcus
>>>
>>>
>>> --
>>> Marcus Denker  --  [hidden email]
>>> http://www.marcusdenker.de
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> About troll^Wtesting closures:
> http://math.andrej.com/2009/04/09/pythons-lambda-is-broken/
>
> --
> Damien Pollet
> type less, do more [ | ] http://people.untyped.org/damien.pollet
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>