On 5/23/2012 21:30, Eliot Miranda wrote:
>
>
> On Wed, May 23, 2012 at 12:04 PM, Andreas Raab <andreas.raab at gmx.de
> <mailto:andreas.raab at gmx.de>> wrote:
>
>     On 5/23/2012 20:51, Eliot Miranda wrote:
>
>         So given that the Interpreter VM now supports the mirror primitives,
>         does anyone object if I add the debugger changes to trunk that
>         use the
>         mirror primitives and hence make accurate debugging of proxies
>         possible?
>         The downside of doing this is that the debugger will be broken on
>         older VMs.
>
>
>     It should be possible to write the mirror prims relatively safely, e.g.:
>
>     object: anObject instVarAt: anIndex
>     "Primitive. Answer a fixed variable in an object. The numbering of the
>             variables corresponds to the named instance variables. Fail
>     if the index
>             is not an Integer or is not the index of a fixed variable.
>     Essential for the
>             debugger. See  Object documentation whatIsAPrimitive."
>
>     <primitive: 73>
>             anIndex <= (self objectClass: anObject) instSize
>                     ifTrue:["Assume mirror primitives are missing"
>                             ^anObject instVarAt: index]
>                     ifFalse:["Access beyond fixed variables."
>                             ^self object: anObject basicAt: anIndex -
>     (self objectClass: anObject) instSize].
>
>
> That's a good idea.  Alas it doesn't work because the primitives won't
> fail on the older VMs.  Note that the same primitive is used for
> instVarAt: and object:instVarAt: (and likewise for object:instVarAt:put:
> & objectClass: etc).  The difference is that in the older VM the prims
> assume a fixed argument count and only pop that many objects from the
> stack.  Hence there is the potential of stack overflow in the older VMs.

Okay, then don't use those prims. Simply rename primitiveInstVarAt to 
primitiveMirrorInstVarAt, export the latter by name, and use the named 
version in cases like the above where the direct usage of prim 73 might 
cause a stack overflow. Tada! You can have your cake and eat it, too :-)

Cheers,
   - Andreas