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

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

[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] #104: SET works with symbols defined with DEFCONSTANT
by armedbear 30 Sep '10

30 Sep '10

#104: SET works with symbols defined with DEFCONSTANT -------------------------+-------------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: new Priority: major | Milestone: unscheduled Component: interpreter | Version: 0.22 Keywords: | -------------------------+-------------------------------------------------- Something is wonky about symbols defined with DEFCONSTANT: {{{ CL-USER> (defconstant +xx+ nil) +XX+ CL-USER> +xx+ NIL CL-USER> (setf +xx+ 53) ; Evaluation aborted. CL-USER> (set (intern "+XX+") 42) 42 CL-USER> +xx+ 42 }}} -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/104> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 1

[armedbear-ticket] [armedbear] #102: Wrapper scripts should honor CLASSPATH environment variables.
by armedbear 29 Aug '10

29 Aug '10

#102: Wrapper scripts should honor CLASSPATH environment variables. -------------------------------------------+-------------------------------- Reporter: mevenson | Owner: mevenson Type: defect | Status: new Priority: major | Milestone: 0.21 Component: other | Version: 1.0 Keywords: wrapper envrionment classpath | -------------------------------------------+-------------------------------- If the UNIX shell script 'abcl', or the DOS batch script 'abcl.bat' are executed in an envrionment where there is a variable named 'CLASSPATH' set, at least add the entries on the classpath. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/102> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 3

[armedbear-ticket] [armedbear] #103: DOCUMENTATION doesn't seem to autoload properly
by armedbear 28 Aug '10

28 Aug '10

#103: DOCUMENTATION doesn't seem to autoload properly --------------------------+------------------------------------------------- Reporter: vvoutilainen | Owner: nobody Type: defect | Status: new Priority: minor | Milestone: 0.22 Component: libraries | Version: 0.21 Keywords: autoload | --------------------------+------------------------------------------------- Here's a transcript from my repl session: CL-USER(1): (documentation 'append 'function) #<THREAD "interpreter" {9260EE}>: Debugger invoked on condition of type UNDEFINED-FUNCTION The function DOCUMENTATION is undefined. Restarts: 0: CONTINUE Try again. 1: USE-VALUE Specify a function to call instead. 2: RETURN-VALUE Return one or more values from the call to DOCUMENTATION. 3: TOP-LEVEL Return to top level. [1] CL-USER(2): (documentation 'append 'function) NIL DOCUMENTATION seems to load after the initial error, but if it's the first function invoked in the REPL, it doesn't seem to quite work. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/103> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 2