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

The road to ABCL 2.0.0
by Mark Evenson 19 Sep '20

19 Sep '20

Greetings Armed Bear fans, Since, I've been able to get our favorite Bear to run on [openjdk15][6], which has now replaced openjdk14 in our CI test regime, an update is in order about the release schedule of [ABCL 2.0][3] for those of you following along at home, and let’s face it: only the homeless aren’t at home these days. ** Either abcl-1.8.0, or abcl-2.0.0 or both will be released by 10.10.2020 ** [abcl-1.8.0][1] will be the last release support openjdk6 and openjdk7 runtimes. [abcl-2.0.0][2] will require openjdk8, and will run on openjdk11, openjdk13, openjdk14, and openjdk15. We will fix compatibility with previous versions of the implementation by incompletely and inefficiently re-implement the use of CL:PATHNAME-DEVICE to "paper over” the use of nested jar references. The ability to access nested jar entries via CL:PATHNAME references has been broken since the openjdk support for nested references to jar files dropped for their creation. Nobody seemed to notice this problem, accept for customers of the [ASDF-JAR][4] contrib which is currently unable to load classes Since either openjdk5 or openjdk6, references like #p"jar:jar:file:/var/tmp/cl-ppcre-2.1.1.jar!/cl-ppcre/packages.abcl!/__loader__._” while syntactically valid cannot actually address the contents on zip files withing zip files. Since we would like such nested jar entries for use by strategies like ABCL All-in-Once (AiO), with [abcl-1.8.0][2] will allow an arbitrary PATHNAME-DEVICE component designating a sequence of nested archive entries. With openjdk8, we can use abstractions to make the caching efficient, but the current strategy (will) just reference everything by a weak reference to allow the implementation to garbage collect if it finds itself under memory pressure. In an era of the available of cheap gibibyte heaps, potentially retaining references to the bytes of artifacts accessed via CL:LOAD will be a viable strategy for at least the core implementation which is only ~ 11 mebibyte. ABCL-2.0.0 will use all of the ABCL-1.8.0 code in additional to an implementation of multi-threaded sensitive atomic operations supporting ubiquitous contemporary ANSI CL compare and swap for memory. The presence of a new compiler for ABCL-2.0.0 is no longer a release driver as it currently stands, but I would love some help if it shows up. Once I get things working well under openjdk8, I will start to work on the new compiler infrastructure. Comments, patches, criticisms welcome! yours, Mark [1]: <https://github.com/armedbear/abcl/blob/05e4b396658d7ba4bd074a8e4f627deec3b7…> [2]: <https://abcl.org/trac/milestone/1.8.0> [3]: <https://abcl.org/trac/milestone/2.0.0> [4]: <https://gitlab.common-lisp.net/abcl/abcl/-/blob/master/contrib/abcl-asdf/RE…> [5]: <https://gitlab.common-lisp.net/abcl/abcl/-/commit/0ba7dea278a474efe0a8e7550…> [6]: <https://travis-ci.org/github/armedbear/abcl/jobs/728128870> -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

1 0

Challenge with ABCL on a commercial project: Licensing
by Steven Nunez 07 Sep '20

07 Sep '20

