Nikodemus Siivola wrote:
> On Thu, 7 Jul 2005 jim@... wrote:
>> couple of questions about images - I can write an image core with
>> sb-ext:save-lisp-and-die but then need to kill sbcl/slime...from the
> Not "need to kill", it does that for you: if save-lisp-and-die does not
> end your session please report this as a bug. Of course, if you are
> saving cores with multiple threads running all bets are off.
>> "It corrupts the current Lisp image enough that the current process
>> needs to be killed afterwards. This can be worked around by forking
>> another process that saves the core."
>> how is this done?
> Like this (read the wait and fork manpages for details):
> * (require :sb-posix)
> ("SB-GROVEL" "SB-POSIX")
> * (let ((pid (sb-posix:fork)))
> (if (zerop pid)
> (save-lisp-and-die "foo.core")
> [doing purification: roots handlers stack bindings static cleanup done]
> [undoing binding stack and other enclosing state... done]
> [saving current Lisp image into /Users/demoss/Sources/sbcl/foo.core:
> writing 21034864 bytes from the read-only space at 0x01000000
> writing 6256504 bytes from the static space at 0x08000000
> writing 2144 bytes from the dynamic space at 0x40000000
> * (lisp-implementation-version)
>> Also, how can I load the image later into a sbcl session in
>> slime/emacs? sbcl --core mycore works but that's launching a raw sbcl
> You can't switch or load cores into a running SBCL. The core is in the
> SBCL: runtime contains code to start the core, the garbage collector and
> bits of OS support, almost everything else is in the core. Loading a
> core is a bit of misnomer anyways: starting a core is more accurate.
> If you need to just save session data write SEXPs to a file and read it
> back in. If you need a quick and dirty way of serializing things that is
> faster then PRINT/READ Google for fasldump and bindum. If you need to
> serialize large amounts of data write an appropriate specialized format
> ("everything is just a bucket of bits"). ...and then there all the
> persistense frameworks, DB interfaces, etc.
> Saving cores is mainly a delivery method, IMO.
> (This is not to say that it cannot be co-opted for other purposes, but
> that is beside the point.)
> -- Nikodemus Schemer: "Buddha is small, clean, and serious."
> Lispnik: "Buddha is big, has hairy armpits, and laughs."
> This SF.Net email is sponsored by the 'Do More With Dual!' webinar
> July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
> core and dual graphics technology at this free one hour event hosted by HP,
> AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
> Sbcl-help mailing list
thanks, that explains a lot.