Opened 10 years ago

Closed 10 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:


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 10 years ago by Mark Evenson

Keywords: ironclad added

comment:2 Changed 10 years ago by Mark Evenson

Bug introduced in r13274.

comment:3 Changed 10 years ago by Mark Evenson

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 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 10 years ago by Mark Evenson

Resolution: fixed
Status: newclosed

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.

Note: See TracTickets for help on using tickets.