Hi devs,
I looked into the asdf jar loading mechanism in the contrib, and found that it doesn't work well on Windows (mainly pathname issues). Attached patch provides a suggested fix (please review).
Additionally, I think a suitable (OS portable?) argument for asdf-jar:package's
&key out #P"/var/tmp"
would be nice.
This was tested informally, seems to work. What do you think?
Thanks for the good work!
Yong. PS Any ideas on how we can avoid bundling the source too (maybe only the .asd file will still be needed). This will make jar files look more like binaries in a way... I tried to add a :exclude-source argument to package, but the resulting jar file failed to load (asdf wants source files still).
On Jan 22, 2012, at 8:50 AM, Theam Yong Chew wrote:
Hi devs,
I looked into the asdf jar loading mechanism in the contrib, and found that it doesn't work well on Windows (mainly pathname issues). Attached patch provides a suggested fix (please review).
[Applied to trunk][r13795] after review and test under UNIX. At least it doesn't break anything…
Need to get my MSFT test environment a bit more in order
Additionally, I think a suitable (OS portable?) argument for asdf-jar:package's
&key out #P"/var/tmp"would be nice.
Got an idea for a single string that would work everywhere? Something like "./" *should* work, but it may not end up really being a temp space. A better idea might be to query the underlying JVM as to what directory the temporary file creations routines use, and ape that.
A conditional read macro at runtime to select "/var/tmp" or "c:/temp"?
Thanks for the good work!
Thanks for the patch!
[r13795]: http://trac.common-lisp.net/armedbear/changeset/13795
Yong. PS Any ideas on how we can avoid bundling the source too (maybe only the .asd file will still be needed). This will make jar files look more like binaries in a way... I tried to add a :exclude-source argument to package, but the resulting jar file failed to load (asdf wants source files still).
At various time I have gotten ASDF to exclude packaging the source, but the protocol always seems to break. Eventually, I just learned to stop fighting not including the source. For situations where it is commercially necessary to strip source, I would recommend the quick and dirty hack of stripping the generated archive.
22.01.2012, 12:54, "Mark Evenson" evenson@panix.com:
On Jan 22, 2012, at 8:50 AM, Theam Yong Chew wrote:
Hi devs,
I looked into the asdf jar loading mechanism in the contrib, and found that it doesn't work well on Windows (mainly pathname issues). Attached patch provides a suggested fix (please review).
[Applied to trunk][r13795] after review and test under UNIX. At least it doesn't break anything…
Need to get my MSFT test environment a bit more in order
Additionally, I think a suitable (OS portable?) argument for asdf-jar:package's
&key out #P"/var/tmp"
would be nice.
Got an idea for a single string that would work everywhere? Something like "./" *should* work, but it may not end up really being a temp space. A better idea might be to query the underlying JVM as to what directory the temporary file creations routines use, and ape that.
A conditional read macro at runtime to select "/var/tmp" or "c:/temp"?
So the jar's are unpacked into a temporary dir?
It would be good also to have a solution when fasls are loaded from jar directly. It would require to present jar as a file system to lisp, so that lisp functions merge-pathnames, open and others work on like #P"jar://some/path/".
It will solve the with choosing right temporary directory and will allow to load lisp code in environments where we don't have writable file system at all - Google App Engine.
Of course, I realize it is probably a significant work of source to support this, so it's just an idea rather than a "feature request".
Best regards, - Anton
22.01.2012, 13:09, "Anton Vodonosov" avodonosov@yandex.ru:
It would be good also to have a solution when fasls are loaded from jar directly. It would require to present jar as a file system to lisp, so that lisp functions merge-pathnames, open and others work on like #P"jar://some/path/".
It will solve the with choosing right temporary directory and will allow to load lisp code in environments where we don't have writable file system at all - Google App Engine.
Of course, I realize it is probably a significant work of source to support this, so it's just an idea rather than a "feature request".
BTW, if think in this direction, it makes sense to investigate firs what new java versions offer in regard to pluggable file systems: http://docs.oracle.com/javase/7/docs/technotes/guides/io/fsp/zipfilesystempr...
On Jan 22, 2012, at 10:09 AM, Anton Vodonosov wrote:
[…]
A conditional read macro at runtime to select "/var/tmp" or "c:/temp"?
So the jar's are unpacked into a temporary dir?
Buildtime: no. We create a hash of current pathnames to desired pathnames relative to the jar archive and package efficiently (directly).
Runtime: dependent on the JVM implementation that hosts the Bear.
It would be good also to have a solution when fasls are loaded from jar directly. It would require to present jar as a file system to lisp, so that lisp functions merge-pathnames, open and others work on like #P"jar://some/path/".
ASDF-JAR includes both source and fasts by default. The ABCL compiler should always be available, but it can take a while before the JIT really warms up, so binary fasts are desired. That Java has a universal byte code representation is used to great advantage here.
The assumption is that the additional bytes to include source is trivial.
It will solve the with choosing right temporary directory and will allow to load lisp code in environments where we don't have writable file system at all - Google App Engine.
GAE should be able to use binary artifacts produced by ASDF-JAR without issues. [abcl-servlet][] provides a plausible hosting framework.
[abcl-servlet]: https://bitbucket.org/easye/abcl-servlet
Of course, I realize it is probably a significant work of source to support this, so it's just an idea rather than a "feature request".
We love features. It gets us more users.
-- Mark
armedbear-devel@common-lisp.net
-
Anton Vodonosov -
Mark Evenson -
Theam Yong Chew