[Pharo-project] Better debugging...

Mariano Martinez Peck marianopeck at gmail.com
Tue Apr 26 16:35:36 CEST 2011


On Tue, Apr 26, 2011 at 1:54 PM, Toon Verwaest <toon.verwaest at gmail.com>wrote:

> 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.
>

I am not sure if I understood correctly, but you may want to take a look to
Gemstone. As far as I remember they can have not only different versions of
a certain class at the same time, but also  instances of a specific class
version all living together at the same time.


> 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
>>
>
>
>


-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20110426/8c7f9436/attachment.htm>


More information about the Pharo-project mailing list