Better debugging...

I'm working on porting this idea already to the Glamour debugger.

The idea is basically to use meta-circular interpreters as a way to specify what semantics you want, but for speed reasons you might want to flatten out the interpretation by combining both. This however should all be done behind the scenes, independent of the definition of the debugger.

More elaborate debuggers such as the alias debugger can be implemented but there's no good way yet to separate the data spaces involved. That's where me and Erwann are looking at how to maybe use a GC that can run multiple different versions code at the same time while synchronizing the shared data between the versions of the code.

For example in the case of the alias debugger, that needs aliases everwhere; but all the global data (classes, methods, ...) is not aliased. To make this work you actually want to have a "copy" of the global data that is aliased, but kept in sync with the original data. Here it starts making a lot of sense to have thread-local heaps + a versioned but synced global heap.

Of course that's all still wishful thinking... step by step :)

cheers,
Toon

On 04/25/2011 11:29 PM, Camillo Bruni wrote:

I think a nice way to have a decent debugger is to run the program on top of a changeable interpreter. Since a classical debugger is nothing else but an interpreter with slightly changed semantics.

The object flow VM does a great job at tracing back stuff.. however it might pose a massive overhead since it collects tons and tons of data.

In Pinocchio[1] we implemented very nice and simple debuggers by "just" changing the current interpreter to take a user-action into account on each message send. Since this is implemented on top of a metacircular interpreter this was quite simple to achieve. So the whole implementation of the known debugger functionality (step, over...) maybe took an afternoon. Since you have access to the full interpreter protocol it is very easy to intercept different sorts of actions. As described in the linked paper, it was very easy to implement the object-flow behavior in Pinocchio.

So for me there is only one real way to have a decent debugger. And that means that it is a first-class interpreter whose semantics I can change at will. Thus I can create a specific debugger for my applications.

But I guess that making the first-class interpreters work right away in Pharo will take a while to do, hence I propose the following additions to the current interpreter to make it partly useable:

- interception of message sends
       - per thread [ok]
       - of specific classes [missing]
       - of specific instances [missing]

- interception of instance variable access, read/write
       - per thread [missing]
       - of specific classes [missing]
       - of specific instances [missing]
       - of specific instance variables [missing]

Furthermore I really want to be able to script all of that stuff, eg. provide a simple test block that gets invoked on each message send. Returning true =>  halt, Returning false =>  continue execution.


[1] http://scg.unibe.ch/archive/papers/Verw10aPinocchio.pdf