Login  Register

Re: Fwd: [ANN] pharo focused sprint - bern, feb 26

Posted by Toon Verwaest-2 on Mar 13, 2011; 1:17am
URL: https://forum.world.st/ANN-pharo-focused-sprint-bern-feb-26-tp3251860p3351152.html

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.

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<[hidden email]>  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.