It's fairly common for people to write an infinite loop in their Eidos code and hang SLiM (or SLiMgui) as a result. This can be confusing. For example, this is common in spatial models, where one's loop to generate an in-bounds point can hang if there is a bug in the code that makes it never generate an in-bounds point.
It seems to me that Eidos could watch for this. Keep an execution counter on each statement; increment the counter each time the statement executes; if it reaches, say, 1 million, terminate with an error message that highlights the offending line of code. This would add a little bit of overhead, but not much; probably appropriate for SLiMgui runs, but not for command-line runs, by default. This facility could be turned off/on explicitly with an option to initializeSLiMOptions(); it could be NULL by default, meaning "on in SLiMgui, off in slim", but you could supply T or F to force it on/off in both environments.
For callbacks/events, it would be nice to zero out the counters each time the callback/event is called, since some callbacks are called a very large number of times even within a single tick.
It's fairly common for people to write an infinite loop in their Eidos code and hang SLiM (or SLiMgui) as a result. This can be confusing. For example, this is common in spatial models, where one's loop to generate an in-bounds point can hang if there is a bug in the code that makes it never generate an in-bounds point.
It seems to me that Eidos could watch for this. Keep an execution counter on each statement; increment the counter each time the statement executes; if it reaches, say, 1 million, terminate with an error message that highlights the offending line of code. This would add a little bit of overhead, but not much; probably appropriate for SLiMgui runs, but not for command-line runs, by default. This facility could be turned off/on explicitly with an option to
initializeSLiMOptions(); it could beNULLby default, meaning "on in SLiMgui, off inslim", but you could supplyTorFto force it on/off in both environments.For callbacks/events, it would be nice to zero out the counters each time the callback/event is called, since some callbacks are called a very large number of times even within a single tick.