Scott Walters
and 1 contributors


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 our, 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 $, and it may leave a $ if interrupted.

Web apps written using Continuity get persistant state, so why shouldn't command line apps? Hey, and maybe Continuity apps want to persist some state in case the server implodes. Who knows.

$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.


Ooops, actually 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 INSERT and 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 undump.

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, <>


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.