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 -- denker@acm.org http://www.marcusdenker.de

-- Marcus Denker -- denker@acm.org http://www.marcusdenker.de

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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. thanks, Mike

It would be great. I mean Really great. Even if we want to have a better OB based may be system having a fall back is really important On Mar 31, 2009, at 10:07 PM, Dale Henrichs wrote:

----- "Michael Roberts" <mike@mjr104.co.uk> 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 Pharo-project@lists.gforge.inria.fr 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

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.

Because it was not in the bugtracker ;-) Mike now added it to http://code.google.com/p/pharo/issues/detail?id=685 Marcus -- Marcus Denker -- denker@acm.org http://www.marcusdenker.de

I guess it is my fault. I forwarded it to various people, probably just not to the right ones ;-) Lukas On Wed, Apr 1, 2009 at 11:29 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Lukas Renggli http://www.lukas-renggli.ch