IDE Interference - the bottom line (that's it!)
briany at qldlearning.com
Sat May 29 00:27:34 CDT 2004
> First I want to say that even though my tone is not apparently RR
> im only trying to point out the obvious in a rudimentary way... Im not
> or raving to get RR aknowledge a bug, just trying to point out a flaw
> design within the IDE and seeing if others have seen this and why it's
> there. Thanks to Jan and Richard, the solution is apparent. Yet the
> will come back im sure...
Well if you know your tone is not Rev friendly, but I digress... I hope
nobody's actually upset- I'm not. Perplexed, but certainly not upset =).
> Im particularly affected (note I haven't entered a bugzilla!) because
> 1) I
> rely on these stack-script-level events "extensively"; 2) my
> usually works within stack events to interact with other stacks; 3) Im
> editing and working in the IDE for the most part; 4) MC is also
> affected yet
> hadn't noticed for the past 4 years until our company decided to do
> serious and relatively unnessarry network segregation (IOW it's hell
> the wrong way!)
I still don't see the bug. suspendstack is well defined, and you point
out MC has been that way for those 4 years (and more). It's not an IDE
message, it's an engine one- and it's working properly. It's probably
just the wrong message to use as a save stack trigger.
> I used to run HC on diskettes... And here we have a FAST network, all
> copper gigabit (about 4 GB/hour avg transfer times)... I still can't
> explain why it takes 30 seconds to save a 1 meg stack. Could be the
> AV or FW, its hard to say... It sure is excrutiatingly slow...
> But its not the net. When I copy data from elsewehere, it's quite
Copying files and saving an open file from memory to disk are different
That why I suggest saving to the local disk and _then_ copying that
file to the network volume, perhaps in the background of ever so many
> Now about the events, logical assumption is that the IDE event model
> should not interfere with the application in development events. This
> is why RR has a secondary event level usually named rev[eventname].
Wouldn't it be worse if suspendStack stopped working as documented
whenever the IDE was present, because the IDE stacks were specially
excluded from the rules? What if your stack needed the actual
documented behavior- you'd be at a loss to have anything work right
without first suspending the development tools.
> But as Jan mentioned, palettes are stacks.
> What I didn't expect is that a palette, let alone the tool palette
> cause a suspend stack.
Fair enough- but it's not a bug, it's documented chosen behavior.
> If RR could speed up our network, EMC, Cisco and HP would be out of
> I hope they find out how ;)
> Again I didn't expect that changing an object property or picking the
> would engender a suspendstack event... This was a left over message I
Understandable, but hardly a Rev problem- see above.
> The bottom line is that through this "experience" we have seen two
> 1 - your stacks should be protected from IDE events IF and ONLY IF you
> decide to use
> the stack messaging system as an event trigger - which in the case of a
> standalone app is futile but in the case of a running system based on
> IDE causes HAVOC. Im testing RR in our production environment and this
> has proven counter productive (dont you like Tuvoc talk?).
So the IDE should dynamically suppress engine messages based on which
ones your stack might be using, just in case you didn't want your stack
to interact with other stacks if they are part of the IDE? Sounds
pretty messy to me...
> Nice assumption but I need these programs from anywhere in the network
> including in different network segments with Firewalls in between...
> More RR
> saving testing to be done next week...
Right- but the point wasn't to only save them locally, it was to make
local saves more frequently and then copy those files to the network
volume- if copying files is actually much faster than saving directly
to the network as you described above, this might help. Surely it's ok
for a few minutes of work to be cached locally, and you could even run
the copying to the network in the background while you continue working
by using shell() to do the copying.
More information about the use-livecode