February 2010 - armedbear-ticket - mailman3.common-lisp.net

[armedbear-ticket] [armedbear] #19: SLIME from CVS HEAD needs 'with-mutex.lisp'
by armedbear 04 Oct '10

04 Oct '10

#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

1 4

[armedbear-ticket] [armedbear] #59: Add extensible sequences to ABCL
by armedbear 04 Oct '10

04 Oct '10

#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

1 3

[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] #38: CLOS :metaclass support
by armedbear 07 May '10

07 May '10

#38: CLOS :metaclass support ------------------------+--------------------------------------------------- Reporter: ehuelsmann | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: component1 | Version: Keywords: | ------------------------+--------------------------------------------------- Blake McBride reports: Running the code: (defclass meta-class1 (standard-class) (cv1 cv2 cv3) (:metaclass standard-class)) (defclass class1 (standard-object) (iv1 iv2 iv3) (:metaclass meta-class1)) The second object returns: #<STANDARD-CLASS CLASS1 {F673CC}> It should be: #<META-CLASS1 CLASS1 {F673CC}> Not only is it reporting the wrong class of class1 but it doesn't work either. I suppose ABCL doesn't support the :metaclass option. It just ignores it. The problem is that without that option ABCL's CLOS is severely limited. Any plans to fix this? Thanks. Blake McBride -- Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/38> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 10

[armedbear-ticket] [armedbear] #79: Identically named gensymed coalesced into same object in fasl file
by armedbear 02 May '10

02 May '10

#79: Identically named gensymed coalesced into same object in fasl file -------------------------+-------------------------------------------------- Reporter: trittweiler | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: CLOS | Version: Keywords: | -------------------------+-------------------------------------------------- From: Erik Huelsmann Date: Mon, Jan 11, 2010 at 11:40 PM Subject: Re: [armedbear-devel] [Bug] Identically named gensymed coalesced into same object in fasl file To: "Tobias C. Rittweiler" Hi Tobias, Thanks for your report. This issue has long been in ABCL and it's not fixed yet. I have known about this problem for a while, but was kind of hoping it wouldn't show up in practice. I guess it did. This is what happens: when reading, the fasl loader creates an anonymous package in which it interns uninterned symbols. It "has" to do that, because ABCL doesn't store references to the actual unique objects everywhere; instead it stores the textual representation in some places. These symbols get coalesced by use of the anonymous package. So, generally the system of coalescing is something inherent to this idea. The idea is wrong enough for you to run into and get bitten by it. We'll have to come up with a better idea. Can you add the mail message below to our issue tracker? BTW: Did you happen to find this issue by accident? How did you find it? Bye, Erik. On Mon, Jan 11, 2010 at 10:35 PM, Tobias C. Rittweiler wrote: > > I'm currently running an old checkout ("0.17.0-dev"), so the issue may > have been fixed meanwhile. > > ### /tmp/foo.lisp > (eval-when (:load-toplevel :execute) > (let ((a '#:foo) > (b '#:foo)) > (setf (fdefinition 'foo) (lambda () (values a b))))) > > (eval-when (:load-toplevel :execute) > (format t "~&(multiple-value-call #'eq (foo)) => ~S~%" > (multiple-value-call #'eq (foo)))) > ### > > CL-USER> (compile-file "/tmp/foo.lisp") > ; Compiling /tmp/foo.lisp ... > ; (LET (# #) ...) > ; (FORMAT T ...) > > ; Compilation unit finished > ; The following functions were used but not defined: > ; FOO > > ; Wrote /tmp/foo.abcl (0.034 seconds) > #P"/tmp/foo.abcl" > NIL > NIL > > That warning is bogus. There some work in this area so this bit may be > fixed already. > > The actual issue of my mail is this one, though: > > CL-USER> (load *) > (multiple-value-call #'eq (foo)) => T > T > > As you can see, ABCL coalesces the two identical named gensyms into the > same object in the fasl file. > > While 3.2.4.2.2 does specify that > > Two apparently uninterned symbols S and C are similar if their names > are similar. > > ABCL's behavior is still wrong because 3.2.4.1 says > > If two literal objects appearing in the source code for a single file > processed with the file compiler are the [sic] identical, the > corresponding objects in the compiled code must also be the > identical. __With the exception of symbols and packages__, any two > literal objects in code being processed by the file compiler may be > coalesced if and only if they are similar; __if they are either both > symbols or both packages, they may only be coalesced if and only if > they are identical__. > > -T. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/79> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 4

[armedbear-ticket] [armedbear] #86: No restarts available on error in thread
by armedbear 09 Apr '10

