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

[MisterX]

Brian,

Dont get me wrong. I think you have...

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...

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!)

As Richard pointed out, I will have to work with frontscripts...
innevitability?

more below...

> Xavier,
>
> > Monte, I saw that MC was also afflicted with thi issue. But IMOHO the
> > Rev
> > messaging
> > should not interfere with applications in development - As I developped
> > XOS, I used
> > extensively the HC messaging to intercept all stack events from the
> > hierarchy top -
> > much like frontscritps would and will soon - the key point was not to
> > interfere with other
> > stacks and this required particular checks everywhere...
>
> If MC is afflicted, then how is Rev messaging the problem? You mean the
> engine messaging you don't like? Comparing HC on save issues is really
> apples and oranges, although I don't know if it would be very happy
> either running off of a slow network disk.

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.

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].

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.

> > In a multicard environment, a single card script would not sufice - if
> > I
> > read you right...
> > That's why it was in the stack script. Note that there is an advantage
> > in
> > this feature...
> > It simulates the HC saving which was part of its robustness...
> >
> > The problem was:
> > - saving over the network is 100 times slower...
> > - choosing a tool or changing a property sent a save which I forgot was
> > there causing these freezes...
>
> It sounds to me like what we should really be doing is having a to the
> point discussion of the crashes, not the saving mechanism.
>
> What do you expect Rev to do... speed up your network? If you're going
> to write an auto-save handler that kicks in every time you click
> around, and you're saving to a slow network volume, well...

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...

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?).

> Can you not write to the local volume at all? If you can, how about
> auto-saving to the local volume and then periodically uploading to the
> network instead of writing your whole stack to the network on every
> other click?

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...

X

> - Brian
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution