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

[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] #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

[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] #93: reader does not respect (values) from reader macros
by armedbear 01 May '10

01 May '10

#93: reader does not respect (values) from reader macros -----------------------+---------------------------------------------------- Reporter: janderson | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: other | Version: 0.19 Keywords: | -----------------------+---------------------------------------------------- the hyperspec includes an example which illustrates the effect of (values) for a reader macro(1) as of 0.19.1 the reader treats (values) as nil. [1] CL-USER(3): (set-macro-character #\! #'(lambda (stream char) (declare (ignore char)) (read stream) (values))) T [1] CL-USER(4): (list 1 !qwer 2) (1 NIL 2) [1] CL-USER(5): (lisp-implementation-version) "0.19.1" [1] CL-USER(6): asdf@ip-10-251-122-82:/development/source/metadata/net /common-lisp/bordeaux-threads$ ccl Welcome to Clozure Common Lisp Version 1.4-r13119 (LinuxX8632)! ? (set-macro-character #\! #'(lambda (stream char) (declare (ignore char)) (read stream) (values))) T ? (list 1 !qwer 2) (1 2) ? --- (1) http://www.lispworks.com/documentation/HyperSpec/Body/f_set_ma.htm -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/93> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 2