December 2009 - armedbear-ticket - mailman3.common-lisp.net

[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] #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] #45: Support for passing unboxed arguments to local functions
by armedbear 15 Mar '10

15 Mar '10

#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

1 3

[armedbear-ticket] [armedbear] #70: Unboxing of simple strings / vectors
by armedbear 15 Mar '10

15 Mar '10

#70: Unboxing of simple strings / vectors -------------------------+-------------------------------------------------- Reporter: ehuelsmann | Owner: ehuelsmann Type: defect | Status: new Priority: major | Milestone: Component: compiler | Version: Keywords: performance | -------------------------+-------------------------------------------------- When so declared, simple strings and vectors can be unboxed to allow faster access. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/70> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 1

[armedbear-ticket] [armedbear] #44: Unboxing of local variables with :float and :double representations
by armedbear 15 Mar '10

15 Mar '10

#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

1 2

[armedbear-ticket] [armedbear] #48: SLIME CVS HEAD as of 2008-12-30 broken
by armedbear 05 Jan '10

05 Jan '10

#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

1 2

[armedbear-ticket] [armedbear] #75: Character \U0080 causes infinite loop
by armedbear 01 Jan '10

01 Jan '10

#75: Character \U0080 causes infinite loop ------------------------+--------------------------------------------------- Reporter: ehuelsmann | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: CLOS | Version: Keywords: | ------------------------+--------------------------------------------------- The following code causes an infinite loop on systems which do not support character \U0080 in their default output character set: (defparameter single-character-symbols '#.(let ((a (make-array 129))) (dotimes (i 129) (setf (svref a i) (make-string 1 :initial-element (code-char i)))) a)) -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/75> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 3

[armedbear-ticket] [armedbear] #71: Stream line counter broken
by armedbear 01 Jan '10

01 Jan '10

#71: Stream line counter broken ------------------------+--------------------------------------------------- Reporter: ehuelsmann | Owner: nobody Type: defect | Status: new Priority: major | Milestone: 0.18 Component: libraries | Version: Keywords: | ------------------------+--------------------------------------------------- Line numbers generated for functions (top-level forms) in compiled code are way off - sometimes. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/71> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 1

[armedbear-ticket] [armedbear] #72: Faster startup times
by armedbear 30 Dec '09

30 Dec '09

#72: Faster startup times -------------------------+-------------------------------------------------- Reporter: ehuelsmann | Owner: somebody Type: enhancement | Status: new Priority: major | Milestone: Component: other | Version: Keywords: performance | -------------------------+-------------------------------------------------- Analysis learned that 40% of the execution time spent loading ABCL was spent finding constructors in the Java reflection code. The idea of this issue is to spread the cost of that 40% better over the life time of the application by loading - but not resolving - function classes until they're actually used, by introducing a proxy object of some kind which holds only the byte array of class bytes. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/72> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 1

[armedbear-ticket] [armedbear] #64: Caught (general) exceptions not rethrown everywhere
by armedbear 30 Dec '09

30 Dec '09

#64: Caught (general) exceptions not rethrown everywhere ------------------------+--------------------------------------------------- Reporter: ehuelsmann | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: other | Version: Keywords: | ------------------------+--------------------------------------------------- The code base uses exceptions derived from ConditionThrowable (Go, Throw, Return) to cause non-local transfers of control. A special exception (ThreadDestroyed) has been derived to cause a jump to the outer-most function in a LispThread. (This doesn't work in the main thread, which isn't enclosed by a function in LispThread like those in other threads.) Some spots in our code seem to discard other exceptions than the ones mentioned above. That's probably wrong in most cases. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/64> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 2

Re: [armedbear-ticket] [armedbear] #14: Support for a C-calling FFI for CFFI to build upon
by armedbear 14 Dec '09

14 Dec '09

#14: Support for a C-calling FFI for CFFI to build upon --------------------------+------------------------------------------------- Reporter: ehuelsmann | Owner: mevenson Type: enhancement | Status: assigned Priority: major | Milestone: Component: other | Version: Resolution: | Keywords: --------------------------+------------------------------------------------- Changes (by mevenson): * owner: somebody => mevenson * status: new => assigned Comment: It looks like Luís Oliveira has [done the hard work][1]. Not sure what the best way to support this in ABCL would be. Maybe I should really start mirroring ASDF packages with ABCL-specific patches until we get those patches merged upstream. But then I would like to ABCL's support for ASDF up to current by implementing the long form of CLOS's DEFINE-METHOD-COMBINATION. Chicken, meet egg. [1]: http://common-lisp.net/~loliveira/patches/cffi-abcl.diff -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/14#comment:3> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 0