[mcclim-devel] Errors installing McClim

[Andy Hefner]

On Mon, Jul 12, 2010 at 3:46 PM, Peter Busser <busserpeter at gmail.com> wrote:
>> The advice on the wiki is a bit out of date.  These days, nine out of
>> ten lispers agree that neither asdf-install, common-lisp-controller,
>> nor Debian/Ubuntu-packaged lisp implementations should be used by
>> anyone, at any time, for any purpose.
>
> Why not go all the way and stop using Lisp altogether? There is no
> need for either asdf-install, common-lisp-controller or any packaged
> Lisp implementation if people stopped using those weird niche
> languages and started to use only C or Java software.

I know you are not being serious, but that isn't too far off from how
I'd advise people interested in writing applications for a large
audience. No one wants to use desktop software written in Java,
though. Whenever I've used software written in Java or Python on my
Debian systems, it has broken randomly and at the whim of the package
system. This isn't entirely fair, as Debian breaks C programs all the
time too, but in those cases the problems are usually more subtle
(I've never had an apt-get upgrade break libc).

> People shouldn't have to
> bother with stuf like CVS or Git, just to give a piece of software a
> try.

For the case of random users, I'd agree. For a UI toolkit, the target
users are developers themselves, a group likely already familiar with
how to use CVS and Git. I'd never considered it this way before, but
if the alternative is downloading a stable release tarball and
decompressing it, pulling the latest code from version control is
actually easier, assuming we provide the correct command to paste into
the terminal.

>> CLC, foisted upon unwitting victims by the Debian lisp packages,
>> may not be intrinsically broken, but few people use it, fewer
>> understand it, and it has earned a reputation for breaking things and
>> causing headaches while offering no real benefit to most users.
>
> Maybe you haven't looked into the common-lisp-controller enough to see
> what advantages it had.

It's true that I haven't. My interaction with it is mostly limited to
observing new lispers turn up on IRC with bizarre problems involving
it, which often are easily solved by jettisoning the Debian lisp
packages and reinstalling from source. For the sake of understanding
the issues I've been curious to take a clean Debian system, apt-get
install sbcl and slime, and then walk through whatever problems might
arise when trying to download and use code from 3rd parties, but for
an individual developer it's so easy to establish a development
environment by hand (or using clbuild) that it's difficult to justify
the effort.

> Try to install an application which uses
> McCLIM on 100 computers which can be used by a hundred or so different
> users. Then you find and fix a serious bug. Now try to update all
> installations...

This would be a great problem to have. I've never found myself in that
situation, and am still tickled when I can find a dozen people
interested in trying my latest lisp hack.

> Debian nor CLC are perfect (far from it in fact). But they still solve
> a number of problems faced by many people.

I guess I'm not one of those people. It isn't clear to me what
fraction of lisp developers might be, but I'll guess it's small, and
the burden of proof is on CLC advocates and the Debian lisp team to
convince the rest of us that it provides something worthwhile.

I feel package systems tend to tie my hands behind my back when it
comes to development, and seldom bother dealing with rebuilding
packages when I find it necessary to patch or debug an application (or
even library) written in C or C++, even though I likely installed it
through the package system initially. More hoops to jump through, for
minimal benefit. This doesn't invalidate the utility of the package
system for installing 99% of the software on my systems (or former
systems, since I've finally lost my faith and bought a Mac). I think
it's a reasonable claim that developers and users have different
needs.

> CLC allows system wide installation of libraries in source form,
> without preventing people from installing (and using) their own
> versions. The FASLs are compiled and per user ID. So CLC allows people
> to use common stuff while at the same time allowing people to use
> their own versions.

Pardon my ignorance.

> The biggest advantage of CLC is that it allows Lisp applications to be
> easily installed and tried. Nowadays people expect to be able to
> apt-get install any given application to just try it. If it doesn't
> work, then it is easy to remove. If it is too much hassle to install a
> Lisp application, then people will simply look for an alternative.
>
> Many Lispers feel that Lisp deserves to be more successful than it is.
> But in order to be successful, Lisp systems need to meet such user
> expectations. The Debian Lisp package maintainers do their best to
> accomplish that. The result isn't perfect. But then, what is?

I agree, this is a worthwhile goal. I've long suspected that if any CL
application ever gains widespread use (focussing on Linux for the
moment), it will be due to a distribution such Debian packaging it, as
few Linux users (if such a thing exists) will tolerate a binary
release or deal with the complexity of setting up the environment to
build a lisp application from source.

On the other hand, how many such applications (oriented to end-users,
not lisp developers) currently exist? Hopefully the list is longer
than Maxima (which, at first glance, doesn't appear to involve the
Debian CL infrastructure anyway). If I wrote such an application, I'd
be thrilled to see it made available through Debian using whatever
infrastructure is necessary (provided it produced a working result),
but I still wouldn't see any reason to use it for my own development.
Further, the last little explicitly end-user oriented lisp app I
wrote, the Shuffletron music player, produced an executable using just
ASDF and its own custom build process, and it isn't clear to me how
something like CLC would help there.

I'm not certain our respective definitions of "user" are compatible
anyway, in which case we're talking past each other. In my mind, no
"user" has any reason to run SLIME, and anyone using SLIME will sooner
or later find a reason to patch and recompile SBCL or SLIME itself, or
need to upgrade to the latest version for a bug fix, at which point
they've outgrown using the packaged versions (and arguably the sooner
this happens the better, if you care about the continued development
of SBCL and SLIME). Conversely I've always been satisfied running
versions of GCC provided by my distribution, but that reflects the
relative maturities of the C versus CL ecosystems.

> In theory the CLC will be integrated when the Lisp system is installed
> using apt-get install. The post-install script takes care of that. It
> will load CLC, and then write a Lisp image to the file system which is
> then loaded when the user starts the Lisp environment.

This is as I'd expect, but theory and practice seem to have diverged,
and there's plenty that can go wrong - somehow starting lisp with a
different core image than expected, for instance.

I notice that, despite coming to CLC's defense, you haven't provided a
solution to the original poster's problem. This is near the heart of
the matter - most lispers, myself included, don't know how to help
when issues involving CLC occur, and the only advice we can offer is
to eliminate CLC and try again. Most popular lisp software is quite
easy to compile once you understand the basics of ASDF and how things
are organized, so this advice is surprisingly effective.