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

[armedbear-ticket] [armedbear] #32: Modify the currently disabled runtime-class.lisp code to not require ASM
by armedbear 28 Jul '12

28 Jul '12

#32: Modify the currently disabled runtime-class.lisp code to not require ASM --------------------------------------------------------------------+------- Reporter: vvoutilainen | Owner: somebody Type: enhancement | Status: new Priority: major | Milestone: Component: component1 | Version: Keywords: jvm bytecode compiler runtime dynamic class generation | --------------------------------------------------------------------+------- It's possible to define classes at runtime, by generating bytecode and loading it from the generated binary data, without ever writing it to a temporary file. runtime-class.lisp does that, but it requires an external bytecode library (ASM). ABCL has all the functionality for this to be done without ASM, so the task is to modify the runtime-class.lisp code so that ASM is no longer required and the code can be taken to be part of the build. -- Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/32> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 2

[armedbear-ticket] [armedbear] #30: Lisp debugger, for both compiled and interpreted code
by armedbear 18 Nov '11

18 Nov '11

#30: Lisp debugger, for both compiled and interpreted code ----------------------------+----------------------------------------------- Reporter: vvoutilainen | Owner: somebody Type: enhancement | Status: new Priority: major | Milestone: unscheduled Component: component1 | Version: Keywords: debug debugger | ----------------------------+----------------------------------------------- ABCL code can be debugged with normal java debuggers, but it is somewhat painful for the portions implemented in lisp(1). So we need a lisp debugger. (1) It's possible, although a bit tedious, to step through eval calls in a java debugger by examining the cars and cdrs of eval parameters when stepping the code. -- Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/30> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 4

[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] #24: Ability to load ASDF systems off JAR files in the classpath
by armedbear 04 Oct '10

04 Oct '10

#24: Ability to load ASDF systems off JAR files in the classpath -------------------------+-------------------------------------------------- Reporter: ehuelsmann | Owner: somebody Type: enhancement | Status: new Priority: major | Milestone: Component: component1 | Version: Keywords: | -------------------------+-------------------------------------------------- Alan Ruttenberg writes: I'd really like the ability to pop an asdf central registry directory into the abcl jar and have abcl be able to asdf load from there. Would really simplify packaging apps based on abcl. -- Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/24> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 7

[armedbear-ticket] [armedbear] #29: Support loading system files off other paths (in a JAR) than the default one
by armedbear 04 Oct '10

04 Oct '10

#29: Support loading system files off other paths (in a JAR) than the default one -------------------------+-------------------------------------------------- Reporter: ehuelsmann | Owner: somebody Type: enhancement | Status: new Priority: major | Milestone: Component: component1 | Version: Keywords: | -------------------------+-------------------------------------------------- Alan Ruttenberg writes: In order to enable easy packaging of a system into a jar file, one that might even be usable as an applet, a small change is needed. Currently load-system-file can read an .abcl compiled file set from the abcl jar. Actually, it doesn't load the .abcl directly. That file is a zip file with a "top level" file with a "._" extension and a bunch of .cls files. The unpacked contents of these files live in the abcl jar, with the "._" file renamed to have the extension ".abcl". The loading happens by first loading the "._" file, a file of lisp forms, which when evaluated, in turn calls load-compiled-function on each of the component .cls files (plus does some other stuff). All of these files live in a single directory in the jar file: org/armedbear/ lisp/ I'd like to be able to load from a subdirectory of that, in which I would put my files. I can tell load-system-file to load the initial abcl file from the subdirectory, say, org/armedbear/lisp/util/, but then load-compiled-function wants to load the components from org/ armedbear/lisp. So the small change is to set *load-truename* in load- system-file, based on the supplied path, and then to use it as the pathname defaults when executing the call to load-compiled-function. It seems to do this for the case where it loads from the regular file system, but not when working with the jar file. Once this change is in place, to package up a system, one would unjar abcl.jar, move one's compiled files in to a subdirectory of org/ armedbear/lisp, unzip all of them, rename *._ to *.abcl, and jar them back up. One could them load a file from the jar with: (sys:load-system-file "mydir/foo.abcl") loadCompiledFunction is defined in Lisp.java and loadSystemFile in Load.java -- Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/29> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 2

[armedbear-ticket] [armedbear] #19: SLIME from CVS HEAD needs 'with-mutex.lisp'
by armedbear 04 Oct '10

04 Oct '10

#19: SLIME from CVS HEAD needs 'with-mutex.lisp' ------------------------+--------------------------------------------------- Reporter: mevenson | Owner: ehuselmann Type: defect | Status: new Priority: major | Milestone: unscheduled Component: component1 | Version: Keywords: SLIME | ------------------------+--------------------------------------------------- SLIME from CVS HEAD fails to load with r11371, as it apparently needs with-mutex.lisp. The attached patch adds 'with-mutex.lisp' to the ABCL jar. -- Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/19> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 4

[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] #20: GRAY-STREAMS breaks ASDF loading
by armedbear 03 Nov '09

03 Nov '09

#20: GRAY-STREAMS breaks ASDF loading ------------------------+--------------------------------------------------- Reporter: ehuelsmann | Owner: somebody Type: defect | Status: new Priority: critical | Milestone: Component: component1 | Version: Keywords: | ------------------------+--------------------------------------------------- The sequence: (require 'asdf) (require 'gray-streams) (asdf:oos 'asdf:load-op :swank) breaks the asdf operation, while the same thing without the gray-streams works like a charm -- Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/20> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 2

[armedbear-ticket] [armedbear] #25: Variable scoping issues
by armedbear 17 Jan '09

17 Jan '09

#25: Variable scoping issues ------------------------+--------------------------------------------------- Reporter: ehuelsmann | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: component1 | Version: Keywords: | ------------------------+--------------------------------------------------- Alex Mizhari writes: compiler and lexical/special variables -- last time i've checked even relatively simple stuff like: (loop for i from 1 to 10 collecting (let ((i i)) (lambda () i))) did not work well. and that's quite idiomatic thing.. -- Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/25> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 1