On Wed, 8 Dec 1999, Ruediger zu Dohna wrote:
> Scott Raney wrote:
> > > "the callStack" that returns the entire call chain that led to the
> > > current handler.
> >
> > This is sort of already available: the executionError returns a
> > traceback of all the script elements that were executing when the
> > error occured. It's more than a "call stack", though, because it
> > doesn't just include the function/message handler names.
>
> We have found that... but it is not perfectly reliable and it only traces
> back to the last "send" command.
Hmm. Would it be sufficient if it did work through "sends" and/or had
improved reliability? Can you provide any examples of cases where it
doesn't work right?
> > > "the variableNames(n)" that returns a list of all variable names used in
> > > the handler that is <n> frames down the call chain (the default for <n>
> > > is 0).
> > >
> > > "the variableScope(<name>,<n>)" that returns one of "parameter",
> > > "local", "script", or "global" for the variable with the name <name>
> > > that is <n> frames down the call chain.
> > >
> > > "the variableValue(<name>,<n>)" that returns the value of the variable
> > > with the name <name> that is <n> frames down the call chain.
> >
> > These three would be very difficult to add ... unless the performance
> > hit were acceptable
>
> The information is already in the system... i can imagine that is difficult
> to get to, but it is possible... at error time... without a general
> performance hit. It is possible in C++, why not in xTalk?
There are two issues here, unwinding the stack and access to the
various contexts. Currently the error routines completely unwind the
stack before the error dialog comes up. It might be possible to have
it work otherwise (e.g., the call stack would only be unwound if some
property was set), but there are a lot risks here (e.g., recursion
would likely crash the program or the whole system). As for the
contexts, these are available via C/C++, but are in a CPU-specific
format and include a lot of junk that you definitely wouldn't want to
see in a script traceback. If you've ever seen a traceback from an
engine crash, you'd see that some commands like "go" and "sort" cause
multiple-level call stacks all by themselves. In order to provide a
script-level callback list, this information would have to be built up
*during* execution which would have a major impact on performance.
Unless of course you build it during the unwinding process, which is
what it does now, but unfortunately during which you lose the
contexts...
> > running a debugger
>
> ... is not solution to our problem. And the debugger has the problem,
> too: You must anticipate the error. If it is difficult to reproduce,
> you are lost. The debugger in HyperCard was much better, you'll have
> to admit, but I'll have to admit that this is not a reason to generally
> go back to HC ;-) ... there even was some XCMD debugger that could
> display the variables up the call chain, but I forgot its name.
All of this is possible because of the MacOS-centric nature of
HyperCard. Building something like this cross platform would be
vastly more difficult and a practical impossibility on some UNIX
systems which don't allow inspection of the internal state of a
running executable.
> > > Even having only access to the callStack could help debugging very much.
> > > Who else needs this? It does not have to slow down the engine, does it?
> >
> > Check out the executionError property and the scripts in the execution
> > error dialog and see if it does what you need.
>
> We do that already and it is helpful. But especially the problem that you
> cant look behind the curtain of a send stops us from finding many errors.
I don't know what all the issues are with that, but can't think of any
technical reason why it couldn't be supported. I'll put it on the
feature-request list.
Regards,
Scott
> Regards
> R�diger
>
> --------------------------------------------------------------------
> GINIT - Gesellschaft fuer integrierte Informationssysteme mbH
> --------------------------------------------------------------------
> GINIT GmbH
> Ruediger zu Dohna email: [EMAIL PROTECTED]
> Technologiepark phone: +49-721-96681-63
> Emmy-Noether-Str. 9 fax: +49-721-96681-11
> D-76131 Karlsruhe www: http://www.ginit.de
> --------------------------------------------------------------------
> PGP-Fingerprint: F1 BF 9D 95 57 26 48 42 FE F8 E8 02 41 1A EE 3E
> --------------------------------------------------------------------
>
********************************************************
Scott Raney [EMAIL PROTECTED] http://www.metacard.com
MetaCard: You know, there's an easier way to do that...
