[step shouldn't show extra stack frames, step can]
I agree.

[the unimplemented calls aren't supposed to cause trouble]
Ok. I'm a little concerned about backChunk and the messages that are
only sent when CC is loaded. Consider that someone reading this code
won't understand that very easily. 

About the messages that are only called by CC, maybe they should be
class extensions included in CC?

I don't know enough about backChunk to suggest how it should be dealt
with. Ideas?

Daniel

Anthony Hannan <ajh18 at cornell.edu> wrote:
> Ned Konz <ned at bike-nomad.com> wrote:
> > I looked for senders of some of the methods in the GeneralEnh 
> > CS, and there were indeed some senders. At least those methods are 
> > required.
> 
> Sorry I did not separate things as cleanly as I thought.  But the
> methods that are missing are ok to be missing or are deliberately
> missing (so it will raise a doesNotUnderstand error).  Details below:
> 
> > Like, for instance, Message class>>catcher, and thus the 
> > MessageCatcher class itself.
> 
> The sender of #catcher is #previousPc.  The sender of #previousPc is
> Debugger>>pcRange, which only calls previousPc if the theMethodNode is a
> RBProgramNode which only happens when ClosureCompiler is loaded.  So
> #catcher will never get called.
> 
> > CompiledMethod sourceClass calls: backChunk
> 
> #sourceClass calls backChunk inside an #on: Error do: block.  The
> handler block returns nil which is ok.
> 
> > Parser parse:class: calls: parseError
> > CompiledMethod blockNodeIn: calls: ir errorNodeNotFound
> 
> #parseError and #errorNodeNotFound is meant to be undefined.  If called
> an error is raised which is appropriate.  This is my style of signaling
> errors that don't have their own Exception subclass yet.  It is more
> specialized then a general #error: message but less cumbersome than
> introducing a special Exception subclass.  If the receiver wants to handle
> it he can implement #parseError and signal a custom Exception subclass
> or do any other kind of handling.  If the sender wants to handle it he
> can catch the doesNotUnderstand looking for that particular selector.  I
> have implememented a special #onDNU:do: method which checks this
> easily.
> 
> > CompiledMethod blockNodeIn: calls: decompileBlock: isInlined
> 
> #decompileBlock: only gets called when ClosureCompiler is loaded,
> because its senders #blockNodeIn: and #blockNode only get called by
> BlockClosures or BlockClosure contexts (MethodContexts where
> isExecutingBlock is true).
> 
> > As it is right now, I suspect that decompilation and 
> > maybe debugging won't work right.
> 
> Things should still work right.  If not, please report reproducable
> bugs.
> 
> Brent Vukmer <bvukmer at blackboard.com> wrote:
> > I was working a 3.6a-5313 image today, and debugging seemed funky;
> > over and over, I would be stepping through a method, and suddenly
> > the debugger would switch to a frame that had something to do with
> > Context-handling.
> 
> I think you are referring to when stepping past a halt or some other
> signal.  It will show the complete stack and not hide the exception
> handling part.  So the active frame will jump up several frames. 
> Maybe we should change this to hide the handling contexts when
> stepping and only show them when sending.
> 
> Things should work without GeneralEnh-ajh but I would still like to see
> GeneralEnh-ajh included.  I took out a lot of stuff and only kept
> things I think a generally useful.  The result is pretty small.  So
> please review it and consider adding it.  ClosureCompiler-ajh will need
> it, so it should go in sooner or later.
> 
> Cheers,
> Anthony