I'm gonna need a bit more time to chew over the ASDF code, but thanks for the general direction. I must confess that in spite of the reasonable looking documentation and having contributed the function translation code to ASDF, its whole output translation API has never really gelled in my understanding as a totality. Maybe I can contribute some examples to the texinfo file when the fuzz in my understanding resolves a bit.
output-translations is not THAT hard to understand, if you read the source code with my previous comments in mind. Patches to the docs are welcome, too.
A reasonable packaging mechanism for ABCL plus "compiled stuff" composed of ASDF system definitions that works well in a Java ecosystem is precisely the itch I'm in the process of scratching for ABCL right now.
Excellent. I hope you provide an API that isn't so ASDF-specific that it's a pain to use with XCVB -- though XCVB can use ASDF as a backend, and considering the slow ABCL start time, it's probably to be the preferred backend on ABCL.
- You can't immediately load FASL out of the jar.
Is that an ABCL limitation?
In my current hackish way—i.e. without comprehending your advice yet—one has first ASDF compile the system with output translations disabled, and then
(defmethod asdf:perform ((o asdf:compile-op) (c asdf:cl-source-file))) (setf (asdf::output-translations) '((t t))))
in the target JVM to load the ABCL FASLS from the jar.
Why that pain? Doesn't the zip process preserve the timestamps?
- One has to specify the absolute path on the local filesystem (or
potentially via a URI) for the jar, which makes things a bit fragile in the typical Java ecosystem usage which shuffles jars around like win32 DLLs (or, to be fair, Unix dynamic libraries) relying merely on the filename to keep things straight. My current insight into a way around would be to define another PATHNAME extension in ABCL for CLASSPATH entries, i.e. "classpath:cl-ppcre-2.0.3.jar!/cl-ppcre-2.0.3/" would refer to the named jar in the JVM CLASSPATH if it exists.
You want CL systems to be in a variety of jars, rather than just a one jar with everything in it?
- The extremely nice use of [JSS][jss] and [ABCLD's slight
modification][abcld] of ASDF to also refer to jar files to dynamically load into the JVM probably needs to be rewritten, otherwise we run into the situation whereby we have jars (i.e. the packaged Java code) within the ASDF packaged jar which A) needs changes within ABCL to completely work and B) would be rather inefficient in that the naive implementation each request for a new entry in the JAR within a JAR would require a complete "reseek" through the enclosed ZIP file.
I welcome patches to ASDF and/or implementation-specific contributions, just like our asdf-ecl.lisp.
- A fear of mine: if I enable all this, I presume that people would start
going around creating 'abcl.jar' files with different inclusions of different ASDF packagings. Without a real smart dynamic introspection system that essentially solves the problems in JVM's classpath we would end up with, at the minimum, a rather hostile situation for the end user. "Put 'abcl.jar' in your classpath." "I did, and it still didn't load Maxima." "Well, what's the checksum of your abcl.jar?" "c48d359a23ee" "Oh, you need 846f78c279cb". Ideally, I would like to come up with a mechanism that would require that 'abcl.jar' come from "official" ABCL packaging, but would somehow be able to introspect the JVM classpath to include ASDF definitions.
Maybe make it hard for anything but the original to be named abcl.jar?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Backwards compatible — If it's not backwards it's not compatible — Greg Newton gregnewton@netscape.net