[armedbear-devel] [asdf-devel] ABCL packaging ASDF system in jars (was Re: Disabling "built-in" output translation)
Faré
fahree at gmail.com
Tue May 17 20:01:18 UTC 2011
> 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.
> 1) 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?
> 2) 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?
> 4) 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.
>
> [jss]: http://code.google.com/p/lsw2/source/browse/#svn%2Ftrunk%2Fjss
> [abcld]:
> http://code.google.com/p/abcl-dynamic-install/source/browse?repo=abcld
>
I welcome patches to ASDF and/or implementation-specific contributions,
just like our asdf-ecl.lisp.
> 5) 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 at netscape.net>
More information about the armedbear-devel
mailing list