March 2007 - cl-debian@common-lisp.net - mailman3.common-lisp.net

[cl-debian] Bug#407606: cmucl fails at initialization
by "Faré" 24 Jun '08

24 Jun '08

Package: cmucl Version: 19d-20061116-1 Severity: normal *** Please type your report below this line *** Since I last upgraded cmucl, I get the following error and backtrace whenever I start it. $ cmucl Error in function UNIX::SIGSEGV-HANDLER: Segmentation Violation at #x10044FB8. [Condition of type SIMPLE-ERROR] Restarts: 0: [ABORT] Skip remaining initializations. Debug (type H for help) (UNIX::SIGSEGV-HANDLER #<unused-arg> #<unused-arg> #.(SYSTEM:INT-SAP #x3FFFCA7C)) Source: Error finding source: Error in function LISP::%ENUMERATE-SEARCH-LIST: Undefined search list: default 0] backtrace 0: (UNIX::SIGSEGV-HANDLER #<unused-arg> #<unused-arg> #.(SYSTEM:INT-SAP #x3FFFCA7C)) 1: (UNIX::SIGSEGV-HANDLER 3 #<unused-arg> #<unused-arg> #.(SYSTEM:INT-SAP #x3FFFCA7C))[:EXTERNAL] 2: ("call_into_lisp+#x8C [#x805560C] cmucl") 3: ("funcall3+#x32 [#x8055422] cmucl") 4: ("interrupt_handle_now+#x105 [#x8050940] cmucl") 5: (EQUAL #<Unprintable Instance {6C69663D}> #<ARRAY-TYPE SIMPLE-BASE-STRING>) 6: (EQUAL (#<Unprintable Instance {6C69663D}> . #<Unprintable Instance {682F3A65}>) (#<ARRAY-TYPE SIMPLE-BASE-STRING> #<MEMBER-TYPE NULL>)) 7: ((FLET #:G30 KERNEL::%TYPE-INTERSECTION-CACHE-LOOKUP)) 8: (KERNEL::%TYPE-INTERSECTION (#<ARRAY-TYPE SIMPLE-BASE-STRING> #<MEMBER-TYPE NULL>)) 9: (KERNEL::UNION-COMPLEX-SUBTYPEP-ARG2 #<ARRAY-TYPE SIMPLE-BASE-STRING> #<UNION-TYPE LIST>) 10: (KERNEL:CSUBTYPEP #<ARRAY-TYPE SIMPLE-BASE-STRING> #<UNION-TYPE LIST>) 11: (MAKE-SEQUENCE SIMPLE-STRING 11 :INITIAL-ELEMENT NIL) 12: (LISP::CONCAT-TO-SIMPLE* SIMPLE-STRING "/home/fare" "/") 13: (DEFAULT-DIRECTORY) 14: (LISP::ENVIRONMENT-INIT) 15: ((LABELS LISP::%RESTART-LISP SAVE-LISP)) 16: ((LABELS LISP::RESTART-LISP SAVE-LISP)) 0] (quit) $ Interestingly, if I run cmucl -noinit, I get no such error. However, I have no initialization file, as far as I can tell: neither of ~/init.lisp ~/.cmucl-init.lisp exists And strace fails on cmucl after the first memory-management-related segfault so I don't know what's going on. Also interestingly, if another user starts cmucl, it works. If same user starts with a different $HOME, it also fails. If another user with essentially the same config starts it, it works. It used to all work fine. Failure 100% reproducible in my current environment. I'm baffled. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] May your desire to be correct overcome your desire to have been correct (which you were not, anyway). -- Faré -- System Information: Debian Release: 4.0 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 en_US.iso-8859-1) Versions of packages cmucl depends on: ii common-lisp-controller 6.9 This is a Common Lisp source and c ii debconf [debconf-2.0] 1.5.11 Debian configuration management sy Versions of packages cmucl recommends: pn binfmt-support <none> (no description available) -- debconf information: cmucl/upgradeproblems:

5 13

[cl-debian] Bug#390967: common-lisp-controller: File permission errors for .fasl files
by Rob Aagaard 10 Jun '08

10 Jun '08

