Execution of a "long" script

[JB]

Thanks Richard!

I was concerned about it after the question was brought up
because there is a chance someone will select a lot of files
to process and I have never tested LiveCode with scripts
that take a long time.

I was glad the question was asked because it made me take
into consideration of a possible crash from any reason and I
will be sure to keep track of the work done so it can start up
where it crashed and not worry about repeating the work.

Once again you have provided me very good information and
the comfort in knowing it has been tested for extremely long
tasks.  Knowing that means a lot to me.

John Balgenorth


On Aug 11, 2014, at 7:49 AM, Richard Gaskin <ambassador at fourthworld.com> wrote:

> JB wrote:
> 
> > Can you trust this large script will not crash or should you inform
> > the user the chances of a crash will increase if they use other
> > memory intensive applications.  Is there a way to prevent it?
> 
> Any time LiveCode crashes it's a bug that should be reported.  Even with low-memory conditions, the app should dip into swap rather than crash. This may not always be practical depending on the nature of the task, but it's an ideal worth pursuing.  The only errors that should ever occur in LC are ones related to our own scripting mistakes.
> 
> Apps reflect a wide range of behaviors in low-memory conditions, and most apps contain in them somewhere some sort of bug that will cause them to crash.  Undesirable, but it happens.
> 
> When the issue is exposed by low-memory conditions, the issue is compounded by the likelihood that there isn't even enough memory to invoke the normal error handling, so that rather than simply stopping execution with a warning the app may simply crash instead.
> 
> All that said, thanks to the community's rigorous testing and the engine team's ardent pursuit of good memory management, many of us have apps that have run for many hours or even days without a hiccup (I have one here where normal uptime is measured in weeks, usually only interrupted because I rebooted the machine for some other reason unrelated to my app).
> 
> LiveCode isn't completely bug-free (if it were it might be the first in computing history), but AFAIK at this time there are no known memory leaks.  The engine team tends to jump on those quickly, so when discovered they usually don't live very long.
> 
> I would encourage you to pursue any sort of task with LC you like, and if you encounter issues to report them.
> 
> For very long tasks it can be helpful to introduce means by which the apps surrenders time to the OS to attend to other things, either by breaking the task up into chunks and calling those chunks with "send", or by using "wait 0 with messages".  This will help ensure the OS can do its job with memory shuffling and other things it needs to do to keep up with LiveCode.
> 
> And FWIW, on some Mac systems I've seen surprisingly poor throttling at the OS level, in which some processes have been allowed to run to the point that it overheats the CPU.  Most modern motherboards contain temperature monitors that shut the machine down before the heat can damage components (even the super-cheap mobo I got from Biostar recently for $59 has this), but one of my Mac laptops went through three motherboards as a result of overheating.  A single date point like one Mac isn't enough to suggest that this is endemic or epidemic to Macs, and if it were we'd have read about it in the Apple support forums more frequently.  Just something to keep in mind which may potentially affect any system, providing good motivation for periodically freeing up clock cycles to let the system at least do the things it needs to do for monitoring.
> 
> After all, if a task is going to take several hours, what's a little extra time introduced by sharing the CPU?
> 
> There are other things to consider as well:  sometimes a long task is just a long task, but often there are means to reduce the processing time through seemingly-small refinements in the code.  Using "repeat for each..." instead of "repeat with i = 1 to ..." is a common example, but there may be others which also provide an order-of-magnitude speed boost.
> 
> And for really long tasks there are ways of spreading the work across multiple computers on your LAN with a sort of MapReduce.  A bit of work to set up and certainly carries a lot of overhead, but for a task that takes the better part of a day it may be worth the effort to explore.
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> ____________________________________________________________________
> Ambassador at FourthWorld.com                http://www.FourthWorld.com
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>