Hi guys, Stef, Bifröst was invented for this particular purpose. http://scg.unibe.ch/research/bifrost Bifröst is a unified approach to reflection.
Stef, if you explain a little bit the use case I can quickly provide an adaptation solution. HTH, Jorge On Mon, Apr 25, 2011 at 11:29 PM, Camillo Bruni <[email protected]> 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 > -- Jorge Ressia www.jorgeressia.com
