Perhaps there is a way to help define your limits in a Rev app or
running in the IDE.
Suggestion: build a ReportStack.exe (or .app) that listens for packets
sent from the stack you are developing.
This means that you would compile a stack that will open a port when
you click a button, then record the packets received.
The stack you are developing will send a packet at the top of a repeat
loop, or other timing event that includes the ticks. The result is
that you can post packets to a standalone that will keep running even
if there is a freeze, crash, or other catastrophe.
This would also allow you to use a timeout setting in the standalone
to detect the packet flow stoppage, then use either Applescript or
Visual Basic or shell() to get the environmental variables from the
operating system.
Of course, recording the environ variables should also be done when
the process is started so you would have a baseline.
This should be easy and stable.
There a two sets of stacks that would let you quickly develop this tool.
UDP Echo Client & UDP Echo Server
TCP App 1 & TCP App 2
... all by Alex Tweedly
These apps running on the same computer are very fast and consume
almost no resources.
Just an idea for developing and also running the StatusReportStack.exe
on the client's computer. Of course you could also add log file
functions so you could receive the info via email, etc. I do the auto-
email-log-files with some web server software I am running on a
client's remote system.
Jim Ault
Las Vegas
On Aug 22, 2009, at 1:52 AM, Bernard Devlin wrote:
I think Andre and Bernd may both have been victims of this bug:
http://quality.runrev.com/qacenter/show_bug.cgi?id=2772
It seems crazy that we have so many different workarounds for a
fundamental bug. Of course the workarounds offer an immediate
solution. But there are other cases where crashes seem inexplicable
(and sometimes unreproducible) which might also be an effect of this
bug. As Ben's comments in the bug report show, this bug can come back
and bite you in your deployed application.
This bug report is over 4 years old, and one of the people who
expressed interest in this bug being fixed subsequently quit using Rev
because of serious problems like this. If you think that it is
important for the stability of your projects and the reputation of
Rev, then I would suggest you vote for this bug.
No more workarounds - Vote Yes on 2772!
Bernard
On Fri, Aug 21, 2009 at 8:50 PM, BNig<[email protected]> wrote:
Andre,
I ran into the same problem when analysing 3500 stacks distributed
over 3
computers, over 1000 stacks on each. Rev crashed. In the repeat
loop version
you could watch the memory go down in the activity monitor (on a
Mac) and
once it went into virtual memory soon after it crashed.
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Jim Ault
[email protected]
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
