Allin Cottrell schrieb:
On Wed, 10 Jan 2007, Sven Schreiber wrote:
> I see. Then my question would be, how can one achieve persistence of
> generated matrices?
Actually, on second thoughts that shouldn't be difficult. Right now,
when you run a script, gretl goes through a checklist of stuff to clear
out, including undefining all existing user matrices. It would be easy
enough to skip the "clear out matrices" step. Is that generally desirable?
Well, just skipping matrices doesn't seem like a clean solution. To be
honest, I don't understand why anything has to be cleared out at all,
except maybe to avoid memory leaks. But in principle I had expected
scripts to work in a "cumulative" fashion, meaning that I can run
several scripts in a row and then have _all_ results available.
What about the following solution (sketch):
- When a script is run, append the existing objects (results from
previous scripts or whatever) to the session file, and clear their
contents from RAM (but keep an accessible list of them in memory).
- when the user requests one of the "old" objects, reload it from the
- alternatively (but more complicated I guess) have an upper memory
limit for objects, and dynamically move the oldest (stalest) objects out
of the working memory to the session file if that limit is hit.