Blake McBride | 25 Aug 18:48 2015

Better integration between ABCL & Java

Greetings,

I worked hard on a project to link ABCL with a very large Java application.  Although the addition of ABCL to that project failed, the work I did could be of use, and with some effort could be made to solve the problem I had.  I believe the original problem I had would be a very common problem in similar circumstances.

My pre-existing Java application has almost 10,000 classes!  I wasn't about to create lisp cover functions for each java method.  I also wasn't going to use a convoluted syntax to get to java each time.

What I did was create some Java and Lisp code that, through reflection, caused the system to auto-generate a complete set of CLOS classes to mirror my primary java application classes - including the class hierarchy.  The methods in these CLOS classes would call the Java methods.  With this, when in Lisp, I could just use all of my Java classes and methods as regular CLOS classes and methods.  It's use of Java classes and methods internally was transparent to lisp.  All of this worked fine.

The problem I ran into was the fact that Java can have several methods with the same name but different arguments.  So, the Java method being called depended on the types and number of arguments too (not just the class of the instance and the method name).  I never solved this, although I think it could be.  I just ran out of time and steam, as well as other non-technical reasons.

The reason I bring this all up now is because I am unclear about what problems Ralph is trying to solve.  I thought what I have done may be of use.

Thanks.

Blake McBride

Ralph Ritoch | 25 Aug 06:54 2015
Picon

All conformance ansi-test's passed

Hello,

I have been able to get ABCL to pass all of the ansi conformance tests. While this is not an official ABCL release, all of the modifications I made are released under the MIT license and may be freely integrated into ABCL at the discretion of the maintainers.

To embed this conforming version into your java applications add the following dependencies which have been released at maven central.

        <dependency>
            <groupId>com.vnetpublishing.lisp</groupId>
            <artifactId>jrelisp-abcl-impl</artifactId>
            <version>0.0.2</version>
        </dependency>

        <dependency> 
            <groupId>com.vnetpublishing.lisp</groupId>
            <artifactId>jrelisp-abcl-contrib</artifactId>
            <version>0.0.2</version>
        </dependency>

The source code for this release can be found at https://github.com/rritoch/jrelisp-abcl/tree/55e808d3c0084d16d1ed04c36a6f5a5ecad4de08 .

While I have moved some files around it is still an ABCL implementation that is mostly backwards-compatible with the official ABCL releases.

Moving forward it is likely that any future development on these branches will further deviate from ABCL. I am not claiming that this solves EVERY compliance issue but I have found solutions for each of the ansi conformance test failures. Any remaining compliance issues can be considered a bug. My primary intention of passing every  test is to lock the build process so that builds will fail if any of the ansi tests fail.

It is unlikely that future modifications to these forks will have any relevance to ABCL. I will likely continue developing features that are needed for modern application development and therefore are of little interest to some, if not all, of the ABCL maintainers. That being said, v0.0.2 is the best release to source conformance solutions from for ABCL as it passes every conformance test. Any future releases will no longer be based on improving ABCL but be for the purpose of better supporting modern application development.

Best Regards,
  Ralph Ritoch
Paul Nathan | 19 Aug 06:12 2015

Unable to quickload Drakma + CL+SSL on ABCL 1.3.2 - (Failed to read artifact descriptor for net.java.dev.jna:jna)

Hello,

