[Openmcl-devel] Unprintable CCL::IMMEDIATE : #xEB
R. Matthew Emerson
rme at clozure.com
Mon Dec 1 16:13:24 EST 2008
On Dec 1, 2008, at 11:49 AM, Cyrus Harmon wrote:
> 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.
I think I fixed the error reporting bug in r11449. Thanks for
pointing that out.
> On Dec 1, 2008, at 8:02 AM, Cyrus Harmon wrote:
>> 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:
>> 2. enter the following from the retrospectiff directory in ccl:
>> (asdf:oos 'asdf:load-op :retrospectiff)
>> (defparameter *snow-image* (retrospectiff:read-tiff-file "images/
>> 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]
>> 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
>> 0: (CCL::GENERIC-CHARACTER-READ-VECTOR #<BASIC-FILE-CHARACTER-INPUT-
>> STREAM ("/Users/sly/projects/git.cyrusharmon.org/retrospectiff/
>> snow.tiff"/7 ISO-8859-1) #x30004158F39D> #(0 0) 0 2)
>> 1: (READ-SEQUENCE #(0 0) #<BASIC-FILE-CHARACTER-INPUT-STREAM ("/
>> 7 ISO-8859-1) #x30004158F39D> :START 0 :END 2)
>> 2: (READ-BYTES #<BASIC-FILE-CHARACTER-INPUT-STREAM ("/Users/sly/
>> ISO-8859-1) #x30004158F39D> 2)
More information about the Openmcl-devel