armedbear-ticket May 2010

armedbear-ticket@common-lisp.net

1 participants
47 discussions

[armedbear-ticket] [armedbear] #33: Measure the impact of filling stack trace information when performing GO/RETURN/THROW
by armedbear 04 Oct '10

04 Oct '10

#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

1 2

[armedbear-ticket] [armedbear] #80: REQUIRE should work with ASDF
by armedbear 04 Oct '10

04 Oct '10

#80: REQUIRE should work with ASDF --------------------------+------------------------------------------------- Reporter: mevenson | Owner: mevenson Type: enhancement | Status: new Priority: major | Milestone: unscheduled Component: libraries | Version: 1.0 Keywords: asdf require | --------------------------+------------------------------------------------- SBCL has the convention that if REQUIRE does not resolve on the filesystem, the argument is passed off to ASDF to resolve. It would be nice to include this in ABCL. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/80> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 3

[armedbear-ticket] [armedbear] #63: Attempt to GO to tag whose dynamic extent has ended exits ABCL
by armedbear 04 Oct '10

04 Oct '10

#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

1 4

[armedbear-ticket] [armedbear] #62: CLOS with &key arguments after &rest fails
by armedbear 04 Oct '10

04 Oct '10

#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

1 3

[armedbear-ticket] [armedbear] #61: Compilation of THE with macros
by armedbear 04 Oct '10

04 Oct '10

#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

1 4

[armedbear-ticket] [armedbear] #46: Compilation failure from several numeric arguments to MIN
by armedbear 04 Oct '10

04 Oct '10

#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

1 2

[armedbear-ticket] [armedbear] #21: Compilation failure from stack inconsistency
by armedbear 04 Oct '10

04 Oct '10

#21: Compilation failure from stack inconsistency ------------------------+--------------------------------------------------- Reporter: mevenson | Owner: somebody Type: defect | Status: new Priority: major | Milestone: unscheduled Component: component1 | Version: 1.0 Keywords: | ------------------------+--------------------------------------------------- #| Eric Marsden on armedbear-j-devel |# (defun foo () (flet ((bar () (unwind-protect 1 2))) (declare (inline bar)) (undefined (bar)))) #| ; Compiling /Users/evenson/work/abcl/bugs/stack-inconsistency.lisp ... Stack inconsistency at index 24: found 3, expected 1. ; Compilation unit finished ; The following functions were used but not defined: ; UNDEFINED |# -- Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/21> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 7

[armedbear-ticket] [armedbear] #26: Multi-thread safety
by armedbear 04 Oct '10

04 Oct '10

#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

1 3

[armedbear-ticket] [armedbear] #97: (apropos "MAKE-THREAD") prints MAKE-THREAD twice
by armedbear 01 Oct '10

01 Oct '10

#97: (apropos "MAKE-THREAD") prints MAKE-THREAD twice ------------------------+--------------------------------------------------- Reporter: ehuelsmann | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: CLOS | Version: Keywords: | ------------------------+--------------------------------------------------- -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/97> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 2

[armedbear-ticket] [armedbear] #88: Predicate to distinguish between functions implemented directly in Java vs. Lisp
by armedbear 01 Oct '10

01 Oct '10

#88: Predicate to distinguish between functions implemented directly in Java vs. Lisp -------------------------+-------------------------------------------------- Reporter: trittweiler | Owner: nobody Type: enhancement | Status: new Priority: minor | Milestone: Component: java | Version: Keywords: | -------------------------+-------------------------------------------------- For Slime, we need a predicate to distinguish between functions implemented in Java, and functions compiled from Lisp. The reason is because we use different mechanism to get at the definition: for Java functions, we'll use TAGS, whereas for Lisp functions we will use source-location information stored by the ABCL compiler. Compiled Lisp functions also end up to be of type Primitive, so just making the Primitive class available to Lisp won't cut it. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/88> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 8

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-ticket May 2010