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" <[email protected]> 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 > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
