"Christopher J. Demers" <
[hidden email]> wrote in
message news:
[hidden email]...
> "Sean Malloy" <
[hidden email]> wrote in message
> news:
[hidden email]...
> > In squeak thisContext is an instance of a MethodContext object.
> >
> > In Dolphin thisContext is a SmallInteger.
> >
> > Is there an actual way to get a MethodContext instance?
>
Dolphin does not use the traditional Smalltalk-80 reification of the runtime
state. Instead it represents it as an explicit stack. For normal method
activations the the only real object involved is the Process, which is a
dynamically growable object with indexable slots representing the stack. The
activation records/frames on the stack are not actually objects, but the
StackFrame classes provide an abstraction which allows the stack to be
treated as a linked list of objects in much the same was as Smalltalk-80
context objects do. Dolphin's debugger uses this abstraction extensively,
and you can also see how it is employed in the Continuations package to take
a copy of a suspended Process.
The MethodContext object in Dolphin 5 is a different beast to that in Squeak
because it is used to hold shared variables where blocks are involved, it
does not hold activation details such as the caller. Since Dolphin 5
implements Smalltalk-80 style blocks rather than full lexical closures, the
activation record (stack frame) for a method with blocks will always have a
MethodContext and all temporaries in that method and its blocks are regarded
as shared and are stored in slots in the MethodContext. This is not the case
in the next release, and the old MethodContext is no longer used. There is
still a Context object for holding shared temporary variables in the rare
cases where these are really needed, but it is little more than an array of
slots. The StackFrame abstraction remains largely the same though.
> I am not sure, maybe someone else knows. However using:
> Processor activeProcess topFrame.
> you can get a StackFrame, which may have what you want. Be carefull with
it
> though, Dolphin crashed when I opened a full inspector on it. However I
> could open a limited inspector on it (SHIFT-CTR-I).
There is a known issue with inspecting the main process in Dolphin 5.x using
the Flipper inspector. It has to do with the way the process stack grows by
catching accesses off the end of the committed region. This has been
corrected for D6 as a result of other changes, but a fix is not really
feasible for D5 so it should be avoided (which is why the Process Monitor
disables the inspect command against the main UI process). It is safe to
read from the Process stack using the StackFrame abstraction as long as you
bear in mind that the #topFrame is only a snapshot, and is invalidated when
the method returns. This means you may encounter problems if you grab the
top-frame of a running process in a workspace (for example), but you'll be
OK with suspended processes or when a process is reflecting on itself.
Writing to the stack of a process is something that can be done, but which
can cause system instability if not done correctly. Again the Debugger and
continuations package demonstrate this, the latter even updating activation
details such as return addresses.
Some useful resources:
Class Comments: Process, StackFrame, Continutation, ProcessCopier
DSDN: Try, e.g., search for StackFrame in the newsgroup archive
Regards
Blair
Locked