Package: common-lisp-controller Version: 6.3 Severity: normal Attempting to load any library through asdf fails. It appears to attempt to no longer redirect the generated .fasl files to someplace outside of the source directory. This means that any installed packages that have not been previously compiled as root fail to load. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16.12 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages common-lisp-controller depends on: ii bash 3.1-5 The GNU Bourne Again SHell ii cl-asdf 1.101-1 Another System Definition Facility ii debconf [debconf-2.0] 1.5.5 Debian configuration management sy ii debianutils 2.17.3 Miscellaneous utilities specific t ii perl 5.8.8-6.1 Larry Wall's Practical Extraction ii realpath 1.10 Return the canonicalized absolute common-lisp-controller recommends no packages. -- debconf information: * common-lisp-controller/short-site-name: zaphod * common-lisp-controller/long-site-name: zaphod.rawb.org

3 2

[cl-debian] Bug#414315: cl-sdl: FTBFS on GNU/kFreeBSD et al.
by Cyril Brulebois 15 Mar '08

15 Mar '08

Package: cl-sdl Severity: important Tags: patch Hi, currently your package FTBFS on GNU/kFreeBSD with the following error: > make clean > make[1]: Entering directory `/build/buildd/cl-sdl-0.2.2' > (sh select_platform.sh) > System not found > make[1]: *** [Makefile.opts] Error 1 Full build logs are available at <http://experimental.ftbfs.de/build.php?arch=kfreebsd-i386&pkg=cl-sdl>. The attached patch fixes this on GNU/kFreeBSD, and maybe on GNU/Hurd (although it is untested there). Cheers, -- Cyril Brulebois

2 2

[cl-debian] Bug#410683: gcl: [INTL:de] initial German debconf translation
by Stefan Bauer 23 Nov '07

23 Nov '07

Package: gcl Version: gcl 2.6.7-32 Severity: wishlist Tags: patch l10n Please find the initial German debconf translation for gcl attached. If there are some untranslated parts, please contact me so I can update the German translation. Greetings Stefan

2 1

[cl-debian] Re: stumpwm: Clarify README.Debian - can't understand a thing how to start this wm
by Jari Aalto 07 Oct '07

07 Oct '07

| > This is too technical. What is "boot up lisp"? How it's being done? | > What command to run, packages to install. Etc. | | I would say that it's not too technical at all. If you know what | Common Lisp is, you should be able to understand the upstream README. | Moreover, this package is not intended for common end-user, but for | users that have a specific background. | | > Please provide step by stem intruction how to start this window | > system, otherwise README.Debian doe snot reflect the needs of | > regular Debian user. | | As I said, it wasn't README.Debian, but the upstream README. In the | package version 1:20060513-1, I added a README.Debian to explain how | to use the SLIME swank together with StumpWM The debian/control::Description reads: Description: a Common Lisp window manager StumpWM is a window manager written entirely in Common Lisp. It attempts to be highly customizable while relying entirely on the keyboard for input. You will not find buttons, icons, title bars, tool bars, or any of the other conventional GUI widgets. >From "StumpWM is a window manager written entirely in Common Lisp" it suggests, that is is just another window manager only that the host language is common lisp. Something is not connecting here. - Aa per you explanation, the the sescription string should differentiate stumpwm from the other regular "window managers" by saing that this one is for only people that understand how to use it with common lisp. Without this, the "joe", like me, expects after download to read /ysr/share/doc/<package>/README.* files in order to see what steps are needed to make the <program> work unless it's setting itself up initially at install. | I'm not inclined to add specific information about how to start | StumpWM to the README.Debian, as the upstream README is quite | self-explanatory. I cc:ed this mail to the Common Lisp in Debian | mailing list [1], in order to have other comments/suggestions about | this bug. In case of no activity for 7 days, I'll tag this bug as | wont-fix. Currently - Description does not suggest anything to be different from standard WM - README* lacks information for anyone else but CL-knowledgeable. Please don't go away, before we can improve this :-) Jari

4 7

[cl-debian] Bug#382430: c-l-c installation of ecl does things wrong
by "Faré" 03 Oct '07

03 Oct '07

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

2 2

[cl-debian] Bug#394775: Sparc64 install fails: 'sbcl.sh install-clc' segfaults
by J.P. Larocque 17 Sep '07

17 Sep '07

Package: sbcl Version: 1:0.8.16-1 Severity: important I cannot install sbcl on a Sun Ultra 1. sbcl crashes during package configuration. The package isn't even marked as broken. --->8--->8--- Selecting previously deselected package common-lisp-controller. (Reading database ... 43010 files and directories currently installed.) Unpacking common-lisp-controller (from .../common-lisp-controller_4.15sarge3_all.deb) ... Setting up common-lisp-controller (4.15sarge3) ... Selecting previously deselected package sbcl. (Reading database ... 43034 files and directories currently installed.) Unpacking sbcl (from .../sbcl_1%3a0.8.16-1_sparc.deb) ... Setting up sbcl (0.8.16-1) ... /usr/lib/common-lisp/bin/sbcl.sh loading and dumping clc. /usr/lib/common-lisp/bin/sbcl.sh: line 58: 12442 Segmentation fault (core dumped) sbcl --core /usr/lib/sbcl/sbcl-dist.core --noinform --sysinit /etc/sbcl.rc --userinit /dev/null --load "/usr/lib/sbcl/install-clc.lisp" 2>/dev/null mv: cannot stat `sbcl-new.core': No such file or directory FAILED Reading Package Lists... Done Building Dependency Tree Reading extended state information Initializing package states... Done Reading task descriptions... Done ---8<---8<--- I read some old bug report leading me to believe that my locale could be a problem for SBCL. The above output is with LC_ALL=C and LANG=C on the environment. The stack trace produced below probably doesn't convey any meaningful information. --->8--->8--- $ sudo gdb sbcl /usr/lib/sbcl/core GNU gdb 6.3-debian Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-linux"...(no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". Core was generated by `sbcl --core /usr/lib/sbcl/sbcl-dist.core --noinform --sysinit /etc/sbcl.rc --us'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 #0 0x000189f8 in handle_control_stack_guard_triggered () (gdb) bt #0 0x000189f8 in handle_control_stack_guard_triggered () #1 0x0001da80 in os_install_interrupt_handlers () #2 0x0001da80 in os_install_interrupt_handlers () Previous frame identical to this frame (corrupt stack?) ---8<---8<--- Attempts to use sbcl: --->8--->8--- $ sbcl This is SBCL 0.8.16, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. Segmentation fault (core dumped) ---8<---8<--- --->8--->8--- $ gdb sbcl GNU gdb 6.3-debian Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-linux"...(no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run Starting program: /usr/bin/sbcl (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) This is SBCL 0.8.16, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. Program received signal SIGSEGV, Segmentation fault. 0x0001516c in alloc_base_string () (gdb) bt #0 0x0001516c in alloc_base_string () #1 0x0001abb8 in main () ---8<---8<--- Please let me know if I can be of any help. -- System Information: Debian Release: 3.1 Architecture: sparc (sparc64) Kernel: Linux 2.6.18 Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages sbcl depends on: ii common-lisp-controlle 4.15sarge3 This is a Common Lisp source and c ii libc6 2.3.2.ds1-22sarge4 GNU C Library: Shared libraries an -- no debconf information -- J.P. Larocque is <piranha(a)thoughtcrime.us> and <piranha(a)ely.ath.cx> Encrypted/signed e-mail preferred; http://ely.ath.cx/~piranha/pgp Fpr 5612 10A8 4986 2D85 A995 252B 4C02 5E02 F61D 2E61; ID 0xF61D2E61

5 6

[cl-debian] Bug#409827: Please support hurd-i386
by Chun Tian (binghe) 17 Sep '07

17 Sep '07

Package: clisp Version: 1:2.41-1 Severity: wishlist Tags: sid It seems that there isn't any Common Lisp platform in Debian GNU/Hurd now. Fortunately, CLISP can build directly on hurd-i386, just add hurd-i386 to clisp's control file is OK, I've tried this and succeed, this is totally done by the great autoconf and gcc, and the GNU/Hurd is much like UNIX through FSF say it's not UNIX. This CLISP on hurd-i386 can easily build something like asdf, common-lisp-controller, and araneida (cl-ppcre, cl-parenscript, ...) which already in debian's hurd-i386 port. A running CLISP can also be used to port SBCL to hurd-i386 (I'm trying working on this)... So, for Common Lisp, hopes more CL-platform can be run on GNU/Hurd! Thank you very much. Chun Tian (binghe)

2 1

[cl-debian] Bug#414682: cl-swank: trying to connect to new SBCL from Emacs throws a CL error
by Drake Wilson 16 Sep '07

16 Sep '07

Package: cl-swank Version: 1:20061201-2 Severity: important Trying to start SBCL using M-x slime-start from GNU Emacs fails with an error on the Common Lisp side. "important" because inferior-lisp is a big part of SLIME by my understanding. Here's the transcript from my *inferior-lisp* buffer: ---------------------------------------------------------------------- (load "/usr/share/common-lisp/source/slime/swank-loader.lisp" :verbose t) (swank:start-server "/tmp/slime.1772" :external-format :iso-latin-1-unix) This is SBCL 1.0, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. * ; loading #P"/usr/share/common-lisp/source/slime/swank-loader.lisp" ;; loading #P"/var/cache/common-lisp-controller/1000/sbcl/swank/fasl/sbcl-1.0-linux-x86-64/swank-backend.fasl" ;; loading #P"/var/cache/common-lisp-controller/1000/sbcl/swank/fasl/sbcl-1.0-linux-x86-64/nregex.fasl" ;; loading #P"/var/cache/common-lisp-controller/1000/sbcl/swank/fasl/sbcl-1.0-linux-x86-64/swank-sbcl.fasl" ;; loading #P"/var/cache/common-lisp-controller/1000/sbcl/swank/fasl/sbcl-1.0-linux-x86-64/swank-source-path-parser.fasl" ;; loading #P"/var/cache/common-lisp-controller/1000/sbcl/swank/fasl/sbcl-1.0-linux-x86-64/swank-source-file-cache.fasl" ;; loading #P"/var/cache/common-lisp-controller/1000/sbcl/swank/fasl/sbcl-1.0-linux-x86-64/swank-gray.fasl" STYLE-WARNING: implicitly creating new generic function STREAM-READ-CHAR-WILL-HANG-P ;; loading #P"/var/cache/common-lisp-controller/1000/sbcl/swank/fasl/sbcl-1.0-linux-x86-64/swank.fasl" STYLE-WARNING: implicitly creating new generic function INSPECT-BIGGER-PIECE-ACTIONS STYLE-WARNING: implicitly creating new generic function INSPECT-WHOLE-THING-ACTION STYLE-WARNING: implicitly creating new generic function INSPECT-SHOW-MORE-ACTION STYLE-WARNING: implicitly creating new generic function MENU-CHOICES-FOR-PRESENTATION WARNING: These Swank interfaces are unimplemented: (CALLS-WHO DISASSEMBLE-FRAME SLDB-BREAK-AT-START SLDB-BREAK-ON-RETURN WHO-BINDS WHO-CALLS WHO-MACROEXPANDS WHO-REFERENCES WHO-SETS WHO-SPECIALIZES) T * debugger invoked on a SB-INT:SIMPLE-PROGRAM-ERROR in thread #<THREAD "initial thread" {10025EFA81}>: unknown &KEY argument: :EXTERNAL-FORMAT Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level. (SWANK:START-SERVER "/tmp/slime.1772" :EXTERNAL-FORMAT :ISO-LATIN-1-UNIX) 0] ---------------------------------------------------------------------- Here's the installed versions of a few other packages, just in case: ii sbcl 1.0.0.0-1 A Common Lisp compiler and development system ii slime 20061201-2 Superior LISP Interaction Mode for Emacs ii emacs21 21.4a+1-5 The GNU Emacs editor ii emacs21-bin-common 21.4a+1-5 The GNU Emacs editor's shared, architecture ii emacs21-common 21.4a+1-5 The GNU Emacs editor's shared, architecture ii emacs21-el 21.4a+1-5 GNU Emacs LISP (.el) files ii emacsen-common 1.4.17 Common facilities for all emacsen Hope this helps. ---> Drake Wilson -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.20.1 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages cl-swank depends on: ii common-lisp-controller 6.9 This is a Common Lisp source and c cl-swank recommends no packages. -- no debconf information

4 5

[cl-debian] Bug#415266: gcl crashes with certain (incorrect) program
by Matej Kosik 04 Jul '07

04 Jul '07

Package: gcl Version: 2.6.7-32 Severity: important Hi, When I define a following function: (defun my-member (some-list sexp) (cond ((null some-list) nil) ((equal (first some-list) sexp) t) ((equal (rest some-list) sexp) t) (t (or (my-member (first some-list) sexp) (my-member (first some-list) sexp) ) ) ) ) the `gcl' interpreter accepts it (it is syntactically correct). However, when I later invoke it as follows: (my-member '(1) 'a) I see Error: Caught fatal error [memory may be damaged] Fast links are on: do (si::use-fast-links nil) for debugging Error signalled by EQUAL. Broken at EQUAL. Type :H for Help. when I try the same query again I see Segmentation fault My program contains an error but running it should not cause segfaults, I guess. Different interpreter (clisp) reports correct run-time error. Regards. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages gcl depends on: ii debconf [debconf-2.0] 1.5.11 Debian configuration management sy ii gcc 4:4.1.1-15 The GNU C compiler gcl recommends no packages. -- debconf-show failed

2 1