[armedbear-devel] cffi, asdf question

[Mark Evenson]

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."