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

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

abcl-1.7.1 released
by Mark Evenson 18 Jul '20

18 Jul '20

With gentle prodding, we have released ABCL 1.7.1, a decidedly minor release correcting a few bugs resulting from the overhaul of arrays specialized on unsigned byte types. The brief list of CHANGES is a available for your perusal. <https://abcl.org/releases/1.7.1/> <https://abcl.org/svn/tags/1.7.1/CHANGES>. "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

1 0

ABCL-1.7.0 released
by Mark Evenson 04 Jun '20

04 Jun '20

We are pleased to announce the immediate availablity of the [ABCL 1.7.0 release][]. After consuming a steady diet of java.nio.ByteBuffer objects over the past month, the Bear has managed to incorporate the use of these abstractions for arrays specialized on the commonly used unsigned-byte types (or (unsigned-byte 8) (unsigned-byte 16) (unsigned-byte 32)). This replacement of the use arrays of primitive bytes is denoted by the presence of the :NIO keyword in CL:*FEATURES*. With this :NIO overhaul, we have extended our implementation of ANSI Common Lisp [CL:MAKE-ARRAY][] with two additional keywords, viz. :NIO-BUFFER and :NIO-DIRECT. The :NIO-BUFFER keyword argument allows one to construct a vector directly utilizing the contents of an already allocated java.nio.ByteBuffer object. When combined with the ability of JNA to allocate memory on the heap via a malloc() system call, we implemented shareable byte vectors in [CFFI-SYS:MAKE-SHAREABLE-BYTE-VECTOR][]. (let* ((length 16) (byte-buffer (java:jstatic "allocate" "java.nio.ByteBuffer" length))) (make-array length :element-type ’(unsigned-byte 8) :nio-buffer byte-buffer)) When the :NIO-DIRECT keyword argument is called with a non-NIL value, the implementation creates a byte vector with a "directly allocated" java.nio.ByteBuffer object. Such direct buffers typically have somewhat higher allocation and deallocation costs than non-direct buffers. The contents of direct buffers may reside outside of the normal garbage-collected heap, and so their impact upon the memory footprint of an application might not be obvious. It is therefore recommended that direct buffers be allocated primarily for large, long-lived buffers that are subject to the underlying system’s native I/O operations. In general it is best to allocate direct buffers only when they yield a measureable gain in program performance. In the near future, we intend to exploring the performance gains available CL:LOAD by accessing direct buffers memory mapped to our on-disk fasl representation. Our fasls, as zipped archives, currently require a new seek() from the beginning of the fasl for each component they contain. With a memory mapped direct buffer we should be able to simply read from the appropiate byte offset for each component. A complete overview of the accumulated fixes and changes since the previous release may be viewed in [CHANGES][]. [ABCL 1.7.0 release]: https://abcl.org/releases/1.7.0/ [java.nio.ByteBuffer]: https://www.doc.ic.ac.uk/csg-old/java/jdk6docs/api/java/nio/ByteBuffer.html [CFFI-SYS:MAKE-SHAREABLE-BYTE-VECTOR]: https://github.com/cffi/cffi/commit/47136ad9a97c2df98dbcd13a068e14489ced5b03 [CHANGES]: https://abcl.org/svn/tags/1.7.0/CHANGES [CL:MAKE-ARRAY]: https://github.com/armedbear/abcl/commit/6c4b7f3c11b2c8151f4599c9bddf5c0991… -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

3 3

Re: armedbear-devel Digest, Vol 64, Issue 4
by Stephen Varey 20 May '20

20 May '20

