>> Furthermore, going to a stack with lockMessages will cause all sorts of
>>syntax errors since the commands have not been registered. I'm not sure
>>it'll turn out exactly like that, but I can imagine that when scripts are
>>interrupted we will get even worse errors than we used to get.
>
>The actuall command/function add can not be interrupted, for good
>reason. The way interrupts in NuInterpreter will probably work is that
>every 50 jiffies, the Intepreter will suspend the instruction stream,
>check for interrupts in a platform-specific manner [damn they're so
>much easier on Unix!] and if it detects one, clean up and exit. The
>actuall syntax add will be a function call, and will be in C++;
>NuInterpreter can not check for interupts then, because it's not in
>control[0].
???! Pardon me? I don't get what you're talking about ... ?
I'm talking about interruptions, not low level interrupts. I.e.
command-period being pressed, a runtime error causing a script to exit
prematurely etc.
>You shouldn't be sending random commands to unknown stacks which aren't
>even in the hierarchy. The worst thing that would happen, though, would
>be a syntax error.
I beg to differ. Many of the stacks I'm using implement plug-in stacks in
a way that would need something like this.
>The problem with this is that there is no clear point of instantiation
>for the user-defined syntax. Also, it's FAR to transparent for the
>wide-ranging effects syntax additions have.
I think it'd be very clear when this syntax is instantiated: Every time
some script in this stack executes, or when the stack is start-used.
>Q: If we don't know how to run the linker, how does our makefile (which will
> need the linker to link FreeCard) work?
>A: Not at all.
>
>Conclusion: We must know how the linker works, if we built FreeCard.
We know what linker we have on *our* computer. But how about some other
user's computer? He might have an entirely different linker installed, and
if the user happens to be a programmer, he'll be able to figure out how to
compile it with his compiler and linker. However, the user would be less
well off.
I don't know, I just think that such a tool that relies on an external
linker will both mean asking for something to go wrong as well as entirely
miss the target audience of a FreeCard product. Those who can work with
this can easily compiler FreeCard from the sources, while those who can't
will probably have enough problems with the linker as is.
Cheers,
-- M. Uli Kusterer
------------------------------------------------------------
http://www.weblayout.com/witness
'The Witnesses of TeachText are everywhere...'
