#65: UTF-32 strings support
------------------------+---------------------------------------------------
Reporter: ehuelsmann | Owner: somebody
Type: defect | Status: new
Priority: major | Milestone:
Component: other | Version:
Keywords: |
------------------------+---------------------------------------------------
ABCL uses Java char[]s to represent its strings. However, the char type
can only represent values in the BMP (Basic Multilingual Plane), because
only the BMP can be represented using 16 bits.
For supplementary characters (all Unicode chars outside the BMP), it uses
a pair of surrogate characters (UTF-16).
Common Lisp programs don't expect this and need strings to be represented
using complete characters.
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/65>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#118: Lisp.getUpgradedElementType returns more types than supported by
'make_array.java'
------------------------+---------------------------------------------------
Reporter: ehuelsmann | Owner: nobody
Type: defect | Status: new
Priority: major | Milestone:
Component: libraries | Version:
Keywords: |
------------------------+---------------------------------------------------
The above leads to possible failure: each upgraded element type has its
own associated defaultInitialValue. If the code does not specify the right
initial value, NIL is taken, which probably is not a good fit.
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/118>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#113: DEFSTRUCT redefinition can crash ABCL on MAKE-FOO
---------------------+------------------------------------------------------
Reporter: mseddon | Owner: nobody
Type: defect | Status: new
Priority: minor | Milestone:
Component: java | Version:
Keywords: |
---------------------+------------------------------------------------------
CL-USER(1): (defstruct foo x y)
FOO
CL-USER(2): (defstruct foo x y z)
FOO
CL-USER(3): (make-foo :x 1 :y 2 :z 3)
ABCL Debug.assertTrue() assertion failed!
java.lang.Error: ABCL Debug.assertTrue() assertion failed!
at org.armedbear.lisp.Debug.assertTrue(Debug.java:46)
at
org.armedbear.lisp.StructureObject.writeToString(StructureObject.java
:483)
Multiple DEFSTRUCTs do not change the underlying structure class, but seem
to cause StructureObject to assert if the new (almost ignored) definition
had a different number of slots than the old.
For example, while the above example crashes out ABCL, the following
example does not:
CL-USER(1): (defstruct foo a b c)
FOO
CL-USER(2): (defstruct foo x y z)
FOO
CL-USER(3): (make-foo :x 1 :y 2 :z 3)
#S(FOO :A 1 :B 2 :C 3)
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/113>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#73: "normalize-type" buffering
-------------------------+--------------------------------------------------
Reporter: ehuelsmann | Owner: somebody
Type: task | Status: new
Priority: major | Milestone:
Component: CLOS | Version:
Keywords: performance |
-------------------------+--------------------------------------------------
Peter Graves points out that with his "canonicalize-type" buffering, he
achieved measurable performance gain in XCL. We want to do the same in
ABCL.
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/73>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#60: Implement USE-FAST-CALLS properly
-------------------------+--------------------------------------------------
Reporter: trittweiler | Owner: ehuelsmann
Type: defect | Status: new
Priority: minor | Milestone:
Component: compiler | Version:
Keywords: |
-------------------------+--------------------------------------------------
USE-FAST-CALLS is implemented at the moment by flipping
an essentially global variable.
The proper implementation would be to make turn it into
a ABCL-specific declaration, and making sure it affects
its lexically enclosing code only.
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/60>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#32: Modify the currently disabled runtime-class.lisp code to not require ASM
--------------------------------------------------------------------+-------
Reporter: vvoutilainen | Owner: somebody
Type: enhancement | Status: new
Priority: major | Milestone:
Component: component1 | Version:
Keywords: jvm bytecode compiler runtime dynamic class generation |
--------------------------------------------------------------------+-------
It's possible to define classes at runtime, by generating bytecode and
loading it from the generated binary data, without ever writing it to a
temporary file. runtime-class.lisp does that, but it requires an external
bytecode library (ASM). ABCL has all the functionality for this to be done
without ASM, so the task is to modify the runtime-class.lisp code so that
ASM is no longer required and the code can be taken to be part of the
build.
--
Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/32>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#55: Clearing LispThread.currentThread()._values more efficiently
-------------------------+--------------------------------------------------
Reporter: ehuelsmann | Owner: ehuelsmann
Type: enhancement | Status: new
Priority: major | Milestone:
Component: compiler | Version:
Keywords: |
-------------------------+--------------------------------------------------
We currently clear _values all over the place; we could be more efficient
some times.
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/55>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#34: adjust generated '*.cls' filenames
------------------------+---------------------------------------------------
Reporter: mevenson | Owner: somebody
Type: defect | Status: new
Priority: major | Milestone:
Component: component1 | Version:
Keywords: |
------------------------+---------------------------------------------------
dmiles:
it be nice to eventually name the coerce-666.cls coerce_666.cls as the
same name of the way classpaths think about them (they'd continue to
work).. one argument agaist is our autoloader at least gets a better whack
at finding them in the right context apart from classloader
--
Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/34>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#30: Lisp debugger, for both compiled and interpreted code
----------------------------+-----------------------------------------------
Reporter: vvoutilainen | Owner: somebody
Type: enhancement | Status: new
Priority: major | Milestone: unscheduled
Component: component1 | Version:
Keywords: debug debugger |
----------------------------+-----------------------------------------------
ABCL code can be debugged with normal java debuggers, but it
is somewhat painful for the portions implemented in lisp(1). So we need a
lisp debugger.
(1) It's possible, although a bit tedious, to step through
eval calls in a java debugger by examining the cars and
cdrs of eval parameters when stepping the code.
--
Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/30>
armedbear <http://common-lisp.net/project/armedbear>
armedbear