memory saturating with a repeat loop
jimaultwins at yahoo.com
Sat Aug 22 14:35:10 EDT 2009
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
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.
On Aug 22, 2009, at 1:52 AM, Bernard Devlin wrote:
> I think Andre and Bernd may both have been victims of this bug:
> 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!
> On Fri, Aug 21, 2009 at 8:50 PM, BNig<niggemann at uni-wh.de> wrote:
>> 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
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
jimaultwins at yahoo.com
More information about the Use-livecode