[squeak-dev] process-faithful debugging?
Locked
[squeak-dev] process-faithful debugging?
 
|
Hi All,
does anyone have a neat hack to make Processor activeProcess answer what's expected in the context of the debugger? i.e. anyone made the Squeak debugger answer the process being debugger when Processor activeProcess is stepped over or through, rather than the debugger process, or made the debugger run as the process being debugged rather than its own?
TIA Eliot
|
[squeak-dev] Re: process-faithful debugging?
|
|
Didn't we talk about this earlier?
Process>>currentProcess "Answer the currently active process. If the receiver is simulating another process, answer the other process. If not, answer self." ^currentProcess ifNil:[self] Process>>currentProcess: aProcess "Set the currently active process. Return the previous active process." | prior | prior := currentProcess. currentProcess := aProcess. ^prior ProcessorScheduler>>activeProcess ^activeProcess currentProcess ProcessorScheduler>>currentProcess: aProcess "For debugging only. Pretend that aProcess is the activeProcess" ^activeProcess currentProcess: aProcess and then: Debugger>>step prior := Processor currentProcess: interruptedProcess. [self doStep] ensure:[Processor currentProcess: prior]. etc. Eliot Miranda wrote: > Hi All, > > does anyone have a neat hack to make Processor activeProcess answer > what's expected in the context of the debugger? i.e. anyone made the > Squeak debugger answer the process being debugger when Processor > activeProcess is stepped over or through, rather than the debugger > process, or made the debugger run as the process being debugged rather > than its own? > > TIA > Eliot > > > ------------------------------------------------------------------------ > > |
Re: [squeak-dev] process-faithful debugging?
|
|
In reply to this post by Eliot Miranda-2
2009/7/17 Eliot Miranda <[hidden email]>:
> Hi All, > does anyone have a neat hack to make Processor activeProcess answer > what's expected in the context of the debugger? i.e. anyone made the Squeak > debugger answer the process being debugger when Processor activeProcess is > stepped over or through, rather than the debugger process, or made the > debugger run as the process being debugged rather than its own? Very good question, Eliot! I always wondered, why to access the active process we use global - Processor. A running process is closely related to contexts, and therefore it would be more correct to ask a context about it's process rather than global: thisContext process instead of Processor activeProcess. I have an idea about this. Its hacky and will require VM modifications - but having much benefits IMO :) I think this is most clean & lean way to deal with process-local storage in smalltalk: - add 3 __class instance__ variables to ContextPart: - methodContextClass - blockContextClass - process Now, when creating a new process , create a two anonymous subclasses of MethodContext and BlockContext, and fill these ivars in each one appropriately. Then, all contexts which allocated for given process should use these anonymous subclasses as their classes. For VM this means, that when it allocating new context, it should copy the class reference from caller context (or read a methodContextClass or blockContextClass ivars in caller context class object). And then accessing a process ( or process-local storage) is trivial & quick: ContextPart>>process ^ self class process > TIA > Eliot > > > -- Best regards, Igor Stasenko AKA sig. |
Re: [squeak-dev] Re: process-faithful debugging?
|
|
In reply to this post by Andreas.Raab
On Thu, Jul 16, 2009 at 6:26 PM, Andreas Raab <[hidden email]> wrote: Didn't we talk about this earlier? Yes we had discussed it, but I needed the reminder... Process>>currentProcess Yes. This is OK, but it means the system codes to suit the debugger and that's always felt like the tail wagging the dog to me. How about creating an anonymous subclass of the process that implements activeProcess to raise an exception caught by the debugger that answers the right thing and class (to answer the proper class) and using adoptInstance: (the new guts of changeClassTo:) for the duration of each step?
The VW debugger uses something similar to this to do step into. All blocks in the current context get their class changed to one that raises an exception on receiving a value message which the debugger catches, converts the block back and pauses the computation after the activation of the block.
Eliot Miranda wrote: |
Re: [squeak-dev] process-faithful debugging?
|
|
In reply to this post by Igor Stasenko
If I were going to modify the VM I'd simply add a bytecode to answer thisProcess. e.g. the thisContext bytecode would become a two-byte bytecode (i is very rare in practice) and the second byte would indicate what special pseudo-variable to answer. What you propose below has the overhead of an anonymous class per process (my closure scheme doesn't use BlockContext at all any more). Fun, but too expensive for my tastes :)
On Thu, Jul 16, 2009 at 6:44 PM, Igor Stasenko <[hidden email]> wrote: 2009/7/17 Eliot Miranda <[hidden email]>: |
Re: [squeak-dev] process-faithful debugging?
|
|
2009/7/17 Eliot Miranda <[hidden email]>:
> If I were going to modify the VM I'd simply add a bytecode to answer > thisProcess. e.g. the thisContext bytecode would become a two-byte bytecode > (i is very rare in practice) and the second byte would indicate what special > pseudo-variable to answer. What you propose below has the overhead of an > anonymous class per process (my closure scheme doesn't use BlockContext at > all any more). Fun, but too expensive for my tastes :) > Hmm.. since when 'MethodContext clone' is too expensive? I was more expecting that you say that it can be expensive when allocating new contexts (because it should pick the right 'class' for it , as i described, instead of taking already known class from special objects array). Or it could be problematic in places where VM should make difference between contexts and other objects , since contexts now could have any object as a class , not just a single, fixed one. And, of course, such overhead can be eliminated, by merging behavior from Process to MethodContext class side. So, instead of creating a Process instance - you creating an anonymous class :) But this would require a bit of refactoring... :) > On Thu, Jul 16, 2009 at 6:44 PM, Igor Stasenko <[hidden email]> wrote: >> >> 2009/7/17 Eliot Miranda <[hidden email]>: >> > Hi All, >> > does anyone have a neat hack to make Processor activeProcess answer >> > what's expected in the context of the debugger? i.e. anyone made the >> > Squeak >> > debugger answer the process being debugger when Processor activeProcess >> > is >> > stepped over or through, rather than the debugger process, or made the >> > debugger run as the process being debugged rather than its own? >> >> Very good question, Eliot! >> I always wondered, why to access the active process we use global - >> Processor. >> A running process is closely related to contexts, and therefore it >> would be more correct to ask a context about it's process rather than >> global: >> >> thisContext process >> instead of >> Processor activeProcess. >> >> I have an idea about this. >> Its hacky and will require VM modifications - but having much benefits IMO >> :) >> I think this is most clean & lean way to deal with process-local >> storage in smalltalk: >> >> - add 3 __class instance__ variables to ContextPart: >> - methodContextClass >> - blockContextClass >> - process >> >> Now, when creating a new process , create a two anonymous subclasses >> of MethodContext and BlockContext, >> and fill these ivars in each one appropriately. >> >> Then, all contexts which allocated for given process should use these >> anonymous subclasses as their classes. >> For VM this means, that when it allocating new context, it should copy >> the class reference from caller context (or read a >> methodContextClass or blockContextClass ivars in caller context >> class object). >> >> And then accessing a process ( or process-local storage) is trivial & >> quick: >> >> ContextPart>>process >> ^ self class process >> >> >> > TIA >> > Eliot >> > >> > >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > > > -- Best regards, Igor Stasenko AKA sig. |
Re: [squeak-dev] Re: process-faithful debugging?
|
|
In reply to this post by Eliot Miranda-2
On 17.07.2009, at 06:16, Eliot Miranda wrote:
#activeProcess is implemented by ProcessorScheduler not Process. So that won't work.
Sounds like a trade-off between magic and simplicity. - Bert - |
Re: [squeak-dev] Re: process-faithful debugging?
|
|
On Fri, Jul 17, 2009 at 2:31 AM, Bert Freudenberg <[hidden email]> wrote:
Doh! Thanks, Bert.
:)
|
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |