I've believe I've written code that can load a compiled asdf system from a jar file. Final testing is pending the patch for loading a compiled file from a subdirectory of a jar.
In order to do that I needed to do 3 things.
1) Patch probe file so that it understands jar:file pathnames 2) Patch truename so that it understands jar:file pathnames 3) Create a new asdf op that knows to load only the compiled files.
These patches are in
http://svn.mumble.net:8080/svn/lsw/trunk/patches/jarfile.lisp
I used advise (http://svn.mumble.net:8080/svn/lsw/trunk/util/encapsulate.lisp) to patch, probe-file, directory, and truename, but don't mind merging the changes into source if it's deemed that they are the right thing.
I'd submit the code for advise too (adapted from MCL), but it's not quite cleaned up yet.
The asdf op is in that file too. It's a bit hacky because I use asdf-binary-locations[1] and I didn't see how to cleanly integrate it. If someone knows how to drive asdf better than I do, please suggest a better way. There's still a nit in that if you load the system a second time it warns about file-write-date not working. I'm not sure file write date should return for a jar:file pathname. The write date of the containing jar?
FWIW, I think that you should consider having asdf-binary-locations be part of the standard distribution. As ABCL is under active development I was always running into issues with stale fasls, but no more since I've been using it.
-Alan
[1] http://common-lisp.net/project/asdf-binary-locations/
laptop:~/ % jar tf test.jar META-INF/ META-INF/MANIFEST.MF bar/ bar/armedbear-0.18.0-dev-darwin-unknown/ bar/armedbear-0.18.0-dev-darwin-unknown/bar1.abcl bar/armedbear-0.18.0-dev-darwin-unknown/bar2.abcl bar/bar.asd
CL-USER> (advise load (if (eql 0 (search "jar:file" (namestring (car arglist)))) (format t ";; would have loaded ~a~%" (car arglist)) (:do-it)) :when :around :name stub) #<FUNCTION (ENCAPSULATE::ADVISED 'LOAD) {ACB16B}>
CL-USER> (load "jar:file:/Users/alanr/repos/lsw/trunk/patches/test.jar!/bar/bar.asd") ; Loading jar:file:/Users/alanr/repos/lsw/trunk/patches/test.jar!/bar/bar.asd ... ; Loaded jar:file:/Users/alanr/repos/lsw/trunk/patches/test.jar!/bar/bar.asd (0.0030 seconds) T
CL-USER> (asdf::oos 'asdf::load-just-fasls-op 'bar) ;; would have loaded jar:file:/Users/alanr/repos/lsw/trunk/patches/test.jar!/bar/armedbear-0.18.0-dev-darwin-unknown/bar1.abcl ;; would have loaded jar:file:/Users/alanr/repos/lsw/trunk/patches/test.jar!/bar/armedbear-0.18.0-dev-darwin-unknown/bar2.abcl
CL-USER> (asdf::oos 'asdf::load-just-fasls-op 'bar) WARNING: Missing FILE-WRITE-DATE for #P"jar:file:/Users/alanr/repos/lsw/trunk/patches/test.jar!/bar/bar1.lisp": treating operation #<ASDF::LOAD-JUST-FASLS-OP NIL {8C2182}> on component #<ASDF:CL-SOURCE-FILE "bar1" {B93BB6}> as done. WARNING: Missing FILE-WRITE-DATE for #P"jar:file:/Users/alanr/repos/lsw/trunk/patches/test.jar!/bar/bar2.lisp": treating operation #<ASDF::LOAD-JUST-FASLS-OP NIL {8C2182}> on component #<ASDF:CL-SOURCE-FILE "bar2" {7242FD}> as done.
On Fri, Jan 8, 2010 at 1:41 PM, Alan Ruttenberg alanruttenberg@gmail.com wrote:
I used advise (http://svn.mumble.net:8080/svn/lsw/trunk/util/encapsulate.lisp) to patch, probe-file, directory, and truename, but don't mind merging the changes into source if it's deemed that they are the right thing.
I take some of this back. I can merge with the source for directory, but truename and probe-file are implemented in java and I don't like writing java :)
-Alan
On Fri, Jan 8, 2010 at 7:48 PM, Alan Ruttenberg alanruttenberg@gmail.com wrote:
On Fri, Jan 8, 2010 at 1:41 PM, Alan Ruttenberg alanruttenberg@gmail.com wrote:
I used advise (http://svn.mumble.net:8080/svn/lsw/trunk/util/encapsulate.lisp) to patch, probe-file, directory, and truename, but don't mind merging the changes into source if it's deemed that they are the right thing.
I take some of this back. I can merge with the source for directory, but truename and probe-file are implemented in java and I don't like writing java :)
I can code the Java part. Is your code published somewhere?
http://svn.mumble.net:8080/svn/lsw/trunk/patches/jarfile.lisp -Alan
On Fri, Jan 8, 2010 at 2:04 PM, Alessio Stalla alessiostalla@gmail.com wrote:
On Fri, Jan 8, 2010 at 7:48 PM, Alan Ruttenberg alanruttenberg@gmail.com wrote:
On Fri, Jan 8, 2010 at 1:41 PM, Alan Ruttenberg alanruttenberg@gmail.com wrote:
I used advise (http://svn.mumble.net:8080/svn/lsw/trunk/util/encapsulate.lisp) to patch, probe-file, directory, and truename, but don't mind merging the changes into source if it's deemed that they are the right thing.
I take some of this back. I can merge with the source for directory, but truename and probe-file are implemented in java and I don't like writing java :)
I can code the Java part. Is your code published somewhere?
On Fri, Jan 8, 2010 at 8:17 PM, Alan Ruttenberg alanruttenberg@gmail.com wrote:
http://svn.mumble.net:8080/svn/lsw/trunk/patches/jarfile.lisp
Sorry, for some reason I had missed your first mail. Thanks anyway.
Ale
On 1/8/10 7:48 PM, Alan Ruttenberg wrote: […]
I take some of this back. I can merge with the source for directory, but truename and probe-file are implemented in java and I don't like writing java :)
Neither do we, believe it or not!
I know you used the ADVISE facility to implement what you needed for "jar:file" but I'd either like to move the existing PATHNAME-stuff completely into Lisp, or figure out how to do this in Java. Unfortunately there is a fair amount of special casing in the ABCL java implementation of PATHNAME for various Windows/UNIX problems for which we have no tests to ensure that a replacement implementation in Lisp would successfully pass. So, I'm looking at how to get "jar:file" working completely on the Java side.
Cool use of ADVISE, though!
On Sat, Jan 9, 2010 at 1:28 PM, Mark Evenson evenson@panix.com wrote:
On 1/8/10 7:48 PM, Alan Ruttenberg wrote: […]
I take some of this back. I can merge with the source for directory, but truename and probe-file are implemented in java and I don't like writing java :)
Neither do we, believe it or not!
I know you used the ADVISE facility to implement what you needed for "jar:file" but I'd either like to move the existing PATHNAME-stuff completely into Lisp, or figure out how to do this in Java.
It would be extremely nice to be able to move some of the current Java stuff into Lisp. To do that effectively, I think we need something like ECL does: build an ecl_min in C (in our case abcl_min in Java) which implements a rather small subset of Lisp. The rest of the system can be based off the minimal lisp and implement the full CL spec. However, this approach would need a good design. Without one, I think we'll be lost.
Unfortunately there is a fair amount of special casing in the ABCL java implementation of PATHNAME for various Windows/UNIX problems for which we have no tests to ensure that a replacement implementation in Lisp would successfully pass. So, I'm looking at how to get "jar:file" working completely on the Java side.
That's probably - in the short term - the best thing to do, yea.
Bye,
Erik.
It would be extremely nice to be able to move some of the current Java stuff into Lisp. To do that effectively, I think we need something like ECL does: build an ecl_min in C (in our case abcl_min in Java) which implements a rather small subset of Lisp. The rest of the system can be based off the minimal lisp and implement the full CL spec. However, this approach would need a good design. Without one, I think we'll be lost.
I suppose that the JVM as an environment is sufficiently different that none of the other Common Lisps can be re-used? Specifically, SBCL's bootstrapping process [1] looks intriguing, but seems to target relatively simple memory architectures, possibly making it a bad fit for the JVM.
[1] http://www.doc.gold.ac.uk/~mas01cr/papers/s32008/sbcl.pdf
On Sat, Jan 9, 2010 at 3:02 PM, Axel Rauschmayer axel@rauschma.de wrote:
It would be extremely nice to be able to move some of the current Java stuff into Lisp. To do that effectively, I think we need something like ECL does: build an ecl_min in C (in our case abcl_min in Java) which implements a rather small subset of Lisp. The rest of the system can be based off the minimal lisp and implement the full CL spec. However, this approach would need a good design. Without one, I think we'll be lost.
I suppose that the JVM as an environment is sufficiently different that none of the other Common Lisps can be re-used? Specifically, SBCL's bootstrapping process [1] looks intriguing, but seems to target relatively simple memory architectures, possibly making it a bad fit for the JVM.
[1] http://www.doc.gold.ac.uk/~mas01cr/papers/s32008/sbcl.pdf
Yea; for one thing: we don't control the memory space. SBCL does. That's a *huge* difference.
Bye,
Erik.
armedbear-devel@common-lisp.net