armedbear-devel April 2022

armedbear-devel@common-lisp.net

4 participants
6 discussions

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

abcl-1.9.0 plans
by Mark Evenson 15 May '22

15 May '22

Greetings Bear fans, On the road in Amsterdam, I judge it time to stabilize the implementation for openjdk{8,11,17}. I don’t think we can do terrabyte heaps with openjdk8, so might as well skip openjdk11 to go for openjdk17 as abcl-2.0.0. Thanks to all who have provided material and spiritual support for the Armed Bear Common Lisp release engineering. Have a nice Northern Hemisphere Spring! One week call for patches for abcl-1.9.0 please. yours in the CONS, Mark -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

3 8

Which repo SVN or GIT?
by Blake McBride 30 Apr '22

30 Apr '22

Greetings, I am pretty sure we are keeping two parallel repos for ABCL, one in subversion and the other in GIT. I thought two things: 1. They were kept in sync 2. The subversion repo was preferred I recently compared the two repos and discovered that: 1. They are not in sync 2. The GIT repo has the latest changes Personally, I prefer subversion. However, I feel strongly that we should drop one of the repos so that this out-of-sync situation no longer arises. Thanks! Blake McBride

2 4

Why is build using Java 11?
by Blake McBride 13 Apr '22

13 Apr '22

Greetings, I am building the latest SVN version of ABCL on a Linux box. Here is what I am seeing: $ java -version openjdk version "1.8.0_322" OpenJDK Runtime Environment (build 1.8.0_322-b06) OpenJDK 64-Bit Server VM (build 25.322-b06, mixed mode) $ javac -version javac 1.8.0_322 $ env |grep JAVA $ ant [...] abcl.init: [echo] java.version: 11.0.14.1 [...] $ Why is the build using Java 11? Thanks! Blake McBride

2 3

Interrupting repl in Slime
by Alan Ruttenberg 12 Apr '22

12 Apr '22

Hi folks, Maybe someone has a feel for how interrupts work in ABCL? Doing an interrupt in ABCL from Slime doesn't interrupt until the end of a function or sleep or wait is called. This means whenever I accidentally have a too long or infinite loop by mistake the only thing I can do is quit lisp and start over. This is probably THE most irritating problem I have with ABCL. It doesn't happen often but when it does it completely disrupts work. Slime handles an interrupt by calling interrupt-thread. Interrupt-thread saves the function and sets a flag. When the interrupted process next checks the flag it will call the interrupt function. At first I thought lisp wasn't checking for an interrupt often enough, but that's not the problem. If I compile (loop for i = 1) I get public final LispObject execute() { ; do { ; if (!Lisp.interrupted) { ; continue; ; } ; Lisp.handleInterrupt(); ; } while (true); ; } So why doesn't the interrupt work? Well it seems there are two paths to interrupt. One is via interrupt-thread. Here is the code that sets the flag. final synchronized void interrupt(LispObject function, LispObject args) { pending = new Cons(args, pending); pending = new Cons(function, pending); threadInterrupted = true; javaThread.interrupt(); } Note that it is setting thread.threadInterrupted rather than Lisp.interrupted. In fact, the only way to set Lisp.interrupted is via Lisp.setInterrupted() and the only function that calls that is ext:interrupt-lisp. Nothing calls ext:interrupt-lisp. So that nice check within the loop is checking for a signal that currently never arrives. The javathread.interrupt is only periodically detected by an explicit call or via an InterruptedException that Java will throw when the thread yields or via a check of thread.isInterrupted. The latter is checked in one place, inside a catch, which afaik isn't executed unless there's an error in the thread - it's the "Ignoring uncaught exception" path. Now, if I call ext:interrupt-lisp from the *inferior-lisp* a break comes up during the infinite loop and I can kill it! This is the desired behavior. The problem is, I can't figure out where to call (ext:interrupt-lisp) within slime. I tried to put it right after interrupt-thread when that is called in swank::queue-thread-interrupt, which is what is eventually called when you hit C-c in the repl. But that causes an error and kills the slime session. And emacs, for that matter, which needs to be force quit. I'm thinking that in the case of a control-c we should not use thread-interrupt but rather lisp interrupted. threadInterrupted is thread local and Lisp.interrupted is a global. So technically the control c might not go to the right thread, since all threads are checking the global. But in the situation where it's locked in an infinite loop, there's no other thread doing anything, so the right thing happens. In any case I think that's probably easy to fix by setting another volatile to the thread to be interrupted. In general one would have to worry about a race condition if there were several places that might call interrupt-lisp, but in this case it would only be called with an explicit Control-c and perhaps on a request to kill a thread from the slime threads buffer. It's an open question as to whether interrupt-thread should take advantage of this as well, but that would require more care to avoid a race condition. Any help on sorting this would be much appreciated. Thanks, Alan

3 13

ABCL manual
by Jonathan L Cunningham 07 Apr '22

07 Apr '22

Hi, The link in the Bibliography [Rho09] appears to have moved, and gives a 403 error. This, similar but different, link appears to be correct: https://research.gold.ac.uk/id/eprint/2344/1/sequences-20070301.pdf Regards, Jonathan

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel April 2022