about the closure

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

about the closure

Stéphane Ducasse
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
Reply | Threaded
Open this post in threaded view
|

Re: about the closure

Michael Roberts-2
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
Reply | Threaded
Open this post in threaded view
|

Re: about the closure

Stéphane Ducasse
- do all kind of things with the system
- checking the tests that failed

Stef

On Mar 30, 2009, at 11:17 PM, Michael Roberts wrote:

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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: about the closure

Lukas Renggli
In reply to this post by Michael Roberts-2
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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

ClosureTests.st (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: about the closure

Stéphane Ducasse
Thanks!

On Mar 30, 2009, at 11:40 PM, Lukas Renggli wrote:

> 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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: about the closure

Lukas Renggli
In reply to this post by Lukas Renggli
> 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
Reply | Threaded
Open this post in threaded view
|

Re: about the closure

Stéphane Ducasse
I really want to see that :)
Because the semantics of Smalltalk block is far from clear to me.
Do you write something on it :)? for DSL? for ESUG workshop?

Stef

On Mar 31, 2009, at 12:20 AM, Lukas Renggli wrote:

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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: about the closure

Marcus Denker-3
In reply to this post by Lukas Renggli
Hi,

Very cool!

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.





On 30.03.2009, at 23:40, Lukas Renggli wrote:

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

ClosureTestCases-rww-bg.cs (34K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: about the closure

Lukas Renggli
> 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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

BlockClosureTests.st (27K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: about the closure

Michael Roberts-2
Ok cool. Good stuff!
Mike

On 3/31/09, Lukas Renggli <[hidden email]> wrote:

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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: about the closure

Stéphane Ducasse
In reply to this post by Lukas Renggli
So the semantics you describe is that the closure refers to variables  
until it is valued and not their values
And of course there is a difference whether the variable is a closure  
temporary or whether it is a enclosing scope one.

lukas is it normal that we get 3 tests yellow - did you get the same  
in your image?
Did you say it to eliot?

The tests of boris remind me some of my lisp cps-iterator :)
Ugly in smalltalk :)


Stef


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: about the closure

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

> 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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

TempVariableNode-analyseClosure.st (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: about the closure

Stéphane Ducasse

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.

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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: about the closure

Marcus Denker-3

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
Reply | Threaded
Open this post in threaded view
|

Re: about the closure

Michael Roberts-2
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
Reply | Threaded
Open this post in threaded view
|

Re: about the closure

Adrian Lienhard
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
Reply | Threaded
Open this post in threaded view
|

Re: about the closure

Michael Roberts-2
I definitely care about the tests all green ;-) I just don't want to
debug into tests when there is no point.  I'm not in favour of the
wiki idea either.  So I'll have a look at expected failures.  sounds
like we need to mark those two of Lukas' if they are not already

thanks,

Mike

On Wed, Apr 1, 2009 at 6:29 PM, Adrian Lienhard <[hidden email]> wrote:

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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: about the closure

Stéphane Ducasse
yeap you re right

> I definitely care about the tests all green ;-) I just don't want to
> debug into tests when there is no point.  I'm not in favour of the
> wiki idea either.  So I'll have a look at expected failures.  sounds
> like we need to mark those two of Lukas' if they are not already
>
> thanks,
>
> Mike


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: about the closure

Damien Pollet
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
Reply | Threaded
Open this post in threaded view
|

Re: about the closure

Stéphane Ducasse
did you try it in pharo.
The tests of lukas are gorgeous BTW

On Apr 9, 2009, at 9:39 PM, Damien Pollet wrote:

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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
12