At 4:54 PM +0200 on 4/8/00, M. Uli Kusterer wrote:
>Anthony,
>
> scope is again a problem. Even if you define that command in an openStack
>handler, where the scope is almost clear, this would then probably modify
>the behaviour of all other stacks.
Yes. That's the idea. It would not be for casual use. It would be for
extensions to FreeCard, which would reside in an extension stack or the
Home stack.
It's for things like the FreeCard web browser, which will need to
define new syntax for other stacks to use. It's for implementing as
much as possible in stacks, not the application. With this, things like
`ask' and `answer' are the responsibility of the UI stacks alone.
Non-programmers can add new syntax easily.
The added syntax would (virtually) become part of the stack; it would
only be active when the stack is in the hierarchy.
>An invitation for FreeCard virus writers
>:-(
No more than that message hierarchy thing. Sure, you can change the
meaning of sripts in very subtle ways, but you can only do it when
you're in the hierarchy.
>
> 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].
> Also what happens with commands like "send 'xy' to card 2 of stack 'y'"?
>If that used any commands that are declared on openStack we'd be in
>trouble.
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'd rather see the addition of another kind of object (like menus
>in SuperCard, or components in MetaCard), in which you can declare new
>syntax. This would be a bit more restricted but also a bit safer.
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.
>
>>Doubtfull. You can't (really) use a Unix box without a linker, because
>>on Unix, you are given source code, not binaries for most everything
>>(unless you happen to use RedHat 6.1/Inhel and trust whomever made the
>>RPM)
>
>But are we guaranteed to be running on a box with the same linker?
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.
There is a great set of packages -- GNU Autoconf and GNU Automake --
which figures theses things out for you at build time.
[0] On Unix it could, but not on MacOS. Not sure about Windows.
