memory saturating with a repeat loop

[Jim Ault]

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<niggemann at uni-wh.de> 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
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution

Jim Ault
jimaultwins at yahoo.com