Library stack organization and standalones

[Dar Scott]

On Wednesday, February 4, 2004, at 07:04 PM, Richard Gaskin wrote:

>> I think this may be a doc problem.  I thought build a standalone meant
>> build a standalone.
>
> It does, in the sense that the application doesn't need a separate 
> "player"
> engine.

That's what I now realize.

> Us "old schoolers" who started out with MC fell into the habit of 
> building
> with the structure we want in the standalone, since the MC builder just
> bound the VM to your specified stack file without any of the extras.

That is what is missing in the description of the DB, that in its heart 
what it does is paste a stack-file onto an executable.

> Thanks to those explanations I understand the intention, but I still 
> prefer
> to minimize differences between the development environment and the
> standalone; it may be superstition, as those who do otherwise report 
> few
> problems, but I have enough debugging to do in my stuff as it is. :)

We still have the difference of where mainStack goes in the message 
path.

However, I wasn't trying to have any differences.  No more than we 
worry about differences between a script and a compiled script, we 
assume the compiled script faithfully reflects the script.  I thought I 
was noticing potential differences.

Now that I am a reformed man, I will try to keep to the traditional 
stacks-lying-about method.  Unless I find embedded stacks and externals 
useful.  ;-)

Dar Scott