#156: Readtime macro compiler error ----------------------+----------------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: new Priority: blocker | Milestone: 0.26 Component: compiler | Version: Keywords: | ----------------------+----------------------------------------------------- [http://article.gmane.org/gmane.lisp.armedbear.devel/1958 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)) }}}
#156: Readtime macro compiler error ----------------------+----------------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: new Priority: blocker | Milestone: 0.26 Component: compiler | Version: Keywords: ironclad | ----------------------+----------------------------------------------------- Changes (by mevenson):
* keywords: => ironclad
#156: Readtime macro compiler error ----------------------+----------------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: new Priority: blocker | Milestone: 0.26 Component: compiler | Version: Keywords: ironclad | ----------------------+-----------------------------------------------------
Comment(by mevenson):
Bug introduced in r13274.
#156: Readtime macro compiler error ----------------------+----------------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: new Priority: blocker | Milestone: 0.26 Component: compiler | Version: Keywords: ironclad | ----------------------+-----------------------------------------------------
Comment(by mevenson):
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?
#156: Readtime macro compiler error -----------------------+---------------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: closed Priority: blocker | Milestone: 0.26 Component: compiler | Version: Resolution: fixed | Keywords: ironclad -----------------------+---------------------------------------------------- Changes (by mevenson):
* status: new => closed * resolution: => fixed
Comment:
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.
armedbear-ticket@common-lisp.net
-
armedbear