#460: upgraded-array-element-type/class-of for arrays
-------------------------+----------------------------
Reporter: mevenson | Owner:
Type: defect | Status: new
Priority: major | Milestone: 1.5.1
Component: interpreter | Version: 1.6.0-dev
Keywords: | Parent Tickets:
-------------------------+----------------------------
Alan notes in <https://github.com/armedbear/abcl/issues/84>
{{{
No code of mine depends on this, but I was reading an article and it
prompted me to check types of arrays and how upgraded-array-element-type
works.
Bottom line is that it isn't consistent.
CL-USER> (make-array 1 :element-type '(unsigned-byte 16))
#(0)
CL-USER> (jobject-class *)
#<java class org.armedbear.lisp.BasicVector_UnsignedByte16 {6F28B4E2}>
CL-USER> (class-of (make-array 1 :element-type '(unsigned-byte 16)))
#<built-in-class vector {352D86C9}>
CL-USER> (upgraded-array-element-type '(unsigned-byte 16))
(unsigned-byte 16)
CL-USER> (make-array 1 :element-type '(unsigned-byte 17))
#(0)
CL-USER> (jobject-class *)
#<java class org.armedbear.lisp.BasicVector_UnsignedByte32 {1C49E33C}>
CL-USER> (upgraded-array-element-type '(unsigned-byte 17))
t
CL-USER> (class-of (make-array 1 :element-type '(unsigned-byte 17)))
#<built-in-class vector {352D86C9}>
Summary:
Implementation of arrays of unsigned byte 16 vs 17 are different
class-of reports the same type
upgraded-array-element-type of (unsigned-byte 17) reports t, but it is
in fact (unsigned-byte 32)
trying to set array element of (unsigned-byte 17) to int larger than
2^17 works, but not setting to a symbol, as type t would imply
}}}
--
Ticket URL: <http://abcl.org/trac/ticket/460>
armedbear <http://abcl.org>
armedbear
#383: Build standalone JARs which contain additional application code
-------------------------+-----------------------
Reporter: mevenson | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: 1.4.0
Component: other | Version: 1.4.0-dev
Keywords: |
-------------------------+-----------------------
Clojure ("lein uberjar") as well as jruby ("warbler jar") have facilities
for creating a standalone JAR which contains the runtime plus application.
Other than creating the necessary assembly instructions, the only
substantial problem would seem to be the need to further abstract the
mechanism for finding ABCL-CONTRIB to something that could work on a
pathname as well as an entire JAR.
--
Ticket URL: <http://abcl.org/trac/ticket/383>
armedbear <http://abcl.org>
armedbear
#459: Defsetf Lambda-Lists Don't Permit the &environment Parameter
---------------------------+----------------------------
Reporter: mevenson | Owner:
Type: defect | Status: new
Priority: major | Milestone: 1.6.0
Component: interpreter | Version: 1.6.0-dev
Keywords: com.github-88 | Parent Tickets:
---------------------------+----------------------------
https://github.com/armedbear/abcl/issues/88
{{{
This is in violation to 3.4.7 which specifically allows the &environment
parameter in defsetf lambda-lists.
Test case:
(defsetf foo (&environment env place) (value))
;; => &ENVIRONMENT is only valid at top level of lambda list.
I'm not entirely sure if 3.4.7 requires &environment to come after the
places, unlike other lambda-lists where &environment has to be first. In
any case, late &environment also fails in the same fashion.
(defsetf foo (place &environment env) (value))
;; => &ENVIRONMENT is only valid at top level of lambda list.
}}}
--
Ticket URL: <http://abcl.org/trac/ticket/459>
armedbear <http://abcl.org>
armedbear