On Mon, Jul 12, 2010 at 3:46 PM, Peter Busser busserpeter@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.