[armedbear-devel] cffi, asdf question
Mark Evenson
evenson at panix.com
Thu Jul 12 07:49:09 UTC 2012
On 7/11/12 9:49 PM, Durward McDonell wrote:
>
> Hello.
>
> I noticed that there is currently some difficulty getting cffi to
> load properly. I've gotten it to load using Mark Evenson's patches
> (I think), but it still required loading something, getting an error,
> and loading it again, and then assuming it was loading correctly.
>
> In the interest of doing it The Right Way, I have some questions. I
> hope they make some sense. ASDF doesn't know about loading systems
> from jar files -- that seems to be the job of abcl-asdf. But abcl-asdf
> has to be loaded from a jar file, right? So there's a bootstrapping
> problem. Where is this dealt with? Or is there some other magic I
> haven't yet figured out to load systems from jar files?
ABCL has a built-in [implementation-specific class SYS:JAR-PATHNAME][1]
as an extension to the CL:PATHNAME object which *can* be used to
reference resources in a jar archive. This mechanism is internally used
by the implementation to address the loading of objects composing ABCL
fasls, which are themselves essentially jar files (aka "zip archives").
Set CL:*LOAD-VERBOSE* to t during an ABCL boot to see the namestring
representation of a SYS:JAR-PATHNAME; further details can be found
[ibid][1].
[1]:
http://code.google.com/p/abcl-dynamic-install/source/browse/doc/design/pathnames/jar-pathnames.markdown
In order to "fit" the addressing of components of an archive, we use the
CL:PATHNAME DEVICE component to refer to the location of the archive,
for which the DIRECTORY, NAME, and TYPE elements refer to the individual
component. If one addresses a zip file within an archive—-as is needed
to reference ABCL fasls contained within 'abcl.jar'--the DEVICE
component is a list of two pathnames, denoting the "outer" and "inner"
archive locations. While we believe that this usage is allowed by the
ANSI specification and there is considerable leeway in the actual types
of the HOST and DEVICE components of a CL:PATHNAME, this seemingly ofter
trips up contemporary Common Lisp code which often takes "shortcuts" in
assumptions of what DEVICE and HOST should be in the process of invoking
CL:MERGE-PATHNAMES. The ABCL-ASDF packages smoothes over these
differences where necessary for the operation of ASDF on jar archives
(and more generically for artifacts that may be named by URI).
Wrt. to CFFI loading, one will currently *always* have to select two
restarts for subsequent loads. CFFI needs to use the Java interface
mechanism to specify callbacks. In our current implementation, we use a
gensym to name the Java class which we create at runtime to satisfy this
contract. Since this naming changes between runtimes, one has to tell
CFFI to recompile the source for the fasl at the "new" gensym naming.
This is a bug that I haven't quite figured out the best way forward, but
it probably involves generating a hash of the interface contract that
will be idempotent over time to use as the basis for the naming of the
JVM artifact.
Great questions,
Mark
--
"A screaming comes across the sky. It has happened before, but there is
nothing to compare it to now."
More information about the armedbear-devel
mailing list