On Tue, Apr 26, 2011 at 1:54 PM, Toon Verwaest <[email protected]>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
