Renew #Include

[BrewManNH]

Perhaps if you posted what your script(s) look like, a description of how you'd want to change them as they're running, what the data looks like that it's working with, and anything else you'd think would be pertinent it would make it easier to see how to go about it without rewriting a script on the fly.

[mrider]

How about an SQLite database?  Open it in script one as default access (e.g. read write and create), open it in the other as read only.  Have a table where the column looks like your array, and also put in a row index, or a timestamp, or something so the reader side can "remember" what all it's seen.

Writer writes whatever data it has whenever it has it, reader does the equivalent of a select * from foo where rowindex > $last_read .

[EDIT] If the write really hammers the hard drive, then wrap it in a transaction that commits after each (say) 1000 writes.  That'll keep the write in memory until a bit of data is built up - which in turn will boost performance.  Make the number of writes a constant, and then play around with values until you find a value that works for you.

Edited January 29, 2015 by mrider

[kylomas]

mrider,

Was just thinking the same, but we need more info like frequency, volume and use.

@millisys - For the best help post your script as BrewmanNH has suggested.

Edited January 29, 2015 by kylomas

[kylomas]

millisys,

From reading your post for the third time here is what I understand:

A script runs all day ( call it script #1 )

A second script runs at night, or periodically during the day, to process data collected from script #1.

If this is not correct it might make sense to describe what you are trying to do.  There are many example of writer / reader type apps, mostly for log files.

It might benefit you to describe exactly what you are doing.  There are some very experience programmers here to help.

kylomas

[SadBunny]

Maybe I'm missing the point, but wouldn't it be easiest to just have the second script spit its output, and then have the first script read it from the StdOut (and/or StdErr) read from the child process? See the example script in the help files for StdErrRead() function.

Apart from that, generating actual autoit code to be executed is almost never a good idea. Fun to think about, maybe fun to have some sort of evolving code experiment (script one writes and runs script two, which then writes and run script one, which then writes and runs script2......), fun for maniacal scientists who want to take over the world Skynet-styley, but for daily purposes, nah... Not clean. Using an in-between solution like a database or a temp file seems much nicer.

If you are worried about hammering the hard drive but still would like to work with temp files, how about creating a ram drive? (You'd need quite some ram if the data gets really big, but it's very possible.)

[kylomas]

fun for maniacal scientists who want to take over the world Skynet-styley

 

You made my evening...

[willichan]

I feel more comfortable with data staying in ram rather than being written to hard disk. It's ok with settings info, but constant hammering of the hard drive to transfer array data makes me concerned about data integrity

Constantly rewriting scripts, as you were originally proposing, would have been hammering your hard drive anyway.  I suggest going with an SQLite database, as was suggested earlier.