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