Acme::State - Save application state on exit and restores state on startup
use Acme::State; our $t; print "t: $t\n"; $t = int rand 100; print "new t: $t\n";
... and then run it again.
Crawls the package hierarchy looking for
our variables. Stores them all off in a file in the home directory of the user running the script. When the script using this module starts up, this same file is read in and the variables are restored.
Serializes scalars, hashes, and arrays declared using
use vars, or otherwise not declared using
my. Uses Storable to write the data. The save is placed in the home directory of the user the script is executing as. The file name is the same as the script's name (
$0) plus ".save". It also keeps one backup around, named
$0.save.last, and it may leave a
$0.save.new if interrupted.
$Acme::State::wantcoderefs, if set true, takes things a step further and tells Acme::State to also serialize subroutines it finds. Nothing says fun like persisting coderefs from the stash and a 40 of Mickey's.
This code reserves the right to
die if anything goes horribly wrong.
Explicitly request a snapshot of state be written to disc.
dies if unable to write the save file or if a sanity check fails.
Optionally also use Coro to create an execution context that runs peroidically to save snapshots.
Original version; created by h2xs 1.23 with options
-A -C -X -b 5.8.0 -c -n Stupid::State
PAUSE rejected the first one because it didn't like the permissions h2xs left for the automatically generated META.yml file so it wouldn't index it, but it also wouldn't let me delete it, so this version is actually identical to 0.01.
use IO::Handle. Not every program already does that for us.
What could possibily go wrong?
You *could* use an ORM, and wind up translating all of your data to a relational schema you don't care about or else have it automatically mapped and completely miss the point of using a relational database. You *could* just store your data in the Ether with Memcached. You could
UPDATE manually against a database to store every little tidbit and factoid as they're computed. You could use BerekelyDB, including the build-in legacy
dbmopen and mangle everything down to a flat associative list. You could use Data::Dumper to write a structure to a file and
eval that on startup and keep all of your precious application data in one big datastructure and still not be able to persist entire objects. You could use
dump and keep waiting for the day that someone finally writes
But what's the fun in that? None of those are one
use line and then never another thought. That's like work for something. Work is for suckers. We're Perl programmers. If it's not automatic, it's not worth doing.
Scott Walters, <firstname.lastname@example.org>
Copyright (C) 2009 by Scott Walters
This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself, either Perl version 5.8.0 or, at your option, any later version of Perl 5 you may have available.