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

[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

Re: [armedbear-ticket] [armedbear] #15: compilation of forms with keywords having the same name as special variables fails
by armedbear 04 Oct '10

04 Oct '10

#15: compilation of forms with keywords having the same name as special variables fails -----------------------+---------------------------------------------------- Reporter: mevenson | Owner: somebody Type: defect | Status: closed Priority: major | Milestone: 0.22 Component: other | Version: 1.0 Resolution: fixed | Keywords: compiler -----------------------+---------------------------------------------------- Changes (by ehuelsmann): * milestone: unscheduled => 0.22 Comment: Selecting no particular closed milestone: it's in unscheduled, which is definitely incorrect. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/15#comment:2> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 0

[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] #107: (setf (values (struct-slot struct)) (values 42)) fails
by armedbear 02 Oct '10

02 Oct '10

#107: (setf (values (struct-slot struct)) (values 42)) fails -------------------------------------+-------------------------------------- Reporter: mmohamed | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: CLOS | Version: Keywords: SETF VALUES STRUCT-SLOT | -------------------------------------+-------------------------------------- ;;; reported by Zach Beane ;;; http://common-lisp.net/pipermail/armedbear- devel/2010-October/001521.html Here's a file that triggers an ABCL bug: ;;;; abcl-bug.lisp (defpackage #:abcl-bug (:use #:cl) (:export #:trigger)) (in-package #:abcl-bug) (defstruct mystruct slot) (defun trigger () (let ((struct (make-mystruct))) (setf (values (mystruct-slot struct)) (values 42)) struct)) Here's what happens when I run it: Armed Bear Common Lisp 0.22.0 Java 1.6.0_18 Sun Microsystems Inc. OpenJDK 64-Bit Server VM Low-level initialization completed in 0.445 seconds. Startup completed in 1.688 seconds. Type ":help" for a list of available commands. CL-USER(1): (load (compile-file "abcl-bug")) ; Compiling /tmp/abcl-bug.lisp ... ; (DEFPACKAGE #:ABCL-BUG ...) ; (IN-PACKAGE #:ABCL-BUG) ; (DEFSTRUCT MYSTRUCT ...) ; (DEFUN TRIGGER ...) ; Wrote /tmp/abcl-bug.abcl (0.447 seconds) T CL-USER(2): (abcl-bug:trigger) #<THREAD "interpreter" {1653033E}>: Debugger invoked on condition of type UNDEFINED-FUNCTION The function (SETF SYSTEM:STRUCTURE-REF) is undefined. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(3): :bt 0: (SYSTEM:BACKTRACE) 1: (INVOKE-DEBUGGER #<UNDEFINED-FUNCTION {8FE2509}>) 2: org.armedbear.lisp.Lisp.error(Lisp.java:353) 3: org.armedbear.lisp.Symbol.getSymbolSetfFunctionOrDie(Symbol.java:399) 4: org.armedbear.lisp.abcl_bug_9.execute(abcl-bug.lisp:11) 5: org.armedbear.lisp.LispThread.execute(LispThread.java:552) 6: org.armedbear.lisp.Lisp.evalCall(Lisp.java:514) 7: org.armedbear.lisp.Lisp.eval(Lisp.java:485) [1] CL-USER(4): I would expect to get a structure back with SLOT set to 42, instead of this error. This is a strange case (you normally wouldn't use VALUES there) but it comes from some larger real code that sets multiple struct slots from a multiple-value-returning function. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/107> 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] #106: DEFSTRUCT :include with :conc-name
by armedbear 01 Oct '10

01 Oct '10

#106: DEFSTRUCT :include with :conc-name ------------------------+--------------------------------------------------- Reporter: ehuelsmann | Owner: nobody Type: defect | Status: new Priority: major | Milestone: Component: libraries | Version: Keywords: | ------------------------+--------------------------------------------------- Juliusz Chroboczek Juliusz.Chroboczek at pps-jussieu-fr writes Consider the following: (defstruct item a) (defstruct (item1 (:include item) (:conc-name item-)) b) (defun abcl-bug () (item-a (make-item :a 'a))) According to the last paragraph of the description of the description of :conc-name in the defstruct section of the CLHS, this is legal. However, abcl says: ABCL-BUG(6): (abcl-bug) #<THREAD "interpreter" {108F8E0}>: Debugger invoked on condition of type SIMPLE-TYPE-ERROR The value #<ABCL-BUG::ITEM {537935}> is not of type ABCL-BUG::ITEM1. Restarts: 0: TOP-LEVEL Return to top level. [1] ABCL-BUG(7): The section he's referring to is this bit which is part of the DEFSTRUCT documentation for the :conc-name keyword argument: Whether or not the :conc-name option is explicitly supplied, the following rule governs name conflicts of generated reader (or accessor) names: For any structure type S1 having a reader function named R for a slot named X1 that is inherited by another structure type S2 that would have a reader function with the same name R for a slot named X2, no definition for R is generated by the definition of S2; instead, the definition of R is inherited from the definition of S1. (In such a case, if X1 and X2 are different slots, the implementation might signal a style warning.) -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/106> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 1

Re: [armedbear-ticket] [armedbear] #17: SLIME: Invoking TOP-LEVEL restart always terminates connection
by armedbear 01 Oct '10

01 Oct '10

#17: SLIME: Invoking TOP-LEVEL restart always terminates connection -----------------------+---------------------------------------------------- Reporter: mevenson | Owner: somebody Type: defect | Status: closed Priority: minor | Milestone: unscheduled Component: other | Version: Resolution: invalid | Keywords: -----------------------+---------------------------------------------------- Comment(by mevenson): Verified that this problem is no longer occurring with contemporary ABCL/SLIME versions, with the TOP-LEVEL restart having been renamed to appear as "*ABORT". Probably this was more a problem on the SLIME end of things that has changed. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/17#comment:4> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 0

Re: [armedbear-ticket] [armedbear] #17: SLIME: Invoking TOP-LEVEL restart always terminates connection
by armedbear 01 Oct '10

01 Oct '10

#17: SLIME: Invoking TOP-LEVEL restart always terminates connection -----------------------+---------------------------------------------------- Reporter: mevenson | Owner: somebody Type: defect | Status: closed Priority: minor | Milestone: unscheduled Component: other | Version: Resolution: invalid | Keywords: -----------------------+---------------------------------------------------- Changes (by ehuelsmann): * cc: trittweiler (added) * status: new => closed * resolution: => invalid Comment: The TOP-LEVEL restart can be circumvented by starting ABCL with an --eval or --load argument instead of piping the SWANK startup commands into it. I don't really think there's an issue here. Please reopen if there actually is - detailing the exact error condition or reason why SLIME can't use the --eval or --load route. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/17#comment:3> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 0

[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