Tim

Ultimately, I think you would find a process faithful debugger would be
the be solution.  This would also address other situations such
as stepping into a recursion lock.  Additionally, if Squeak ever implements
something like the VW threaded API problems may arise by not
having a process faithfull debugger.

Terry

===========================================================
Terry Raymond       Smalltalk Professional Debug Package
Crafted Smalltalk   *Breakpoints* and *Watchpoints* for
80 Lazywood Ln.                  VW and ENVY/Developer 
Tiverton, RI  02878
(401) 624-4517      traymond at craftedsmalltalk.com
http://www.craftedsmalltalk.com
===========================================================
 

> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org
> [mailto:squeak-dev-admin at lists.squeakfoundation.org]On Behalf Of Tim
> Rowledge
> Sent: Tuesday, February 12, 2002 9:52 PM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: RE: Process local variable and debugging
> 
> 
> Well, nobody has offered up any actual code for this problem, so let's
> run though a couple of ideas.
> 
> The first problem comes down to 'context' or 'Process'; are these
> process global variables to be considered to belong to the stack of
> contexts currently above the active context, or are they to belong to
> the Process? Which Process - how do you work out which process is
> attached to the context?
> 
> If to the context stack, then we are reasonably safe in 
> scanning up the
> stack and finding a place where we can consider it to be the 
> root. Or we
> could (ab)use the exception handlers and allow overriding of these
> values anywhere in the stack. Or we could have a simpified 
> prim similar
> to the exception handler prim that just finds the root context. Things
> remain safe almost no matter what we do with #swapSenders: 
> and other fun
> stack manipulations, though the effects might be amusing. The drawback
> is that scanning the stack is somwhat slower than merely accessing
> variables. It should be safe in the debugger though, both practically
> and semantically.
> 
> For the process, we have only Processor activeProcess as a 
> mechanism for
> now. At least, I don't know any good way to reliably get the process
> from a context (barring Anthony's changes). When debugging, we could
> possibly trap #activeProcess (it looks easiest to me if we give it a
> fake primitive, then it can be picked up in ContextPart>
> doPrimitive:method:receiver:args:) to return the process 
> being debugged.
> What happens if you do a doit in the debugger and really want 
> the actual
> active process though?
> 
> The second idea was that described by Dave Simmons; swap the values of
> the Associations in the literal frames of the affected methods. This
> gets past the problem of the wrong activeProcess, but does involve
> potential messing around when debugging - the process running the
> debugger mustn't change the values that were/are in use by 
> the debuggee.
> I'm also still unsure of exactly what one needs to do to 
> implement this
> idea for anything but the most trivial case; since we would 
> have to set
> the values of any/all Association involved for every process
> suspend/resume it seems like it could get expensive for more than a
> couple. Maybe the answer is to only have one, and have it be a
> dictionary of the rest of the variables of interest?
> 
> Anyone else have interesting thoughts?
> 
> tim
> 
> -- 
> Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
> Useful random insult:- If you stand close enough to him, you 
> can hear the ocean.
> 
>