Gents, I nearly had ABCL into an upcoming project, until I checked the license. I should have looked at this before I embarked down this path, but for some reason assumed that since ABCL is a relatively young implementation it was using Apache/MIT/BSD or something similar. Here's the opensource clause from the contract: 1.1 OPEN SOURCE SOFTWARE. To the extent that the Company develops orprovides any software to <Customer> under this Agreement, without <Customer’s> priorwritten consent, that <Customer> may grant or withhold in its sole discretion, nosuch deliverable shall incorporate, link to or call upon any Open SourceSoftware. “Open Source Software” means any software that is generally availableto the public in source code form under (i) licenses substantially similar tothose approved by the Open Source Initiative and listed athttp://www.opensource.org/licenses, or (ii) any copyleft license (including aReciprocal License), or (iii) any other license that contains terms thatrequire, whether or not conditionally, disclosure of any source code. This clause, or one very much like it, has been in every contract for the last 10 years or so, or at least since the BusyBox debacle. Most of the time companies have a list of pre-approved licenses, with MIT/Apache/BSD almost always being on it. Note the specific exclusion "any copyleft license" and any license in any form that might cause disclosure of source code. Reading the ABCL FAQ and web page, it seems the intention is to avoid compelling a company from releasing their source code: The use of Armed Bear Common Lisp (ABCL) is covered by the GNU General Public License with Classpath exception, meaning that you can use ABCL in your application without the requirement to open the sources to your application. However there's a few problem with this: - It has the words "GNU General Public License", which rings loud alarm bells with corporate lawyers (and is disqualified by clauses ii/iii anyway) - Whilst the intention is to allow ABCL to be mixed with proprietary code, the IP equivalent of ambulance chasing lawyers may still see it as an opportunity for profit. It's worth reading the BusyBox saga if you're not familiar with it. - It's never been tested in court The last point is worth elaborating on. I once cornered a friendly corporate lawyer at one of our company drinks functions and showed him the LLGPL and asked what he thought. His response put it all in perspective. He said: "It looks fine to me, but it's never been tested in court. Would you take an open source project and deploy it to production and bet the company's livelihood on it, without testing it first?" I guess I can't blame them really. Would you want stick your neck out for something with potentially catastrophic consequences, when there's plenty of alternatives? Lisp has enough of an uphill climb just on the technology front, this is the nail in the coffin. Questions: - Would the current maintainers of ABCL consider relicensing it under a MIT, BSD or Apache license? - If so, do we have a list of all the contributors? - If so, how many are there and are they contactable?

6 9

Test
by Steven Nunez 08 Aug '20

08 Aug '20

Testing. I sent out a message last night but haven't seen it yet; neither in my mailbox nor the archives.

1 0

Am I at a dead-end?
by Steven Nunez 07 Aug '20

07 Aug '20

I've been looking at a few other ways to accomplish wrapping Spark, and none look good. I could generate Java functions, which seem to be inherently serialisable, but that defeats the point of using ABCL. I also considered an approach using Java to call into ABCL, but then I've got to ensure that the ABCL functions are distributed to each node, defeating the point of using Spark. @Alessio Stalla, your most recent github commit suggests that things might have moved along to the point that function and closure serialisation is working. Are things stable enough to give it a try? Not this week, but perhaps on Monday? I'm happy to debug anything that I turn up. There's a new project on the horizon and I'd like to use the Java compatibility angle to try and get Lisp into it. If I'm lucky, I may not even have to mention lisp, depending on how/if the contract terms work out.

2 3

Regarding Steps Towards ABCL STEP Functionality
by loveleague 03 Aug '20

03 Aug '20

Hello, While reading through the release manual, I came across the realization -- from section 1.1.2 -- that ABCL still needs an implementation of the STEP function. I would like to look into the details of the hurdles one might need to overcome to bring STEP functionality to ABCL. I imagine there may be some additional challenges from dealing with the JVM, but I'm not well versed as of yet on the topic of debuggers or JVM internals. If it would be possible to share some details on where one would get started in trying to approach this, that would be appreciated. - Luke

4 3

run-program issues with OpenJDK 11
by Eric Timmons 30 Jul '20

30 Jul '20

