[ANN] #10262cl

> Hi,
>
> I have merged the closure changed in the 1062 image (manually).
>
> We now can continue with this image to provide updates using the  
> update stream:
>
> http://gforge.inria.fr/frs/download.php/20098/ 
> Pharo0.1Core-10262cl.zip
>
>
> Changes:
> -> Closure changes merged.
> -> BlockClosurePharo.1.cs
> -> FixDebugger.1.cs
> -> TraitDescription-closure support.st
> -> BlockContextTestFix.1.cs
> -> ArrayLiteralTestFix.1.cs
>
>
> --
> Marcus Denker  --  [hidden email]
> http://www.marcusdenker.de
>

> Hi,
>
> I have merged the closure changed in the 1062 image (manually).
>
> We now can continue with this image to provide updates using the
> update stream:
>
> http://gforge.inria.fr/frs/download.php/20098/ 
> Pharo0.1Core-10262cl.zip
>
>
> Changes:
> -> Closure changes merged.
> -> BlockClosurePharo.1.cs
> -> FixDebugger.1.cs
> -> TraitDescription-closure support.st
> -> BlockContextTestFix.1.cs
> -> ArrayLiteralTestFix.1.cs
>
>
> --
> 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
>

> Hi,
>
> So this is not done as an update... reason: much simpler.
> doing the closure conversation is a bit manual, e.g. closing all
> windows,
> doing some other stuff, then save, restart, cleanup changeset... then
> re-saving all the dirty packages.
>
> I would *a lot* of work to do that with the update-stream.
>
> The question is: can we live without?
>
> We could add a changeset that just pops up a window that says: end-of-
> line, please get the hand-build image.
>
> Marcus
>
>
> On 31.03.2009, at 16:15, Marcus Denker wrote:
>
>> Hi,
>>
>> I have merged the closure changed in the 1062 image (manually).
>>
>> We now can continue with this image to provide updates using the
>> update stream:
>>
>> http://gforge.inria.fr/frs/download.php/20098/
>> Pharo0.1Core-10262cl.zip
>>
>>
>> Changes:
>> -> Closure changes merged.
>> -> BlockClosurePharo.1.cs
>> -> FixDebugger.1.cs
>> -> TraitDescription-closure support.st
>> -> BlockContextTestFix.1.cs
>> -> ArrayLiteralTestFix.1.cs
>>
>>
>> --
>> Marcus Denker  --  [hidden email]
>> http://www.marcusdenker.de
>>
>
> --
> 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

> I think we can do it manually, yes.
>
> But it would be good to have a detailed description of the manual
> steps so that we (or someone else) is able to reproduce it at a later
> point in time.
>
> Adrian
>
> On Mar 31, 2009, at 16:52 , Marcus Denker wrote:
>
>> Hi,
>>
>> So this is not done as an update... reason: much simpler.
>> doing the closure conversation is a bit manual, e.g. closing all
>> windows,
>> doing some other stuff, then save, restart, cleanup changeset... then
>> re-saving all the dirty packages.
>>
>> I would *a lot* of work to do that with the update-stream.
>>
>> The question is: can we live without?
>>
>> We could add a changeset that just pops up a window that says: end-of-
>> line, please get the hand-build image.
>>
>> Marcus
>>
>>
>> On 31.03.2009, at 16:15, Marcus Denker wrote:
>>
>>> Hi,
>>>
>>> I have merged the closure changed in the 1062 image (manually).
>>>
>>> We now can continue with this image to provide updates using the
>>> update stream:
>>>
>>> http://gforge.inria.fr/frs/download.php/20098/
>>> Pharo0.1Core-10262cl.zip
>>>
>>>
>>> Changes:
>>> -> Closure changes merged.
>>> -> BlockClosurePharo.1.cs
>>> -> FixDebugger.1.cs
>>> -> TraitDescription-closure support.st
>>> -> BlockContextTestFix.1.cs
>>> -> ArrayLiteralTestFix.1.cs
>>>
>>>
>>> --
>>> Marcus Denker  --  [hidden email]
>>> http://www.marcusdenker.de
>>>
>>
>> --
>> 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
>

> Hi,
>
> I have merged the closure changed in the 1062 image (manually).
>
> We now can continue with this image to provide updates using the
> update stream:
>
> http://gforge.inria.fr/frs/download.php/20098/ 
> Pharo0.1Core-10262cl.zip
>
>
> Changes:
> -> Closure changes merged.
> -> BlockClosurePharo.1.cs
> -> FixDebugger.1.cs
> -> TraitDescription-closure support.st
> -> BlockContextTestFix.1.cs
> -> ArrayLiteralTestFix.1.cs
>
>
> --
> 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
>

