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

[armedbear-ticket] [armedbear] #69: Gray stream compatibility
by armedbear 28 Apr '11

28 Apr '11

#69: Gray stream compatibility ---------------------------+------------------------------------------------ Reporter: ehuelsmann | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: other | Version: Keywords: compatibility | ---------------------------+------------------------------------------------ The last thing holding us back from being fully Gray stream compatible, is that TYPEP should return T for any fundamental-stream derived instance when tested against 'STREAM or (find-class 'STREAM). -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/69> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 6

[armedbear-ticket] [armedbear] #123: REGISTER-JAVA-EXCEPTION failing
by armedbear 14 Feb '11

14 Feb '11

#123: REGISTER-JAVA-EXCEPTION failing ------------------------+--------------------------------------------------- Reporter: ehuelsmann | Owner: nobody Type: defect | Status: new Priority: major | Milestone: Component: java | Version: Keywords: | ------------------------+--------------------------------------------------- William writes: Hi, I am trying to register Java exceptions using REGISTER-JAVA-EXCEPTION but it does not seem to work for me as evidenced by the transcript below. Is there anything that I may have missed? Armed Bear Common Lisp 0.23.1 Java 1.6.0_20 Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.354 seconds. Startup completed in 1.579 seconds. Type ":help" for a list of available commands. CL-USER(1): (define-condition java-illegal-argument-error (java-exception) ()) JAVA-ILLEGAL-ARGUMENT-ERROR CL-USER(2): (register-java-exception "java.lang.IllegalArgumentException" 'java-illegal-argument-error) NIL -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/123> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 4

[armedbear-ticket] [armedbear] #67: initarg checking performance
by armedbear 13 Feb '11

13 Feb '11

#67: initarg checking performance -------------------------+-------------------------------------------------- Reporter: ehuelsmann | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: CLOS | Version: Keywords: performance | -------------------------+-------------------------------------------------- Our initarg checking strictness has improved (used to be non-existent), but we've seen a rather large performance hit, amongst other things upon object instantiation (make-instance). Functions involved (?): ALLOCATE-INSTANCE INITIALIZE-INSTANCE REINITIALIZE-INSTANCE SHARED-INITIALIZE UPDATE-INSTANCE-FOR-DIFFERENT-CLASS UPDATE-INSTANCE-FOR-REDEFINED-CLASS -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/67> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 5

[armedbear-ticket] [armedbear] #83: problem with error reporting on undefined class during make instance
by armedbear 13 Feb '11

13 Feb '11

#83: problem with error reporting on undefined class during make instance ------------------------+--------------------------------------------------- Reporter: ehuelsmann | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: CLOS | Version: Keywords: | ------------------------+--------------------------------------------------- CL-USER(25): (defclass c (d) ((q :initarg :q))) #<STANDARD-CLASS C {B5BEE0}> CL-USER(26): (make-instance 'c :q t) Debugger invoked on condition of type PROGRAM-ERROR: Invalid initarg :Q. The error should say instead something about d not being defined. This in build of a freshly updated trunk abcl -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/83> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 5

[armedbear-ticket] [armedbear] #125: Qi loading issues
by armedbear 27 Jan '11

27 Jan '11

#125: Qi loading issues ------------------------+--------------------------------------------------- Reporter: ehuelsmann | Owner: nobody Type: defect | Status: new Priority: major | Milestone: Component: libraries | Version: 0.24 Keywords: | ------------------------+--------------------------------------------------- Greg Baryza writes: {{{ I recently became interested in the language QI. Since it did not run on ABCL (it does on SBCL, Allegro, LispWorks and others), I decided to see what it would take to move it there. From the QI mailing list, I found several others had tried on earlier versions of ABCL with inconclusive results. I decided to give it a try on 0.23.1. When I tried the standard script with compiles and then loads the compiled files, ABCL hangs it what appears to be an infinite loop try to load one of the compiled files. When I switch to just loading them in as Lisp sources, things seem to work (though some of the QI tests later fail). I tried the compile/load script under 0.24.0 today and the same hang happens. }}} -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/125> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 2

[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