On 10/19/12 5:19 AM, Stas Boukarev wrote:
Mark Evenson evenson@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.
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