November 2021 - armedbear-devel - mailman3.common-lisp.net

Setting different class loader
by Steven Nunez 06 Feb '23

06 Feb '23

Greetings all, I have what I think is a problem with the ABCL class loader. I am working with a 'big data' library, Spark, but run into an issue on line 2 of the programming guide example. I am able to load the JARs from Maven with the ASDF system definition: (asdf:defsystem #:spark :description "Wrapper for Spark 3.0" :serial t :defsystem-depends-on (abcl-asdf) :depends-on (#:jss #:javaparser) :components ((:mvn "org.apache.spark/spark-core_2.12" :version "3.0.0") (:file "package") (:file "spark"))) and can create a SparkConf object: (defvar *spark-conf* #1"new SparkConf() .setAppName("abcl-app") .setMaster("local")" ) But when I try to create a 'context' (defvar *sc* (new 'JavaSparkContext *spark-conf*)) I get an error in the initialisation: Java exception 'java.lang.NoClassDefFoundError: Could not initialize class org.apache.spark.package$'. There isn't much on this except from the Jenkins guys, who have attempted to put Spark and Spark applications into a CI system. They seem to think that it's related to a call to get a properties file in the package class and on a StackOverflow discussion suggested that "you should make sure that you set the classloader that Spark was loaded through using the Thread.currentThread().setContextClassLoader(myCustomLoader) call". I've verified with (java:dump-classpath) that the JAR is on the ABCL classpath, and the JAR file does contain the spark-version-info.properties file. I've also tried getting the file myself with: (defvar rs #1"Thread.currentThread() .getContextClassLoader() .getResourceAsStream("spark-version-info.properties")" ) which returns nil, so their theory may be correct. Messing around with class loaders is a bit beyond my 20 year old Java knowledge so I thought I'd ask here if anyone has any ideas on how I can load Spark in way to use the default Java class loader. Alternatively it occurs to me to ask why the ABCL class loader isn't able to find the properties file if the JAR is on the classpath and then to correct whatever that problem is. Cheers, Steve

3 6

(rationalize) works differently in ABCL
by Andrew Sengul 27 Nov '21

27 Nov '21

I've been doing operations that require me to rationalize floats, and I've found that (rationalize 2.3d0)gives very different output in ABCL compared SBCL and CCL. Floats can have any number of valid rational conversions but I'd expect a good algorithm for this conversion to find 23/10 rather than the huge numerators and denominators that get produced. It appears that the (rationalize) in ABCL is using the same algorithm as (rational) does in other CLs. Does (rationalize) just pass through to (rational) in ABCL? Would it make sense for ABCL to adopt the implementation of this function used by other CLs? Thanks. Andrew

1 0

One more question - compiling large code
by Andrew Sengul 23 Nov '21

23 Nov '21

I was just trying to compile a system containing macros that generate a large amount of code. I got this error: Compiled function can't be loaded: org.armedbear.lisp.demo_tmpHVF0FTR3_246 from org.armedbear.lisp.Pathname@2a31c2ec Does anyone know the likely reason for this? The code I'm compiling works with all other CL implementations I've tried. Is it just a matter of the code size? Thanks, Andrew

3 3

Problem - can't set environment variables when starting ABCL via Slime
by Andrew Sengul 21 Nov '21

21 Nov '21

Hello, I'm using ABCL through Emacs with Slime and I'm having trouble setting bash environment variables needed for Maven to work. Here's what I have in my ~/.emacs file: (setq slime-lisp-implementations '((abcl ("/usr/bin/java" "-jar" "/path/to/abcl-bin-1.8.0/abcl.jar" "/path/to/abcl-bin-1.8.0/abcl-contrib.jar" "-Xmx6g") :coding-system utf-8-unix :env ("JAVA_HOME=/path/to/jdk-12/" "PATH=/opt/apache-maven-3.8.3/bin:$PATH")))) Problem is, the $JAVA_HOME and $PATH variables are not set for the ABCL process despite putting them here. The environment variables do work with other CL implementations. When I set them in SBCL, for example, I can run (uiop:run-program "echo $PATH" ...) and see the extension added to the path. This doesn't work in ABCL, and I need those extra environment variables set in order for Maven to work. Does anyone know a way to fix this? It works for other CLs, so I'm guessing something particular about ABCL is preventing the variables from being set. Thanks, Andrew

1 0