Opened 13 years ago
Closed 13 years ago
#156 closed defect (fixed)
Readtime macro compiler error
Reported by: | Mark Evenson | Owned by: | ehuelsmann |
---|---|---|---|
Priority: | blocker | Milestone: | 0.26 |
Component: | compiler | Version: | |
Keywords: | ironclad | Cc: | |
Parent Tickets: |
Description
Binghe reports that Ironclad cannot be compiled any longer.
He distilled the problem to
(defconstant a #.(make-array '(8 256) :element-type '(unsigned-byte 32) :initial-element 0))
Change History (4)
comment:1 Changed 13 years ago by
Keywords: | ironclad added |
---|
comment:2 Changed 13 years ago by
comment:3 Changed 13 years ago by
From what I can understand, r13274 introduced the binding of *PRINT-READABLY* for everything output by DUMP-FORM which in turn calls LispObject.writeToString(). But SimpleArray_UnsignedByte32.java signals an error if asked to writeToString() with *PRINT-READABLY* being non-NIL.
Is this because a READ of this form does not necessarily return an underlying type of (UNSIGNED_BYTE (0 32)) on say an array of all zeros?
comment:4 Changed 13 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
r13380 allows compilation to succeed, but the compiled code is suboptimal.
The ABCL compiler currently dumps such forms in their READ form to be read at load time rather than constructing JVM code to initialize the value. This has two consequences for your usage here: first, since the string has to be derserialized by the Lisp reader there is almost no conceivable JVM implementation that will make this usage faster. And the potentially more serious problem is that since the Lisp reader syntax doesn't specify the underlying array type, at runtime one gets an array who's BASE-ELEMENT-TYPE is T rather than (UNSIGNED-BYTE 32) which is probably less efficient.
Closing the ticket, as the immediate bug has been addressed to the old behavior.
Bug introduced in r13274.