I know we can :) and I did some prototypes already as part of my thesis.

The question is if that is a design we *want* or not.


On 18 nov 2015, at 5:29 p.m., Cl��ment Bera <bera.clement@gmail.com> wrote:



2015-11-18 8:43 GMT-03:00 Guillermo Polito <guillermopolito@gmail.com>:
I���d like to discuss also the possibility to add those low level operations on mirrors objects, that could be packaged separately from the kernel of the language. Adding them on a first step is easy, then making all tools use them is the hard/timeconsuming part, yes.

All the needed operations already exist. You can put them on your mirror objects without any problem.



On 18 nov 2015, at 12:35 p.m., Cl��ment Bera <bera.clement@gmail.com> wrote:

Hello,

This is known and was discussed on the bug tracker.

The problem is that currently Pharo has many tools and classes: EyeInspector in the debugger, GTInspector outside, the debugger itself, the in-image interpreter in the Context class ... that need to be changed to support debugging objects that basically cannot receive any message.

We are aware of the solution but fixing it for all the toolkits and classes is quite some work. In addition, if not tested, someone will break it because he won't understand that an inspected object can't receive any message because the expected behavior of an object with no DNU behavior and no methods inherited from Object is to freeze the system. 

It's a lot of fun doing that though.

Clement

2015-11-17 21:39 GMT-03:00 Eliot Miranda <eliot.miranda@gmail.com>:
Hi Esteban,

On Tue, Nov 17, 2015 at 1:37 PM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:

2015-11-17 14:37 GMT-03:00 Eliot Miranda <eliot.miranda@gmail.com>:
> Hi Esteban,
>
> I think EyeInspector needs to handle classes that don't inherit from
> Object specially. Instead of asking the instance it should ask the class.
> You should be able to use the Context methods for mirror primitives to
> extract state without sending messages to the instance. Then the special
> version of EyeInspector for ProtoObject subclasses can ask this like

Yes, an special inspector for ProtoObject subclasses would be required, but I couldn't find one already suited for this purpose.

> (thisContext objectClass: object) isIndexable ifTrue:
> [size := thisContext objectSize: object]

I don't know if your code was meant to be accurate or just a guideline of how this could be implemented, but Context doesn't implement #objectClass: nor #objectSize:


Find attached.  I think you'll find they are in the Spur version.  You might think of back-porting their use in Context form Spur; that'll make the debugger able to handle proxies.

> Basically both the Inspector and the Debugger's execution simulation
> machinery need to treat encapsulators such as MessageArchiver with kid
> gloves. One *must not* cause inspecting or debugging to send messages
> through the encapsulator. Instead, all access to the object should be
> through primitives that don't send messages to the objects.

I know that dealing with Proxies and similar objects is tricky, I had to deal with my own subclasses of ProtoObject in Dolphin, but there the class implemented all that was needed to interact with the environment tools.

Hiwever, to me all this is a kind of black magic, I read the blue book years ago and can understand it, but I do understand it as I understand the mechanics of my car, however when it breaks down I take it to the specialist :)

Well, the thing to think of is that inside the VM objects are just a sequence of words, and the VM, while it sends messages, doesn't send messages to objects to update their state; it just accesses the state directly.  So in an execution simulation method such as

Context methods for instruction decoding
pushReceiverVariable: offset
    self push: (receiver instVarAt: offset + 1)

that will send the message instVarAt: to the receiver, and if the receiver is a proxy, that will go through the proixie's doesNotUnderstand: method and send instVarAt: the the object the proxy wraps, which won't do the right thing at all.  Instead it needs to be written

Context methods for instruction decoding
pushReceiverVariable: offset
    self push: (self object: receiver instVarAt: offset + 1)

which reaches into the object without sending any messages to it.  I understand that this will appear in Spur, because I made it part of the bootstrap, but if I were you I would integrate these changes into the current version asap.  The debugger won't work properly with proxies, encapsulators etc otherwise.

_,,,^..^,,,_
best, Eliot