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

[armedbear-ticket] [armedbear] #126: Provide mechanism for user to extend Java classes via Lisp
by armedbear 01 Feb '11

01 Feb '11

#126: Provide mechanism for user to extend Java classes via Lisp ----------------------+----------------------------------------------------- Reporter: mevenson | Owner: nobody Type: task | Status: new Priority: minor | Milestone: unscheduled Component: java | Version: 1.0 Keywords: | ----------------------+----------------------------------------------------- [http://stackoverflow.com/questions/4785969/can-you-write-a-java-class- with-abcl/4803353#4803353 In a question on StackOverflow] a user asks if it is possible to extend a Java class in Lisp. This sort of functionality generally seems to be unavailable in any JVM language, only possible by using bytecode libraries. Since we have a fairly complete bytecode library in our Java class writer, it might provide a distinguishing feature to implement such an extension mechanism. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/126> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 1

[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

[armedbear-ticket] [armedbear] #114: Strange backtrace growth
by armedbear 28 Dec '10

28 Dec '10

#114: Strange backtrace growth ------------------------+--------------------------------------------------- Reporter: ehuelsmann | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: other | Version: Keywords: | ------------------------+--------------------------------------------------- Armed Bear Common Lisp 0.23.0-dev Java 1.5.0_11 Sun Microsystems Inc. Java HotSpot(TM) Server VM Low-level initialization completed in 0.71 seconds. Startup completed in 2.53 seconds. Type ":help" for a list of available commands. CL-USER(1): foo #<THREAD "interpreter" {6D3B92}>: Debugger invoked on condition of type UNBOUND-VARIABLE The variable FOO is unbound. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(2): :bt 100 0: (SYSTEM:BACKTRACE) 1: (INVOKE-DEBUGGER #<UNBOUND-VARIABLE FOO {388C74}>) 2: org.armedbear.lisp.Lisp.pushJavaStackFrames(Lisp.java:332) 3: org.armedbear.lisp.Lisp.error(Lisp.java:353) 4: org.armedbear.lisp.Lisp.eval(Lisp.java:457) 5: org.armedbear.lisp.Primitives$pf__eval.execute(Primitives.java:343) 6: (SYSTEM::%EVAL FOO) 7: (EVAL FOO) 8: (SYSTEM:INTERACTIVE-EVAL FOO) 9: (TOP-LEVEL::REPL) 10: (TOP-LEVEL::TOP-LEVEL-LOOP)[1] CL-USER(3): 0 CL-USER(4): foo #<THREAD "interpreter" {6D3B92}>: Debugger invoked on condition of type UNBOUND-VARIABLE The variable FOO is unbound. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(5): :bt 100 0: (SYSTEM:BACKTRACE) 1: (INVOKE-DEBUGGER #<UNBOUND-VARIABLE FOO {1E492D8}>) 2: org.armedbear.lisp.Lisp.pushJavaStackFrames(Lisp.java:332) 3: org.armedbear.lisp.Lisp.error(Lisp.java:353) 4: org.armedbear.lisp.Lisp.eval(Lisp.java:457) 5: org.armedbear.lisp.Primitives$pf__eval.execute(Primitives.java:343) 6: (SYSTEM::%EVAL FOO) 7: (EVAL FOO) 8: (SYSTEM:INTERACTIVE-EVAL FOO) 9: (TOP-LEVEL::REPL) 10: (SYSTEM::%EVAL FOO) 11: (EVAL FOO) 12: (SYSTEM:INTERACTIVE-EVAL FOO) 13: (TOP-LEVEL::REPL) 14: (TOP-LEVEL::TOP-LEVEL-LOOP)[1] CL-USER(6): 0 CL-USER(7): foo #<THREAD "interpreter" {6D3B92}>: Debugger invoked on condition of type UNBOUND-VARIABLE The variable FOO is unbound. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(8): :bt 100 0: (SYSTEM:BACKTRACE) 1: (INVOKE-DEBUGGER #<UNBOUND-VARIABLE FOO {164DE59}>) 2: org.armedbear.lisp.Lisp.pushJavaStackFrames(Lisp.java:332) 3: org.armedbear.lisp.Lisp.error(Lisp.java:353) 4: org.armedbear.lisp.Lisp.eval(Lisp.java:457) 5: org.armedbear.lisp.Primitives$pf__eval.execute(Primitives.java:343) 6: (SYSTEM::%EVAL FOO) 7: (EVAL FOO) 8: (SYSTEM:INTERACTIVE-EVAL FOO) 9: (TOP-LEVEL::REPL) 10: (SYSTEM::%EVAL FOO) 11: (EVAL FOO) 12: (SYSTEM:INTERACTIVE-EVAL FOO) 13: (TOP-LEVEL::REPL) 14: (SYSTEM::%EVAL FOO) 15: (EVAL FOO) 16: (SYSTEM:INTERACTIVE-EVAL FOO) 17: (TOP-LEVEL::REPL) 18: (TOP-LEVEL::TOP-LEVEL-LOOP)[1] CL-USER(9): 0 CL-USER(10): -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/114> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 2

[armedbear-ticket] [armedbear] #108: ASDF-INSTALL fails to download
by armedbear 19 Nov '10

19 Nov '10

#108: ASDF-INSTALL fails to download --------------------------+------------------------------------------------- Reporter: mevenson | Owner: nobody Type: defect | Status: new Priority: major | Milestone: unscheduled Component: libraries | Version: 0.22 Keywords: ASDF-INSTALL | --------------------------+------------------------------------------------- ASDF-INSTALL is improperly casting its download streams to something other than raw bytes, causing the following sort of errors. From http://article.gmane.org/gmane.lisp.armedbear.devel/1468 {{{ I recently started using abcl 0.22.0 but have run into issues installing packages using asdf-install. Here is an example error message. Does anyone know of a solution to this? CL-USER(7): (asdf-install:install 'hunchentoot) Install where? 1) System-wide install: System in /usr/local/asdf-install/site-systems/ Files in /usr/local/asdf-install/site/ 2) Personal installation: System in /home/raison/.asdf-install-dir/systems/ Files in /home/raison/.asdf-install-dir/site/ 0) Abort installation. --> 2 ;;; ASDF-INSTALL: Downloading 139617 bytes from http://weitz.de/files/hunchentoot.tar.gz to /home/raison/asdf-install-0.asdf-install-tmp ... #<THREAD "interpreter" {4DA42824}>: Debugger invoked on condition of type STREAM-ERROR Input value 0xdc4a is malformed while recoding with charset UTF-8 Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(8): 0 CL-USER(9): }}} -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/108> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 4

[armedbear-ticket] [armedbear] #110: #\+ in cl+ssl filename confuses the compiler when looking for FASLs in jars
by armedbear 15 Nov '10

15 Nov '10

#110: #\+ in cl+ssl filename confuses the compiler when looking for FASLs in jars ----------------------+----------------------------------------------------- Reporter: charmon | Owner: ehuelsmann Type: defect | Status: new Priority: minor | Milestone: Component: compiler | Version: 0.23 Keywords: | ----------------------+----------------------------------------------------- The #\+ in cl+ssl's name confuses the compiler when attempting to ASDF :load-op cl+ccl: Here's the backtrace: Loadable FASL not found for '/Users/sly/.cache/common- lisp/armedbear-0.23.0-dev-fasl36-darwin- java-1.6/Users/sly/src/clbuild/source/cl+ssl/package.abcl' in 'jar:file:/Users/sly/.cache/common-lisp/armedbear-0.23.0-dev-fasl36 -darwin-java-1.6/Users/sly/src/clbuild/source/cl ssl/package.abcl!/package._' [Condition of type FILE-ERROR] Restarts: 0: [TRY-RECOMPILING] Recompile package and try loading it again 1: [RETRY] Retry performing #<ASDF:LOAD-OP NIL {7056C23D}> on #<ASDF:CL- SOURCE-FILE "cl+ssl" "package">. 2: [ACCEPT] Continue, treating #<ASDF:LOAD-OP NIL {7056C23D}> on #<ASDF :CL-SOURCE-FILE "cl+ssl" "package"> as having been successful. 3: [RETRY] Retry SLIME REPL evaluation request. 4: [*ABORT] Return to SLIME's top level. 5: [ABORT] Abort thread. Backtrace: 0: (#<FUNCTION {7AA93A16}> #<FILE-ERROR {50802ED1}> #<FUNCTION {7AA93A16}>) 1: (APPLY #<FUNCTION {7AA93A16}> (#<FILE-ERROR {50802ED1}> #<FUNCTION {7AA93A16}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<FILE-ERROR {50802ED1}> #<FUNCTION {7AA93A16}>) 3: (INVOKE-DEBUGGER #<FILE-ERROR {50802ED1}>) 4: org.armedbear.lisp.Lisp.error(Lisp.java:353) 5: org.armedbear.lisp.Load.load(Load.java:183) 6: org.armedbear.lisp.Load.load(Load.java:674) 7: org.armedbear.lisp.Load$_load.execute(Load.java:624) 8: org.armedbear.lisp.Symbol.execute(Symbol.java:814) 9: org.armedbear.lisp.LispThread.execute(LispThread.java:620) 10: org.armedbear.lisp.load_1.execute(load.lisp) 11: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:101) 12: org.armedbear.lisp.Symbol.execute(Symbol.java:779) 13: org.armedbear.lisp.LispThread.execute(LispThread.java:568) 14: org.armedbear.lisp.asdf_352.execute(asdf.lisp) 15: org.armedbear.lisp.clos_197.execute(clos.lisp) 16: org.armedbear.lisp.clos_176.execute(clos.lisp) 17: org.armedbear.lisp.StandardGenericFunction.execute(StandardGenericFunction.java:138) 18: org.armedbear.lisp.Symbol.execute(Symbol.java:790) 19: org.armedbear.lisp.LispThread.execute(LispThread.java:585) 20: org.armedbear.lisp.asdf_354.execute(asdf.lisp) 21: org.armedbear.lisp.LispThread.execute(LispThread.java:585) 22: org.armedbear.lisp.clos_203.execute(clos.lisp) 23: org.armedbear.lisp.LispThread.execute(LispThread.java:568) 24: org.armedbear.lisp.asdf_357.execute(asdf.lisp) 25: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:92) 26: org.armedbear.lisp.asdf_359.execute(asdf.lisp) 27: org.armedbear.lisp.LispThread.execute(LispThread.java:585) 28: org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2805) 29: (SYSTEM::%LOAD #P"/Users/sly/.cache/common-lisp/armedbear-0.23.0-dev- fasl36-darwin-java-1.6/Users/sly/src/clbuild/source/cl+ssl/package.abcl" NIL NIL T) 30: (LOAD #P"/Users/sly/.cache/common-lisp/armedbear-0.23.0-dev-fasl36 -darwin-java-1.6/Users/sly/src/clbuild/source/cl+ssl/package.abcl") 31: org.armedbear.lisp.LispThread.execute(LispThread.java:568) 32: org.armedbear.lisp.asdf_512.execute(asdf.lisp) 33: org.armedbear.lisp.Symbol.execute(Symbol.java:779) 34: org.armedbear.lisp.LispThread.execute(LispThread.java:568) 35: org.armedbear.lisp.asdf_516.execute(asdf.lisp) 36: org.armedbear.lisp.LispThread.execute(LispThread.java:585) 37: org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2805) 38: (TRUENAME #P"/Users/sly/src/clbuild/source/cl+ssl/package.abcl") 39: (#<FUNCTION {59FDEF61}>) 40: (JRUN-EXCEPTION-PROTECTED #<FUNCTION {59FDEF61}>) 41: (ASDF-UTILITIES:TRUENAMIZE #P"/Users/sly/src/clbuild/source/cl+ssl/package.abcl") 42: (ASDF:APPLY-OUTPUT-TRANSLATIONS #P"/Users/sly/src/clbuild/source/cl+ssl/package.abcl") 43: (#<FUNCTION {2E6EF76F}> #<ASDF:COMPILE-OP {7736B039}> #<ASDF:CL- SOURCE-FILE {B97CF78}>) 44: (APPLY #<FUNCTION {2E6EF76F}> (#<ASDF:COMPILE-OP {7736B039}> #<ASDF :CL-SOURCE-FILE {B97CF78}>)) 45: (ASDF:OUTPUT-FILES #<ASDF:COMPILE-OP {7736B039}> #<ASDF:CL-SOURCE- FILE {B97CF78}>) 46: (#<FUNCTION {276BAB54}> (ASDF:COMPILE-OP "package")) 47: (APPLY #<FUNCTION {276BAB54}> ((ASDF:COMPILE-OP "package"))) 48: (SYSTEM::MAP1 #<FUNCTION {276BAB54}> (((ASDF:COMPILE-OP "package"))) :NCONC T) 49: (MAPCAN #<FUNCTION {276BAB54}> ((ASDF:COMPILE-OP "package"))) 50: (ASDF:INPUT-FILES #<ASDF:LOAD-OP {7056C23D}> #<ASDF:CL-SOURCE-FILE {B97CF78}>) 51: (ASDF:PERFORM #<ASDF:LOAD-OP {7056C23D}> #<ASDF:CL-SOURCE-FILE {B97CF78}>) 52: (#<FUNCTION (LAMBDA (MOP::ARGS MOP::NEXT-EMFUN)) {5485F086}> (#<ASDF :LOAD-OP {7056C23D}> #<ASDF:CL-SOURCE-FILE {B97CF78}>) NIL) 53: (#<FUNCTION {257218C4}> (#<ASDF:LOAD-OP {7056C23D}> #<ASDF:CL-SOURCE- FILE {B97CF78}>)) 54: (#<FUNCTION {DBD2C04}> #<ASDF:LOAD-OP {7056C23D}> #<ASDF:CL-SOURCE- FILE {B97CF78}>) 55: (APPLY #<FUNCTION {DBD2C04}> (#<ASDF:LOAD-OP {7056C23D}> #<ASDF:CL- SOURCE-FILE {B97CF78}>)) 56: (ASDF::PERFORM-WITH-RESTARTS #<ASDF:LOAD-OP {7056C23D}> #<ASDF:CL- SOURCE-FILE {B97CF78}>) 57: (#<FUNCTION {7E94C1A7}>) 58: (JVM::%WITH-COMPILATION-UNIT #<FUNCTION {5835FBDD}>) 59: org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2805) --more-- -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/110> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 5

[armedbear-ticket] [armedbear] #105: DIRECTORY ignores :WILD-INFERIORS
by armedbear 30 Oct '10

30 Oct '10

#105: DIRECTORY ignores :WILD-INFERIORS ----------------------+----------------------------------------------------- Reporter: mevenson | Owner: mevenson Type: defect | Status: new Priority: minor | Milestone: 0.22 Component: other | Version: 0.22 Keywords: | ----------------------+----------------------------------------------------- All occurences of :WILD-INFERIORS as arguments to DIRECTORY are ignored. Reported by Faré working on ASDF-2.005 -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/105> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 2