Excellent, thanks very much Nikodemus. Those pointers should save me a
lot of time with this kind of stuff :)
On Tue, 2004-05-11 at 20:32, Nikodemus Siivola wrote:
> On Tue, 11 May 2004, Robert Marlow wrote:
> > Actually, a sort of unrelated question - what's an easy way to speed up
> > code testing for SBCL development? There's a lot of cross compilation
> > stuff in reader.lisp so it doesn't make it easy for me to just load up
> > the file and start messing with it interactively as lisp hackers are
> > wont to enjoy. Is there a trick you guys have to make SBCL source
> > hacking quicker than a hack->full-recompile->debug cycle?
> The ways I'm aware of:
> * Just load the code into a running system. May work as long as the code
> contains no def!foo, sb!foo or #! +stuff.
> * Load src/cold/chill.lisp -- this allows loading _some_ parts
> of the SBCL sources into a running image, including sending
> stuff from Slime with C-c C-c and friends. Though it seems that
> hacking on a chilled system is a good way to get Slime confused
> eventually, at least when tinkering with PCL.
> * Modify sources, cross your fingers and run "sh slam.sh <original build
> host>". Works for only some changes, though. After you get your
> stuff working you better do a full build still, since it's possible to
> slam some stuff that will break a full build -- mostly things that
> affect the cross-compilation.
> Requires having :sb-after-xc-core in features for the original
> build. This is the reason that I usually use CMUCL as a build host,
> since then I can safely install the freshly built SBCL without
> invalidating old after-xc-cores.
> * If you really want to live dangerously, see my slam-host hack in
> the archives (around last december, iirc): just like slam, but
> occasionally able to incorporate changes that normal slam can't.
> Can result in spectacular *CRASH* *BOOM* *BANG* sound effects,
> -- Nikodemus