Script Only Stack Architecture

Thu Mar 31 11:04:45 EDT 2016

Sannyasin Brahmanathaswami wrote:

 > On March 30, 2016 at 6:17:20 PM, Richard Gaskin wrote:
 >
 >> in brief:
 >> 1. Open them
 >
 > # this did not work for me earlier today

What exactly happened?

It may be helpful while demystifying this to work with ordinary stack 
files for your behavior scripts.  There's really no difference between 
ordinary stack files and script-only stack files beyond the storage 
format, but if nothing else sense you're already confident in your use 
of normal stacks it may help you focus on the things that may actually 
be the source of the problem.

In this case, with opening a stack used as a behavior script, I'd guess 
that the problem wasn't that the stack couldn't be opened, but that it 
failed to resolve as a behavior for another object.

If that hunch is correct then the problem isn't with the script-only 
stacks or even how you opened them.  The problem is with the strangely 
finicky way behaviors are resolved.  As I wrote yesterday:

    NOTE: a long-standing source of confusion and frustration with
    behaviors is that the object holding the behavior script must
    be in memory when any stack containing objects subscribed to it
    is loaded.

    When behaviors are in the same stack file the engine figures it
    out on its own.  But if the behaviors are in a separate stack
    file (regardless of whether it's script-only or normal) that
    separate stack file must be in memory first.

    In some cases this can mean introducing a new stack only for
    the purpose of loading your others so that they load in an
    order that will allow behaviors to be resolved correctly.

    Another option is to write a script that works on preOpenStack
    and walks through each object setting the object's behavior
    property to the object's behavior property, which forces
    resolution of the information already known to the engine but
    not loaded in the finicky order it requires.

    A request to simplify this has been submitted:
    <http://quality.livecode.com/show_bug.cgi?id=8993>

Given that this finicky quality has been around as long as parentScripts 
themselves (er, "behaviors" <g>), I don't expect to see it addressed 
soon.  Would be nice, but there are bigger fish to fry with v8 right now.

So we just need to make sure that anything containing a behavior script 
is in memory when anything that relies on that behavior script is put 
into memory.

Review the sequence of stack opening you'd tried earlier and see if 
that's not what had caused your earlier problem with opening the 
behavior definition stacks.

 >> 2. Read any property from them
 >
 > # have yet to try that..

It's kinda handy sometimes because it needs to unpack the stack file to 
be able to obtain a property value, but since it's not truly opening the 
stack per se it never shows visibly and doesn't trigger the open- 
messages (preOpenStack, preOpenCard, openStack, etc.).

 > 3. Adding stack files and restarting the stack works

The stackFiles is an old property predating behaviors, but useful for 
many things like image ID resolution and more - a good fit for any 
problem where you have multiple stack files used by a single stack that 
relies on them.

I rarely use it because my runtime setup is very different from my 
development setup (most external stack files are used on multiple 
projects and reside in a very different folder from the relative 
position they'll be to the app's mainstack when deployed).  But I miss 
it.  Very handy.

 > Forgive me for seeming to be obtuse.  It's partly deliberate because
 > the discourse is  opaque enough to make using script-only stacks for
 > behaviors challenging --  gaps in the picture of "exactly what should
 > I do?"  so I thought we might get some "ghee" out of the churn  --
 > clear instructions, for everyone -- and also because I really want to
 > go this modular direction so I tend to dig, dig, dig until all the
 > worms are out of the can and crawling on the table. Gold may appear.

It can seem daunting when you're making so many changes at once, since 
that makes it hard to pin down the root cause of an issue.

But I think we can boil down text-optimized development in a few simple 
guidelines:

1. Use libraries for as much global availability as practical,
    and use behaviors for as much object-specific availability
    as practical.

2. When using behaviors, the object containing the behavior script
    must be in memory when anything relying on it is brought into
    memory.

3. A library can be any stack, regardless whether it's a mainstack
    or substack.

4. A behavior definition can be any button or stack.

5. The format of the stack on disk (whether saved as an ordinary
    binary stack or as a script-only stack) only affects what gets
    saved in the file, but has no affect on how we work with them
    in memory.

Far harder than any of this is learning to use GitHub. :)

 > I did read your post and I did try to put my script-only stack  into
 > memory by using "open" in the preopenstack of the main stack.
 >
 > But it did not work. The child called out, (mouse up on field) but
 > the parent didn't hear it even though he was in the room (in memory
 > via "open)

I suspect that's because of the loading order (#2 above).  But let us 
know if you find otherwise.

 > I will test again tomorrow after letting LC8 rest over night. The
 > LC8 IDE has a  referencing issues... and is "losing the target" in
 > a number of scenarios. Like the case of deleting an object on your
 > card and watching while a button in the inspector palette disappears
 > instead. Msg path gone awry until you restart. The failure of mouseup
 > to not trigger the behavior when the parent stack is in memory
 > already... smells like a similar fish...

Please report those, or if already reported add your notes confirming 
the issue.

For most of LC's life there has only ever been two versions:  current 
and past.  Current is whatever is in development, and the past is 
whatever used to be in development and reached end-of-life when a newer 
version becomes current.

During this long process of moving from the v5-and-earlier world into 
the modern world that can fulfill the Kickstarter goals, we've 
temporarily been indulging in a very expensive process in which the team 
has been maintaining three very different versions (6,7, and now 8) 
simultaneously.   There were good reasons for this, given the scope of 
monster tasks like Cocoa, Unicode, and others, but it's unsustainable.

It's time to return to the normal world most software projects have, and 
LiveCode used to have, in which there is only one version in active 
development.

It's critically important that issues found in v8.0 be reported and 
addressed.  If reports add another week or two to the development cycle, 
that's far better than releasing it and having those issues still present.

Please do report issues you find.  It takes only as much time as 
describing them here, but makes them actionable for the team so they can 
be resolved.

 > I agree BTW -- "parent" is a  much more helpful term.. we use that in
 > CSS and XML... so why not here? I've even start replacing "behavior"
 > with "parent" in my head, as it helps keep things straight.

I believe it's more specific and less ambiguous (so many properties 
alter the behavior of an object; the word "behavior" is so very broadly 
used that it makes writing about that specific property somewhat 
cumbersome at time).  "ParentScript" was the original name for the 
property and last I looked it remains a reserved token.

But we're so far down this road with the newer "behavior" that I think 
we're just stuck with yet another learning impairment in the language 
going forward.

Oh well.  Better than not having the feature at all.

 > POINT:  though you may not want to overload the dictionary, something
 > more is needed.  Who has contributing rights?    I could give is a
 > shot (much more concise.)

That would be most welcome.  They made a blog post with the relevant 
links introducing the process of community enhancement of the docs:
<https://livecode.com/putting-the-you-in-documentation/>

 > Mahalo for your near-infinite patience!

Happy to help.  Just paying it forward.  You should have seen some of my 
posts on the MetaCard list circa '98.  I was moving from SuperCard, 
where we only had a single custom property set, and was having a very 
difficult time wrapping my head around the syntax for working with 
multiple property sets.  Kevin Miller and Scott Raney were far more 
patient with me back then than I've ever been. :)

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com