Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
I've been making intermittent noises about supporting automagic
customization of target cores for some while.
Attached are bits of build machinery that would allow users to get eg. get
ASDF into their sbcl.core with minimum extra hassle.
I'm not too sure about this, so unless other people actually like this
andd say so I'm not going to go forward with this.
-- Nikodemus Schemer: "Buddha is small, clean, and serious."
Lispnik: "Buddha is big, has hairy armpits, and laughs."
From: William Harold Newman <william.newman@ai...> - 2005-07-05 20:45:24
On Tue, Jul 05, 2005 at 09:05:45PM +0300, Nikodemus Siivola wrote:
> I've been making intermittent noises about supporting automagic
> customization of target cores for some while.
> Attached are bits of build machinery that would allow users to get eg. get
> ASDF into their sbcl.core with minimum extra hassle.
> I'm not too sure about this, so unless other people actually like this
> andd say so I'm not going to go forward with this.
The basic idea of trying to help make it routine for people to make a
customized core seems reasonable. It is a pretty common wish, and it
seems feasible to choose one way to do it which works well for almost
everyone. However, I wonder whether it's a good idea to choose this
style of customized core creation/installation, where the customized
system is expected still to be named "sbcl".
I have used custom cores sometimes, but for reasonably stable
application code, not to add some extra libraries to my default REPL
environment. For such reasonably stable application code it is of
course natural to name the core something like "mywonderfulapp".core
instead of just "sbcl.core". It's a more complicated choice when
naming an almost-vanilla-CL REPL environment, but I'd guess that
there, too, the right thing is to use a different name than sbcl.core.
One argument in support of this is a question: how confident are we
that on any given computer system there will be one right way to
customize an almost-vanilla-CL REPL? E.g., I could imagine one for
statistical number crunching, and another for weird modelling with an
object system customized to play nicely with something like Screamer.
If so, they might want to be invoked as
It is probably pretty common for users to have only one interesting
way to customize the REPL on a given computer system, and I'm not
proposing that it should be made terribly difficult for such users to
shadow the un-customized "sbcl" with a customized "sbcl". But I'd
suggest not making it the only convenient choice, and my snap judgment
is that likely it shouldn't be the default choice, either.
William Harold Newman <william.newman@...>
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C
Communication would be much more reliable if people would turn off the
gainy decompression. -- Del Cotter