On 13 March 2011 02:17, Toon Verwaest <[email protected]> wrote: > I'm working on extracting everything to a model. DebuggerMethodMap is a mess > so we'll also have our own version of that class. Other methods that I found > too messy are rewritten in the model. > > Still work to be done, and Cog for linux doesn't like me committing code to > MC (it just crashes when I click save); so ... But it'll get there ;) Most > of the functionality is already there.
You can use Stack interpreter VM https://pharo-ic.lille.inria.fr/hudson/view/Cog/job/Stack%20VM%20Unix/ which can open images saved by JIT-based one, and see if it can do things which leading to crash under JIT. > > Making it all remote shouldn't be too much of a problem. The debugger just > relies on the debugger model and a list of objects that represent the stack. > All actual evaluating actions can easily be forwarded over a proxy to the > remote model. > > cheers, > Toon > > On 03/13/2011 01:31 AM, Igor Stasenko wrote: >> >> On 2 March 2011 20:56, Adrian Lienhard<[email protected]> wrote: >>> >>> On Mar 2, 2011, at 20:33 , Luc Fabresse wrote: >>> >>>>> - Adrian, Jorge and Toon worked on implementing a Debugger on top of >>>>> Glamour. They got a first version working that is able to do basic >>>>> actions: >>>>> step, restart, step into. The challenge was to get to understand the >>>>> model, >>>>> and to figure out that<primitive: 19> is used for marking that a >>>>> method >>>>> should not be debugged. In any case, working with Glamour seemed to >>>>> work >>>>> quite smoothly. The code is available in the Glamorous Toolkit. Adrian, >>>>> did >>>>> I get it right? :) >>>>> >>>> Nick in CC worked a lot to understand the model part of the Debugger. >>>> He has worked on a remote debugger. >>>> @Nick, you should have a look probably at this implementation of a >>>> debugger >>>> in Glamour. >>>> AFAICR the Debugger code really mixes the model, the GUI, the Debugees, >>>> ... >>>> so perhaps you can all join forces and propose a cleaner and extensible >>>> debugger ;-) >>> >>> Indeed, an independent model would make a lot of sense. Since the >>> original logic is mixed with the GUI code, we just copied parts of it over >>> to our new prototype. By factoring this out into an independent model we >>> would not end up multiple copies for the original debugger, the Glomour >>> debugger, the OB debugger, the remote debugger etc. >>> >> even if you copy it, we still badly need remote tools. :) >> Because we really cannot rely on having RFB installed on every >> headless image. It could be much more nicer and sexier >> to have small kernel image with small dispatcher to which you can >> connect and communicate with image remotely, >> without need of carrying Morphic blob inside it. > > > -- Best regards, Igor Stasenko AKA sig.
