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?
Thanks.
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/pathn...
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
armedbear-devel@common-lisp.net
-
Durward McDonell -
Mark Evenson