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