Matt,
Thanks for the very helpful information.
Given the recent changes (namely, migration away from common-lisp-controller), I've decided I should try to continue to upgrade to the most recent versions (e.g. cmucl 19d). I'm trying to follow the directions on the Gentoo Common Lisp User Guide, but I'm having a bit of trouble -- I was getting an error message that fasl's (e.g. for clx) were compiled for 19c. I tried manually deleting the offending fasl (OK, I realize this was stupid), but then cmucl tells me it doesn't know how to require clx, because it can't find the source. (I am now also using asdf-binary-locations and gentoo-init.)
I include the output below.
-Hans
====================
# lisp ; Loading #P"/home/hhalvors/.cmucl-init.lisp". ;; Loading #P"/etc/gentoo-init.lisp". ;;; Loading #P"/usr/share/common-lisp/source/asdf/asdf.lisp". ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. X): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. X): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. X): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. X): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. X): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. X): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. X): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. X): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. X): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. X): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. C S): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. C S): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. COMPONENT): ; Compiling Top-Level Form:
; In: LAMBDA (PCL::.PV-CELL. PCL::.NEXT-METHOD-CALL. C STREAM)
; (KERNEL:FLOAT-WAIT) ; Note: Deleting unreachable code. ; ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. C STREAM): ; Compiling Top-Level Form:
; Compilation unit finished. ; 1 note
; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. COMPONENT): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. COMPONENT): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. C PROPERTY): ; Compiling Top-Level Form: ; [GC threshold exceeded with 12,011,904 bytes in use. Commencing GC.] ; [GC completed with 4,077,968 bytes retained and 7,933,936 bytes freed.]
--- approximately 50 lines cut ---
; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OPERATION C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. PACKAGE NAME DOC-TYPE): ; Compiling Top-Level Form: ; loading system definition from ; /usr/share/common-lisp/systems/asdf-binary-locations.asd into ; #<The ASDF1655 package> ;;; Loading #P"/usr/share/common-lisp/source/asdf-binary-locations/asdf-binary-locations.asd". ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OP COMPONENT): ; Compiling Top-Level Form: ; [GC threshold exceeded with 22,701,096 bytes in use. Commencing GC.] ; [GC completed with 14,260,640 bytes retained and 8,440,456 bytes freed.] ; [GC will next occur when at least 26,260,640 bytes are in use.] ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OP COMPONENT): ; Compiling Top-Level Form: ; registering #<SYSTEM ASDF-BINARY-LOCATIONS {581BE745}> as ; ASDF-BINARY-LOCATIONS ;;; Loading #P"/usr/share/common-lisp/source/asdf-binary-locations/dev/main.lisp". ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. SYSTEM OPERATION COMPONENT SOURCE POSSIBLE-PATHS): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. SOURCE POSSIBLE-PATHS PATH-MAPPINGS): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OPERATION COMPONENT): ; Compiling Top-Level Form: CMU Common Lisp CVS Head 2006-11-12 07:33:49 (19D), running on phi-ghk3981 With core: /usr/lib/cmucl/lib/lisp.core Dumped on: Sun, 2006-11-12 07:40:42-05:00 on phi-ghk3981 See http://www.cons.org/cmucl/ for support information. Loaded subsystems: Python 1.1, target Intel x86 CLOS based on Gerd's PCL 2004/04/14 03:32:47 * (require :clx)
Error in function REQUIRE: Don't know how to load CLX [Condition of type SIMPLE-ERROR]
Restarts: 0: [ABORT] Return to Top-Level.
Debug (type H for help)
(REQUIRE :CLX NIL) Source: Error finding source: Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM: Source file no longer exists: target:code/module.lisp.
At Thu, 09 Nov 2006 21:02:22 -0600, Matthew Kennedy wrote:
Hans Halvorson hhalvors@Princeton.EDU writes:
I upgraded to cmucl-19d (unstable), and I was having trouble accessing the cmucl-clx libraries. (Are they not installed with 19d?) So, I
Hi Hans,
With dev-lisp/cmucl-19d_pre1, dev-lisp/sbcl-0.9.18 and dev-lisp/clisp-2.41 (all committed to CVS last night), we've stopped using the Common Lisp Controller. Before with CMUCL 19c and the Common Lisp Controller, the clx subsystem, and other CMUCL subsystems (clm, gray-streams, simple-streams, hemlock etc.) were installed with ASDF system definitions.
Now you need to do things the CMUCL way, the way the upstream developers intended:
$ lisp CMU Common Lisp CVS Head 2006-10-28 01:59:57 (19D), running on localhost With core: /usr/lib/cmucl/lib/lisp.core Dumped on: Sat, 2006-10-28 02:17:51-05:00 on localhost See http://www.cons.org/cmucl/ for support information. Loaded subsystems: Python 1.1, target Intel x86 CLOS based on Gerd's PCL 2004/04/14 03:32:47
- (require :clx)
; Loading #P"/usr/lib/cmucl/lib/subsystems/clx-library.x86f". ; [GC threshold exceeded with 12,011,280 bytes in use. Commencing GC.] ; [GC completed with 2,940,480 bytes retained and 9,070,800 bytes freed.] ; [GC will next occur when at least 14,940,480 bytes are in use.] ("CLX")
We have an upgrade guide here:
http://www.gentoo.org/proj/en/common-lisp/guide.xmlIt describes how to use the Common Lisp libraries in the absence of the Common Lisp Controller. It doesn't mention the change to loading CLX for CMUCL though. I'll add a section on that tonight and also link the guide from the project page:
http://www.gentoo.org/proj/en/common-lisp/index.xmldowngraded to 19c. But now when I try to start cmucl, I get:
"Strange ... dynamic space lossage Segmentation fault."
I'm not sure what would cause that problem, especially since your CMUCL 19c ran fine under the same configuration. Could you file a bug report? Make sure to include the output of emerge --info.
Best regards,
Matt
-- Matthew Kennedy Gentoo Linux Developer (Public Key 0x401903E0)