purging a stack: the third way has been found

Richard Gaskin ambassador at fourthworld.com
Mon Jul 12 10:57:34 CDT 2004


Recap:

There are two ways Transcript can purge a stack from memory: setting its 
destroyStack to true and then closing the stack, or using the "delete 
stack" command.

In more than a year and a half RevNet has had only four users which have 
reported anomalies suggesting that the GoRevNet plugin is being purged 
from memory, but this could not be reproduced here and in most cases the 
issue had mysteriously gone away.


The Third Way Found:  Preferences in the Rev IDE

The mystery has been solved thanks to the dilligent sleuthing of Jacque 
Gay and Jim Lyons:

There is a preference in Rev, under the "Files and Memory" section, 
which allows you to have a stack purged when the last stack in its file 
is closed.

This preference reflects the engine's behavior by default (no such 
behavior naturally occurs unless the destroyStack is true or a script 
under your own control comes into play), but apparently those few who 
have reported issues have turned that preference on.

So one fix is simple enough:  stomach the hit to the download time of 
RevNet by replicating much of GoRevNet's scripts and libraries into 
RevNet itself.

This raises a question:

   Should a plugin be treated like one of the user's work stacks,
   or like an extension to the IDE
   enjoying the same exceptions as IDE stacks do?

The preferences were designed to operate on the user's stacks, and as a 
by-product also affect plugins.  But plugins serve a different role, one 
arguably more akin to the nature of the IDE itself than to the user's 
work stacks.  So one could argue that plugins, as extensions to the IDE, 
should be as exempt from this purging action as the IDE itself.

A purist might counter-argue that stacks are stacks, it in keeping with 
the "eating our own haggis" approach all are treated equally.

But such a view conveniently overlooks the IDE itself, which operates by 
different rules because its stacks serve a different set of goals than 
the user's work stacks.  If ALL stacks were treated equally it would be 
like doing watch repair where the only tool you have to work with is 
another watch.

So in short:

Should plugins be recognized as IDE extensions and given the same 
exceptional treatment as other IDE stacks?

If there's some agreement with this view I'll Bugzilla this.....

-- 
  Richard Gaskin
  Fourth World Media Corporation
  ___________________________________________________
  Rev tools and more:  http://www.fourthworld.com/rev




More information about the use-livecode mailing list