[BUG] GeneralEnh-ajh.1.cs is missing from update stream

Anthony Hannan ajh18 at cornell.edu
Fri Jul 4 03:03:10 UTC 2003


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



More information about the Squeak-dev mailing list