09 Apr '10

#86: No restarts available on error in thread ------------------------+--------------------------------------------------- Reporter: ehuelsmann | Owner: nobody Type: defect | Status: new Priority: major | Milestone: 0.19 Component: libraries | Version: Keywords: | ------------------------+--------------------------------------------------- Evaluating the following (threads:make-thread #'(lambda () (error "foof")) :name "foof") will get you into the debugger. But there's not restart available. As it does not make sense to provide a RETURN-TO-TOPLEVEL restart for an error occuring in a thread, I think there should be a TERMINATE-THREAD restart instead. And the debugger should probably print the thread's name the error occured in. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/86> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 4

[armedbear-ticket] [armedbear] #45: Support for passing unboxed arguments to local functions
by armedbear 15 Mar '10

15 Mar '10

#45: Support for passing unboxed arguments to local functions -------------------------+-------------------------------------------------- Reporter: ehuelsmann | Owner: ehuelsmann Type: enhancement | Status: new Priority: major | Milestone: Component: compiler | Version: Keywords: | -------------------------+-------------------------------------------------- It would save a great deal of boxing/unboxing, if local functions and self-calling recursive functions could pass and return unboxed values. Although passing unboxed values from the outside world is generally considered 'dependency on implementation details', recursive calls and calls to local functions should be able to depend on this: they get recompiled upon function redefinition anyway. One of the reasons for this ticket: with the improved type-derivations in Jan/Feb 2009, the cl-bench TAK test deteriorated: more boxing was performed. With this change, the (un)boxing can be eliminated, except for the first call (from the outside world). -- Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/45> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 3

[armedbear-ticket] [armedbear] #70: Unboxing of simple strings / vectors
by armedbear 15 Mar '10

15 Mar '10

#70: Unboxing of simple strings / vectors -------------------------+-------------------------------------------------- Reporter: ehuelsmann | Owner: ehuelsmann Type: defect | Status: new Priority: major | Milestone: Component: compiler | Version: Keywords: performance | -------------------------+-------------------------------------------------- When so declared, simple strings and vectors can be unboxed to allow faster access. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/70> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 1

[armedbear-ticket] [armedbear] #44: Unboxing of local variables with :float and :double representations
by armedbear 15 Mar '10

15 Mar '10

#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

1 2

[armedbear-ticket] [armedbear] #85: CL-JSON throws an error under ABCL where SBCL doesn't.
by armedbear 12 Mar '10

12 Mar '10

#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

1 4

[armedbear-ticket] [armedbear] #81: Inlining functions with &optional and other "complex" arguments
by armedbear 12 Mar '10

12 Mar '10

#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

1 1

[armedbear-ticket] [armedbear] #82: TRANSLATE-PATHNAME failure
by armedbear 04 Feb '10

04 Feb '10

#82: TRANSLATE-PATHNAME failure ------------------------------+--------------------------------------------- Reporter: mevenson | Owner: somebody Type: defect | Status: new Priority: minor | Milestone: Component: other | Version: Keywords: logical-pathname | ------------------------------+--------------------------------------------- Regression in TRANSLATE-PATHNAME (added in r12406 to testsuite)] {{{ (deftest bugs.translate-logical-pathname #| Date: Mon, 18 Jan 2010 10:51:07 -0500 Message-ID: <29af5e2d1001180751l7cf79a3ay929cef1deb9ed063(a)mail.gmail.com> Subject: Re: [armedbear-devel] translate-logical-pathname and :wild- inferiors regression From: Alan Ruttenberg <alanruttenberg(a)gmail.com> |# (progn (setf (logical-pathname-translations "ido") '((#P"IDO:IDO-CORE;**;*.*" #P"/Users/alanr/repos/infectious-disease- ontology/trunk/src/ontology/ido-core/**/*.*") (#P"IDO:IMMUNOLOGY;**;*.*" #P"/Users/alanr/repos/infectious-disease- ontology/trunk/src/ontology/immunology/**/*.*") (#P"IDO:TOOLS;**;*.*" #P"/Users/alanr/repos/infectious-disease- ontology/trunk/src/tools/**/*.*") (#P"IDO:LIB;**;*.*" #P"/Users/alanr/repos/infectious-disease- ontology/trunk/lib/**/*.*"))) (translate-pathname #P"IDO:IMMUNOLOGY;" #P"IDO:IMMUNOLOGY;**;*.*" #P"/Users/alanr/repos/infectious-disease- ontology/trunk/src/ontology/**/*.*")) #P"/users/alanr/repos/infectious-disease- ontology/trunk/src/ontology/immunology/") }}} -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/82> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 3