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

[armedbear-ticket] [armedbear] #92: Characters created with invalid code points
by armedbear 10 Apr '10

10 Apr '10

#92: Characters created with invalid code points ------------------------+--------------------------------------------------- Reporter: ehuelsmann | Owner: somebody Type: defect | Status: new Priority: major | Milestone: 0.20 Component: CLOS | Version: Keywords: | ------------------------+--------------------------------------------------- ABCL will happily create characters in the range #xD800 to #xDFFF and above #x10FFFF. These refer to invalid unicode code points and should not be allowed. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/92> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 4

[armedbear-ticket] [armedbear] #86: No restarts available on error in thread
by armedbear 09 Apr '10

09 Apr '10

#86: No restarts available on error in thread ------------------------+--------------------------------------------------- Reporter: ehuelsmann | Owner: nobody Type: defect | Status: new Priority: major | Milestone: 0.19 Component: libraries | Version: Keywords: | ------------------------+--------------------------------------------------- Evaluating the following (threads:make-thread #'(lambda () (error "foof")) :name "foof") will get you into the debugger. But there's not restart available. As it does not make sense to provide a RETURN-TO-TOPLEVEL restart for an error occuring in a thread, I think there should be a TERMINATE-THREAD restart instead. And the debugger should probably print the thread's name the error occured in. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/86> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 4

[armedbear-ticket] [armedbear] #90: resetSpecialBindings efficiency
by armedbear 27 Mar '10

27 Mar '10

#90: resetSpecialBindings efficiency -------------------------+-------------------------------------------------- Reporter: ehuelsmann | Owner: ehuelsmann Type: enhancement | Status: new Priority: major | Milestone: unscheduled Component: compiler | Version: Keywords: | -------------------------+-------------------------------------------------- The code {{{ (PROGN (DEFVAR *X*) (DEFUN F (*X*) (LET (*X*) (PRINT "OK")))) }}} will compile 2 specials-restoring blocks after the PRINT form: one for LET and one for the function argument list. If the function indicated to the body that it would be clearing the specials, the LET form could skip that action (being the last form in the body), reducing the number of CATCH/THROWs in case of non-local exits and the number of resetSpecialBindings() calls in case of normal exits. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/90> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 0

[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

Re: [armedbear-ticket] [armedbear] #5: CLOS reimplementation to support a MOP (preferably AMOP)
by armedbear 15 Mar '10

15 Mar '10

#5: CLOS reimplementation to support a MOP (preferably AMOP) --------------------------+------------------------------------------------- Reporter: ehuelsmann | Owner: somebody Type: enhancement | Status: new Priority: major | Milestone: too-vague Component: other | Version: Resolution: | Keywords: --------------------------+------------------------------------------------- Changes (by ehuelsmann): * milestone: => too-vague Old description: > Well, the subject says it all: the CLOS implementation doesn't support > much of a MOP, which makes it impossible for Closer to run. Some (very > interesting) projects require Closer to run (portably). New description: Well, the subject says it all: the CLOS implementation doesn't support much of a MOP, which makes it impossible for Closer to run. Some (very interesting) projects require Closer to run (portably). -- -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/5#comment:1> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 0

[armedbear-ticket] [armedbear] #87: input history for REPL
by armedbear 15 Mar '10

15 Mar '10

#87: input history for REPL -------------------------+-------------------------------------------------- Reporter: trittweiler | Owner: somebody Type: enhancement | Status: new Priority: minor | Milestone: Component: other | Version: Keywords: repl | -------------------------+-------------------------------------------------- Would be nice to use http://jline.sourceforge.net/ for getting an input history and tab completion for the REPL. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/87> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 1

[armedbear-ticket] [armedbear] #85: CL-JSON throws an error under ABCL where SBCL doesn't.
by armedbear 12 Mar '10

12 Mar '10

#85: CL-JSON throws an error under ABCL where SBCL doesn't. ------------------------+--------------------------------------------------- Reporter: ehuelsmann | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: other | Version: Keywords: | ------------------------+--------------------------------------------------- The code is: (require 'asdf) (asdf:operate 'asdf:load-op :cl-json) (json:decode-json-from-string "{\"foo\": [10,20,50], \"bar\": true}") The error message is: The value 50 is not of type CONS. I'm using Yason as a work-around, but thought that you guys might want to know, maybe this points to a deeper issue. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/85> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 4

[armedbear-ticket] [armedbear] #81: Inlining functions with &optional and other "complex" arguments
by armedbear 12 Mar '10

12 Mar '10

#81: Inlining functions with &optional and other "complex" arguments -------------------------+-------------------------------------------------- Reporter: ehuelsmann | Owner: ehuelsmann Type: enhancement | Status: new Priority: major | Milestone: 0.20 Component: compiler | Version: Keywords: | -------------------------+-------------------------------------------------- Currently we only inline functions which have only required parameters. With a little bit more intelligence we could easily inline functions with optional parameters. With a bit more intelligence than that, we can even inline functions with &keyword and &rest parameters. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/81> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 1