Package: ecl Version: 0.9i-2 Severity: normal the c-l-c installation of ecl does a few wrong things: (1) it uses the c-l-c version of asdf and not the ecl-provided one from /usr/lib/ecl/asdf.fas as a result it fails to include the make-build extension from ECL sources ecl-0.9i/contrib/asdf/asdf-ecl.lisp Solution (a) would be to (require 'asdf) from the c-l-c compiled image and not compile it in the c-l-c binary for ecl. Solution (b) would be to include asdf-ecl.lisp in the ecl package, and recompile it together with c-l-c's asdf.lisp when installing c-l-c. (2) it somehow gets cmp.fas and sysfun.lsp to systematically load verbosely in a way that isn't hushed up by flag -q resulting in an unremovable banner ;;; Loading #P"/usr/lib/ecl/cmp.fas" ;;; Loading #P"/usr/lib/ecl/sysfun.lsp" which is quite annoying for programs that need produce controlled output. This is probably caused by the runtime loading of /etc/lispconfig.lisp by c-l-c. This banner should not be printed by quiet ecl scripts. Solution (2a) is to explicitly bind *load-verbose* to nil when loading /etc/lispconfig.lisp. Solution (2b) is to modify the c-l-c ecl startup to somehow hook the value of *load-verbose* on the -q flag. However, this requires modifying or overriding code from ecl-0.9i/src/lsp/cmdline.lsp and maintaining the result. Ouch. Solution (2c) is to hook into ecl's loading of a user resource file and replace it with the loading of a system resource file, say /etc/ecl/rc.lisp that in turn loads /etc/lispconfig.lisp then the user resource file. We would just prepend that path to *lisp-init-file-list* from install-clc.lisp, and writing the proper default code in /etc/ecl/rc.lisp Thus the usual parsing of -q and -norc applies to clc's ecl. (3) compiling configuration files everytime can be a performance issue, in addition to requiring to load the compiler. We could instead have a mechanism such as cl-launch's compile-and-load-file to only recompile when needed (SLIME's doesn't try hard enough for ECL), and put c-l-c cached .fas variants of the files in *lisp-init-file-list* before the source variants. Also, we want it to not require users to do anything special for the fasl to remain in synch with their lisp configuration. Any hackish code should come precompiled as part of install-clc.lisp so as to avoid requiring costly recompilation at runtime when things change. Solution (3a) would be to only do that for the system-wide file, and have that system-wide file include provisions for recompiling itself and then loading the compiled contents, and do the same for lispconfig.lisp and user files. A bit of a hack. Solution (3b) would be to modify or override cmdline.lsp to do the compile-and-load instead of load. Costly to maintain. (4) If we use a compile-and-load-file strategy for (3), then we might share code with cl-launch. This would mean having a dependency on cl-launch. It also means I should change cl-launch to install its file in /usr/share/common-lisp/source/cl-launch instead of /usr/share/common-lisp/cl-launch and produce a cl-launch.asd. I'll do that for cl-launch 1.85. In any cases, problems (1) and (2) both interact badly with cl-launch, and although cl-launch 1.84 now fully supports ECL, debian users need export ECL=/usr/lib/ecl/ecl-original so as to use cl-launch with ECL. I should probably include detection of that executable in cl-launch as a workaround to current breakage, since I already kluge a lot of my way to supporting ECL in cl-launch. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16.9-blefuscu Locale: LANG=en_US.iso-8859-1, LC_CTYPE=en_US.iso-8859-1 (charmap=ISO-8859-1) (ignored: LC_ALL set to e n_US.iso-8859-1) Versions of packages ecl depends on: ii common-lisp-controller 6.1 This is a Common Lisp source and c ii gcc-4.1 4.1.1-9 The GNU C compiler ii libc6 2.3.6-16 GNU C Library: Shared libraries ii libgc-dev 1:6.7-2 conservative garbage collector for ii libgc1c2 1:6.7-2 conservative garbage collector for ii libgmp3-dev 2:4.2.1+dfsg-3 Multiprecision arithmetic library ii libgmp3c2 2:4.2.1+dfsg-3 Multiprecision arithmetic library ii libncurses5-dev 5.5-2 Developer's libraries and docs for ecl recommends no packages. -- no debconf information