It appears that java.lang.UNIXProcess was removed in OpenJDK 9 or thereabouts, assuming I'm interpreting https://github.com/openjdk/jdk/commit/aa6b19f38ee4dc69cac664d1211bff0e69b31… correctly (/definitely/ not a Java developer here...). This seems to make run-program unusable when using prebuilt jars on recent JREs. Using the prebuilt 1.7.0 release and OpenJDK 11, I get the errors shown in prebuilt-openjdk11.txt (attached). If compiling using OpenJDK 11, run-program seems usable, but any attempt to get the PID of a process gives the error in from-source-openjdk11.txt (attached). -Eric VM settings: Max. Heap Size (Estimated): 7.79G Using VM: OpenJDK 64-Bit Server VM Armed Bear Common Lisp 1.7.0 Java 11.0.7 Oracle Corporation OpenJDK 64-Bit Server VM Low-level initialization completed in 0.198 seconds. Startup completed in 1.107 seconds. Type ":help" for a list of available commands. CL-USER(1): (sys:run-program "ls" nil) Error loading jar:file:/home/abcl/work/abcl/dist/abcl.jar!/org/armedbear/lisp/run-program.abcl at line 278 (offset 19142) #<THREAD "interpreter" {5C1AE0C4}>: Debugger invoked on condition of type ERROR Class not found: java.lang.UNIXProcess Restarts: 0: TOP-LEVEL Return to top level. [1] SYS(2): 0 java.lang.ExceptionInInitializerError at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490) at java.base/java.lang.Class.newInstance(Class.java:584) at org.armedbear.lisp.FaslClassLoader.loadFunction(FaslClassLoader.java:130) at org.armedbear.lisp.FaslClassLoader$pf_get_fasl_function.execute(FaslClassLoader.java:165) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:582) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:577) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.SpecialOperators$sf_progn.execute(SpecialOperators.java:273) at org.armedbear.lisp.Lisp.eval(Lisp.java:530) at org.armedbear.lisp.Load.faslLoadStream(Load.java:667) at org.armedbear.lisp.Load$init_fasl.execute(Load.java:457) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:582) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Load.loadStream(Load.java:629) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:597) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:477) at org.armedbear.lisp.Load.loadSystemFile(Load.java:375) at org.armedbear.lisp.Load.loadSystemFile(Load.java:255) at org.armedbear.lisp.Autoload.effectiveLoad(Autoload.java:110) at org.armedbear.lisp.Autoload.load(Autoload.java:147) at org.armedbear.lisp.Lisp.eval(Lisp.java:537) at org.armedbear.lisp.Primitives$pf__eval.execute(Primitives.java:345) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:575) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.Primitives$sf_block.execute(Primitives.java:3743) at org.armedbear.lisp.Lisp.eval(Lisp.java:530) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.Closure.execute(Closure.java:220) at org.armedbear.lisp.Closure.execute(Closure.java:148) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp$1.execute(Lisp.java:285) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.top_level_47.execute(top-level.lisp:407) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:89) at org.armedbear.lisp.Symbol.execute(Symbol.java:793) at org.armedbear.lisp.LispThread.execute(LispThread.java:798) at org.armedbear.lisp.top_level_48.execute(top-level.lisp:415) at org.armedbear.lisp.LispThread.execute(LispThread.java:798) at org.armedbear.lisp.Interpreter.run(Interpreter.java:361) at org.armedbear.lisp.Main$1.run(Main.java:48) at java.base/java.lang.Thread.run(Thread.java:834) Caused by: org.armedbear.lisp.Go Error loading jar:file:/home/abcl/work/abcl/dist/abcl.jar!/org/armedbear/lisp/run-program.abcl at line 278 (offset 19142) #<THREAD "interpreter" {5C1AE0C4}>: Debugger invoked on condition of type ERROR Compiled function can't be loaded: org.armedbear.lisp.run_program_60 from org.armedbear.lisp.Pathname@49bd2fd0 Restarts: 0: TOP-LEVEL Return to top level. [1] SYS(3): 0 CL-USER(4): (exit) VM settings: Max. Heap Size (Estimated): 7.79G Using VM: OpenJDK 64-Bit Server VM Armed Bear Common Lisp 1.7.1-dev Java 11.0.7 Oracle Corporation OpenJDK 64-Bit Server VM Low-level initialization completed in 0.205 seconds. Startup completed in 1.224 seconds. Type ":help" for a list of available commands. CL-USER(1): (sys:run-program "ls" nil :wait nil) #S(SYSTEM:PROCESS :JPROCESS #<java.lang.ProcessImpl Process[pid=125, exitValue=0] {1E464845}> :%INPUT #S(SYSTEM::SYSTEM-STREAM) :%OUTPUT #S(SYSTEM::SYSTEM-STREAM) :%ERROR #S(SYSTEM::SYSTEM-STREAM)) CL-USER(2): (sys:process-pid *) #<THREAD "interpreter" {7278E1D6}>: Debugger invoked on condition of type ERROR Class not found: java.lang.UNIXProcess Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(3): 0 CL-USER(4): (exit)

