memory persistance

[dbs]

Hi! Is there a module that will allow me to keep a variable at a certain value across different runtimes? Whats the name? So I run my script at 2PM, a value gets set to 5 then I run the same script at 4PM the value remains at 5. I run it again at 430PM this time setting the value to 6. The next day (no reboot) I run it at 8AM and the value is still at 6. thx!

[chromatic]

I use DBD::SQLite for this. My cron jobs launch shell scripts which set up paths to driver programs which connect to databases, perform some work, and then exit.

The initial setup and learning curve may seem daunting (and it may be daunting for your purposes), but I've found it easier on my projects than starting with flat files and reinventing file handling and the such.

With that said, if you use something like YAML::XS to abstract away the file loading, parsing, and saving, flat files aren't too bad.

[dbs]

cool thanks! I am looking at IPC-ShareLite-0.17 and IPC-SharedCache-1.3. Thx!

[ww]

Not a module, but...

#!/usr/bin/perl
use strict;
use warnings;
use 5.012;

BEGIN: recover_var();

# main here
# ... insert your existing code for getting the value here
# Since you didn't tell us the variable name, we'll use $var and assum
+e you've used it

my $var;

say "(\t\t Simulating execution of existing...";
say "\t\t code to obtain a (new) value for \$var";
say "\t\t and NOW simulating that said execution is complete. \t)\n";
$var += int(rand(113));

say "\n\tTake a pencil and write the current value of \$var, $var, on 
+your yellow sticky.";
say "\t Otherwise, the value of \$var will disappear when the RAM used
+ by \n\t this script is returned to the OS on termination of the scri
+pt./n";
say "\n\t\t\tTerminating...";
exit;


sub recover_var {
  if ( !$var ) {
    print "\n\t Find your yellow sticky (you did write down the old va
+lue, didn't you?) \n\t and enter the last \$var found on the sheet\n\
+t or '0' if no sticky is found: ";
    chomp ($var = <>);
    say "\n The last known value of \$var was $var.\n";
    return;
  }
}

Tested, but may not be suitable for purchaser's application. No warranty of fitness implied.

Despite the actual syntax error (the begin block that isn't), this passed perl -c ... with flying colors. Expanding on the note above, this is NOT suitable for OP's need, but taken litterally, OP asked for a way to keep a variable in memory after script termination... so here's a way, albeit with "dead tree RAM".

:-)

[splicer]

@ww:

I think your code needs error handling. You should be tossing an exception if the user chooses non-sticky paper or paper of a different color.

[ww]

...and if user selects a recording implement other than a pencil?

[dwm042]

Do you see any particular advantage to keeping such a value in memory rather than reading and writing such a value to a file or database?

If speed were required, keep the file on a ramdisk.

[sundialsvc4]

To my way of thinking, “IPC sharing” modules are intended, as the acronym implies, for Inter-Process Communication.   In other words, two or more processes are running at the same time and they need to communicate with one another reliably in real-time.   Which is not the case here.

What you seem to be describing is a persistence mechanism, for preserving data between runs that occur many hours apart.   “Storing the data in memory” would, in my view, be entirely unsuitable.

SQLite is an excellent suggestion because, even though it is “a disk file,” it is also a database in that you can keep any number of tables inside the thing, and you can run queries against it, all without involving a database server.   (If you do have a database server at-hand, and a friendly DBA, you might also consider using a database on that server for this and any similar purposes.)   You might even consider using this storage, not merely for “the parameters needed for the next run,” but for a log about previous runs that have been made, and/or for anything that you might need to support re-runs.

If you do use SQLite, here’s one important caveat from experience:   use transactions.   If you don’t, SQLite will obediently verify every single disk-write by re-reading the data, as it has been programmed to do, thus dropping performance to one-half disk drive speeds.   Wrap even small requests in a transaction so that SQLite will know that it can buffer the data in-memory for a while and do “lazy writes,” with a dramatic improvement in performance.   Also note that SQLite (IMHO...) really isn’t architected with “many simultaneous writers” in mind.

[spadacciniweb]

Storable?

[afoken]

Storable?

Perhaps not. Storable highly depends on the perl version. It's ok if you need it just for communication with perl processes on the same machine, but it will bite you when you update perl or move to a different platform.

Alexander

[spadacciniweb]

I read from documentation:


You can also store data in network order to allow
easy sharing across multiple platforms, or when storing
on a socket known to be remotely connected. The routines
to call have an initial n prefix for network, as in nstore
and nstore_fd . At retrieval time, your data will be
correctly restored so you don't have to know whether you're
restoring from native or network ordered data. Double
values are stored stringified to ensure portability as
well, at the slight risk of loosing some precision in the
last decimals.

and

This version of Storable will defer croaking until it encounters a dat
+a type in the file that it does not recognize. This means that it wil
+l continue to read files generated by newer Storable modules which ar
+e careful in what they write out, making it easier to upgrade Storabl
+e modules in a mixed environment.

Mariano