Steel Bank Common Lisp

John Morrison <jm@...> writes:

> Long Version: I am trying to create a saved core of a reasonably large
> system, buildable both under CMUCL and SBCL.  However, if I try to
> save an image containing the system (including XP-TEST, XMLS, McCLIM,
> and my own stuff), the SBCL one dies in the act of saving the core.
> CMUCL does not.

Heh, bad luck.  This is in fact three separate issues, which I think
have converged on you in an unfortunate way: the removal of
bit-bash-copy, which is notionally an internal function, affects
builders of clx releases using an unreleased version of sbcl, which by
now contains two separate fixes for the problem causing
save-lisp-and-die to die without saving.

There are several workarounds.  You can replace
sb-kernel:bit-bash-copy in clx with sb-kernel:ub1-bash-copy; you could
patch any of your sbcl rpms by altering (gensym "EVAL-TMP") to nil in
src/code/eval.lisp; or you could use one of your existing cores, load
the fasls that your previous compilation step has left lying around,
and save a core from that.  Or, you can wait until clx is likewise
patched and released.

Cheers,

Christophe

On Friday 08 April 2005 12:32 pm, Christophe Rhodes wrote:
> Heh, bad luck.  This is in fact three separate issues, which I think

and bad timing, apparently.

> have converged on you in an unfortunate way: the removal of
> bit-bash-copy, which is notionally an internal function, affects
> builders of clx releases using an unreleased version of sbcl, which by
> now contains two separate fixes for the problem causing
> save-lisp-and-die to die without saving.
>
> There are several workarounds.  You can replace
> sb-kernel:bit-bash-copy in clx with sb-kernel:ub1-bash-copy; you could

Are they identical in terms of args and return values, so this is
almost idiotproof (me being the idiot in question)?  

> patch any of your sbcl rpms by altering (gensym "EVAL-TMP") to nil in
> src/code/eval.lisp; or you could use one of your existing cores, load
> the fasls that your previous compilation step has left lying around,
> and save a core from that.  Or, you can wait until clx is likewise
> patched and released.

Given that I cannot wait, it seems that the best thing is to patch the
source to CLX (as in your first suggestion) in my .sbcl/site
directory, yes?

And if I do patch, is there anything I can do (no matter how trivial,
like sending the single-line patch) to help expedite the fix of CLX?
What would the correct (convention-wise) '#' directive be, as a
function of SBCL implementation and release/version number?

Thanks for the prompt, bulls-eye response.

-jm


> Christophe
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Sbcl-help mailing list
> Sbcl-help@...
> https://lists.sourceforge.net/lists/listinfo/sbcl-help

-- 
==== John Morrison
==== MAK Technologies Inc.
==== 10 Fawcett Street, Cambridge, MA 02138
==== http://www.mak.com/
==== vox:617-876-8085 x115
==== fax:617-876-9208
==== jm@...

On Fri, 2005-04-08 at 17:32 +0100, Christophe Rhodes wrote:
> Heh, bad luck.  This is in fact three separate issues, which I think
> have converged on you in an unfortunate way: the removal of
> bit-bash-copy, which is notionally an internal function, affects
> builders of clx releases using an unreleased version of sbcl, which by
> now contains two separate fixes for the problem causing
> save-lisp-and-die to die without saving.

This is a bit of a tangent, but would it make sense to add a public set
of bit-bashing functions to the SBCL library somewhere, parameterized to
deal with the machine word width. I ran into a need for some similar
functions a couple months ago but didn't know what other functions
existed and were stable enough to create a dependency on. In the end, I
just wrote up some of my own macros. Rather than duplicate the code,
however, I'd rather rely on some official routines/macros that are
optimized to produce good code with the SBCL compiler.

Is sb-kernel:ub1-bash-copy and the like what I'm looking for?

-- 
Dave Roberts <ldave@...>