IDE Interference - the bottom line (that's it!)

[Brian Yennie]

> First I want to say that even though my tone is not apparently RR 
> friendly,
> im only trying to point out the obvious in a rudimentary way... Im not 
> upset
> or raving to get RR aknowledge a bug, just trying to point out a flaw 
> in
> 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 
> error
> 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 
> environment
> 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 
> some
> serious and relatively unnessarry network segregation (IOW it's hell 
> planned
> 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 
> zippy.

Copying files and saving an open file from memory to disk are different 
operations.
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 
saves.

> 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 
> would
> 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
> business!
>
> I hope they find out how ;)
>
> Again I didn't expect that changing an object property or picking the 
> button
> tool
> would engender a suspendstack event... This was a left over message I 
> forgot
> about...

Understandable, but hardly a Rev problem- see above.

> The bottom line is that through this "experience" we have seen two 
> things:
> 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 
> the
> IDE causes HAVOC. Im testing RR in our production environment and this 
> issue
> 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.

- Brian