3 8

java:jinterface-implementation: multiple interfaces?
by Steven Nunez 30 Jul '20

30 Jul '20

Is there a way to implement multiple interfaces on a single Java proxy? This code almost works: (java:jinterface-implementation "org.apache.spark.api.java.function.Function" "call" (lambda (s) (length s))) except that the proxy also needs to implement Serializable. The jproxy code in java.lisp seems to suggest that multiple implementations are allowed: (defgeneric jmake-proxy (interface implementation &optional lisp-this) (:documentation "Returns a proxy Java object implementing the provided interface(s)... but I can't see adding multiple implementations in the code. I see there's a few jmake-proxy methods in there though: are there any documentation or examples for their usage? Lsw2 doesn't use this at all and I can't find any other good examples of using ABCL. Multiple interfaces from the jinterface-implementation function would be ideal, as the above code could then be wrapped with a macro to produce a 'spark-lambda' and be used nearly like the regular ABCL lambda.

3 12

JDK8 Style Lambda Functions and ABCL
by Steven Nunez 30 Jul '20

30 Jul '20

Greetings all, I'm trying to convert the following Java code in the "Basics" section of the Spark Programming Guide to ABCL: JavaRDD<Integer> lineLengths = lines.map(s -> s.length()); I know that "s -> s.length" is a JDK8 style lambda function with one parameter, returning the result of calling length() on 's'. What I'd like to be able to do is write: (let ((line-lengths (#"map" *lines* (lambda (s) (#"length" s))))) but this isn't getting me anywhere, with Java saying there is no applicable method 'map' on *lines* (an instance of JavaRDD). There is such a method (if it matters, it is inherited by JavaRDD from interface JavaRDDLike). Investigating that map method a bit further, it seems to want an org.apache.spark.api.java.function. Here's a clip from the Spark description: Spark’s API relies heavily on passing functions in the driver program to run on the cluster. In Java, functions are represented by classes implementing the interfaces in the org.apache.spark.api.java.function package. There are two ways to create such functions: - Implement the Function interfaces in your own class, either as an anonymous inner class or a named one, and pass an instance of it to Spark. - Use lambda expressions to concisely define an implementation. I think what I'm getting from the ABCL lambda expression is a java.util.function: SPARK> (describe (lambda (s) #"length" s))#<FUNCTION #<FUNCTION (LAMBDA (S)) {70B82AD0}> {70B82AD0}> is an object of type FUNCTION.The function's lambda list is: (S) I do wonder though how the Java lambda "s -> s.length()" manages to produce the correct result, so this theory may not be correct. The Spark guide goes on to say: While much of this guide uses lambda syntax for conciseness, it is easy to use all the same APIs in long-form. For example, we could have written our code above as follows: JavaRDD<String> lines = sc.textFile("data.txt"); JavaRDD<Integer> lineLengths = lines.map(new Function<String, Integer>() { public Integer call(String s) { return s.length(); } }); int totalLength = lineLengths.reduce(new Function2<Integer, Integer, Integer>() { public Integer call(Integer a, Integer b) { return a + b; } }); Or, if writing the functions inline is unwieldy: class GetLength implements Function<String, Integer> { public Integer call(String s) { return s.length(); } } class Sum implements Function2<Integer, Integer, Integer> { public Integer call(Integer a, Integer b) { return a + b; } } JavaRDD<String> lines = sc.textFile("data.txt"); JavaRDD<Integer> lineLengths = lines.map(new GetLength()); int totalLength = lineLengths.reduce(new Sum()); To me, both of those examples look unwieldy. There was a stack overflow discussion on creating Java classes with ABCL from 9 years ago, and I've read the java interface examples on abcl.org, but both of those techniques look like they will produce code just as unwieldy as the Java syntax above. Is there any way to use a lisp-style lambda syntax to produce a function that will satisfy Spark's requirement to implement the org.apache.spark.api.java.function interface? If not, the obvious route would be some macrology to create a defsparkfun, defsparkfun2, etc. that wrap the ABCL function I want to use with something that implements 'call' in the org.apache.spark.api.java.function interface. I'm hoping there's a better way.

2 3

Third Brick Wall
by Steven Nunez 27 Jul '20

27 Jul '20

OK, I'm on lines 4 and 5 of 'hello world' and ran into yet another brick wall. Trying to convert the following two lines into ABCL: List<Integer> data = Arrays.asList(1, 2, 3, 4, 5); JavaRDD<Integer> distData = sc.parallelize(data); it looks like it should be easy. Heck, I can do that in one line: (#"parallelize" *sc* '(1 2 3 4 5)) ; *sc* defined yesterday and known to be correct But no, it claims "no applicable method named parallelize found on JavaSparkContext" (but there is!). Reading through section 3.1.1 of the documentation, it appears that this is probably because '(1 2 3...) is a LispObject and not a Java object (why no automatic conversion?). Let's try to convert it: (#"parallelize" *sc* (#"copytoArray" '(1 2 3 4 5))) No instance method named copytoArray found for type org.armedbear.lisp.Cons' And the same with using an array, e.g. (#"parallelize" *sc* (#"copytoArray" #(1 2 3 4 5))) Sigh It's been a week and my intention was to have a working prototype by now and present ABCL as a viable alternative to use in a project. I haven't got past line 5 in 'hello world'. This doesn't bode well. I've been reading about ABCL for years, and it's impressive. Full MOP, extensible sequences, nearly 100% ANSI compliance, and the ability to deploy on the JVM are major achievements. However, as a not-inexperienced Lisp programmer, I find the barrier to entry remarkably high and the documentation and examples sparse and insufficient to surmount the hurdles I encountered. Please take these comments in the way they are intended: constructive feedback from someone who is a fan of the project and would love to be able to use it. It's nearly impossible to get Lisp introduced into enterprise environments, and ABCL provides a wedge into those types of projects, ticking the boxes on deployment and ability to work with legacy Java code. Perhaps it makes more sense to someone approaching Lisp from the Java side, but coming from the Lisp side to Java, there's a high barrier to entry. I know that no volunteer wants to write documentation, but more and clearer docs are sorely needed here. This is probably not news, but sometimes it helps to be reminded of the obvious. I hate giving up, so this will be a personal background project in the hopes that at the next opportunity things will have improved to the point where we can consider introducing ABCL, so if anyone has any pointers, generally (though I think I would have found any docs or examples (lsw2) by now) and explaining this problem in particular, it would be greatly appreciated. @easye, you mentioned your ember project. If you're going to continue with that, please message me. A Spark wrapper would be useful, serve as a good exemplar for using ABCL to wrap a large library and, with a companion tutorial, help others overcome the kind of obstacles I've encountered. I'd be happy to contribute.

4 9

Create instance of generic class at runtime, supplying specializer?
by Alan Ruttenberg 21 Jul '20

21 Jul '20

For instance in http://owlcs.github.io/owlapi/apidocs_4/org/semanticweb/owlapi/util/Inferre… It says: Type Parameters:A - the axiom type Question is: how do I supply the axiom type when creating an instance. Thanks ALan

3 5