>
> ----- "Michael Roberts" <[hidden email]> wrote:
>
> | guys I have done a quick test of the closure image, with the mac VM
> | on
> | the inria page.
> |
> | I think it is probably unrelated but the old debugger in the core
> | image is severely broken.  Could someone please remind me
> |
> | 1) what we were going to do with the old debugger. I know there is
> | work going on in the dev image on the new one... what is the
> | strategy?
> |
> | 2) i'd appreciate if someone could see if there is a bug report that
> | confirms this behaviour below.  Otherwise I will at least file a
> | report.  Candidate bug report is #329 but I am not sure exactly if  
> it
> | is what I see.
> |
> | steps
> | 1. run ClosureTests in the test runner
> | 2. 3 fail, so click on testToDoWithArgument
> | 3. hit debug
> | 4. restart the test method
> | 5. step over the to:do:. you only enter the loop block once,  BUG #1
> | ?
> | 6. step into the assertValues: method as it is highlighted
> | 7. highlight now enters the loop again, not into the utility method.
> | BUG #2 ?
> | 8. carefully step until you get into the assert method, if you do
> | this
> | wrong a new notifier pops up BUG #3. if you kill this you get error
> | unwind pop up that you can't ever kill. BUG #4 ?
> |
> | basically this debugger is unusable and I think it has been for some
> | time. I'm sure I commented in the past.  so please give me your
> | thoughts on the old debugger and live issues in the tracker.  Do
> | people not notice, because they generally load the OB debugger?  I
> | want to know where to concentrate my efforts. I'm not sure we should
> | develop the old debugger too much, but at one point it did work in
> | squeak.  I'm sure the unwind notifier bug predates pharo. surely  
> it's
> | not just me.  my vote would be to attempt to fix the debugger, so we
> | have one in the core image that works, and then perhaps leave it
> | alone..  or we promote the new one into it when it can be a
> | replacement.
> |
> | on the closure related note, what is perhaps interesting in a
> | workspace is
> |
> | values := (1 to: 5) collect: [:each | [each] ].
> | values collect: [:each | each value]
> | --> #(1 2 3 4 5)
> |
> | | i |
> | values := (1 to: 5) collect: [:each |
> | i := each.
> | [i] ].
> | values collect: [:each | each value]
> | -->#(5 5 5 5 5)
> |
> | values := OrderedCollection new.
> | 1 to: 5 do: [:i | values add: [i] ].
> | values collect: [:each | each value]
> | --> an OrderedCollection(6 6 6 6 6)
> |
> | I know the second and third gives non closure related result, but I
> | don't know if the first one shows valid closure or not.
> |
> | Anyway please direct and I will keep testing.
>
> If there is consensus to fix the old debugger, and noone else steps  
> to the plate, I would be willing to see what I could do in getting  
> the old debugger functional with the ClosureTests...
>
> Dale
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

>> on the closure related note, what is perhaps interesting in a  
>> workspace is
>>
>> values := (1 to: 5) collect: [:each | [each] ].
>> values collect: [:each | each value]
>> --> #(1 2 3 4 5)
>
> That's correct.
>
>> | i |
>> values := (1 to: 5) collect: [:each |
>>                        i := each.
>>                        [i] ].
>> values collect: [:each | each value]
>> -->#(5 5 5 5 5)
>
> That behavior is correct. i is defined outside the block, thus it
> refers to the current number which is 5.
>
>> values := OrderedCollection new.
>> 1 to: 5 do: [:i | values add: [i] ].
>> values collect: [:each | each value]
>> --> an OrderedCollection(6 6 6 6 6)
>
> That's a bug, but already fixed by Eliot. I don't know why the patch
> is not included with the image? Load the attachement.
>
> The two other failing tests are actually failing in most Smalltalk,
> even in commercial ones.
>
> 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

> Because marcus was not aware of it.
> I will add it this evening (if nobody does it before).
>
> Stef
>
> On Mar 31, 2009, at 10:35 PM, Lukas Renggli wrote:
>
>>> on the closure related note, what is perhaps interesting in a
>>> workspace is
>>>
>>> values := (1 to: 5) collect: [:each | [each] ].
>>> values collect: [:each | each value]
>>> --> #(1 2 3 4 5)
>>
>> That's correct.
>>
>>> | i |
>>> values := (1 to: 5) collect: [:each |
>>>                        i := each.
>>>                        [i] ].
>>> values collect: [:each | each value]
>>> -->#(5 5 5 5 5)
>>
>> That behavior is correct. i is defined outside the block, thus it
>> refers to the current number which is 5.
>>
>>> values := OrderedCollection new.
>>> 1 to: 5 do: [:i | values add: [i] ].
>>> values collect: [:each | each value]
>>> --> an OrderedCollection(6 6 6 6 6)
>>
>> That's a bug, but already fixed by Eliot. I don't know why the patch
>> is not included with the image? Load the attachement.
>>
>> The two other failing tests are actually failing in most Smalltalk,
>> even in commercial ones.
>>
>> 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
>