sorry guys, i have not had time to be online much. Eliot, guys, thanks for the code (Phillipe, Hi!). I think i saw marcus comment on the tracker that something sensible had been done? i just wanted to offer a thought that we do not change the original Pharo debugger too much from Squeak. i saw a recent issue # that was a 'debugger refactoring'. tracking merges & bugs between Squeak and Pharo is hard, it would be nice to concentrate on pure fixes where possible.... (if you itch to refactor...help Doru with the new debugger model etc). cheers Mike On Thu, Sep 8, 2011 at 9:37 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi guys
I'm a bit busy (too much to follow carefully). Just tell me what I should integrate and I will do it fast.
Stef
On Sep 8, 2011, at 2:37 PM, Michael Roberts wrote:
So I found the bug with the first assignment. It is caused by a difference between squeak and Pharo in SortedCollection. (on my phone so will be brief)
In Pharo the debugger map collection gets sorted and asked for an index for a given pc. It is supposed to answer 1 because there is no match and it is expected to be the first index for insertion. However when the asSortedCollection gets done the internal start index of the collection is 2. This manifests the bug. 2 is answered as the insertion position but this is a value internal to the collection.
Squeak does not have this bug because it forces a reset of the start index to 1. Hope that makes sense. I don't know what the correct fix is. We copy the reset:1 type code to force the collection to have start from 1 property. We check semantics of index for insertion. Is it the position of the element of index relative to pointers? Or we change the debugger to calculate the offset (but this feels wrong)
So this is an opportunity for some test cases and fixes around sorted collection if we know what the correct semantics are. This leak of '2' out of the collection is only wrong if 2 is a valid state. If that makes sense...
Cheers Mike