[mcclim-devel] Errors installing McClim
Hello! I'm trying to follow the guide on http://mcclim.cliki.net/McCLIM%2BSBCL for installing McClim, but when I do (asdf-install:install :mcclim) I get an error, which I tried to accept and continue the install from, but the errors just keep coming after that so I thought I'd ask. The error I'm getting is: ; compilation aborted because of fatal error: ; SB-INT:SIMPLE-READER-PACKAGE-ERROR at 5151 (line 128, column 45) on #<SB-SYS:FD-STREAM ; for "file /usr/share/common-lisp/source/slime/swank-loader.lisp" ; {BF565E1}>: ; package "CLC" not found ; ; compilation aborted after 0:00:00.063 debugger invoked on a TYPE-ERROR in thread #<THREAD "initial thread" RUNNING {A9F5811}>: The value NIL is not of type (OR (VECTOR CHARACTER) (VECTOR NIL) BASE-STRING PATHNAME STREAM). I tried (asdf-install:install :clc) but there doesn't seem to be a package with that name. I know it stands for common-lisp-controller, and I have it apt-getted on my system (Ubuntu Lucid x86). Anybody know what the problem is? Regards, Oliver Uvman
Oliver Uvman <oliver.uvman@gmail.com> writes:
Hello!
I'm trying to follow the guide on http://mcclim.cliki.net/McCLIM%2BSBCL for installing McClim, but when I do (asdf-install:install :mcclim) I get an error, which I tried to accept and continue the install from, but the errors just keep coming after that so I thought I'd ask. The error I'm getting is:
; compilation aborted because of fatal error: ; SB-INT:SIMPLE-READER-PACKAGE-ERROR at 5151 (line 128, column 45) on #<SB-SYS:FD-STREAM ; for "file /usr/share/common-lisp/source/slime/swank-loader.lisp" ; {BF565E1}>: ; package "CLC" not found ; ; compilation aborted after 0:00:00.063
debugger invoked on a TYPE-ERROR in thread #<THREAD "initial thread" RUNNING {A9F5811}>: The value NIL is not of type (OR (VECTOR CHARACTER) (VECTOR NIL) BASE-STRING PATHNAME STREAM).
I tried (asdf-install:install :clc) but there doesn't seem to be a package with that name. I know it stands for common-lisp-controller, and I have it apt-getted on my system (Ubuntu Lucid x86). Anybody know what the problem is?
Actually, you need to uninstall CLC, or more specifically, uninstall Slime from apt-get and install it manually from CVS: apt-get --purge remove slime cl-swank (or dpkg --purge slime cl-swank) -- With Best Regards, Stas.
On Mon, Jul 12, 2010 at 1:38 AM, Oliver Uvman <oliver.uvman@gmail.com> wrote:
Hello!
I'm trying to follow the guide on http://mcclim.cliki.net/McCLIM%2BSBCL for installing McClim, but when I do (asdf-install:install :mcclim) I get an error, which I tried to accept and continue the install from, but the errors just keep coming after that so I thought I'd ask.
Short answer: Follow Stas's advice, and additionally check out the latest version of McCLIM from CVS rather than using asdf-install. Longer answer: 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. McCLIM itself should certainly be checked out from CVS (or a git mirror) rather than using asdf-install, because the last released version of McCLIM is quite old. 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.
The error I'm getting is: ... for "file /usr/share/common-lisp/source/slime/swank-loader.lisp" ; {BF565E1}>: ; package "CLC" not found ... I tried (asdf-install:install :clc) but there doesn't seem to be a package with that name. I know it stands for common-lisp-controller, and I have it apt-getted on my system (Ubuntu Lucid x86). Anybody know what the problem is?
Some background: Swank is the backend half of SLIME, written in CL and loaded into your lisp process, which emacs talks to over a socket. It contains several functions which are useful to McCLIM for doing things which can't be implemented portably, and as it's been ported to every CL of interest and virtually everyone can be expected to already have it on their machines, it makes a handy compatibility layer. CLC is a strange thing which, as I understand it, is used by the Debian CL packages for its ability to compile systems to FASLs and copy those to /usr where any user will be able to load them, so that each user isn't forced to compile everything themselves (and deal with the problem of not having write permission to /usr where the source code is installed). You can imagine how such an arrangement might not appeal to someone who wants the option of easily hacking on any and all components in their lisp environment, and as such most "upstream" hackers, so to speak, reject the CLC-based environment and install everything from source, rendering them unable to help when buggy interactions involving CLC crop up. :) The version of SLIME provided by your Linux distribution appears to have been modified with the expectation that CLC will always be loaded before attempting to load Swank. This must hold true for however they've arranged SLIME to work, but not for the (admittedly uncommon) case of CL software that wants to load Swank independently. Loading CLC manually before attempting to load McCLIM may well fix the issue, but I don't know how to do that.
Big thanks for the replies! I'll set about cleaning up my SBCL install and then attempting to install McClim from CVS now, but please notify me if it's a better idea to install SBCL from CVS, too. Regards, Oliver Uvman On Mon, Jul 12, 2010 at 06:23, Andy Hefner <ahefner@gmail.com> wrote:
On Mon, Jul 12, 2010 at 1:38 AM, Oliver Uvman <oliver.uvman@gmail.com> wrote:
Hello!
I'm trying to follow the guide on http://mcclim.cliki.net/McCLIM%2BSBCL for installing McClim, but when I do (asdf-install:install :mcclim) I get an error, which I tried to accept and continue the install from, but the errors just keep coming after that so I thought I'd ask.
Short answer: Follow Stas's advice, and additionally check out the latest version of McCLIM from CVS rather than using asdf-install.
Longer answer:
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. McCLIM itself should certainly be checked out from CVS (or a git mirror) rather than using asdf-install, because the last released version of McCLIM is quite old. 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.
The error I'm getting is: ... for "file /usr/share/common-lisp/source/slime/swank-loader.lisp" ; {BF565E1}>: ; package "CLC" not found ... I tried (asdf-install:install :clc) but there doesn't seem to be a package with that name. I know it stands for common-lisp-controller, and I have it apt-getted on my system (Ubuntu Lucid x86). Anybody know what the problem is?
Some background: Swank is the backend half of SLIME, written in CL and loaded into your lisp process, which emacs talks to over a socket. It contains several functions which are useful to McCLIM for doing things which can't be implemented portably, and as it's been ported to every CL of interest and virtually everyone can be expected to already have it on their machines, it makes a handy compatibility layer. CLC is a strange thing which, as I understand it, is used by the Debian CL packages for its ability to compile systems to FASLs and copy those to /usr where any user will be able to load them, so that each user isn't forced to compile everything themselves (and deal with the problem of not having write permission to /usr where the source code is installed). You can imagine how such an arrangement might not appeal to someone who wants the option of easily hacking on any and all components in their lisp environment, and as such most "upstream" hackers, so to speak, reject the CLC-based environment and install everything from source, rendering them unable to help when buggy interactions involving CLC crop up. :)
The version of SLIME provided by your Linux distribution appears to have been modified with the expectation that CLC will always be loaded before attempting to load Swank. This must hold true for however they've arranged SLIME to work, but not for the (admittedly uncommon) case of CL software that wants to load Swank independently. Loading CLC manually before attempting to load McCLIM may well fix the issue, but I don't know how to do that.
Hey again! Just wanted to report in and say I got it working! Compared to the many days I've spent trying to get various clbuild, asdf, clc and other systems to do it for me, this was easy as pie. Is it ok if I go in and edit the clwiki to reflect that this (and not asdf) is the easiest way to install it? Right now the wiki is probably going to lead many people like myself to think that asdf is the way to go, while it doesn't seem to work at all. /Oliver On Mon, Jul 12, 2010 at 13:21, Oliver Uvman <oliver.uvman@gmail.com> wrote:
Big thanks for the replies! I'll set about cleaning up my SBCL install and then attempting to install McClim from CVS now, but please notify me if it's a better idea to install SBCL from CVS, too.
Regards, Oliver Uvman
On Mon, Jul 12, 2010 at 06:23, Andy Hefner <ahefner@gmail.com> wrote:
On Mon, Jul 12, 2010 at 1:38 AM, Oliver Uvman <oliver.uvman@gmail.com> wrote:
Hello!
I'm trying to follow the guide on http://mcclim.cliki.net/McCLIM%2BSBCL for installing McClim, but when I do (asdf-install:install :mcclim) I get an error, which I tried to accept and continue the install from, but the errors just keep coming after that so I thought I'd ask.
Short answer: Follow Stas's advice, and additionally check out the latest version of McCLIM from CVS rather than using asdf-install.
Longer answer:
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. McCLIM itself should certainly be checked out from CVS (or a git mirror) rather than using asdf-install, because the last released version of McCLIM is quite old. 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.
The error I'm getting is: ... for "file /usr/share/common-lisp/source/slime/swank-loader.lisp" ; {BF565E1}>: ; package "CLC" not found ... I tried (asdf-install:install :clc) but there doesn't seem to be a package with that name. I know it stands for common-lisp-controller, and I have it apt-getted on my system (Ubuntu Lucid x86). Anybody know what the problem is?
Some background: Swank is the backend half of SLIME, written in CL and loaded into your lisp process, which emacs talks to over a socket. It contains several functions which are useful to McCLIM for doing things which can't be implemented portably, and as it's been ported to every CL of interest and virtually everyone can be expected to already have it on their machines, it makes a handy compatibility layer. CLC is a strange thing which, as I understand it, is used by the Debian CL packages for its ability to compile systems to FASLs and copy those to /usr where any user will be able to load them, so that each user isn't forced to compile everything themselves (and deal with the problem of not having write permission to /usr where the source code is installed). You can imagine how such an arrangement might not appeal to someone who wants the option of easily hacking on any and all components in their lisp environment, and as such most "upstream" hackers, so to speak, reject the CLC-based environment and install everything from source, rendering them unable to help when buggy interactions involving CLC crop up. :)
The version of SLIME provided by your Linux distribution appears to have been modified with the expectation that CLC will always be loaded before attempting to load Swank. This must hold true for however they've arranged SLIME to work, but not for the (admittedly uncommon) case of CL software that wants to load Swank independently. Loading CLC manually before attempting to load McCLIM may well fix the issue, but I don't know how to do that.
On Mon, Jul 12, 2010 at 1:36 PM, Oliver Uvman <oliver.uvman@gmail.com> wrote:
Hey again!
Just wanted to report in and say I got it working! Compared to the many days I've spent trying to get various clbuild, asdf, clc and other systems to do it for me, this was easy as pie.
Glad to hear that.
Is it ok if I go in and edit the clwiki to reflect that this (and not asdf) is the easiest way to install it?
Sure, that would be great.
Hi!
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.
McCLIM itself should certainly be checked out from CVS (or a git mirror) rather than using asdf-install, because the last released version of McCLIM is quite old.
How come noone created a newer release? People shouldn't have to bother with stuf like CVS or Git, just to give a piece of software a try.
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. 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... Debian nor CLC are perfect (far from it in fact). But they still solve a number of problems faced by many people.
Some background: Swank is the backend half of SLIME, written in CL and loaded into your lisp process, which emacs talks to over a socket. It contains several functions which are useful to McCLIM for doing things which can't be implemented portably, and as it's been ported to every CL of interest and virtually everyone can be expected to already have it on their machines, it makes a handy compatibility layer.
CLC is a strange thing which, as I understand it, is used by the Debian CL packages for its ability to compile systems to FASLs and copy those to /usr where any user will be able to load them, so that each user isn't forced to compile everything themselves (and deal with the problem of not having write permission to /usr where the source code is installed). You can imagine how such an arrangement might not appeal to someone who wants the option of easily hacking on any and all components in their lisp environment, and as such most "upstream" hackers, so to speak, reject the CLC-based environment and install everything from source, rendering them unable to help when buggy interactions involving CLC crop up. :)
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. 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?
The version of SLIME provided by your Linux distribution appears to have been modified with the expectation that CLC will always be loaded before attempting to load Swank. This must hold true for however they've arranged SLIME to work, but not for the (admittedly uncommon) case of CL software that wants to load Swank independently. Loading CLC manually before attempting to load McCLIM may well fix the issue, but I don't know how to do that.
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. Groetjes, Peter.
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.
Andy Hefner <ahefner@gmail.com> writes:
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.
Ummm, common-lisp-controller is the reason that I was able to build my mcclim packages for Fedora. It works _really_ well. It easily enables Lisp source to be installed by root, with FASLs cached neatly, and allows multiple Common Lisp implementations to share the same source. It's great. -- Robert A. Uhl
So in summay clc works really well when it works, but when it doesn't it is very difficult to ascertain where the fault lies. Is it still actively developed, and if so do the developers know that this is people's opinion about their system? They can't do anything about it if we don't inform them. /Oliver On Mon, Jul 12, 2010 at 23:29, Robert Uhl <eadmund42@gmail.com> wrote:
Andy Hefner <ahefner@gmail.com> writes:
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.
Ummm, common-lisp-controller is the reason that I was able to build my mcclim packages for Fedora. It works _really_ well.
It easily enables Lisp source to be installed by root, with FASLs cached neatly, and allows multiple Common Lisp implementations to share the same source.
It's great.
-- Robert A. Uhl
Oliver, Well, my experience with creating lots of Common Lisp .deb packages on Debian shows that problems in most cases are caused by incorrect placement of the .asd file(s) followed by missing .lisp files or other missing stuff. Sometimes the .asd file tries to be smart by doing things that it shouldn't do (like i.e. compile C source code). The most time consuming part for me is to find the right version of libraries. Especially for larger programs with lots of dependencies like Closure, the McCLIM based web browser. Somehow I never got it to do anything useful. I think that once people seriously try to understand what kind of problems the Debian (and other packagers) try to solve, that they will understand that it is only logical to choose something like CLC. I can only hope that such an understanding leads to more constructive ideas than just dismissing it by saying that it is evil. Groetjes, Peter. 2010/7/12 Oliver Uvman <oliver.uvman@gmail.com>:
So in summay clc works really well when it works, but when it doesn't it is very difficult to ascertain where the fault lies. Is it still actively developed, and if so do the developers know that this is people's opinion about their system? They can't do anything about it if we don't inform them.
/Oliver
On Mon, Jul 12, 2010 at 23:29, Robert Uhl <eadmund42@gmail.com> wrote:
Andy Hefner <ahefner@gmail.com> writes:
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.
Ummm, common-lisp-controller is the reason that I was able to build my mcclim packages for Fedora. It works _really_ well.
It easily enables Lisp source to be installed by root, with FASLs cached neatly, and allows multiple Common Lisp implementations to share the same source.
It's great.
-- Robert A. Uhl
_______________________________________________ mcclim-devel mailing list mcclim-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
On 7/12/10 Jul 12 -4:39 PM, Peter Busser wrote:
Oliver,
Well, my experience with creating lots of Common Lisp .deb packages on Debian shows that problems in most cases are caused by incorrect placement of the .asd file(s) followed by missing .lisp files or other missing stuff. Sometimes the .asd file tries to be smart by doing things that it shouldn't do (like i.e. compile C source code). The most time consuming part for me is to find the right version of libraries. Especially for larger programs with lots of dependencies like Closure, the McCLIM based web browser. Somehow I never got it to do anything useful.
Well, for the record, compiling C source code is a perfectly legitimate thing for an ASDF system definition to do (at least when not in the context of a .deb). ASDF system definitions /can/ specify version requirements, but it seems that this fact is not well known among ASDF users, and this feature is not extensively used. If library authors would tag their systems with x.y.z version info that complied with ASDF::VERSION-SATISFIES and would put in :version dependencies, then I bet you would find your life a lot easier. I know mine would be, and I don't try to make .debs!
I think that once people seriously try to understand what kind of problems the Debian (and other packagers) try to solve, that they will understand that it is only logical to choose something like CLC. I can only hope that such an understanding leads to more constructive ideas than just dismissing it by saying that it is evil.
Maybe it's not evil, but it seems like there are two challenges: 1. There is a not well understood subset of valid .asd files that is compatible with CLC. 2. Installing CLC has an effect on the host lisp that is not well understood by people who don't use it; unfortunately those people are the ones who must supply help to CLC users who encounter problems with their libraries. Best, r
Am 13.07.2010 um 00:06 schrieb Robert Goldman:
On 7/12/10 Jul 12 -4:39 PM, Peter Busser wrote:
Oliver,
Well, my experience with creating lots of Common Lisp .deb packages on Debian shows that problems in most cases are caused by incorrect placement of the .asd file(s) followed by missing .lisp files or other missing stuff. Sometimes the .asd file tries to be smart by doing things that it shouldn't do (like i.e. compile C source code). The most time consuming part for me is to find the right version of libraries. Especially for larger programs with lots of dependencies like Closure, the McCLIM based web browser. Somehow I never got it to do anything useful.
Well, for the record, compiling C source code is a perfectly legitimate thing for an ASDF system definition to do (at least when not in the context of a .deb).
I would disagree. Side effecting .asd files are evil and make other peoples lives very hard. (See e.g. http://www.mail-archive.com/asdf-devel@common-lisp.net/msg00949.html) The problem boils down to the fact, that with side effecting asd files you cannot safely determine a system's dependencies without loading the system. Best regards, Niko
On 7/13/10 Jul 13 -6:53 AM, Nikolaus Demmel wrote:
Am 13.07.2010 um 00:06 schrieb Robert Goldman:
On 7/12/10 Jul 12 -4:39 PM, Peter Busser wrote:
Oliver,
Well, my experience with creating lots of Common Lisp .deb packages on Debian shows that problems in most cases are caused by incorrect placement of the .asd file(s) followed by missing .lisp files or other missing stuff. Sometimes the .asd file tries to be smart by doing things that it shouldn't do (like i.e. compile C source code). The most time consuming part for me is to find the right version of libraries. Especially for larger programs with lots of dependencies like Closure, the McCLIM based web browser. Somehow I never got it to do anything useful.
Well, for the record, compiling C source code is a perfectly legitimate thing for an ASDF system definition to do (at least when not in the context of a .deb).
I would disagree. Side effecting .asd files are evil and make other peoples lives very hard. (See e.g. http://www.mail-archive.com/asdf-devel@common-lisp.net/msg00949.html)
I think we are talking at cross-purposes. It is quite possible to have an .asd file that contains a system with a C source file as one of its components. Loading that system would cause the C file to be compiled but is not at all a /side/ effect --- it is an intended effect of loading the system, of which the C file is a part.
The problem boils down to the fact, that with side effecting asd files you cannot safely determine a system's dependencies without loading the system.
As I said, I think we are talking at cross-purposes here and are not truly in disagreement: I am not talking about compiling a C file as a side effect of loading the .asd file (which I agree would be wrong), but as a main effect of loading the /system/ defined in the .asd file. The latter is NOT a side-effect and is explicitly supported by ASDF. BTW, side-effects in .asd files are NOT necessarily evil and may be /essential/. E.g., it is possible that an .asd file relies on another ASDF system simply in order that it can be processed. E.g., if my ASDF system foo relies on an ASDF extension (say an ASDF system that defines a new ASDF component subtype/subclass), then it /must/ do this by side-effecting. This may be somewhat evil, but there is no alternative means of achieving it in ASDF. This has been discussed before, and it might well be good to make .asd's fully declarative, but they are not now. Best, r
Best regards, Niko _______________________________________________ mcclim-devel mailing list mcclim-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
Am 13.07.2010 um 14:21 schrieb Robert Goldman:
On 7/13/10 Jul 13 -6:53 AM, Nikolaus Demmel wrote:
Am 13.07.2010 um 00:06 schrieb Robert Goldman:
On 7/12/10 Jul 12 -4:39 PM, Peter Busser wrote:
Oliver,
Well, my experience with creating lots of Common Lisp .deb packages on Debian shows that problems in most cases are caused by incorrect placement of the .asd file(s) followed by missing .lisp files or other missing stuff. Sometimes the .asd file tries to be smart by doing things that it shouldn't do (like i.e. compile C source code). The most time consuming part for me is to find the right version of libraries. Especially for larger programs with lots of dependencies like Closure, the McCLIM based web browser. Somehow I never got it to do anything useful.
Well, for the record, compiling C source code is a perfectly legitimate thing for an ASDF system definition to do (at least when not in the context of a .deb).
I would disagree. Side effecting .asd files are evil and make other peoples lives very hard. (See e.g. http://www.mail-archive.com/asdf-devel@common-lisp.net/msg00949.html)
I think we are talking at cross-purposes.
It is quite possible to have an .asd file that contains a system with a C source file as one of its components. Loading that system would cause the C file to be compiled but is not at all a /side/ effect --- it is an intended effect of loading the system, of which the C file is a part.
The problem boils down to the fact, that with side effecting asd files you cannot safely determine a system's dependencies without loading the system.
As I said, I think we are talking at cross-purposes here and are not truly in disagreement: I am not talking about compiling a C file as a side effect of loading the .asd file (which I agree would be wrong), but as a main effect of loading the /system/ defined in the .asd file. The latter is NOT a side-effect and is explicitly supported by ASDF.
BTW, side-effects in .asd files are NOT necessarily evil and may be /essential/. E.g., it is possible that an .asd file relies on another ASDF system simply in order that it can be processed.
E.g., if my ASDF system foo relies on an ASDF extension (say an ASDF system that defines a new ASDF component subtype/subclass), then it /must/ do this by side-effecting.
This may be somewhat evil, but there is no alternative means of achieving it in ASDF.
This has been discussed before, and it might well be good to make .asd's fully declarative, but they are not now.
I agree with you. I did understand you wrongly and as you said we were talking at cross-purposes. Sorry. Best regards, Niko
Robert Goldman <rpgoldman@sift.info> writes:
Well, for the record, compiling C source code is a perfectly legitimate thing for an ASDF system definition to do (at least when not in the context of a .deb).
I would disagree. Side effecting .asd files are evil and make other peoples lives very hard. (See e.g. http://www.mail-archive.com/asdf-devel@common-lisp.net/msg00949.html)
I think we are talking at cross-purposes.
It is quite possible to have an .asd file that contains a system with a C source file as one of its components. Loading that system would cause the C file to be compiled but is not at all a /side/ effect --- it is an intended effect of loading the system, of which the C file is a part.
IMHO, the right thing is for the C file to be compiled _when the ASDF system is installed_; that object code would then be loaded when the system is loaded. -- Robert A. Uhl
participants (7)
-
Andy Hefner -
Nikolaus Demmel -
Oliver Uvman -
Peter Busser -
Robert Goldman -
Robert Uhl -
Stas Boukarev