#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
#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
#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
#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
#48: SLIME CVS HEAD as of 2008-12-30 broken
-------------------------------------+--------------------------------------
Reporter: mevenson | Owner: mevenson
Type: defect | Status: new
Priority: major | Milestone: 0.13
Component: other | Version: 1.0
Keywords: slime emacs application |
-------------------------------------+--------------------------------------
Symptom is the failed listening to SlimeInputStream that doesn't detect a
pipe close, therefore never closes, so further enviornment bindings are
incorrect.
*inferior-lisp* buffers needs to evaluate a form before SLIME works
properly.
Something messed up in the Stream ._finishOuput() calls??
--
Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/48>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#54: pprint.lisp incompatible with gray-streams.lisp
------------------------+---------------------------------------------------
Reporter: ehuelsmann | Owner: somebody
Type: defect | Status: new
Priority: major | Milestone:
Component: other | Version:
Keywords: |
------------------------+---------------------------------------------------
pprint.lisp special-cases the XP-STRUCTURE argument type for the stream
argument specified to all the stream functions.
Although SBCL uses largely the same approach, it uses a (slightly)
different approach, which is important in the details. (Isn't that where
the devil usually is?)
The difference between ABCL and SBCL is that SBCL - although it uses
largely the same structure to store its pprinter values - this structure
extends the structure which is used to represent streams. In ABCL, this
structure is a structure by itself. To compensate for the fact that the
structure isn't recognised as a stream itself, all stream functions
special case the XP-STRUCTURE argument handling.
Proposed solution: make streams based on dispatch tables stored in
structures, just as SBCL does. This way, most of our streams "stuff" can
be implemented in Lisp, instead of Java. As a bonus, this issue can be
resolved along the same lines as SBCL does.
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/54>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#49: Support loading of compiled functions off byte arrays
-------------------------+--------------------------------------------------
Reporter: ehuelsmann | Owner: somebody
Type: enhancement | Status: new
Priority: major | Milestone:
Component: other | Version:
Keywords: |
-------------------------+--------------------------------------------------
loadCompiledFunction() in Lisp.java loads bytes out of a file, then loads
the "class-bytes" off the resulting byte array. The result being a loaded
class.
The goal of this issue is to expose this interface in order to eliminate
the need for the compiler to write compiled functions out to files before
loading them into the JVM.
--
Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/49>
armedbear <http://common-lisp.net/project/armedbear>
armedbear