[armedbear-devel] Change in merge semantics which fixes loading CFFI

[Mark Evenson]

On 10/19/12 5:19 AM, Stas Boukarev wrote:
> Mark Evenson <evenson at panix.com> writes:
>
>> I currently [need to patch CFFI][abcl-cffi] to get past a error about
>> "u955" not being understood by the BABEL reader.
>>
>> [abcl-cffi]: http://slack.net/~evenson/abcl/cffi/cffi-abcl-20121016a.patch

Thanks for the work here!  In the meantime, I have [started to rework 
the ABCL implementation CFFI][abcl-cffi] to remove the compiler 
warnings, and to start fixing bugs for particular versions of the 
jna.jar for various platforms.  jna-3.4.0 seems to be failing for some 
usages of implementing callbacks, like those required cl+ssl, where 
jna-3.0.9 seems to work.

[abcl-cffi] 
http://detroit.slack.net/~evenson/abcl/cffi/cffi-abcl-20121017a.patch

> Now when trying to load cffi from quicklisp I get a different error, a
> misplaced COND body. A patch is attached.

[…]

> Further, as I'm trying it on a different machine and it doesn't have maven
> installed. So it throws a not so helpful error:
> The value NIL is not of type (OR PATHNAME STRING FILE-STREAM SYSTEM:JAR-STREAM SYSTEM:URL-STREAM).
>
> Attached a patch for this as well.

[…]

Both of your patches have been combined into [r14205][].

[r14205]: http://trac.common-lisp.net/armedbear/changeset/14205

> Now, after installing maven I'm able to load cffi from quicklisp, but
> not in my ordinary setup.
>
> Turns out the error is actually caused by (:asd :jss), more
> specifically, by
> (load #P"/tmp/fasls/.../abcl-contrib.jar!/jss/packages.abcl")
 >
 > Which means that it can't load fasls from directories with "!".

ABCL pathnames *should* allow directories with "!" in them, as long as 
the hosting JVM implementation can handle them.  But "!" has a special 
meaning in the namestrings that a ABCL PATHNAME converts to/from.  In 
ABCL, a PATHNAME with a namestring of 
"jar:file://foo/abcl-contrib.jar!/jss/packages.abcl" names a specific 
entry in a jar archive.  The ABCL specific code in the ASDF output 
translations, namely ASDF::TRANSLATE-JAR-PATHNAME, should now correctly 
deal with these things.  Maybe you are somehow not running the ASDF 
shipped with ABCL, but instead one that is listed in the ASDF system 
registry?  This could explain why we see different behavior on what 
should be otherwise fairly identical systems, namely the binaries 
installed by ubuntu-12.04 system packaging.  (Faré:  I'm waiting for 
reports like Stas' to shake out before submitting a patch for asdf-2.26).

[…]

> I'm now able to load CFFI. And also load cl+ssl, although it doesn't
> actually work.
>
> (drakma:http-request "https://google.com")
> WARNING: JAVA:MAKE-IMMEDIATE-OBJECT is deprecated.
> WARNING: JAVA:MAKE-IMMEDIATE-OBJECT is deprecated.
> WARNING: JAVA:MAKE-IMMEDIATE-OBJECT is deprecated.
> WARNING: JAVA:MAKE-IMMEDIATE-OBJECT is deprecated.
> #<THREAD "interpreter" {29ED3DA1}>: Debugger invoked on condition of type TYPE-ERROR
>    $Proxy5 is not assignable to com.sun.jna.Pointer

I'll have to get back to the big machine where I installed my 
Ubuntu-12.04 to check this precisely.  Under Solaris (oi-151a6), I get 
to problems with cl+ssl::*global-lock*, so CFFI definitely needs a bit 
of love to get things working smoothly.  When I initially implemented 
callbacks with JNA, I left some of the primitive constructs, like 
mapping vectors to space in memory, unimplemented, and a fair amount 
untested.  That debt now needs to be repaid.

>
> And loading cl+ssl in a fresh imaged, after it was compiled beforehand
> causes:
> Error loading /tmp/fasls/.../cl+ssl/ffi.abcl at line 168 (offset 9274)
> #<THREAD "interpreter" {32269133}>: Debugger invoked on condition of type ERROR
>    Class not found: org.armedbear.jna.dynamic.callbacks.G72378

There is an interactive restart available where one of the options is to 
"recompile" the interface.  As Yogi Bera might say where confronted with 
options, take it.  The current implementation for generating interfaces 
for CFFI sub-optimally uses GENSYM to name the associated java class. 
Before abcl-1.1.0, I need to come up with a way to hash a given 
implementation to a reasonable Java class name, so I can avoid the need 
for a restart.

Thanks so much for the detective work,
Mark

-- 

"A screaming comes across the sky.  It has happened before, but there is 
nothing to compare it to now."