I just downloaded ABCL 1.3.2 for OSX (curl -L -O http://abcl.org/releases/1.3.2/abcl-bin-1.3.2.tar.gz) and tried to load a few things in. Drakma & CL+SSL failed to load for me. I have copied the tracebacks to the end of the email.

Please advise: is this my own error or something with ABCL?
Is there more information you would like?

Regards,
Paul



CL-USER(3): (ql:quickload :cl+ssl)
To load "cl+ssl":
  Load 1 ASDF system:
    cl+ssl
; Loading "cl+ssl"
..........
Using probed value of abcl-contrib:
'/Users/pnathan/bin/abcl-bin-1.3.2/abcl-contrib.jar'.
Added jar:file:/Users/pnathan/bin/abcl-bin-1.3.2/abcl-contrib.jar!/quicklisp/ to ASDF.
Added jar:file:/Users/pnathan/bin/abcl-bin-1.3.2/abcl-contrib.jar!/mvn/ to ASDF.
Added jar:file:/Users/pnathan/bin/abcl-bin-1.3.2/abcl-contrib.jar!/jss/ to ASDF.
Added jar:file:/Users/pnathan/bin/abcl-bin-1.3.2/abcl-contrib.jar!/jfli/ to ASDF.
Added jar:file:/Users/pnathan/bin/abcl-bin-1.3.2/abcl-contrib.jar!/asdf-jar/ to ASDF.
Added jar:file:/Users/pnathan/bin/abcl-bin-1.3.2/abcl-contrib.jar!/asdf-install/ to ASDF.
Added jar:file:/Users/pnathan/bin/abcl-bin-1.3.2/abcl-contrib.jar!/abcl-asdf/ to ASDF.
ARTIFACT_RESOLVING net.java.dev.jna:jna:pom:4.1.0
ARTIFACT_DOWNLOADING net.java.dev.jna:jna:pom:4.1.0 <at> central (http://repo1.maven.org/maven2/, default, releases+snapshots)
ARTIFACT_DOWNLOADED net.java.dev.jna:jna:pom:4.1.0 <at> central (http://repo1.maven.org/maven2/, default, releases+snapshots)
ARTIFACT_RESOLVED net.java.dev.jna:jna:pom:4.1.0
jnaASDF could not load  because Java exception 'org.eclipse.aether.collection.DependencyCollectionException: Failed to read artifact descriptor for net.java.dev.jna:jna:jar:4.1.0'..
#<THREAD "interpreter" {10EDE4B7}>: Debugger invoked on condition of type JAVA-EXCEPTION
  Java exception 'org.eclipse.aether.collection.DependencyCollectionException: Failed to read artifact descriptor for net.java.dev.jna:jna:jar:4.1.0'.
Restarts:
  0: RETRY                         Retry compiling #<ASDF/INTERFACE:MVN "jna" "net.java.dev.jna/jna/4.1.0">.
  1: ACCEPT                        Continue, treating compiling #<ASDF/INTERFACE:MVN "jna" "net.java.dev.jna/jna/4.1.0"> as having been successful.
  2: RETRY                         Retry compiling #<ASDF/LISP-ACTION:CL-SOURCE-FILE "cffi" "src" "cffi-abcl">.
  3: ACCEPT                        Continue, treating compiling #<ASDF/LISP-ACTION:CL-SOURCE-FILE "cffi" "src" "cffi-abcl"> as having been successful.
  4: RETRY                         Retry ASDF operation.
  5: CLEAR-CONFIGURATION-AND-RETRY Retry ASDF operation after resetting the configuration.
  6: ABORT                         Give up on "cl+ssl"
  7: TOP-LEVEL                     Return to top level.


CL-USER(4): (ql:quickload :drakma)
To load "drakma":
  Load 1 ASDF system:
    drakma
; Loading "drakma"
ARTIFACT_RESOLVING net.java.dev.jna:jna:pom:4.1.0
ARTIFACT_DOWNLOADING net.java.dev.jna:jna:pom:4.1.0 <at> central (http://repo1.maven.org/maven2/, default, releases+snapshots)
ARTIFACT_DOWNLOADED net.java.dev.jna:jna:pom:4.1.0 <at> central (http://repo1.maven.org/maven2/, default, releases+snapshots)
ARTIFACT_RESOLVED net.java.dev.jna:jna:pom:4.1.0
jnaASDF could not load  because Java exception 'org.eclipse.aether.collection.DependencyCollectionException: Failed to read artifact descriptor for net.java.dev.jna:jna:jar:4.1.0'..
#<THREAD "interpreter" {A19A2B4}>: Debugger invoked on condition of type JAVA-EXCEPTION
  Java exception 'org.eclipse.aether.collection.DependencyCollectionException: Failed to read artifact descriptor for net.java.dev.jna:jna:jar:4.1.0'.
Restarts:
  0: RETRY                         Retry compiling #<ASDF/INTERFACE:MVN "jna" "net.java.dev.jna/jna/4.1.0">.
  1: ACCEPT                        Continue, treating compiling #<ASDF/INTERFACE:MVN "jna" "net.java.dev.jna/jna/4.1.0"> as having been successful.
  2: RETRY                         Retry compiling #<ASDF/LISP-ACTION:CL-SOURCE-FILE "cffi" "src" "cffi-abcl">.
  3: ACCEPT                        Continue, treating compiling #<ASDF/LISP-ACTION:CL-SOURCE-FILE "cffi" "src" "cffi-abcl"> as having been successful.
  4: RETRY                         Retry ASDF operation.
  5: CLEAR-CONFIGURATION-AND-RETRY Retry ASDF operation after resetting the configuration.
  6: ABORT                         Give up on "drakma"
  7: TOP-LEVEL                     Return to top level.
[1] CL-USER(5): 6
Hamda Binte Ajmal | 18 Aug 11:45 2015
Picon

loading lisp files from inside the java jar

Hi,
I am sending this message again, as the last thread went a little too far.
I have developed a Java Application that runs lisp code at the back end, and I use ABCL for that.
Before using the lisp commands, I load a few .lisp files so that I can call the functions defined in those files.
Everything works fine as long as I run the application from Netbeans.
When I run the application from the jar file, it throws 'File not found error'.
as the lisp files are not a part of file system inside the project jar.
I tried to follow the suggestions given by Mark
(load “jar:file:/absolute/path/to/file.jar!/path/within/jar/setup.lisp”)
It shows the same File not found error. Am i missing something here?
As suggested by Ralph to use (load-system-file "path/to/resource.lisp"), I tried to use that, but I was unable to access sys package, please let me know how to do this.

I find the help documentation and tutorials very confusing, and difficult to understand.
Any hints will be appreciated.
Thanking in anticipation.
Regards,
Hamda
NUIG, Ireland.
Hamda Binte Ajmal | 17 Aug 15:04 2015
Picon

Re: Lisp filepath issues when running application directly from jar file

Please, can anyone help me here?

On Mon, Aug 17, 2015 at 2:03 PM, Ralph Ritoch <rritoch <at> gmail.com> wrote:
Erik,

   Your pointing out ONE fix that didn't completely solve ALL problems related to compound types, but that one fix didn't solve all of the failures. Most of the repairs I made were complete. I don't expect my fork to run most LISP applications because it is only being re-designed to support compliant applications. Specifically I dropped automatic support for the #No-Break_Space named character. ABCL does not meet my needs, period, and it doesn't meet the needs of most business applications.  It won't be adopted by the industry until it is refactored to meet the needs of the industry, and that is what I am working on. As mark says, he doesn't want to allow users to have access to loading lisp from the classloader. Appropriate maven integration was also flat-out rejected, and his solution of tying system dependent configuration settings to the deployment of applications is not conducive to Interoperability.  At the end of the day it all comes down to two questions, does ABCL meet my needs today, and will it meet those needs in the future. Mark has made it clear that the answers to both questions are a resounding NO.  Anyone looking to include a LISP in an enterprise application is going to come to the same conclusion, leaving ABCL in a subculture that can never be part of the mainstream because it doesn't meet the needs of the industry.

Best Regards,
  Ralph Ritoch

On Mon, Aug 17, 2015 at 8:52 PM, Erik Huelsmann <ehuels <at> gmail.com> wrote:

On Mon, Aug 17, 2015 at 2:04 PM, Ralph Ritoch <rritoch <at> gmail.com> wrote:
This "idiot" refactored a very small portion of your code making it MUCH faster, and also passed more than 90% of the tests ABCL is currently failing, leaving only 3 ansi-tests that are still failing. If I'm an idiot it doesn't say much  about you since you've been working on this for years and I've only been working on it for weeks.

True. But it's not like you solved all these issues by fundamentally supporting what they're testing for. The complex types that you fixed (and I already said this in IRC) could have been fixed the way you did over 10 years ago. We find it more important to fix the underlying issues. I'd like to note here that compliance doesn't come from "not failing the ansi tests", but from implementing the features the tests are trying to test. In other words, you're not compliant with a class of issues by being able to produce on specific instance of the class.

The fix to make things "MUCH faster" as you say doesn't solve problems in the bigger picture; does the ABCL in your git repository now have fewer CL-TEST-GRID failures? If not, then it's not more useful than it was before: it doesn't run more of the most-used CL code out there.... Now, *that* would have been a great and useful contribution. I'm affraid that coming rushing in, expecting immediate answers, solving unimportart problems, calling people names if they don't respond quickly enough by your standards and then hard-forking the project all don't classify as great contributions.

I hoped that we could get the progress you said you wanted through the discussion that's to be expected when you are an open source contributor. Alas, as Mark points out, there hasn't been much of the discussion I had hoped for...


Regards,


Erik.

 
Best Regards,
  Ralph Ritoch

On Mon, Aug 17, 2015 at 8:00 PM, <armedbear-devel-request <at> common-lisp.net> wrote:
Send armedbear-devel mailing list submissions to
        armedbear-devel <at> common-lisp.net

To subscribe or unsubscribe via the World Wide Web, visit
        https://mailman.common-lisp.net/listinfo/armedbear-devel
or, via email, send a message with subject or body 'help' to
        armedbear-devel-request <at> common-lisp.net

You can reach the person managing the list at
        armedbear-devel-owner <at> common-lisp.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of armedbear-devel digest..."


Today's Topics:

   1. Re: Lisp filepath issues when running application directly
      from jar file (Mark Evenson)


----------------------------------------------------------------------

Message: 1
Date: Sun, 16 Aug 2015 14:38:44 +0200
From: Mark Evenson <evenson <at> panix.com>
To: Armed Bear <armedbear-devel <at> common-lisp.net>
Subject: Re: Lisp filepath issues when running application directly
        from jar file
Message-ID: <5616917D-F789-4F95-93E2-FC3B7633B051 <at> panix.com>
Content-Type: text/plain; charset="utf-8"


> On Aug 16, 2015, at 02:34, Ralph Ritoch <rritoch <at> gmail.com> wrote:
>
> I have used this function in my code without ANY problems. [?]

The SYSTEM package is not intended to be used by users unless there is no
alternative.  The manual states clearly that functionality provided by SYSTEM
is subject to be changed between major releases without warning.  Therefore,
the argument in this case isn?t that one would have problems using
SYSTEM:LOAD-SYSTEM-FILE, but rather that one should use the ANSI interface as
implemented CL:LOAD which should be able to load Lisp and/or fasls in all cases
needed by the user.  My work on EXT:JAR-PATHNAME and EXT:URL-PATHNAME was
motivated by precisely the need for CL:LOAD to work in all conceivable cases in
the JVM ecology.  And the best contemporary mechanism for expression for
resolution of and  dependency order for CL:LOAD lies in ASDF, hence my
emphasis on using its abstraction where extending CL:LOAD is not desirable.

As a side note, over time, we wish to move functions in SYSTEM which useful to
the user into the EXTENSION package, but this work is incomplete at best.
Currently, there are indeed cases in which using a function from SYSTEM is
unavoidable.  The use of SYSTEM:LOAD-SYSTEM-FILE is not one of them.

> Your attitude regarding "progress" is archaic. If you don't want to support maven or other java technologies why do you even bother controlling abcl?


Your attitude towards discussion is not only archaic (i.e. immature) but
counterproductive towards reaching the sort of consensus needed for progress.

However misguided such an endeavor may be, a couple points follow towards a
defense from your sleazy ad hominem ?argumentation?.

As for supporting Maven, I have developed the machinery to use Maven artifacts
in ABCL-ASDF, and continued to maintain them (with help from users) even as the
lurching horror that comprises Maven release engineering continues to change
API semantics between patch level releases.  I have offered to collaborate
with you on incorporating your initial work on building from Maven, pointing
out the problems that I see with your approach to which I have received no
reply.

As for supporting ?other technologies?, I suppose you are referring to your
attempt to merge abcl-contrib.jar and abcl.jar.  In this effort, I pointed out
you could do this cleanly with the current code by adding site-specific code to
the ?system.lisp? file whose contents are controlled by the Ant build process.
Since your Maven build doesn?t use the Ant target to package (one of my
explicit criticisms), you presumedly weren?t interested in using this
mechanism.  I responded twice to your proposal to probe jar files on the
classpath for code to pontential load with suggestions which you found too
burdensome to discuss so you developed what you needed.  Your email announcing
this implementation implied you had implemented to a ?specification?, but no
such entity existed external to the source code.  If you wish to provide such a
specification for your current implementation, please do so that others may
consider its usefulness.

As to whether I control ABCL, I was going to reply that I am but one maintainer
out of five; that you are welcome to convince a majority of the maintainers
through useful and accepted contributions that that you should be in ?control?
too; and that since the code is GPL?d so you are welcome to get the fork out of
here.  But at this point, I would reply that if I do somehow ?control? ABCL, I
am glad to protect it from idiots like you.

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





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20150816/f10b225d/attachment-0001.html>

------------------------------

Subject: Digest Footer

_______________________________________________
armedbear-devel mailing list
armedbear-devel <at> common-lisp.net
https://mailman.common-lisp.net/listinfo/armedbear-devel


------------------------------

End of armedbear-devel Digest, Vol 16, Issue 11
***********************************************




--
Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.




--
Hamda Binte Ajmal
+92 344 550 7680
Hamda Binte Ajmal | 14 Aug 12:20 2015
Picon

Lisp filepath issues when running application directly from jar file

Hi,
I was working on an application, that loads a few lisp files using lisp command
(load "fullfilepath.lisp") from java using ABCL.
This file in turn loads the other lisp files located in same folder hierarchy, and then i call lisp functions (defined in these files) from java and everything works perfect as long as I run the application from Netbeans.
Close to deployment, I tested the application by running it from jar file, I found that there are issues with filepaths, as the files are not a part of file-system, and hence not accessible using a file-path.
Does anyone has any idea how to fix this issue ?
I tried many things, like 
URL url = LispConnector.class.getResource("/Aima/aima/quicklisp/setup.lisp"); String path = url.getFile(); File f = new File(path); path = f.getAbsolutePath(); path = path.replace("\\", "/");which returns
But which is wrong as this is not a valid file path and does not exists so lisp : (load "filepath") fails here.

When I use the code

String path = url.toURI(); File = new File(path); path = path.getAbsolutePath();
Again it works fine while running from netbeans, but shows error "URI is not hierarchical" error while running the jar file.

Has anyone encountered this issue, please help.


--
Hamda Binte Ajmal
NUIG, Ireland
Vibhu Mohindra | 12 Aug 13:57 2015
Picon

ABCL on jailbroken iPhone

My jailbroken iPhone has GNU classpath[0] and jamvm[1] installed.

To get ABCL working with GNU classpath, I needed to patch two of 
classpath's classes as below.

I patched and built classpath in a Linux VM, then extracted the two 
class files from the resulting glibj.zip and inserted them into the 
iPhone's /usr/share/classpath/glibj.zip .

I've reported these modifications to:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67188
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67189
the latter of which may be an ABCL problem, not a GNU classpath one.

(Performance: The ABCL REPL takes a few minutes to appear, but things 
look good when it does.)

ref:
[0] http://www.gnu.org/software/classpath/
[1] http://jamvm.sourceforge.net/

Vibhu

diff -Naur classpath-0.99/java/math/BigInteger.java 
classpath-0.99.abcl/java/math/BigInteger.java
--- classpath-0.99/java/math/BigInteger.java    2010-09-02 
17:47:07.000000000 +0100
+++ classpath-0.99.abcl/java/math/BigInteger.java    2015-08-11 
02:01:18.000000000 +0100
 <at>  <at>  -183,6 +183,7  <at>  <at> 
      int i, digit;
      boolean negative;
      byte[] bytes;
+    if (len == 0) throw new NumberFormatException("zero length big 
integer");
      char ch = s.charAt(0);
      if (ch == '-')
        {
diff -Naur classpath-0.99/java/nio/charset/CharsetEncoder.java 
classpath-0.99.abcl/java/nio/charset/CharsetEncoder.java
--- classpath-0.99/java/nio/charset/CharsetEncoder.java  2010-06-03 
20:13:04.000000000 +0100
+++ classpath-0.99.abcl/java/nio/charset/CharsetEncoder.java  2015-08-12 
12:16:13.000000000 +0100
 <at>  <at>  -159,8 +159,6  <at>  <at> 
      // in progress" and also that "it resets this Encoder".
      // Should we check to see that the state is reset, or should we
      // call reset()?
-    if (state != STATE_RESET)
-      throw new IllegalStateException ();

      // REVIEW: Using max instead of average may allocate a very large
      // buffer.  Maybe we should do something more efficient?
 <at>  <at>  -199,9 +197,6  <at>  <at> 
      // a return value indicating an incomplete decoding operation"
      // XXX: We will not check the previous return value, just
      // that the previous call passed true for endOfInput
-    if (state != STATE_RESET && state != STATE_CODING
-        && !(endOfInput && state == STATE_END))
-      throw new IllegalStateException ();
      state = newState;

      for (;;)

Ralph Ritoch | 1 Aug 11:06 2015
Picon

Are you looking for an idea for an ABCL project?

Hi,

I was invited by someone in the virt.x community to add ABCL to the virt.x project http://vertx.io/ .  I don't foresee having the time to do the integration this year but if anyone is interested it looks like there are many in the Java development community who are interested in using common-lisp in their JVM applications. The virt.x system supports maven and integration with vert.x will most likely require that the maven integration issues, including integration of abcl-contrib from the classpath (maven) be resolved before integration will be possible. I don't currently use virt.x but it looks like a good system for large teams with diverse programming backgrounds.

Best Regards,
  Ralph Ritoch
Ralph Ritoch | 26 Jul 14:29 2015
Picon

Proposal to improve the loading of the abcl-contrib dependency.

Hi,

   I have run into an issue with making executable abcl jars when the jar depends on, and provides, abcl-contrib. As far as I can tell abcl looks for abcl-contrib in the following locations.

1. Looks for a jar named abcl-contrib.jar in the classpath determined by probing the classloader for the jars it provides.
2. Looks in the directory of the jars in the classpath for a file named abcl-contrib.jar

Neither of these solutions work if the currently executing jar includes abcl-contrib and isn't named abcl-contrib.jar.

The following code proves that it is relatively easy to add this capability.

(in-package 'sys)
(sys:add-contrib (make-pathname :defaults (java:jcall "toString" (svref (java:jcall "getURLs" (sys:boot-classloader)) 0))))

This code properly loads abcl-contrib when the executing jar provides abcl-contrib, while (require 'abcl-contrib) does not.

My proposal is to add a file named abcl-contrib/version.lisp to the abcl-contrib.jar, possibly in the /META-INF directory to avoid any potential conflicts with java, and to have sys:find-contrib look for this file in the resources provided by the classpath. The contents of this file is not important.

This change makes it possible to include the abcl-contrib "dependency" directly inside the jar application that is currently running, regardless of the name of the jar file. Therefore, applications which make use of abcl-contrib can be distributed as a single jar.

For maven users, this means that their uberjars will work by just including abcl and abcl-contrib as dependencies. 

For ant users they would probably need to extract abcl-contrib and include the extracted files in their generated jar which I believe can be fully automated.

It would be relatively easy for me to produce a patch to provide this feature as part of ABCL. It may be possible to provide this feature as an add-on, but the functions needed within the system package are private (not exported) so it would be difficult, if not impossible, to implement this feature as an add-on.

I would like your feedback on this issue. If this is a feature you want, or if you have any specific objections to including this feature in ABCL, please let me know.

Best Regards,
   Ralph Ritoch




Alejandro Zamora Fonseca | 24 Jul 14:33 2015
Picon

bug?

Hi!

Just now playing a little with ABCL(1.3.2), I saw some strange 
behaviour:

CL-USER> '(2 . 5)
(2 . 5)
CL-USER> '(2 . 5 . 5)
(2 . 5)
CL-USER> (equal '(2 . 5) '(2 . 5 . 5))
T

while other implementations give me an error when i type '(2 . 5 . 5)
it's a bug or ANSI CL allows this?

greetings,

Alejandro

--
Este mensaje le ha llegado mediante el servicio de correo electronico que ofrece Infomed para respaldar el
cumplimiento de las misiones del Sistema Nacional de Salud. La persona que envia este correo asume el
compromiso de usar el servicio a tales fines y cumplir con las regulaciones establecidas

Infomed: http://www.sld.cu/

Stelian Ionescu | 22 Jul 02:00 2015

Bordeaux-threads issues

Hi, can somebody take a look at the Bordeaux-threads support for ABCL?
The test suite hangs on Travis-CI.org during automatic tests so I guess
there's something wrong there. TraviCI runs Ubuntu 12.04 LTS on x86_64.
Thanks.

--

-- 
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.


Gmane