On Sat, Mar 12, 2005 at 12:48:02PM +0000, Christophe Rhodes wrote:
> Nikodemus Siivola <nikodemus@...> writes:
> > I propose the following policy: dump the debug-blocks (required for
> > this to work) if DEBUG is at least 1 and at least as important as
> > SPACE.
> > For comparison (ppc/darwin):
> > asdf.fasl sbcl.core
> > with debug-blocks 244423 24657920 bytes
> > without debug-blocks 225936 27103232 bytes
> > difference 18487 2445312 bytes
> > While significant, this is still IMO tolerable as the default policy.
> I think it's completely reasonable for sbcl itself to have this debug
> information around; after all, we laugh at people who distribute
> stripped binaries these days (at least I do). Whether this should
> happen as a matter of course on user code I'm slightly less sure
> about, but I'm willing to hear arguments either way. (I presume your
> sbcl.core numbers are the wrong way round).
I agree that it's worth it to pay 10% in system footprint in order to
keep debug information by default.
I don't feel passionately that the with-debug way is The Only Possible
Right Way for SBCL; I don't laugh at people who use stripped binaries,
as long as they have the sources available and the build process under
control so that they can switch to the with-debug version without
difficulty when they feel like it. (That seems to me rather like the
way that I usually work on projects where I control the code
completely. I tend to have a number of build options -- level of
verbosity, level of internal-self-check paranoia, level of
debuggability/introspection/dynamicism... -- and usually no one
default is correct all the time, so I just make sure it's easy to
rebuild.) But having SBCL's debugging stuff present by default does
seem like the dynamic introspective Lispy way, so it's appropriate in
principle and as what people can reasonably expect.
William Harold Newman <william.newman@...>
Ubi saeva indignatio ulterius cor lacerare nequit. -- Jonathan Swift's epitaph