gmane.lisp.openmcl.devel

value * is not of the expected type LIST

Cyrus Harmon — 2008-12-01T22:59:17

and here's another CCL issue that happens on both x86 and x8664 on Darwin. The problem seems to have something to do with declarations of the form: (declare (type (simple-array ,element-type *) ,vals)) changing the * to (*) seems to fix the problem, but it would seem that * should work here as well, declaring that this is a simple-array, not that it is a simple array of one dimension of unknown size. thanks again, cyrus value * is not of the expected type LIST. [Condition of type TYPE-ERROR] Restarts: 0: [RETRY-COMPILE-FILE] Retry compiling #P"/Users/sly/projects/ git.cyrusharmon.org/clem/src/matrix.lisp" 1: [SKIP-COMPILE-FILE] Skip compiling #P"/Users/sly/projects/ git.cyrusharmon.org/clem/src/matrix.lisp" 2: [TRY-RECOMPILING] Try recompiling matrix 3: [RETRY] Retry performing # on #. 4: [ACCEPT] Continue, treating # on # as having been successful. 5: [RETRY] Retry SLIME REPL evaluation request. 6: [ABORT] Return to SLIME's top level. 7: [ABORT-BREAK] Reset this thread 8: [ABORT] Kill this thread Backtrace: 0: ((:INTERNAL CCL::%XERR-DISP)) 1: (CCL::FUNCALL-WITH-ERROR-REENTRY-DETECTION #) 2: (CCL::%XERR-DISP 369755270) 3: (CCL::%PASCAL-FUNCTIONS% 2 369755270) 4: (CCL::X862-GENERAL-ASET2 # NIL NIL (27 (SIMPLE-ARRAY DOUBLE-FLOAT) (24614 #)) (27 (MOD 1152921504606846975) ..)) 5: (CCL::X862-FORM :DOUBLE-FLOAT-VECTOR NIL NIL (9315 (27 (SIMPLE- ARRAY DOUBLE-FLOAT) (24614 #)) (27 (MOD 1152921504606846975) (24614 #)) ..))) 6: (CCL::X862-LOCAL-TAGBODY # NIL NIL (#3=(#:G866 14 #1=#(1 0 80 #) . T) #2=(#:G867 15 #1#)) ((43 #2#) (30 . #3#) ..)))) 7: (CCL::X862-PROGN # NIL NIL ((#:|nil|))) 8: (CCL::X862-UNDO-BODY # NIL NIL (22529 ((8223 (# #) (# # # # # #)) (#:|nil|))) #(1 0 80 #)) 9: (CCL::X862-LET* # NIL NIL (# #) ((27 FIXNUM (24614 #)) (24617 0)) (22529 ..)))) 10: (CCL::X862-FORM # NIL NIL (29 (# #) ((27 FIXNUM (24614 #)) (24617 0)) (22529 ((8223 # #) (#:|nil|))) 2162688)) 11: (CCL::X862-LOCAL-TAGBODY # NIL NIL (#3=(#:G863 12 #1=#(1 0 80 #) . T) #2=(#:G864 13 #1#)) ((43 #2#) (30 . #3#) ..))))) 12: (CCL::X862-PROGN # NIL NIL ((#:|nil|))) 13: (CCL::X862-UNDO-BODY # NIL NIL (22529 ((8223 (# #) (# # # # # #)) (#:|nil|))) #(1 0 80 #)) 14: (CCL::X862-LET* # NIL NIL (# #) ((27 FIXNUM (24614 #)) (24617 0)) (22529 ..)))) 15: (CCL::X862-FORM # NIL NIL (29 (# #) ((27 FIXNUM (24614 #)) (24617 0)) (22529 ((8223 # #) (#:|nil|))) 2162688)) 16: (CCL::X862-UNDO-BODY # NIL NIL (29 (# #) ((27 FIXNUM (24614 #)) (24617 0)) (22529 ((8223 # #) (#:|nil|))) 2162688) #(1 ..)) 17: (CCL::X862-LET* # NIL NIL (#) ((27 (SIMPLE-ARRAY DOUBLE-FLOAT) (42 (24616 CLEM::MATRIX-VALS) (NIL #) NIL))) (29 ..))) 18: (CCL::X862-FORM # NIL NIL (29 (#) ((27 (SIMPLE-ARRAY DOUBLE-FLOAT) (42 # # NIL))) ..)))) 19: (CCL::X862-UNDO-BODY # NIL NIL (29 (#) ((27 (SIMPLE-ARRAY DOUBLE-FLOAT) (42 # # NIL))) ..)))) 20: (CCL::X862-LET* # NIL NIL (#) ((27 (SIMPLE-ARRAY DOUBLE-FLOAT) (42 (24616 CLEM::MATRIX-VALS) (NIL #) NIL))) (29 ..))))) 21: (CCL::X862-FORM # NIL NIL (29 (#) ((27 (SIMPLE-ARRAY DOUBLE-FLOAT) (42 # # NIL))) ..))))) 22: (CCL::X862-PROGN # # 262143 ((24614 #))) 23: (CCL::X862-UNDO-BODY # # 262143 (22529 ((29 (#) (#) (29 # # # 2162688) 2162688) (24614 #))) #(1 0 64 #)) 24: (CCL::X862-LET* # # 262143 (#) ((29 (#) ((24616 #)) (42 (25678 # #) (# #) NIL) 2162688)) (22529 ..)))) 25: (CCL::X862-FORM # # 262143 (29 (#1=#) ((29 (#) (#) (42 # # NIL) 2162688)) (22529 ((29 # # # 2162688) (24614 #1#))) 2162688)) 26: (CCL::X862-UNDO-BODY # # 262143 (29 (#1=#) ((29 (#) (#) (42 # # NIL) 2162688)) (22529 ((29 # # # 2162688) (24614 #1#))) ..)) 27: (CCL::X862-LET* # # 262143 (# # # #) ((42 (24616 CLEM:DIM) (NIL (#)) NIL) ..))))) 28: (CCL::X862-FORM # # 262143 (29 (# # # #) ..))))) 29: (CCL::X862-UNDO-BODY # # 262143 (29 (# # # #) ..))))) 30: (CCL::X862-SEQ-FBIND # # 262143 NIL NIL (29 (# # # #) ..)))) 31: (CCL::X862-LAMBDA # # 262143 (#) NIL NIL NIL (NIL NIL) (117 NIL NIL ..))))) 32: (CCL::X862-COMPILE # NIL T) 33: (CCL::COMPILE-NAMED-FUNCTION (LAMBDA (CCL::&METHOD #:NEXT-METHOD- CONTEXT CLEM::M) ..) 34: (CCL::FCOMP-NAMED-FUNCTION (LAMBDA (CCL::&METHOD #:NEXT-METHOD- CONTEXT CLEM::M) ..) 35: (CCL::FCOMP-RANDOM-TOPLEVEL-FORM (CCL::ENSURE-METHOD ..)) 36: (CCL::FCOMP-FORM (CCL::ENSURE-METHOD ..) 37: (CCL::FCOMP-FORM-LIST ((CCL::ENSURE-METHOD ..)) 38: (CCL::FCOMP-COMPILER-LET (COMPILER-LET ((CCL::*NX-METHOD-WARNING- NAME* '(CLEM:TRANSPOSE #))) ..) 39: (CCL::FCOMP-FORM (COMPILER-LET ((CCL::*NX-METHOD-WARNING-NAME* '(CLEM:TRANSPOSE #))) ..) 40: (CCL::FCOMP-FORM-LIST ((EVAL-WHEN (:COMPILE-TOPLEVEL) ..))) 41: (CCL::FCOMP-FORM (PROGN (EVAL-WHEN (:COMPILE-TOPLEVEL) ..)) 42: (CCL::FCOMP-FORM (DEFMETHOD CLEM:TRANSPOSE ((CLEM::M CLEM:DOUBLE- FLOAT-MATRIX)) ..) 43: (CCL::FCOMP-READ-LOOP "/Users/sly/projects/git.cyrusharmon.org/ clem/src/matrix.lisp" #P"home:projects;git.cyrusharmon.org;clem;src;matrix.lisp.newest" 0 # :NOT.. 44: (CCL::FCOMP-FILE "/Users/sly/projects/git.cyrusharmon.org/clem/ src/matrix.lisp" #P"home:projects;git.cyrusharmon.org;clem;src;matrix.lisp.newest" 0 #) 45: (CCL::%COMPILE-FILE "/Users/sly/projects/git.cyrusharmon.org/ clem/src/matrix.lisp" "/Users/sly/projects/git.cyrusharmon.org/clem/ src/ccl-1.3-darwin-x86-64/matrix.dx64fsl" NIL NIL NIL NIL T T NIL :NO- T.. 46: (COMPILE-FILE #P"/Users/sly/projects/git.cyrusharmon.org/clem/ src/matrix.lisp" :OUTPUT-FILE #P"/Users/sly/projects/ git.cyrusharmon.org/clem/src/ccl-1.3-darwin-x86-64/ matrix.dx64fsl" :VERBOSE NIL :PRIN.. 47: (# # #) 48: (# # #) 49: (CCL::%CALL-NEXT-METHOD (NIL # # #)) 50: (# # #) 51: (CCL::%%CALL-METHOD* # (#) (# ..)) 52: (# # #) 53: ((:INTERNAL CCL::WITH-COMPILATION-UNIT-BODY ASDF:OPERATE)) 54: (CCL::CALL-WITH-COMPILATION-UNIT # :OVERRIDE NIL) 55: (ASDF:OPERATE ASDF:LOAD-OP #:CLEM) 56: (CCL::CALL-CHECK-REGS ASDF:OOS ASDF:LOAD-OP #:CLEM) 57: (SWANK::EVAL-REGION "(asdf:oos 'asdf:load-op '#:clem)\n") 58: ((:INTERNAL SWANK::REPL-EVAL)) 59: (SWANK::TRACK-PACKAGE #) 60: (SWANK::CALL-WITH-RETRY-RESTART "Retry SLIME REPL evaluation request." #) 61: (SWANK::CALL-WITH-BUFFER-SYNTAX NIL #) 62: (SWANK::REPL-EVAL "(asdf:oos 'asdf:load-op '#:clem)\n") 63: (CCL::CALL-CHECK-REGS SWANK:LISTENER-EVAL "(asdf:oos 'asdf:load- op '#:clem)\n") 64: (SWANK::EVAL-FOR-EMACS (SWANK:LISTENER-EVAL "(asdf:oos 'asdf:load-op '#:clem)\n") "COMMON-LISP-USER" 10) 65: (SWANK::PROCESS-REQUESTS NIL) 66: ((:INTERNAL SWANK::HANDLE-REQUESTS)) 67: (# # #) 68: (SWANK::CALL-WITH-REDIRECTED-IO # #) 69: (SWANK::CALL-WITH-CONNECTION # #) 70: (SWANK::HANDLE-REQUESTS # NIL) 71: (SWANK::CALL-WITH-BINDINGS NIL #) 72: (CCL::RUN-PROCESS-INITIAL-FORM # (#)) 73: ((:INTERNAL CCL::%PROCESS-PRESET-INTERNAL) # (#)) 74: ((:INTERNAL CCL::THREAD-MAKE-STARTUP-FUNCTION))

Re: Unprintable CCL::IMMEDIATE : #xEB

R. Matthew Emerson — 2008-12-01T21:13:24

On Dec 1, 2008, at 11:49 AM, Cyrus Harmon wrote: I think I fixed the error reporting bug in r11449. Thanks for pointing that out. http://trac.clozure.com/openmcl/changeset/11449

yet another ccl/x86 issue

Cyrus Harmon — 2008-12-01T18:47:03

The combination of ccl and my code seems to be quite good at picking up subtle "issues" in both systems. Here's the latest: Bug (probably): can't determine class of # #x8F1F7B6> [Condition of type SIMPLE-ERROR] Restarts: 0: [LOAD-SOURCE] Load "home:projects;git.cyrusharmon.org;clem;src;subtr.lisp" instead of "/ Users/sly/projects/git.cyrusharmon.org/clem/src/ccl-1.3-darwin-x86/ subtr.dx32fsl" 1: [RECOMPILE] Compile "home:projects;git.cyrusharmon.org;clem;src;subtr.lisp" into "/Users/ sly/projects/git.cyrusharmon.org/clem/src/ccl-1.3-darwin-x86/ subtr.dx32fsl" then load "/Users/sly/projects/git.cyrusharmon.org/clem/ src/ccl-1.3-darwin-x86/subtr.dx32fsl" again 2: [RETRY-LOAD] Retry loading #P"/Users/sly/projects/ git.cyrusharmon.org/clem/src/ccl-1.3-darwin-x86/subtr.dx32fsl" 3: [SKIP-LOAD] Skip loading #P"/Users/sly/projects/ git.cyrusharmon.org/clem/src/ccl-1.3-darwin-x86/subtr.dx32fsl" 4: [LOAD-OTHER] Load other file instead of #P"/Users/sly/projects/ git.cyrusharmon.org/clem/src/ccl-1.3-darwin-x86/subtr.dx32fsl" 5: [TRY-RECOMPILING] Recompile subtr and try loading it again 6: [RETRY] Retry performing # on #. 7: [ACCEPT] Continue, treating # on # as having been successful. 8: [RETRY] Retry SLIME REPL evaluation request. 9: [ABORT] Return to SLIME's top level. 10: [ABORT-BREAK] Reset this thread 11: [ABORT] Kill this thread Backtrace: 0: [error printing frame] 1: [error printing frame] 2: [error printing frame] 3: (CCL::COMPUTE-NTH-ARG-COMBINED-METHOD # (# #((#) NIL NIL 2 ..)) 6: [error printing frame] 7: (# # T :DATUM # #x8F1F7B6> :EXPECTED-TYPE FUNCTION) 8: (# # :DATUM # #x8F1F7B6> :EXPECTED-TYPE FUNCTION) 9: (CCL::%MAKE-STD-INSTANCE # (:DATUM #) 10: (# # :DATUM # #x8F1F7B6> :EXPECTED-TYPE FUNCTION) 11: (# TYPE- ERROR :DATUM # #x8F1F7B6> :EXPECTED-TYPE FUNCTION) 12: (MAKE-CONDITION TYPE-ERROR :DATUM # #x8F1F7B6> :EXPECTED-TYPE FUNCTION) 13: [error printing frame] 14: [error printing frame] 15: [error printing frame] 16: [error printing frame] 17: (CCL::%%BEFORE-AND-AFTER-COMBINED-METHOD-DCODE (NIL # . 1564219)) 18: (CCL::%%STANDARD-COMBINED-METHOD-DCODE (NIL (#) ..) 19: (# # (:NAME CLEM::MAT-SUBTR-RANGE3 :SPECIALIZERS ..))) 21: (# # :NAME CLEM::MAT-SUBTR- RANGE3 :SPECIALIZERS (# ..).. 22: (CCL::ENSURE-METHOD CLEM::MAT-SUBTR-RANGE3 (#1=# # #1# #2=# #2# #2# ..) 23: (CCL::$FASL-LFUNCALL #) 24: (CCL::%FASLOAD "/Users/sly/projects/git.cyrusharmon.org/clem/src/ ccl-1.3-darwin-x86/subtr.dx32fsl" #(# ..)) 25: (CCL::%LOAD #P"/Users/sly/projects/git.cyrusharmon.org/clem/src/ ccl-1.3-darwin-x86/subtr.dx32fsl" NIL NIL :ERROR :DEFAULT) 26: (LOAD #P"/Users/sly/projects/git.cyrusharmon.org/clem/src/ ccl-1.3-darwin-x86/subtr.dx32fsl" :VERBOSE NIL :PRINT NIL :IF-DOES-NOT- EXIST :ERROR :EXTERNAL-FORMAT :DEFAULT) 27: (# # #) 28: (# # #) 29: (CCL::%CALL-NEXT-METHOD (NIL # # #)) 30: (# # #) 31: (CCL::%%CALL-METHOD* # (#) (# #)) 32: (# # #) 33: ((:INTERNAL CCL::WITH-COMPILATION-UNIT-BODY ASDF:OPERATE)) 34: (CCL::CALL-WITH-COMPILATION-UNIT # :OVERRIDE NIL) 35: (ASDF:OPERATE ASDF:LOAD-OP #:CLEM) 36: (CCL::CALL-CHECK-REGS ASDF:OOS ASDF:LOAD-OP #:CLEM) 37: (SWANK::EVAL-REGION "(asdf:oos 'asdf:load-op '#:clem)\n") 38: ((:INTERNAL SWANK::REPL-EVAL)) 39: (SWANK::TRACK-PACKAGE #) 40: (SWANK::CALL-WITH-RETRY-RESTART "Retry SLIME REPL evaluation request." #) 41: (SWANK::CALL-WITH-BUFFER-SYNTAX NIL #) 42: (SWANK::REPL-EVAL "(asdf:oos 'asdf:load-op '#:clem)\n") 43: (CCL::CALL-CHECK-REGS SWANK:LISTENER-EVAL "(asdf:oos 'asdf:load- op '#:clem)\n") 44: (SWANK::EVAL-FOR-EMACS (SWANK:LISTENER-EVAL "(asdf:oos 'asdf:load-op '#:clem)\n") "COMMON-LISP-USER" 6) 45: (SWANK::PROCESS-REQUESTS NIL) 46: ((:INTERNAL SWANK::HANDLE-REQUESTS)) 47: (# # #) 48: (SWANK::CALL-WITH-REDIRECTED-IO # #) 49: (SWANK::CALL-WITH-CONNECTION # #) 50: (SWANK::HANDLE-REQUESTS # NIL) 51: (SWANK::CALL-WITH-BINDINGS NIL #) 52: (CCL::RUN-PROCESS-INITIAL-FORM # (#)) 53: ((:INTERNAL CCL::%PROCESS-PRESET-INTERNAL) # (#)) 54: ((:INTERNAL CCL::THREAD-MAKE-STARTUP-FUNCTION))

Re: Unprintable CCL::IMMEDIATE : #xEB

Cyrus Harmon — 2008-12-01T16:49:23

Yes, changing the :element-type in with-open-file from :default to '(unsigned-byte 8) makes the problem go away on both x86 and x86-64. So it looks like it is a combination of some sort of problem with the error reporting pathway and a creeping SBCL-ism that should be fixed. thanks, cyrus On Dec 1, 2008, at 8:02 AM, Cyrus Harmon wrote:

Re: Unprintable CCL::IMMEDIATE : #xEB

Cyrus Harmon — 2008-12-01T16:02:37

One reliable way to reproduce the bug (?) is to try loading a TIFF file using my retrospectiff package: To reproduce: 1. install retrospectiff, which can be found at: http://git.cyrusharmon.org/cgi-bin/gitweb.cgi?p=retrospectiff.git 2. enter the following from the retrospectiff directory in ccl: (asdf:oos 'asdf:load-op :retrospectiff) (defparameter *snow-image* (retrospectiff:read-tiff-file "images/ snow.tiff")) Interestingly, this also fails in x86-64 darwin, but with a more sensible error message. So perhaps it's a bug in my code that is triggering a deficient error mechanism: #\M doesn't match array element type of #(0 0). [Condition of type SIMPLE-ERROR] Restarts: 0: [RETRY] Retry SLIME REPL evaluation request. 1: [ABORT] Return to SLIME's top level. 2: [ABORT-BREAK] Reset this thread 3: [ABORT] Kill this thread Backtrace: 0: (CCL::GENERIC-CHARACTER-READ-VECTOR # #(0 0) 0 2) 1: (READ-SEQUENCE #(0 0) # :START 0 :END 2) 2: (READ-BYTES # 2) 3: (READ-INT-16 # :BYTE-ORDER NIL) 4: (READ-TIFF-STREAM #) 5: (READ-TIFF-FILE "images/snow.tiff") 6: (CCL::CALL-CHECK-REGS READ-TIFF-FILE "images/snow.tiff") 7: (CCL::CHEAP-EVAL-IN-ENVIRONMENT (CCL::%DEFPARAMETER '*SNOW- IMAGE* (READ-TIFF-FILE "images/snow.tiff") NIL) #) 8: (SWANK::EVAL-REGION "(defparameter *snow-image* (read-tiff-file \"images/snow.tiff\"))\n") 9: ((:INTERNAL SWANK::REPL-EVAL)) 10: (SWANK::TRACK-PACKAGE #) 11: (SWANK::CALL-WITH-RETRY-RESTART "Retry SLIME REPL evaluation request." #) 12: (SWANK::CALL-WITH-BUFFER-SYNTAX NIL #) 13: (SWANK::REPL-EVAL "(defparameter *snow-image* (read-tiff-file \"images/snow.tiff\"))\n") 14: (CCL::CALL-CHECK-REGS SWANK:LISTENER-EVAL "(defparameter *snow- image* (read-tiff-file \"images/snow.tiff\"))\n") 15: (SWANK::EVAL-FOR-EMACS (SWANK:LISTENER-EVAL "(defparameter *snow- image* (read-tiff-file \"images/snow.tiff\"))\n") "RETROSPECTIFF" 19) 16: (SWANK::PROCESS-REQUESTS NIL) 17: ((:INTERNAL SWANK::HANDLE-REQUESTS)) 18: (# # #) 19: (SWANK::CALL-WITH-REDIRECTED-IO # #) 20: (SWANK::CALL-WITH-CONNECTION # #) 21: (SWANK::HANDLE-REQUESTS # NIL) 22: (SWANK::CALL-WITH-BINDINGS NIL #) 23: (CCL::RUN-PROCESS-INITIAL-FORM # (#)) 24: ((:INTERNAL CCL::%PROCESS-PRESET-INTERNAL) # (#)) 25: ((:INTERNAL CCL::THREAD-MAKE-STARTUP-FUNCTION)) thanks again, cyrus On Dec 1, 2008, at 7:35 AM, Cyrus Harmon wrote:

Re: Unprintable CCL::IMMEDIATE : #xEB

Cyrus Harmon — 2008-12-01T15:35:43

My bug writing skills have clearly atrophied. Yes, this is 32-bit x86 on darwin (10.5.5). This is in the trunk (or the trunk as of a couple days ago). It's quite possible that I'm the culprit by lying to the compiler with various declarations in ways that SBCL isn't offended by. I'll see what I can do about a reproducible test case. thanks, cyrus On Nov 30, 2008, at 10:10 PM, Gary Byers wrote:

Re: (setf (find-class ...) ...) problem

Pascal Costanza — 2008-12-01T08:20:55

Hi there, Section 4.3.1 defines what a proper name of a class is. The restriction is there because otherwise you could have ambiguities in the type system. (Two different classes can have the same name, but only one can have that name as a proper name.) Pascal On 1 Dec 2008, at 06:04, Cyrus Harmon wrote:

Re: Unprintable CCL::IMMEDIATE : #xEB

Gary Byers — 2008-12-01T06:10:55

It's hard to respond to something like this without knowing what version of the lisp you're running. Unless you're really sure that that information is irrelevant, it's generally a good idea to include it when reporting a problem like this. My best guess is that you're running some 32-bit X86 version on Darwin. On that platform, #xeb is just a placeholder value used to reserve space for an outgoing stack frame in some cases; nothing's supposed to ever "see" that marker value. Having one of these things get passed around is indicative of a fairly serious bug (the compiler's lost track of what's on the stack, or the runtime is pushing or popping more than it's supposed to, or something like that.) It's been a while since I've seen that sort of bug in the x86-32 trunk lisps, but that doesn't mean that such a bug isn't still there. If it is still present in the trunk, then knowing how to reproduce it would be helpful. On Sun, 30 Nov 2008, Cyrus Harmon wrote:

Unprintable CCL::IMMEDIATE : #xEB

Cyrus Harmon — 2008-12-01T05:07:19

Ok, so my latest issue in trying to port my stuff to ccl is the error shown below. Not sure where to begin with this one. thanks, Cyrus value # is not of the expected type CCL::UVECTOR. [Condition of type TYPE-ERROR] Restarts: 0: [RETRY] Retry SLIME REPL evaluation request. 1: [ABORT] Return to SLIME's top level. 2: [ABORT-BREAK] Reset this thread 3: [ABORT] Kill this thread Backtrace: 0: ((:INTERNAL CCL::%XERR-DISP)) 1: (CCL::FUNCALL-WITH-ERROR-REENTRY-DETECTION #) 2: (CCL::%XERR-DISP -334757490) 3: (CCL::%PASCAL-FUNCTIONS% 2 -334757490) 4: (CCL::%PR-INTEGER # 10 # T NIL) 5: (CCL::%RSC-STRING #) 6: (CCL::%ERR-DISP-INTERNAL # (# \M #(0 0)) 1564382) 7: (READ-SEQUENCE #(0 0) # :START 0 :END 2) 8: (READ-BYTES # 2) 9: (READ-INT-16 # :BYTE-ORDER NIL) 10: (READ-TIFF-STREAM #) 11: (READ-TIFF-FILE "images/snow.tiff") 12: (CCL::CALL-CHECK-REGS READ-TIFF-FILE "images/snow.tiff") 13: (CCL::CHEAP-EVAL-IN-ENVIRONMENT (CCL::%DEFPARAMETER '*SNOW- IMAGE* (READ-TIFF-FILE "images/snow.tiff") NIL) #) 14: (SWANK::EVAL-REGION "(defparameter *snow-image* (read-tiff-file \"images/snow.tiff\"))\n") 15: ((:INTERNAL SWANK::REPL-EVAL)) 16: (SWANK::TRACK-PACKAGE #) 17: (SWANK::CALL-WITH-RETRY-RESTART "Retry SLIME REPL evaluation request." #) 18: (SWANK::CALL-WITH-BUFFER-SYNTAX NIL #) 19: (SWANK::REPL-EVAL "(defparameter *snow-image* (read-tiff-file \"images/snow.tiff\"))\n") 20: (CCL::CALL-CHECK-REGS SWANK:LISTENER-EVAL "(defparameter *snow- image* (read-tiff-file \"images/snow.tiff\"))\n") 21: (SWANK::EVAL-FOR-EMACS (SWANK:LISTENER-EVAL "(defparameter *snow- image* (read-tiff-file \"images/snow.tiff\"))\n") "RETROSPECTIFF" 85) 22: (SWANK::PROCESS-REQUESTS NIL) 23: ((:INTERNAL SWANK::HANDLE-REQUESTS)) 24: (# # #) 25: (SWANK::CALL-WITH-REDIRECTED-IO # #) 26: (SWANK::CALL-WITH-CONNECTION # #) 27: (SWANK::HANDLE-REQUESTS # NIL) 28: (SWANK::CALL-WITH-BINDINGS NIL #) 29: (CCL::RUN-PROCESS-INITIAL-FORM # (#)) 30: ((:INTERNAL CCL::%PROCESS-PRESET-INTERNAL) # (#)) 31: ((:INTERNAL CCL::THREAD-MAKE-STARTUP-FUNCTION))

Re: (setf (find-class ...) ...) problem

Cyrus Harmon — 2008-12-01T05:04:04

Gary, Thanks for the thoughtful explanation. Explicitly deftype'ing the class first sounds reasonable to me. I've asked the cxml-stp developers for their opinion as well. thanks again, cyrus On Nov 30, 2008, at 6:12 PM, Gary Byers wrote:

Re: how to use quicktime

R. Matthew Emerson — 2008-12-01T02:15:03

On Nov 30, 2008, at 8:15 PM, Alexander Repenning wrote: Welcome to Clozure Common Lisp Version 1.2-r11429M (DarwinX8664)! ? (require 'cocoa) [...] ;;; open shared library, use interface dir, update objc bridge info ? (objc:load-framework "QTKit" :qtkit) NIL ? (make-instance 'ns:q-t-movie-view) # (#x127C1B00)> ? http://trac.clozure.com/openmcl/wiki/AddressBook is another example (but it uses the AddressBook framework instead of QTKit).

Re: (setf (find-class ...) ...) problem

Gary Byers — 2008-12-01T02:12:04

On Sun, 30 Nov 2008, Cyrus Harmon wrote: I assume that you mean something like: (defclass fruit () ()) (defclass orange (fruit) ()) (setf (find-class 'tangerine) (find-class 'fruit)) (typep (make-instance 'orange) 'tangerine) complains that TANGERINE isn't a valid type-specifier. My first reaction was to think that that was a bug, but after looking at the spec for a while I haven't yet found anything that confirms that and have found at least one passage that (weakly) contradicts that intuition, but it's a bit unclear. The second paragraph of CLHS 4.3.7 says that "the PROPER name of every class is a valid type specifier.", then discusses the use of class objects as type specifiers and notes TYPE-OF's behavior wrt instances of properly and improperly-named classes. The next paragraph says "Because the names of classes and class objects are type specifiers, they can be used in special form THE and in type declarations." I think that the clearest reading of that is something like "Based on what was established in the preceding paragraph, the PROPER names of classes ... can be used in THE forms and as type specifiers." I'd feel better about making that claim if the language in the third paragraph was a little stronger, but I find it hard to parse the "because" qualifier as referring to anything but what's established in the preceding paragraph. I couldn't find anything else in the spec that was any clearer; the other things that I found referred to things like "symbols naming classes defined by DEFCLASS" and their relation to the type system. (I didn't find anything analogous discussing "symbols established as class names via (SETF FIND-CLASS).") I don't see anything in the spec that says that improper class names -can't- be treated as type specifiers, and it's hard to imagine that anyone's code would break if CCL's (SETF FIND-CLASS) stopped checking for proper-namedness in this case, though it's not quite impossible imagine that. I'm also perfectly willing to believe that there's something else in the spec that's more definitive and that contradicts the interpretation above, but in the absence of that I have to conclude that code that assumes that (SETF (FIND-CLASS a) c) S into a valid type specifier is incorrect (even though it likely "works" in most/all other implementations.) I think that there actaully are reasons for the spec's (seeming) insistence on only considering properly-named classes to be type specifiers (and that those reasons probably have to do with the compilation model.) I'm not sure that those reasons are fully developed, but I don't think that the spec's distinctions between proper and improper class names are arbitrary and accidental, either. If we all strongly believed that (SETF FIND-CLASS) only made S into a type specifier if S was the class name of C, then a portable way of doing this would be something like: (setf (find-class s) c) (deftype s () 'c) ; whatever the "proper name" of C is CCL actually errs in the expansion of DEFTYPE, because S names a class (even though it doesn't properly name it and even though it's therefore not a type-specifier; it'd be more consistent if the expansion of DEFTYPE did the same kind of check for proper-namedness that (SETF FIND-CLASS) does. It -does- work to do the DEFTYPE first: (deftype tangerine () 'orange) (setf (find-class 'tangerine) (find-class 'orange)) I'm not entirely comfortable in saying that I think that CCL's "right" about this (at least in trying to adhere to the letter of the spec) and that other implementations are all wrong. At the moment, let's just say that I'm not entirely comfortable (though I think that I'd be a little closer to comfort if CCL was more consistent, e.g., if DEFTYPE's expansion only rejected attempts to redefine class-names that the implementation considered to be type specifiers.)

how to use quicktime

Alexander Repenning — 2008-12-01T01:15:47

_______________________________________________ Openmcl-devel mailing list Openmcl-devel< at >clozure.com http://clozure.com/mailman/listinfo/openmcl-devel

(setf (find-class ...) ...) problem

Cyrus Harmon — 2008-11-30T21:40:14

I'm trying to use david lichteblau's cxml-stp with ccl and am getting errors about undefined types. It seems that ccl doesn't like the following: (setf (find-class 'document-type) (find-class 'cxml-stp:document-type)) a similar problem was discussed a while back where this problem arose with GSharp, but I'm not sure what the resolution was. Any suggestions? thanks, Cyrus

International Lisp Conference 2009

Andrew Shalit — 2008-11-26T21:13:18

The 2009 ILC will be held in Cambridge, Mass. Many Clozurites will be in attendance. If you have something you'd like to share, please consider submitting a paper. Regardless of that, we hope that you'll attend. ---- CALL FOR SUBMISSIONS INTERNATIONAL LISP CONFERENCE 2009 Lisp: The Next 50 Years http://www.international-lisp-conference.org Massachusetts Institute of Technology Cambridge, Massachusetts, USA March 22-25, 2009 Sponsored by the Association of Lisp Users General Information: The Association of Lisp Users is pleased to announce the 2009 International Lisp Conference will be held in Cambridge, Massachusetts, at the Massachusetts Institute of Technology, Sunday through Wednesday, March 22-25, 2009. The emphasis will be on present and future applications of technologies that have been or might soon be associated with the Lisp programming language and/or related languages and software. We encourage submissions in diverse areas, including but not limited to: language design and implementation, memory management, software engineering, mathematical and scientific computing, artificial intelligence, database processing and data mining, business intelligence, performance analysis, parallel processing, quantum computing, bioinformatics, telecommunications and networking, the semantic web, music, domain-specific languages, and entertainment technologies. ILC09 is not limited to topics discussed in previous symposia. Authors concerned about the appropriateness of a topic may communicate by electronic mail with the program chair prior to submission. Explaining a known idea in a new way may make as strong a contribution as inventing a new one. We encourage the submission of "pearls": elegant essays that illustrate an idea, for example by developing a short program. (A pearl should be concise, instructive, self-contained, and entertaining. Your pearl is likely to be rejected if your readers get bored, if the material gets too complicated, if too much specialized knowledge is needed, or if the writing is inelegant. The key to writing a good pearl is polishing.) There is no formal separation of categories and no need to explicitly label pearls as such: all papers, whether pearl or otherwise, will be judged on a combination of correctness, significance, novelty, clarity, and elegance. Each paper should explain its contributions in both general and technical terms, identifying what has been accomplished, explaining why it is significant, and comparing it with previous work. Authors should strive to make their papers understandable to a broad audience. Alongside our usual four-day program of tutorials, prominent invited speakers, and excellent technical sessions, this year we will also consider demonstration sessions. The official language of the conference is English. Further details are available at the conference web site: http://www.international-lisp-conference.org Technical Program: Original submissions in all areas related to the conference themes are invited for the following categories. Papers: Technical papers of up to 15 pages that describe original results ("research papers") or explain known ideas in new ways ("pearls"). Demonstrations: Abstracts of up to 4 pages for demonstrations of tools, libraries, and applications. Tutorials: Abstracts of up to 4 pages for in-depth presentations about topics of special interest for at least 90 minutes and up to 180 minutes. Panel discussions: Abstracts of up to 4 pages for discussions about current themes. Panel discussion proposals must mention panel members who are willing to partake in a discussion. Lightning talks: Abstracts of up to one page for talks to last for no more than 5 minutes. Important Dates: Please send contributions before the submission deadline to the program committee (ilc09-program-committee at alu.org). Deadline for submissions: December 9, 2009 Notification of acceptance or rejection: January 9, 2009 Deadline for final paper submissions: February 9, 2009 Organizing Committee: Conference Chair: Daniel Weinreb (ITA Software) General correspondence: ilc09-organizing-committee at alu.org Program Chair: Guy L. Steele Jr. (Sun Microsystems Laboratories) Contact: ilc09-program-committee at alu.org Local chair: Howard Shrobe (MIT) Technical Program Committee: to be announced soon

Re: defclass initform issue

R. Matthew Emerson — 2008-11-26T18:22:16

On Nov 26, 2008, at 9:36 AM, Gail Zacharias wrote: I went ahead and committed this fix to the 1.2 branch as well.

Re: defclass initform issue

Gail Zacharias — 2008-11-26T14:36:14

In CCL. Should be fixed in the trunk now.

Re: defclass initform issue

Zach Beane — 2008-11-26T13:47:07

And another data point: ? (funcall (lambda () (make-array '(1) :element-type '(signed-byte 16) :initial-element -1))) #(-1) Zach

Re: defclass initform issue

Zach Beane — 2008-11-26T12:58:03

I can simplify: ? (funcall (lambda () (make-array 1 :element-type '(signed-byte 16) :initial-element -1))) > Error: value -1 is not of the expected type (UNSIGNED-BYTE 16). Zach

defclass initform issue

Zach Beane — 2008-11-26T12:51:22

I didn't expect the following result: ? (defclass foo () ((data :initform (make-array 1 :element-type '(signed-byte 16) :initial-element -1)))) # ? (make-instance 'foo) > Error: value -1 is not of the expected type (UNSIGNED-BYTE 16). Startup says: Welcome to Clozure Common Lisp Version 1.2-r10552 (LinuxX8664)! Is that a bug in CCL, or in my expectations? Zach

Re: Running out of file descriptors with run-program

Daniel Dickison — 2008-11-25T22:14:13

Ahh I should have searched trac first. (Remembered to search openmcl- devel, forgot about trac). Thanks for pointing me to that, and for the work around. Daniel