memory saturating with a repeat loop

[Andre.Bisseret]

Bonjour,
What an awesome list !
Thank you much Richard, Jim, Pierre and Bernd for your prompt answers  
and advices.
Given your help (and a good night :-) I feel far better!
I am just going to study them a bit more, but I already glimpse fairly  
clearly how I shall get my handlers free from "the long repeat  
loop" ;-))

Thanks again

Best regards from Grenoble

André
Le 21 août 09 à 21:50, BNig a écrit :

>
> 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.
> Than I did a send in time version and it went smoothly and fast even  
> though
> it was over a local area network.
> I made a bug report as a minor bug #6631 which has a demo stack that  
> shows
> how repeatedly loading a stack and deleting it afterwards crashes
> revolution. And there is the send in time version that avoids  
> crashing.
> Essentially it is like the code Richard has proposed.
>
> Once you get the idea of send in time constructs they are a) easy to  
> do and
> b) keep you out of trouble because Revolution can do it's  
> housekeeping while
> you do your long and tedious computing.
>
> It may be a design flaw to put that amount of data into that many  
> individual
> stacks but there were reasons for me to choose this approach. And  
> with the
> send in time approach all went well.
>
> regards
> Bernd
>
>
> Andre.Bisseret wrote:
>>
>>
>> I don"t see how I could avoid the repeat loop ? (how to use a "send  
>> in
>> time" structure ? is it instead of the repeat loop ??)