#43: Interface for API users to hook into debugging output
-------------------------+--------------------------------------------------
Reporter: ehuelsmann | Owner: somebody
Type: enhancement | Status: new
Priority: major | Milestone:
Component: other | Version:
Keywords: debug |
-------------------------+--------------------------------------------------
Currently, we don't have ways to hook into debugging information in ABCL
from higher-up API users. It would be nice to be able to offer such
interfaces, since it would definitely offer developers better ways to
integrate ABCL into deployed apps.
--
Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/43>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#19: SLIME from CVS HEAD needs 'with-mutex.lisp'
------------------------+---------------------------------------------------
Reporter: mevenson | Owner: ehuselmann
Type: defect | Status: new
Priority: major | Milestone: unscheduled
Component: component1 | Version:
Keywords: SLIME |
------------------------+---------------------------------------------------
SLIME from CVS HEAD fails to load with r11371, as it apparently needs
with-mutex.lisp.
The attached patch adds 'with-mutex.lisp' to the ABCL jar.
--
Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/19>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#59: Add extensible sequences to ABCL
----------------------------------------------+-----------------------------
Reporter: astalla | Owner: somebody
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: other | Version:
Keywords: extensible sequences collections |
----------------------------------------------+-----------------------------
Implement the protocol described in
http://www.doc.gold.ac.uk/~mas01cr/papers/ilc2007/sequences-20070301.pdf
to allow users to provide new types of sequences working with the standard
Common Lisp sequences API. Use this protocol to make Java collections
first-class in abcl.
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/59>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#33: Measure the impact of filling stack trace information when performing
GO/RETURN/THROW
----------------------------------------------------------------------+-----
Reporter: vvoutilainen | Owner: somebody
Type: task | Status: new
Priority: minor | Milestone: unscheduled
Component: component1 | Version: 1.0
Keywords: exception ConditionThrowable go return throw performance |
----------------------------------------------------------------------+-----
Douglas R. Miles reported recently that
java.lang.Throwable.fillInStackTrace() can be a very time consuming
operation when instantiating Throwables or objects the class of which
extends Throwable.
A patch for overriding the fillInStackTrace() function with an empty
implementation was created, it seems to be a performance gain, but a
benchmark is required. ANSI tests test so many other things that it's
difficult to compare the impact of the patch without a test that tests
only GO/RETURN/THROW.
--
Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/33>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#63: Attempt to GO to tag whose dynamic extent has ended exits ABCL
----------------------+-----------------------------------------------------
Reporter: mevenson | Owner: somebody
Type: defect | Status: new
Priority: major | Milestone: unscheduled
Component: CLOS | Version: 1.0
Keywords: |
----------------------+-----------------------------------------------------
Reported by Brian Mastenbrook:
When attempting to GO to a tag whose dynamic extent has ended, ABCL quits
and prints the name of the exception used for internally handling GO
(org.armedbear.lisp.Go). I see the same behavior in compiled or
interpreted code.
{{{
CL-USER(1): (lisp-implementation-version)
"0.16.0"
CL-USER(2): (let ((f nil)) (tagbody (setf f (lambda () (go foo))) foo)
(funcall f))
org.armedbear.lisp.Go
abcl-src-0.16.0 chandler$
}}}
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/63>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#62: CLOS with &key arguments after &rest fails
----------------------+-----------------------------------------------------
Reporter: mevenson | Owner: somebody
Type: defect | Status: new
Priority: major | Milestone: unscheduled
Component: CLOS | Version: 1.0
Keywords: |
----------------------+-----------------------------------------------------
The problem can be tested by attempting to load an ASDF system defintion
as follows:
(asdf:operate 'asdf:load-op :abcl :verbose t)
which produces the error
Invalid initarg :VERBOSE.
but probably can be reduced to a simpler test case involving functions
with &key arguments after &rest.
Introduced in r12067
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/62>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#61: Compilation of THE with macros
----------------------+-----------------------------------------------------
Reporter: mevenson | Owner: ehuelsmann
Type: defect | Status: new
Priority: major | Milestone: unscheduled
Component: compiler | Version: 1.0
Keywords: |
----------------------+-----------------------------------------------------
As reported in http://article.gmane.org/gmane.lisp.armedbear.devel/152 by
Eric Marsden, the recent work on THE forms has broken the compilation of
THE forms involving macros as follows:
#|
COMPILE-FILE for this file fails with [svn r12114].
|#
(defconstant +foo-OK+ (the (integer 0 10) 5))
(deftype foo () '(integer 0 10))
(defmacro assemble-foo (x) `(the foo ,x))
(defconstant +foo+ (assemble-foo 6))
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/61>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#46: Compilation failure from several numeric arguments to MIN
----------------------+-----------------------------------------------------
Reporter: mevenson | Owner: ehuselmann
Type: defect | Status: new
Priority: major | Milestone: unscheduled
Component: compiler | Version: 1.0
Keywords: |
----------------------+-----------------------------------------------------
After the recent (JAN/FEB) changes to the compiler to support numeric
types more efficiently, the following code fails to compile:
{{{
(defun fail ()
(min 1 2 3))
}}}
with a Failed AVER: "NIL" arising out of COMPILE-FORMS-AND-MAYBE-EMIT-
CLEAR_VALUES failing to parse its arguments correctly.
--
Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/46>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#26: Multi-thread safety
-------------------------+--------------------------------------------------
Reporter: ehuelsmann | Owner: somebody
Type: enhancement | Status: new
Priority: major | Milestone:
Component: component1 | Version:
Keywords: |
-------------------------+--------------------------------------------------
Alex Mizhari writes:
multithread safety -- while perhaps not
thoroughly checked, most stuff behaves
fine with multiple threads, at least
i don't remember having problems with it.
--
Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/26>
armedbear <http://common-lisp.net/project/armedbear>
armedbear