I have also tried powerloom with Allegro common lisp which works fine. It works with LispWorks if you change one option to do with a the latin-1 char set. On Wed, May 20, 2020 at 2:00 PM <armedbear-devel-request(a)common-lisp.net> wrote: > Send armedbear-devel mailing list submissions to > armedbear-devel(a)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(a)common-lisp.net > > You can reach the person managing the list at > armedbear-devel-owner(a)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: help with verify error (Mark Evenson) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 19 May 2020 22:19:00 +0200 > From: Mark Evenson <evenson(a)panix.com> > To: abcl-dev <armedbear-devel(a)common-lisp.net> > Cc: Stephen Varey <srvarey(a)gmail.com> > Subject: Re: help with verify error > Message-ID: <C407C514-EE3B-4651-A4A0-1105B2651A7C(a)panix.com> > Content-Type: text/plain; charset=utf-8 > > > > > On May 18, 2020, at 18:42, Stephen Varey <srvarey(a)gmail.com> wrote: > > > > I am trying to load powerloom into abcl. > > > > If you download powerloom ( > https://www.isi.edu/isd/LOOM/PowerLoom/download.html#PowerLoom) > > > > start abcl and then (load "~/powerloom-4.0.10/load-powerloom.lisp") ;;; > assuming downloaded into home directory > > > > It fails with the following stacktrace. > > > > Can you help? > > This code expresses a bug in the compiler. Due to the ISI codebase doing > what > would be considered nowawdays real hacks around compilation, it will take > a bit > of effort to isolate the exact problem in the compiler, but it gives a > practical problem to improve the disassembly tools. > > The ISI codebase hasn’t been updated since 2010. It works under CCL, but > not > SBCL so ABCL isn’t the only implementation with problems here. > > I’ve filed [an issue][186][467]. > > [186]: https://github.com/armedbear/abcl/issues/186 > [467]: https://abcl.org/trac/ticket/467 > > Thanks for trying out the Bear; we’ll see what we can do to get your code > running, as it is a great example of a substantial application. > > > > > STELLA 3.5.35 loaded. > > Type `(in-package "STELLA")' to execute STELLA commands.Making required > system logic > > java.lang.VerifyError: (class: org/armedbear/lisp/pl_kernel_kb_2, > method: <clinit> signature: ()V) Bad type in putfield/putstatic > > at java.lang.Class.getDeclaredConstructors0(Native Method) > > at java.lang.Class.privateGetDeclaredConstructors(Class.java:2671) > > at java.lang.Class.getConstructor0(Class.java:3075) > > at java.lang.Class.newInstance(Class.java:412) > > at > org.armedbear.lisp.FaslClassLoader.loadFunction(FaslClassLoader.java:130) > […] > > at java.lang.Thread.run(Thread.java:745) > > Error loading > /home/srv/powerloom-4.0.10/native/lisp/bin/lisp/logic/pl-kernel-kb.sabcl at > line 44 (offset 3242) > > #<THREAD "interpreter" {5B983350}>: Debugger invoked on condition of > type ERROR > > Compiled function can't be loaded: org.armedbear.lisp.pl_kernel_kb_2 > from org.armedbear.lisp.Pathname@54789d54 > > Restarts: > > 0: TOP-LEVEL Return to top level. > > [1] STELLA(2): > > -- > "A screaming comes across the sky. It has happened before but there is > nothing > to compare to it now." > > > > > > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > armedbear-devel mailing list > armedbear-devel(a)common-lisp.net > https://mailman.common-lisp.net/listinfo/armedbear-devel > > > ------------------------------ > > End of armedbear-devel Digest, Vol 64, Issue 4 > ********************************************** >

1 0

help with verify error
by Stephen Varey 19 May '20

19 May '20

I am trying to load powerloom into abcl. If you download powerloom ( https://www.isi.edu/isd/LOOM/PowerLoom/download.html#PowerLoom) start abcl and then (load "~/powerloom-4.0.10/load-powerloom.lisp") ;;; assuming downloaded into home directory It fails with the following stacktrace. Can you help? CL-USER(1): ; Caught STYLE-WARNING: ; redefining STELLA::GET-SGT in #P"/home/srv/powerloom-4.0.10/native/lisp/stella/symbols.slisp" (previously defined in #P"/home/srv/powerloom-4.0.10/native/lisp/stella/cl-lib/cl-setup.slisp") ; Caught STYLE-WARNING: ; redefining STELLA::/STELLA/DEFMODULE in #P"/home/srv/powerloom-4.0.10/native/lisp/stella/cl-lib/stella-to-cl.slisp" (previously defined in #P"/home/srv/powerloom-4.0.10/native/lisp/stella/modules.slisp") ; Caught STYLE-WARNING: ; redefining STELLA::/STELLA/DEFDEMON in #P"/home/srv/powerloom-4.0.10/native/lisp/stella/cl-lib/stella-to-cl.slisp" (previously defined in #P"/home/srv/powerloom-4.0.10/native/lisp/stella/demons.slisp") ; Compilation unit finished ; Caught 3 STYLE-WARNING conditions *** This Stella image uses CL-structs instead of CLOS instances *** STELLA 3.5.35 loaded. Type `(in-package "STELLA")' to execute STELLA commands.Making required system logic java.lang.VerifyError: (class: org/armedbear/lisp/pl_kernel_kb_2, method: <clinit> signature: ()V) Bad type in putfield/putstatic at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2671) at java.lang.Class.getConstructor0(Class.java:3075) at java.lang.Class.newInstance(Class.java:412) 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.load(Load.java:224) at org.armedbear.lisp.Load.load(Load.java:745) at org.armedbear.lisp.Load$_load.execute(Load.java:693) at org.armedbear.lisp.Symbol.execute(Symbol.java:852) at org.armedbear.lisp.LispThread.execute(LispThread.java:894) at org.armedbear.lisp.load_1.execute(load.lisp:33) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.cl_translate_file_22.execute(cl-translate-file.slisp:357) at org.armedbear.lisp.compiler_pass2_370.execute(compiler-pass2.lisp:7511) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.cl_translate_file_21.execute(cl-translate-file.slisp:357) at org.armedbear.lisp.Symbol.execute(Symbol.java:826) at org.armedbear.lisp.systems_67.execute(systems.slisp:1266) at org.armedbear.lisp.Symbol.execute(Symbol.java:826) at org.armedbear.lisp.systems_63.execute(systems.slisp:1192) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.systems_51.execute(systems.slisp:922) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.systems_40.execute(systems.slisp:692) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.systems_41.execute(systems.slisp:755) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.systems_42.execute(systems.slisp:782) at org.armedbear.lisp.walk_401.execute(walk.slisp:6703) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.walk_395.execute(walk.slisp:6641) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.systems_33.execute(systems.slisp:561) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.systems_34.execute(systems.slisp:611) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.systems_45.execute(systems.slisp:813) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.systems_51.execute(systems.slisp:922) 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.eval(Lisp.java:533) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.Primitives$sf_unless.execute(Primitives.java:867) at org.armedbear.lisp.Lisp.eval(Lisp.java:530) at org.armedbear.lisp.Load.loadStream(Load.java:629) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:597) at org.armedbear.lisp.Load.load(Load.java:224) at org.armedbear.lisp.Load.load(Load.java:745) at org.armedbear.lisp.Load$_load.execute(Load.java:693) at org.armedbear.lisp.Symbol.execute(Symbol.java:852) at org.armedbear.lisp.LispThread.execute(LispThread.java:894) at org.armedbear.lisp.load_1.execute(load.lisp:33) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) 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.eval(Lisp.java:538) 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.lang.Thread.run(Thread.java:745) Error loading /home/srv/powerloom-4.0.10/native/lisp/bin/lisp/logic/pl-kernel-kb.sabcl at line 44 (offset 3242) #<THREAD "interpreter" {5B983350}>: Debugger invoked on condition of type ERROR Compiled function can't be loaded: org.armedbear.lisp.pl_kernel_kb_2 from org.armedbear.lisp.Pathname@54789d54 Restarts: 0: TOP-LEVEL Return to top level. [1] STELLA(2):

2 1

Re: Bug with lambda expressions (ABCL 1.6.1)
by Mark Evenson 07 May '20

07 May '20

> On May 7, 2020, at 23:14, Alan Ruttenberg <alanruttenberg(a)gmail.com> wrote: > > Nice catches! > Tests for both compiler bugs added via PROVE as <https://github.com/armedbear/abcl/pull/175>. […] -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

1 0

Bug with lambda expressions (ABCL 1.6.1)
by Paul Dietz 07 May '20

07 May '20

(compile nil '(lambda () ((lambda () ((lambda () 0)))))) => The value (LAMBDA NIL 0) is not of type SYMBOL. [Condition of type TYPE-ERROR] Restarts: 0: [TOP-LEVEL] Return to top level. Backtrace: 0: (#<FUNCTION {6495CFA3}> #<TYPE-ERROR {FAD3C52}> #<FUNCTION {6495CFA3}>) 1: (APPLY #<FUNCTION {6495CFA3}> (#<TYPE-ERROR {FAD3C52}> #<FUNCTION {6495CFA3}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<TYPE-ERROR {FAD3C52}> #<FUNCTION {6495CFA3}>) 3: (INVOKE-DEBUGGER #<TYPE-ERROR {FAD3C52}>) 4: org.armedbear.lisp.Lisp.error(Lisp.java:382) 5: org.armedbear.lisp.Lisp.type_error(Lisp.java:435) 6: org.armedbear.lisp.Lisp.checkSymbol(Lisp.java:1097) 7: org.armedbear.lisp.Lisp.get(Lisp.java:1973) 8: org.armedbear.lisp.precompiler_53.execute(precompiler.lisp:402) 9: org.armedbear.lisp.Symbol.execute(Symbol.java:814) 10: org.armedbear.lisp.LispThread.execute(LispThread.java:832) 11: org.armedbear.lisp.precompiler_51.execute(precompiler.lisp:381) 12: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 13: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 14: org.armedbear.lisp.precompiler_48.execute(precompiler.lisp:350) 15: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 16: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 17: org.armedbear.lisp.precompiler_73.execute(precompiler.lisp:643) 18: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 19: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 20: org.armedbear.lisp.precompiler_48.execute(precompiler.lisp:350) 21: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 22: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 23: org.armedbear.lisp.precompiler_104.execute(precompiler.lisp:988) 24: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) 25: org.armedbear.lisp.Symbol.execute(Symbol.java:826) 26: org.armedbear.lisp.compiler_pass2_362.execute(compiler-pass2.lisp:7436) 27: org.armedbear.lisp.Symbol.execute(Symbol.java:867) 28: org.armedbear.lisp.compiler_pass2_387.execute(compiler-pass2.lisp:7556) 29: org.armedbear.lisp.compiler_pass2_370.execute(compiler-pass2.lisp:7511) 30: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) 31: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 32: org.armedbear.lisp.compiler_pass2_386.execute(compiler-pass2.lisp:7556) 33: org.armedbear.lisp.Symbol.execute(Symbol.java:838) 34: org.armedbear.lisp.compiler_pass2_388.execute(compiler-pass2.lisp:7580) 35: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) 36: org.armedbear.lisp.Symbol.execute(Symbol.java:814) 37: org.armedbear.lisp.compiler_pass2_392.execute(compiler-pass2.lisp:7650) 38: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) 39: org.armedbear.lisp.LispThread.execute(LispThread.java:832) 40: org.armedbear.lisp.Lisp.evalCall(Lisp.java:582) 41: org.armedbear.lisp.Lisp.eval(Lisp.java:540) 42: org.armedbear.lisp.Primitives$pf__eval.execute(Primitives.java:345) 43: (PRECOMPILER::PRECOMPILE-FUNCTION-POSITION-LAMBDA (LAMBDA NIL ((LAMBDA NIL 0))) NIL) 44: (PRECOMPILER::PRECOMPILE-FUNCTION-CALL ((LAMBDA NIL (#)))) 45: (PRECOMPILER::PRECOMPILE1 ((LAMBDA NIL (#)))) 46: (PRECOMPILER::PRECOMPILE-LAMBDA (LAMBDA NIL ((LAMBDA NIL #)))) 47: (PRECOMPILER::PRECOMPILE1 (LAMBDA NIL ((LAMBDA NIL #)))) 48: (COMPILE NIL (LAMBDA NIL ((LAMBDA NIL #)))) 49: (SYSTEM::%EVAL (COMPILE NIL '(LAMBDA NIL (#)))) 50: (EVAL (COMPILE NIL '(LAMBDA NIL (#)))) 51: (SYSTEM:INTERACTIVE-EVAL (COMPILE NIL '(LAMBDA NIL (#)))) 52: (TOP-LEVEL::REPL) 53: (TOP-LEVEL::TOP-LEVEL-LOOP) ________________________________ The information contained in this e-mail and any attachments from GrammaTech, Inc may contain confidential and/or proprietary information, and is intended only for the named recipient to whom it was originally addressed. If you are not the intended recipient, any disclosure, distribution, or copying of this e-mail or its attachments is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by return e-mail and permanently delete the e-mail and any attachments.

2 1

Manually allowed your non-subscription address to post to armedbear-devel
by Mark Evenson 07 May '20

07 May '20

Paul, I’ve taken the liberty of manually allowing your recent messages to the <armedbear-devel@…> mailing list to propagate in spite of this address bot being subscribed to the list. [1]: https://mailman.common-lisp.net/pipermail/armedbear-devel/2020-May/004054.h… [2]: https://mailman.common-lisp.net/pipermail/armedbear-devel/2020-May/004055.h… If you wish your messages to go through without needing administrative approval, please consider subscribing to the list Happy to have your questions about ABCL: without the ANSI-TEST suite, we would be a much poorer Bear. sincerely, Mark -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

1 0

Bug with CATCH w. constant form
by Paul Dietz 07 May '20

07 May '20

(compile nil '(lambda () (dotimes (i 1 2) (catch 'c 3)))) ==> COMPILE-TAGBODY: tag not found: 3 [Condition of type SIMPLE-ERROR] Restarts: 0: [TOP-LEVEL] Return to top level. Backtrace: 0: (#<FUNCTION {6495CFA3}> #<SIMPLE-ERROR {74889B81}> #<FUNCTION {6495CFA3}>) 1: (APPLY #<FUNCTION {6495CFA3}> (#<SIMPLE-ERROR {74889B81}> #<FUNCTION {6495CFA3}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<SIMPLE-ERROR {74889B81}> #<FUNCTION {6495CFA3}>) 3: (INVOKE-DEBUGGER #<SIMPLE-ERROR {74889B81}>) 4: (COMPILE NIL (LAMBDA NIL (DOTIMES (I 1 2) (CATCH 'C 3)))) 5: (SYSTEM::%EVAL (COMPILE NIL '(LAMBDA NIL (DOTIMES # #)))) 6: (EVAL (COMPILE NIL '(LAMBDA NIL (DOTIMES # #)))) 7: (SYSTEM:INTERACTIVE-EVAL (COMPILE NIL '(LAMBDA NIL (DOTIMES # #)))) 8: (TOP-LEVEL::REPL) 9: (TOP-LEVEL::TOP-LEVEL-LOOP) ________________________________ The information contained in this e-mail and any attachments from GrammaTech, Inc may contain confidential and/or proprietary information, and is intended only for the named recipient to whom it was originally addressed. If you are not the intended recipient, any disclosure, distribution, or copying of this e-mail or its attachments is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by return e-mail and permanently delete the e-mail and any attachments.

1 0

Problems compiling abcl-1.6.1
by Mark Evenson 28 Apr '20

28 Apr '20

[For some reason Greg’s message wasn’t delivered via email, so I am replying “out of band” without the proper SMTP headers.] > I am an ABCL user, but by no means an expert. I just unpacked the source > zip file and tried to compile it without success. I am using Java 14.0.1 > and Ant 1.9.6. The resulting output is attached. buildfile: C:\Users\baryza\__Library\Armed_Bear_Lisp\abcl-src-1.6.1\build.xml […] abcl.compile.java: [javac] Compiling 271 source files to C:\Users\baryza\__Library\Armed_Bear_Lisp\abcl-src-1.6.1\build\classes [javac] warning: [options] bootstrap class path not set in conjunction with -source 6 [javac] error: Source option 6 is no longer supported. Use 7 or later. [javac] error: Target option 6 is no longer supported. Use 7 or later. For Java 14, we need to tell the compiler to target the right source compatibility. There is a script in `ci/create-abcl-properties.bash` that works with Bash to do configuration, but I see from your logs that you are running under Windows. So do the steps manually: 1. copy `abcl.properties.in` to `abcl.properties` 2. Change the line with `abcl.javac.source` to read abcl.javac.source=1.8 Then you should be able to compile (or at least get past this error). Not sure what is going on with the mailing list… -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

2 1

Release 1.6.1
by Gregory Baryza 28 Apr '20

28 Apr '20

Hello: I am an ABCL user, but by no means an expert. I just unpacked the source zip file and tried to compile it without success. I am using Java 14.0.1 and Ant 1.9.6. The resulting output is attached. Advice is appreciated. Greg Baryza

1 0

ABCL-1.6.1 Springs Forth
by Mark Evenson 28 Apr '20

28 Apr '20

As augured, the Bear is pleased to join fellow open ANSI Common Lisp implementations [CCL][], [ECL][], and [SBCL][] in publishing a new release around the online advent of the thirteenth European Lisp Symposium, [ELS2020][]. The [ABCL 1.6.1 binaries and signatures][1.6.1] are now available with their associated [CHANGES][]. Thanks to everyone involved in continuing to further the progress of our implementation. [CCL]: https://github.com/Clozure/ccl/releases/tag/v1.12 [ECL]: https://common-lisp.net/project/ecl/posts/ECL-20424-release.html [SBCL]: http://sbcl.org/news.html#2.0.4 [ELS2020]: https://european-lisp-symposium.org/2020/index.html [1.6.1] https://abcl.org/releases/1.6.1/ [CHANGES]: https://abcl.org/svn/tags/1.6.1/CHANGES -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

1 0

abcl-1.6.1 release candidate for ELS2020 rc0
by Mark Evenson 24 Apr '20

24 Apr '20

Rejoice! for the Bear has emerged from its Lair to slough off a release candidate for abcl-1.6.1 <urn:abcl/1.6.1#rc0> Currently, the release candidate rc-0 committed to cloud builds; we will be rendezvousing with the cryptographic signatures to do the actual public release on Monday, live "at" ELS 2020. Please get any outstanding github pull requests in before April 27, 2020 to be included in the release. We should now be able to accept pull requests while preserving your github identity if you are so inclined. Otherwise pseudo-anonymous patches are still solicited via this mailing list. [ABCL-BUILD]: https://github.com/easye/abcl/blob/abcl/1.6.1/ci/release.lisp [abcl.1.6.1]: https://github.com/armedbear/abcl/pull/172 [els2020]: https://european-lisp-symposium.org/2020/index.html [CHANGES]: https://github.com/easye/abcl/blob/abcl/1.6.1/CHANGES [elsconf]: https://twitter.com/elsconf stay tuned bear fans, -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

1 0

[CfPart] 13th European Lisp Symposium, happening online, free of charge!
by Didier Verna 14 Apr '20

14 Apr '20

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 13th European Lisp Symposium Special Focus on Compilers In cooperation with: ACM SIGPLAN Call for participation April 27 - April 28, 2020 Sponsored by EPITA, Igalia S.L., and RavenPack ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ #COVID19 important information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In the context of the current pandemic, the symposium has been turned into an online event, and will be open to anyone, free of charge! Connection instructions will be posted on the website when available. Invited Speakers ~~~~~~~~~~~~~~~~ Andrew W. Keep (Cisco Systems, Inc.), on the Nanopass Framework. Daniel Kochmański (Turtleware), on ECL, the Embeddable Common Lisp. Scope ~~~~~ The purpose of the European Lisp Symposium is to provide a forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp dialects, including Common Lisp, Scheme, Emacs Lisp, Clojure, Racket, ACL2, AutoLisp, ISLISP, Dylan, ECMAScript, SKILL and so on. We encourage everyone interested in Lisp to participate. This year's focus is directed towards "Compilers". Programme Chair ~~~~~~~~~~~~~~~ Ioanna M. Dimitriou H. - Igalia, Spain/Germany Local Chair ~~~~~~~~~~~ Nicolas Hafner - Shinmera, Switzerland Programme Committee ~~~~~~~~~~~~~~~~~~~ Andy Wingo - Igalia, Spain/France Asumu Takikawa - Igalia, Spain/USA Charlotte Herzeel - Imec, ExaScience Lab, Belgium Christophe Rhodes - Google, UK Irène Durand - Université Bordeaux 1, France Jim Newton - EPITA Research Lab, France Kent Pitman - HyperMeta, USA Leonie Dreschler-Fischer - University of Hamburg, Germany Marco Heisig - FAU Erlangen-Nürnberg, Germany Mark Evenson - not.org, Austria Max Rottenkolber - Interstellar Ventures, Germany Metin Evrim Ulu - Middle East Technical University, Turkey Paulo Matos - Igalia, Spain/Germany Robert Goldman - SIFT, USA Robert Strandh - Université Bordeaux 1, France Sky Hester - consultant, USA -- Resistance is futile. You will be jazzimilated. Jazz site: http://www.didierverna.com Other sites: http://www.didierverna.info

1 0

Could not transfer artifact net.java.dev.jna:jna:pom:5.5.0 from/to central (http://repo1.maven.org/maven2/): Transfer failed for http://repo1.maven.org/maven2/net/java/dev/jna/jna/5.5.0/jna-5.5.0.pom 501 HTTPS Required
by Anton Vodonosov 14 Mar '20

14 Mar '20

The following error started to happen recently (in my case in Travis CI runs of a library, which includes ABCL as one of the lisps): jnaASDF could not load because Java exception 'org.eclipse.aether.collection.DependencyCollectionException: Failed to read artifact descriptor for net.java.dev.jna:jna:jar:5.5.0'.. Could not transfer artifact net.java.dev.jna:jna:pom:5.5.0 from/to central (http://repo1.maven.org/maven2/) Transfer failed for http://repo1.maven.org/maven2/net/java/dev/jna/jna/5.5.0/jna-5.5.0.pom 501 HTTPS Required It must be caused by the following change in the maven central repo: https://support.sonatype.com/hc/en-us/articles/360041287334-Central-501-HTT… What is the best way to solve this? In other words, how to make sure ABCL uses the HTTPS versions of the central repo URLs? Best regards, - Anton

2 2

Regression from 1.5.0 in compiling SBCL on Haiku
by Alexandru Popa 02 Mar '20

02 Mar '20

Currently, ABCL is the only way to run Common Lisp on Haiku (https://www.haiku-os.org/) I try to bootstrap SBCL on Haiku usinbg ABCL. Previously, bootstrap (first stage of compilation) was possible with ABCL 1.5.0. Now with ABCL 1.6.0 the compilation fails with the attached Java error. This is a regression fomr 1.5.0.

2 3

ASDF 3.3.4 released today
by Robert Goldman 14 Feb '20

14 Feb '20

Dear Lisp Maintainers, Here is the announcement of today's bug fix release, version 3.3.4, of ASDF. This will not change the API, and fixes some issues, so it should be low-risk inclusion into your distributions. Best regards, Robert ---- In honor of Valentine's Day, and more honestly, just because it's overdue, today we release ASDF 3.3.4, the fourth bugfix release for the 3.3 release series. We urge implementations that are currently bundling previous versions of ASDF -- and especially those bundling 3.3.0 or 3.3.1 -- to upgrade to 3.3.4 at their earliest convenience. This is especially true for SBCL, for which 3.3.4 fixes a bug preventing ASDF upgrade from working smoothly. Immense thanks, as always, to Faré Rideau. Also thanks to the many bug reporters and patch submitters including (alphabetically): * Rommel Martinez * Jan Moringen * Karsten Poeck * François-René Rideau * Martin Simmons * Eric Timmons * Guillaume Le Vaillant

1 0

coerce a number to a short
by Brad Knotwell 12 Feb '20

12 Feb '20

I've been using ABCL to get access to a Java library and it's worked generally well. I have run into one problem I haven't been able to workaround. I need to make a call to a method that takes a short as an argument. I'm passing in a value--10--that fits in a short but ABCL can't find the method (presumedly due to a type issue). I've tried using jcoerce but it's not doing what I expect. What's the right way to do this? Thx. --Brad

3 10

Maven artifacts no longer available via non-TLS which breaks ABCL-ASDF
by Mark Evenson 06 Feb '20

06 Feb '20

Sometime in the last month, the Maven central repository has stopped serving non-TLS content. This change badly borks ABCL-ASDF’s use of Maven which has utilized the non-TLS version of the Maven central repository since its inception, which means that previous versions of ABCL will mysteriously stop working without one having changed any code. The error reported by ABCL is obscure, as the actual error reported by the Maven Aether class is not present anywhere in the thrown exception but rather only written to the file-system under the <file:~/.m2/> hierarchy. Initially, the error reported by ABCL resembled ones in the past which involved incompatible releases of the Maven Aether interfaces which caused me a fair amount of confusion in diagnosing this problem. Solutions: 1) One may build ABCL from source with the [required patch][1][2] 2) The bug only affects downloading artifacts, not using the local cache present under <file:~/.m2/>, so as long as one doesn’t “go to the network”, one can use locally present artifacts without problems. One could use the `mvn` command-line interface to download artifacts for ABCL to use. 3) One may patch an instance of ABCL without recompilation via the following code at the REPL or placed in <file:~/.abclrc> (require :abcl-contrib) (asdf:load-system :abcl-asdf) (setf abcl-asdf::*default-repository* "https://repo1.maven.org/maven2/“) [1]: https://github.com/armedbear/abcl/commit/42abe93f4170ee30c92ba2507780cfba06… [2]: https://abcl.org/trac/changeset/15229 -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

1 0

[CfP] Reminder: 13rd European Lisp Symposium, April 27-28, Zürich
by Didier Verna 22 Jan '20

22 Jan '20

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 13th European Lisp Symposium Special Focus on Compilers In cooperation with: ACM SIGPLAN Call for papers April 27 - April 28, 2020 GZ Riesbach Zürich, Switzerland http://www.european-lisp-symposium.org/2020 Sponsored by EPITA, Igalia S.L. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Invited Speakers ~~~~~~~~~~~~~~~~ Andrew W. Keep (Cisco Systems, Inc.), on the Nanopass Framework. Daniel Kochmański (Turtleware), on ECL, the Embeddable Common Lisp. Important Dates ~~~~~~~~~~~~~~~ - Submission deadline: February 13, 2020 - Author notification: March 16, 2020 - Final papers due: April 6, 2020 - Symposium: April 27 - 28, 2020 Scope ~~~~~ The purpose of the European Lisp Symposium is to provide a forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp dialects, including Common Lisp, Scheme, Emacs Lisp, Clojure, Racket, ACL2, AutoLisp, ISLISP, Dylan, ECMAScript, SKILL and so on. We encourage everyone interested in Lisp to participate. The European Lisp Symposium 2020 invites high quality papers about novel research results, insights and lessons learned from practical applications, and educational perspectives. We also encourage submissions about known ideas as long as they are presented in a new setting and/or in a highly elegant way. This year's focus will be directed towards "Compilers". We especially invite submissions in the following areas: - Compiler techniques - Compiler passes - Compiler compilers - Showcasing of industrial or experimental compilers - Code generation - Compiler verification - Compiler optimizations - JIT compilers Contributions are also welcome in other areas, including but not limited to: - Context-, aspect-, domain-oriented and generative programming - Macro-, reflective-, meta- and/or rule-based development approaches - Language design and implementation - Language integration, inter-operation and deployment - Development methodologies, support and environments - Educational approaches and perspectives - Experience reports and case studies Technical Program ~~~~~~~~~~~~~~~~~ We invite submissions in the following forms: * Papers: Technical papers of up to 8 pages that describe original results or explain known ideas in new and elegant ways. * Demonstrations: Abstracts of up to 4 pages for demonstrations of tools, libraries, and applications. * Tutorials: Abstracts of up to 4 pages for in-depth presentations about topics of special interest for at least 90 minutes and up to 180 minutes. All submissions should be formatted following the ACM SIGS guidelines and include ACM Computing Classification System 2012 concepts and terms. Submissions should be uploaded to Easy Chair, at the following http://www.easychair.org/conferences/?conf=els2020 Note: to help us with the review process please indicate the type of submission by entering either "paper", "demo", or "tutorial" in the Keywords field. Programme Chair ~~~~~~~~~~~~~~~ Ioanna M. Dimitriou H. - Igalia, Spain/Germany Local Chair ~~~~~~~~~~~ Nicolas Hafner - Shinmera, Switzerland Programme Committee ~~~~~~~~~~~~~~~~~~~ Andy Wingo - Igalia, Spain/France Asumu Takikawa - Igalia, Spain/USA Charlotte Herzeel - Imec, ExaScience Lab, Belgium Christophe Rhodes - Google, UK Irène Durand - Université Bordeaux 1, France Jim Newton - EPITA Research Lab, France Kent Pitman - HyperMeta, USA Leonie Dreschler-Fischer - University of Hamburg, Germany Marco Heisig - FAU Erlangen-Nürnberg, Germany Mark Evenson - not.org, Austria Max Rottenkolber - Interstellar Ventures, Germany Paulo Matos - Igalia, Spain/Germany Robert Goldman - SIFT, USA Robert Strandh - Université Bordeaux 1, France Sky Hester - consultant, USA -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

java.lang.VerifyError with PROGN
by Eric Marsden 19 Dec '19

19 Dec '19

Hi, Compiling the loading the code below (a simplified extract of SBCL's codebase, found attempting to crossbuild SBCL with ABCL) results in a VerifyError, possibly related to the implementation of PROGN. Using 1.6.1-dev-svn-15217. java.lang.VerifyError: (class: org/armedbear/lisp/foo_1, method: execute signature: (Lorg/armedbear/lisp/LispObject;)Lorg/armedbear/lisp/LispObject;) Expecting to find object/array on stack at java.base/java.lang.Class.getDeclaredConstructors0(Native Method) at java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3137) at java.base/java.lang.Class.getConstructor0(Class.java:3342) at java.base/java.lang.Class.newInstance(Class.java:556) 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) --- (in-package :cl-user) (progn (defvar*sxhash-crosscheck* nil) (defun sxhash (x) (let ((answer (if (string= x "NIL") (ash 1343225879 (- 1))))) (push (cons x answer)*sxhash-crosscheck*) answer))) -- Eric Marsden https://risk-engineering.org/

5 10

[CfP] ELS 2020, 13th European Lisp Symposium, April 27-28, Zurich
by Didier Verna 06 Dec '19

06 Dec '19

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 13th European Lisp Symposium Special Focus on Compilers Call for papers April 27 - April 28, 2020 GZ Riesbach Zürich, Switzerland http://www.european-lisp-symposium.org/2020 Sponsored by EPITA, Igalia S.L. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Invited Speakers ~~~~~~~~~~~~~~~~ Andrew W. Keep (Cisco Systems, Inc.), on the Nanopass Framework. Daniel Kochmański (Turtleware), on ECL, the Embeddable Common Lisp. Important Dates ~~~~~~~~~~~~~~~ - Submission deadline: February 13, 2020 - Author notification: March 16, 2020 - Final papers due: April 6, 2020 - Symposium: April 27 - 28, 2020 Scope ~~~~~ The purpose of the European Lisp Symposium is to provide a forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp dialects, including Common Lisp, Scheme, Emacs Lisp, Clojure, Racket, ACL2, AutoLisp, ISLISP, Dylan, ECMAScript, SKILL and so on. We encourage everyone interested in Lisp to participate. The European Lisp Symposium 2020 invites high quality papers about novel research results, insights and lessons learned from practical applications, and educational perspectives. We also encourage submissions about known ideas as long as they are presented in a new setting and/or in a highly elegant way. This year's focus will be directed towards "Compilers". We especially invite submissions in the following areas: - Compiler techniques - Compiler passes - Compiler compilers - Showcasing of industrial or experimental compilers - Code generation - Compiler verification - Compiler optimizations - JIT compilers Contributions are also welcome in other areas, including but not limited to: - Context-, aspect-, domain-oriented and generative programming - Macro-, reflective-, meta- and/or rule-based development approaches - Language design and implementation - Language integration, inter-operation and deployment - Development methodologies, support and environments - Educational approaches and perspectives - Experience reports and case studies Technical Program ~~~~~~~~~~~~~~~~~ We invite submissions in the following forms: * Papers: Technical papers of up to 15 pages that describe original results or explain known ideas in new and elegant ways. * Demonstrations: Abstracts of up to 4 pages for demonstrations of tools, libraries, and applications. * Tutorials: Abstracts of up to 4 pages for in-depth presentations about topics of special interest for at least 90 minutes and up to 180 minutes. All submissions should be formatted following the ACM SIGS guidelines and include ACM Computing Classification System 2012 concepts and terms. Submissions should be uploaded to Easy Chair, at the following http://www.easychair.org/conferences/?conf=els2020 Note: to help us with the review process please indicate the type of submission by entering either "paper", "demo", or "tutorial" in the Keywords field. Programme Chair ~~~~~~~~~~~~~~~ Ioanna M. Dimitriou H. - Igalia, Spain/Germany Local Chair ~~~~~~~~~~~ Nicolas Hafner - Shinmera, Switzerland Programme Committee ~~~~~~~~~~~~~~~~~~~ Andy Wingo - Igalia, Spain/France Asumu Takikawa - Igalia, Spain/USA Charlotte Herzeel - IMEC, Intel Exascience Lab, Belgium Christophe Rhodes - Google, UK Iréne Durand - Université Bordeaux 1, France Jim Newton - EPITA Research Lab, France Kent Pitman - HyperMeta, USA Leonie Dreschler-Fischer - University of Hamburg, Germany Marco Heisig - FAU Erlangen-Nürnberg, Germany Mark Evenson - not.org, Austria Max Rottenkolber - Interstellar Ventures, Germany Paulo Matos - Igalia, Spain/Germany Robert Goldman - SIFT, USA Robert Strandh - Université Bordeaux 1, France (more PC members to be announced) -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0