Yes soon or later we will clean the debugger code and principle too :)
I'm interested in any progress on that front.

Stef
On Apr 25, 2011, at 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


Reply via email to