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

[armedbear-ticket] [armedbear] #119: Unexpected CLOS shared slot initialization order
by armedbear 26 Jan '11

26 Jan '11

#119: Unexpected CLOS shared slot initialization order --------------------------------------+------------------------------------- Reporter: mevenson | Owner: analysis Type: defect | Status: new Priority: major | Milestone: unscheduled Component: CLOS | Version: 1.0 Keywords: clos unexpected-behavior | --------------------------------------+------------------------------------- Didier Verner writes: {{{ it seems that until now, I've been relying on a non-standard behavior, namely the fact that shared slots with an :initform are initialized before the first actual class instance is created: (defclass test () ((slot :allocation :class :initform t))) (defmethod initialize-instance :before ((test test) &key) (format t "Slot boundp: ~A~%" (slot-boundp test 'slot))) CL-USER> (make-instance 'test) Slot boundp: NIL #<TEST {C5D3B8}> CL-USER> (make-instance 'test) Slot boundp: T #<TEST {14563D4}> CL-USER> I just fell on this because every other Common Lisp implementation I've tried gives T and T here. Is it due to the way CLOS is implemented in ABCL, and is there a chance that this can be improved? }}} -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/119> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 3

[armedbear-ticket] [armedbear] #18: Incorporate 'invoke.lisp' dynamic classpath ability
by armedbear 23 Jan '11

23 Jan '11

#18: Incorporate 'invoke.lisp' dynamic classpath ability -------------------------+-------------------------------------------------- Reporter: mevenson | Owner: somebody Type: enhancement | Status: new Priority: minor | Milestone: Component: component1 | Version: Keywords: | -------------------------+-------------------------------------------------- Alan Ruttenberg's [invoke.lisp][1] has the ability to easily add additional Java JARs at runtime by using the [beanshell classloader][2]. With a few additions to the ASDF system, this allows one to easily specify "wrappings" of Java components which load JARs or find classfiles on the filesystem. The code in the Beanshell classmanager could be added to the ABCL src tree fairly easily to facilitate this behavior. [1]: http://svn.mumble.net:8080/svn/lsw/trunk/jss/invoke.lisp [2]: http://www.beanshell.org/home.html -- Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/18> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 2

[armedbear-ticket] [armedbear] #109: When TPL::REPL is unavailable, the debugger kills the entire application
by armedbear 23 Jan '11

23 Jan '11

#109: When TPL::REPL is unavailable, the debugger kills the entire application ------------------------+--------------------------------------------------- Reporter: ehuelsmann | Owner: nobody Type: defect | Status: new Priority: major | Milestone: Component: libraries | Version: Keywords: | ------------------------+--------------------------------------------------- Ole Myren Rohne reports: "" I'm playing with AbclScriptEngine (with Electric VLSI) and found a tiny problem with config.lisp: EXT:MAKE-THREAD should be THREADS:MAKE-THREAD. "" which is already solved, but continues: Unfortunately the problem was unnecessary hard to debug because in the absence of TPL::REPL the debugger ends up quitting the entire application. I'm wondering if in that case it would be more useful to throw a Java error, eg like SYS::%DEBUGGER-HOOK-FUNCTION? That's what this ticket is about. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/109> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 3

[armedbear-ticket] [armedbear] #117: Compiler stack inconsistency
by armedbear 01 Jan '11

01 Jan '11

#117: Compiler stack inconsistency ----------------------+----------------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: new Priority: major | Milestone: unscheduled Component: compiler | Version: 0.23 Keywords: | ----------------------+----------------------------------------------------- In compiling Alexandria from its git repository, I isolated the following case where the compiler fails by detecting a stack inconsistency: {{{ ;;; Stack inconsistency detected in NIL at index 240: found 4, expected 1. (mapcar (lambda (x) (handler-case (elt x 0) (type-error () :type-error))) (list nil #() 3)) }}} -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/117> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 1