#44: Unboxing of local variables with :float and :double representations
-------------------------+--------------------------------------------------
Reporter: ehuelsmann | Owner: ehuelsmann
Type: enhancement | Status: new
Priority: major | Milestone:
Component: compiler | Version:
Keywords: |
-------------------------+--------------------------------------------------
Currently, variables with :float or :double representations don't get
stored unboxed. Since intermediate results of those types do get unboxed,
this leads to additional boxing/unboxing.
--
Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/44>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#85: CL-JSON throws an error under ABCL where SBCL doesn't.
------------------------+---------------------------------------------------
Reporter: ehuelsmann | Owner: somebody
Type: defect | Status: new
Priority: major | Milestone:
Component: other | Version:
Keywords: |
------------------------+---------------------------------------------------
The code is:
(require 'asdf)
(asdf:operate 'asdf:load-op :cl-json)
(json:decode-json-from-string
"{\"foo\": [10,20,50], \"bar\": true}")
The error message is: The value 50 is not of type CONS.
I'm using Yason as a work-around, but thought that you guys might want to
know, maybe this points to a deeper issue.
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/85>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#81: Inlining functions with &optional and other "complex" arguments
-------------------------+--------------------------------------------------
Reporter: ehuelsmann | Owner: ehuelsmann
Type: enhancement | Status: new
Priority: major | Milestone: 0.20
Component: compiler | Version:
Keywords: |
-------------------------+--------------------------------------------------
Currently we only inline functions which have only required parameters.
With a little bit more intelligence we could easily inline functions with
optional parameters.
With a bit more intelligence than that, we can even inline functions with
&keyword and &rest parameters.
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/81>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#48: SLIME CVS HEAD as of 2008-12-30 broken
-------------------------------------+--------------------------------------
Reporter: mevenson | Owner: mevenson
Type: defect | Status: new
Priority: major | Milestone: 0.13
Component: other | Version: 1.0
Keywords: slime emacs application |
-------------------------------------+--------------------------------------
Symptom is the failed listening to SlimeInputStream that doesn't detect a
pipe close, therefore never closes, so further enviornment bindings are
incorrect.
*inferior-lisp* buffers needs to evaluate a form before SLIME works
properly.
Something messed up in the Stream ._finishOuput() calls??
--
Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/48>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#77: FASLs use wrong encoding: system default
------------------------+---------------------------------------------------
Reporter: ehuelsmann | Owner: ehuelsmann
Type: defect | Status: new
Priority: critical | Milestone: 0.19
Component: compiler | Version:
Keywords: |
------------------------+---------------------------------------------------
Because FASLs are using the system default encoding, we can't be sure they
can hold all characters which Java (and thus Lisp) can handle.
Additionally, reading back FASLs on systems which have a different default
encoding might break.
Solution: use UTF-8 as the encoding for FASLs.
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/77>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#2: Human readable printing of errors and conditions
--------------------------+-------------------------------------------------
Reporter: ehuelsmann | Owner: somebody
Type: enhancement | Status: new
Priority: major | Milestone:
Component: other | Version:
Resolution: | Keywords:
--------------------------+-------------------------------------------------
Comment(by ehuelsmann):
The source of this behaviour is the fact that in some cases the 'format-
control slot in the built-in condition doesn't get set.
When that happens, the print-object code in print-object.lisp doesn't get
triggered to print the nice message, but rather passes control to the
standard object printing routine (which prints the ugly output above).
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/2#comment:2>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#75: Character \U0080 causes infinite loop
------------------------+---------------------------------------------------
Reporter: ehuelsmann | Owner: somebody
Type: defect | Status: new
Priority: major | Milestone:
Component: CLOS | Version:
Keywords: |
------------------------+---------------------------------------------------
The following code causes an infinite loop on systems which do not support
character \U0080 in their default output character set:
(defparameter single-character-symbols
'#.(let ((a (make-array 129)))
(dotimes (i 129)
(setf (svref a i) (make-string 1 :initial-element (code-char i))))
a))
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/75>
armedbear <http://common-lisp.net/project/armedbear>
armedbear