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

integration with java's threading
by Devon Miller 13 Mar '17

13 Mar '17

I saw that Bordeaux threads uses a very thin layer of java threads in their abcl implementation file. I wanted to use some libraries from java that use threading fairly heavily (web apis) and was wondering if there had been good testing with exchanging data from the lisp layer to the java layer when threading is heavily used in the java layer. For example, passing xml and json s-expr into java for processing and sending out through a multi-threaded environment i.e. akka actors.

2 1

[CfPart] 10th European Lisp Symposium, Apr 3-4 2017, Brussels
by Didier Verna 03 Mar '17

03 Mar '17

ELS'17 - 10th European Lisp Symposium VUB - Vrije Universiteit Brussel Belgium April 3-4, 2017 In co-location with <Programming> 2017 Sponsors: Brunner Software GmbH, Franz Inc., LispWorks Ltd. and EPITA http://www.european-lisp-symposium.org/ Recent news: - Invited speakers announced (see below) - Registration open. Don't miss the March 13 deadline for the full <Programming> conference early bird discount! 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 and Lisp-inspired dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, Hop and so on. We encourage everyone interested in Lisp to participate. Keynote speakers: - Hans Hübner -- Identity in a World of Values - Bohdan B. Khomtchouk -- How the Strengths of Lisp Facilitate Building Complex and Flexible Bioinformatics Applications Important dates: - 13 Mar 2017 Early registration deadline - 03-04 Apr 2017 Symposium - 05-06 Apr 2017 <Programming> main tack Programme chair: Alberto Riva, University of Florida, USA Programme committee: Marco Antoniotti, Università Milano Bicocca, Italy Marc Battyani, FractalConcept Theo D'Hondt, Vrije Universiteit Brussel, Belgium Marc Feeley, Université de Montreal, Canada Erick Gallesio, Université de Nice Sophia-Antipolis, France Stelian Ionescu, Google Rainer Joswig, Independent Consultant, Germany António Menezes Leitão, Technical University of Lisbon, Portugal Nick Levine, RavenPack Henry Lieberman, MIT, USA Mark Tarver, Shen Programming Group Jay McCarthy, University of Massachusetts Lowell, USA Christian Queinnec, Université Pierre et Marie Curie, France François-René Rideau, Bridgewater Associates, USA Nikodemus Siivola, ZenRobotics Ltd Alessio Stalla, Università degli Studi di Genova, Italy Chris Stacy, CS Consulting Search Keywords: #els2017, ELS 2017, ELS '17, European Lisp Symposium 2017, European Lisp Symposium '17, 10th ELS, 10th European Lisp Symposium, European Lisp Conference 2017, European Lisp Conference '17 -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

asdf:defsystem complains about path, sometimes
by Mirko Vukovic 01 Mar '17

01 Mar '17

Hello, This is with asdf 3.1.7.27, Armed Bear Common Lisp 1.4.0 Java 1.6.0_41 Sun Microsystems Inc. OpenJDK 64-Bit Server VM, Emacs & Slime The following example code from the ASDF manual (asdf:defsystem "hello-lisp" :description "hello-lisp: a sample Lisp system." :version "0.0.1" :author "Joe User <joe(a)example.com>" :licence "Public Domain" :depends-on ("optima.ppcre" "command-line-arguments") :components ((:file "packages") (:file "macros" :depends-on ("packages")) (:file "hello" :depends-on ("macros")))) when executed via the ABCL command line gives a relative path error Invalid relative pathname #P"packages.lisp" for component ("hello-lisp" "packages") Restarts: 0: RETRY Retry ASDF operation. 1: CLEAR-CONFIGURATION-AND-RETRY Retry ASDF operation after resetting the configuration. 2: TOP-LEVEL Return to top level. If that code is in a file, then the file compiles cleanly: CL-USER(6): (load (compile-file "test.asd")) ; Compiling /home/mv/projects/poi+excel/test.asd ... ; (IN-PACKAGE :CL-USER) ; (ASDF/PARSE-DEFSYSTEM:DEFSYSTEM "hello-lisp" ...) ; Wrote /home/mv/projects/poi+excel/test.abcl (0.021 seconds) T CL-USER(7): I am looking for confirmation of this and second opinions before taking up at the ASDF mailing list. Thanks, Mirko

3 4

sys:run-program errs (both Windows & Linux)
by Mirko Vukovic 15 Jan '17

15 Jan '17

While narrowing down the problems I was having with maven and cffi, I came across the maven-embedded.lisp file ( https://common-lisp.net/svn/armedbear/branches/1.4.0/contrib/abcl-asdf/mave… ) where I saw the sys:run-program. I now have ABCL installed on both Linux and Windows, and have problems on both when issuing #+windows(sys:run-program "where.exe" nil) #+linux(sys:run-program "which" nil) On Windows, the first call fails, while the second succeeds. On Linux, the call fails, and repeated calls also fail. Is this just me or can anyone else reproduce this? Thanks. Transcript of the Windows 10 session (Linux follows) P:\>java -jar c:\mv-program-files\abcl-bin-1.4.0\abcl.jar --noinit Armed Bear Common Lisp 1.4.0 Java 1.8.0_112 Oracle Corporation Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.274 seconds. Startup completed in 4.28 seconds. Type ":help" for a list of available commands. CL-USER(1): (sys:run-program "which.exe" nil) ;;; *First invocation results in error* Error loading jar:file:C:/mv-program-files/abcl-bin-1.4.0/abcl.jar!/org/armedbear/lisp/run-program.abcl at line 166 (offset 8688) #<THREAD "interpreter" {6A8B2747}>: Debugger invoked on condition of type ERROR Class not found: java.lang.UNIXProcess ;;; *ERROR* Restarts: 0: TOP-LEVEL Return to top level. [1] SYS(2): 0 java.lang.ExceptionInInitializerError ... Java stack elided Caused by: org.armedbear.lisp.Go Error loading jar:file:C:/mv-program-files/abcl-bin-1.4.0/abcl.jar!/org/armedbear/lisp/run-program.abcl at line 166 (offset 8688) #<THREAD "interpreter" {6A8B2747}>: Debugger invoked on condition of type ERROR Compiled function can't be loaded: org.armedbear.lisp.run_program_49 from org.armedbear.lisp.Pathname@60a4bd75 Restarts: 0: TOP-LEVEL Return to top level. [1] SYS(3): 0 CL-USER(4): (sys:run-program "which.exe" nil) ;;; *Second invocation succeeds* #S(SYSTEM:PROCESS :JPROCESS #<java.lang.ProcessImpl java.lang.ProcessImpl@6aaa6218 {2F20252D}> :%INPUT #S(SYSTEM::SYSTEM-STREAM) :%OUTPUT #S(SYSTEM::SYSTEM-STREAM) :%ERROR #S(SYSTEM::SYSTEM-STREAM)) CL-USER(5): On Linux I work through Slime. Here is the startup message on a RedHat EL6. I hope my Java patch is recent enough. Armed Bear Common Lisp 1.4.0 Java 1.6.0_40 Sun Microsystems Inc. OpenJDK 64-Bit Server VM Low-level initialization completed in 0.491 seconds. Startup completed in 2.488 seconds. Using probed value of abcl-contrib: '/usr/local/share/java/abcl-contrib.jar'. Added jar:file:/usr/local/share/java/abcl-contrib.jar!/quicklisp/ to ASDF. Added jar:file:/usr/local/share/java/abcl-contrib.jar!/mvn/ to ASDF. Added jar:file:/usr/local/share/java/abcl-contrib.jar!/jss/ to ASDF. Added jar:file:/usr/local/share/java/abcl-contrib.jar!/jfli/ to ASDF. Added jar:file:/usr/local/share/java/abcl-contrib.jar!/asdf-jar/ to ASDF. Added jar:file:/usr/local/share/java/abcl-contrib.jar!/abcl-asdf/ to ASDF. Loading /home/mv/.abclrc completed in 9.644 seconds. Type ":help" for a list of available commands. CL-USER(1): ; Loading /home/sm/software/slime/swank-loader.lisp ... Doing (sys:run-program "which" nil) the error backtrace is: Class not found: java.lang.ProcessBuilder$Redirect [Condition of type ERROR] Restarts: 0: [RETRY] Retry SLIME REPL evaluation request. 1: [*ABORT] Return to SLIME's top level. 2: [ABORT] Abort thread. Backtrace: 0: (#<FUNCTION {5A18A372}> #<ERROR {47BE45A7}> #<FUNCTION {5A18A372}>) 1: (APPLY #<FUNCTION {5A18A372}> (#<ERROR {47BE45A7}> #<FUNCTION {5A18A372}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<ERROR {47BE45A7}> #<FUNCTION {5A18A372}>) 3: (INVOKE-DEBUGGER #<ERROR {47BE45A7}>) 4: org.armedbear.lisp.Lisp.error(Lisp.java:382) 5: org.armedbear.lisp.Java.classForName(Java.java:1299) 6: org.armedbear.lisp.Java.javaClass(Java.java:1332) 7: org.armedbear.lisp.Java.javaClass(Java.java:1306) 8: org.armedbear.lisp.Java.jfield(Java.java:177) 9: org.armedbear.lisp.Java$pf_jfield.execute(Java.java:272) 10: org.armedbear.lisp.Primitive.execute(Primitive.java:123) 11: (JFIELD "java.lang.ProcessBuilder$Redirect" "INHERIT") 12: (SYSTEM:INIT-FASL :VERSION 42) 13: (SYSTEM::%MAKE-PROCESS-BUILDER "which" NIL) 14: (SYSTEM:RUN-PROGRAM "which" NIL) 15: (SYSTEM::%EVAL (SYSTEM:RUN-PROGRAM "which" NIL)) 16: (EVAL (SYSTEM:RUN-PROGRAM "which" NIL))

2 2

Strange, magical, thing :)
by Marco Antoniotti 13 Jan '17

13 Jan '17

Hi just to point out what happens hitting (or just writing) the following address in you Browser :) (I noticed it because of my CL Ook compiler) ook.common-lisp.net Cheers -- Marco Antoniotti

2 1

Anyone understand the logic of pushJavaStackFrames
by Alan Ruttenberg 09 Jan '17

09 Jan '17

I'm getting backtraces that are noisy and therefore impede comprehension. For example, in the following stack trace, frames 68-4 seem to recapitulate, for the most part, the java stack corresponding to frames 87-69 Thanks, Alan The value CL-UTILS::FORMS is not of type LIST. [Condition of type TYPE-ERROR] Restarts: 0: [RETRY] Retry compiling #<ASDF/LISP-ACTION:CL-SOURCE-FILE "jnil" "cl-utils">. 1: [ACCEPT] Continue, treating compiling #<ASDF/LISP-ACTION:CL-SOURCE-FILE "jnil" "cl-utils"> as having been successful. 2: [RETRY] Retry ASDF operation. 3: [CLEAR-CONFIGURATION-AND-RETRY] Retry ASDF operation after resetting the configuration. 4: [ABORT] Abort compilation. 5: [*ABORT] Return to SLIME's top level. --more-- Backtrace: 0: (#<LOCAL-FUNCTION IN MAKE-INVOKE-DEBUGGER-HOOK {5108C7A9}> #<TYPE-ERROR {D3CDE50}> #<LOCAL-FUNCTION IN MAKE-INVOKE-DEBUGGER-HOOK {5108C7A9}>) 1: (APPLY #<LOCAL-FUNCTION IN MAKE-INVOKE-DEBUGGER-HOOK {5108C7A9}> (#<TYPE-ERROR {D3CDE50}> #<LOCAL-FUNCTION IN MAKE-INVOKE-DEBUGGER-HOOK {5108C7A9}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<TYPE-ERROR {D3CDE50}> #<LOCAL-FUNCTION IN MAKE-INVOKE-DEBUGGER-HOOK {5108C7A9}>) 3: (INVOKE-DEBUGGER #<TYPE-ERROR {D3CDE50}>) 4: org.armedbear.lisp.Lisp.error(Lisp.java:382) 5: org.armedbear.lisp.Lisp.type_error(Lisp.java:435) 6: org.armedbear.lisp.LispObject.car(LispObject.java:165) 7: org.armedbear.lisp.precompiler_51.execute(precompiler.lisp:381) 8: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 9: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 10: org.armedbear.lisp.precompiler_48.execute(precompiler.lisp:350) 11: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 12: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 13: org.armedbear.lisp.precompiler_51.execute(precompiler.lisp:381) 14: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 15: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 16: org.armedbear.lisp.precompiler_48.execute(precompiler.lisp:350) 17: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 18: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 19: org.armedbear.lisp.precompiler_51.execute(precompiler.lisp:381) 20: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 21: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 22: org.armedbear.lisp.precompiler_48.execute(precompiler.lisp:350) 23: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 24: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 25: org.armedbear.lisp.precompiler_51.execute(precompiler.lisp:381) 26: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 27: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 28: org.armedbear.lisp.precompiler_48.execute(precompiler.lisp:350) 29: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 30: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 31: org.armedbear.lisp.precompiler_51.execute(precompiler.lisp:381) 32: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 33: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 34: org.armedbear.lisp.precompiler_48.execute(precompiler.lisp:350) 35: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 36: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 37: org.armedbear.lisp.precompiler_73.execute(precompiler.lisp:643) 38: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 39: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 40: org.armedbear.lisp.precompiler_48.execute(precompiler.lisp:350) 41: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 42: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 43: org.armedbear.lisp.precompiler_105.execute(precompiler.lisp:988) 44: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) 45: org.armedbear.lisp.Symbol.execute(Symbol.java:826) 46: org.armedbear.lisp.compiler_pass2_362.execute(compiler-pass2.lisp:7380) 47: org.armedbear.lisp.Symbol.execute(Symbol.java:867) 48: org.armedbear.lisp.LispThread.execute(LispThread.java:918) 49: org.armedbear.lisp.compile_file_19.execute(compile-file.lisp:175) 50: org.armedbear.lisp.Symbol.execute(Symbol.java:814) 51: org.armedbear.lisp.LispThread.execute(LispThread.java:832) 52: org.armedbear.lisp.compile_file_51.execute(compile-file.lisp:655) 53: org.armedbear.lisp.Symbol.execute(Symbol.java:826) 54: org.armedbear.lisp.LispThread.execute(LispThread.java:851) 55: org.armedbear.lisp.compile_file_59.execute(compile-file.lisp:780) 56: org.armedbear.lisp.compiler_pass2_370.execute(compiler-pass2.lisp:7450) 57: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) 58: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 59: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 60: org.armedbear.lisp.compile_file_57.execute(compile-file.lisp:780) 61: org.armedbear.lisp.Symbol.execute(Symbol.java:914) 62: org.armedbear.lisp.LispThread.execute(LispThread.java:986) 63: org.armedbear.lisp.compile_file_68.execute(compile-file.lisp:962) 64: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:150) 65: org.armedbear.lisp.Symbol.execute(Symbol.java:852) 66: org.armedbear.lisp.LispThread.execute(LispThread.java:894) 67: org.armedbear.lisp.Lisp.funcall(Lisp.java:180) 68: org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2845) 69: (PRECOMPILER::PRECOMPILE-FUNCTION-CALL (CL-UTILS::KEY . CL-UTILS::FORMS)) 70: (PRECOMPILER::PRECOMPILE1 (CL-UTILS::KEY . CL-UTILS::FORMS)) 71: (PRECOMPILER::PRECOMPILE-FUNCTION-CALL (CL-UTILS::LOOP CL-UTILS::FOR (CL-UTILS::KEY . CL-UTILS::FORMS) CL-UTILS::IN CL-UTILS::CLAUSES CL-UTILS::DO ...)) 72: (PRECOMPILER::PRECOMPILE1 (CL-UTILS::LOOP CL-UTILS::FOR (CL-UTILS::KEY . CL-UTILS::FORMS) CL-UTILS::IN CL-UTILS::CLAUSES CL-UTILS::DO ...)) 73: (PRECOMPILER::PRECOMPILE-FUNCTION-CALL (CL-UTILS::LET ((CL-UTILS::CLAUSE-COLLECTION (CL-UTILS::LIST))) ..)) 74: (PRECOMPILER::PRECOMPILE1 (CL-UTILS::LET ((CL-UTILS::CLAUSE-COLLECTION (CL-UTILS::LIST))) ..)) 75: (PRECOMPILER::PRECOMPILE-FUNCTION-CALL (CL-UTILS::WITH-GENSYMS (CL-UTILS::TEST) ..)) 76: (PRECOMPILER::PRECOMPILE1 (CL-UTILS::WITH-GENSYMS (CL-UTILS::TEST) ..)) 77: (PRECOMPILER::PRECOMPILE-FUNCTION-CALL (CL-UTILS::DEFMACRO CL-UTILS::CASE* (CL-UTILS::KEYFORM CL-UTILS::&REST CL-UTILS::CLAUSES) ..)) 78: (PRECOMPILER::PRECOMPILE1 (CL-UTILS::DEFMACRO CL-UTILS::CASE* (CL-UTILS::KEYFORM CL-UTILS::&REST CL-UTILS::CLAUSES) ..)) 79: (PRECOMPILER::PRECOMPILE-LAMBDA (LAMBDA NIL ..)) 80: (PRECOMPILER::PRECOMPILE1 (LAMBDA NIL (CL-UTILS::DEFMACRO CL-UTILS::CASE* (CL-UTILS::KEYFORM CL-UTILS::&REST CL-UTILS::CLAUSES) (CL-UTILS::WITH-GENSYMS (CL-UTILS::TEST) (CL-UTILS::LET # # #))))) 81: (JVM:COMPILE-DEFUN NIL (LAMBDA NIL (CL-UTILS::DEFMACRO CL-UTILS::CASE* (CL-UTILS::KEYFORM CL-UTILS::&REST CL-UTILS::CLAUSES) (CL-UTILS::WITH-GENSYMS (CL-UTILS::TEST) (CL-UTILS::LET # # #)))) NIL #P"/U.. 82: (SYSTEM::CONVERT-TOPLEVEL-FORM (CL-UTILS::DEFMACRO CL-UTILS::CASE* (CL-UTILS::KEYFORM CL-UTILS::&REST CL-UTILS::CLAUSES) ..) NIL) 83: (SYSTEM::PROCESS-TOPLEVEL-FORM (CL-UTILS::DEFMACRO CL-UTILS::CASE* (CL-UTILS::KEYFORM CL-UTILS::&REST CL-UTILS::CLAUSES) ..) #<FILE-STREAM {1773B7E}> NIL) 84: (JVM::%WITH-COMPILATION-UNIT #<LOCAL-FUNCTION IN COMPILE-FROM-STREAM {1FEBE62E}>) 85: (SYSTEM::COMPILE-FROM-STREAM #<FILE-STREAM {744E75DD}> #P"/Users/lori/.cache/common-lisp/abcl-1.5.0-dev-fasl43-macosx-x64/Volumes/upstairs/repos/jnil/lisp/jnil/cl-utils-tmpUYPFRO0B.abcl" #P"/Users/lor.. 86: (COMPILE-FILE #P"/Volumes/upstairs/repos/jnil/lisp/jnil/cl-utils.lisp" :OUTPUT-FILE #P"/Users/lori/.cache/common-lisp/abcl-1.5.0-dev-fasl43-macosx-x64/Volumes/upstairs/repos/jnil/lisp/jnil/cl-utils-tm.. 87: (APPLY COMPILE-FILE #P"/Volumes/upstairs/repos/jnil/lisp/jnil/cl-utils.lisp" :OUTPUT-FILE #P"/Users/lori/.cache/common-lisp/abcl-1.5.0-dev-fasl43-macosx-x64/Volumes/upstairs/repos/jnil/lisp/jnil/cl-ut.. private static final void pushJavaStackFrames() { final LispThread thread = LispThread.currentThread(); final StackTraceElement[] frames = thread.getJavaStackTrace(); // frames[0] java.lang.Thread.getStackTrace // frames[1] org.armedbear.lisp.LispThread.getJavaStackTrace // frames[2] org.armedbear.lisp.Lisp.pushJavaStackFrames if (frames.length > 5 && frames[3].getClassName().equals("org.armedbear.lisp.Lisp") && frames[3].getMethodName().equals("error") && frames[4].getClassName().startsWith("org.armedbear.lisp.Lisp") && frames[4].getMethodName().equals("eval")) { // Error condition arising from within Lisp.eval(), so no // Java stack frames should be visible to the consumer of the stack abstraction return; } // Search for last Primitive in the StackTrace; that was the // last entry point from Lisp. int last = frames.length - 1; for (int i = 0; i<= last; i++) { if (frames[i].getClassName().startsWith("org.armedbear.lisp.Primitive")) last = i; } // Do not include the first three frames which, as noted above, constitute // the invocation of this method. while (last > 2) { thread.pushStackFrame(new JavaStackFrame(frames[last])); last--; } }

3 9

IEEE NaN and Infinities
by Antoniotti Marco 08 Jan '17

08 Jan '17

Hi I am fiddling around with IEEE NaN and Infinities. In LW and CCL you have the following conventions for such things: 1d+-0 is NaN (quiet; double float) 1d++0 is positive infinity (double float) Negative infinities are obtained by prepending ‘-‘ to the positive infinities. Other float lengths can be obtained by using the appropriate ’s’, ‘e’, ‘f’, ‘l’. I tried an (APROPOS “NAN”) and an (APROPOS “INFINITY”) in ABCL, but got nothing. Being myself a lazy bastard, I thought of asking directly here instead of looking at the code :) Any possibility of seeing these in ABCL? Apart from that, there is the issue of “rounding modes”. Would it be possible to add them or access them in ABCL? Thanks Marco -- Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY Please check: http://cdac2017.lakecomoschool.org Please check: https://sites.google.com/site/troncopackage/ Please note that I am not checking my Spam-box anymore. Please do not forward this email without asking me first (cum grano salis).

1 0

Failure to load cffi (again): unable to find maven (again)
by Mirko Vukovic 05 Jan '17

05 Jan '17

Earlier today I was able to load cffi by renaming mvn.cmd to mvn.bat. Later on, I am unable to, and I would appreciate a fresh pair of eyes. (ABCL/Java info: C:\Users\977315>java -jar "c:\mv-program-files\abcl-bin-1.4.0\abcl.jar" Armed Bear Common Lisp 1.4.0 Java 1.8.0_112 Oracle Corporation Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.243 seconds. Startup completed in 3.812 seconds. Loading C:\Users\977315\.abclrc completed in 13.729 seconds.) The error seems to happen in abcl-cffi.lisp. mvn.bat is visible: (uiop/run-program:run-program '("where" "mvn.bat") :output :string) gives "C:\\Program Files\\apache-maven-3.3.9\\bin\\mvn.bat " NIL 0 I don't know how to narrow down the search for the culprit. It makes me think that maybe the error message is not correct - that there is a different underlying cause. Is there some direct way I can test maven+aether? I now next to nothing about Java, and looking at abcl-cffi, I did not find anything obvious. Thanks for your help and patience, Backtrace follows. CL-USER(4): (asdf:load-system :cffi) ; Compiling C:/mv-program-files/my-lisp-libraries/cffi/src/cffi-abcl.lisp ... Using probed value of abcl-contrib: 'C:/mv-program-files/abcl-bin-1.4.0/abcl-contrib.jar'. Added jar:file:C:/mv-program-files/abcl-bin-1.4.0/abcl-contrib.jar!/quicklisp/ to ASDF. Added jar:file:C:/mv-program-files/abcl-bin-1.4.0/abcl-contrib.jar!/mvn/ to ASDF. Added jar:file:C:/mv-program-files/abcl-bin-1.4.0/abcl-contrib.jar!/jss/ to ASDF. Added jar:file:C:/mv-program-files/abcl-bin-1.4.0/abcl-contrib.jar!/jfli/ to ASDF. Added jar:file:C:/mv-program-files/abcl-bin-1.4.0/abcl-contrib.jar!/asdf-jar/ to ASDF. Added jar:file:C:/mv-program-files/abcl-bin-1.4.0/abcl-contrib.jar!/abcl-asdf/ to ASDF. java.lang.ExceptionInInitializerError at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source) at java.lang.reflect.Constructor.newInstance(Unknown Source) at java.lang.Class.newInstance(Unknown Source) 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.progn(Lisp.java:709) Caused by: org.armedbear.lisp.Go ; in (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL ...) ...) ; Caught SIMPLE-WARNING: ; Unable to locate Maven executable to find Maven Aether adaptors. jnaASDF could not load because Java exception 'java.lang.ClassNotFoundException: com.sun.jna.Native'.. #<THREAD "interpreter" {49B3491F}>: Debugger invoked on condition of type JAVA-EXCEPTION Java exception 'java.lang.ClassNotFoundException: com.sun.jna.Native'. Restarts: 0: RETRY Retry completing load for #<ASDF/SYSTEM:SYSTEM "jna">. 1: ACCEPT Continue, treating completing load for #<ASDF/SYSTEM:SYSTEM "jna"> 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: TOP-LEVEL Return to top level.

1 1

uiop/run-program:run-program regression after asdf-3.1.7
by Mirko Vukovic 05 Jan '17

05 Jan '17

I try running (uiop/run-program:run-program '("where" "mvn.bat") :output :string) On asdf 3.1.7, it returns the correct output. With asdf 3.1.7.27 and 3.1.7.43. I get an error "Class not found: java.lang.UNIXProcess". If I go to the top level, and try again, I get the correct result. This is with: C:\Users\977315>java -jar "c:\mv-program-files\abcl-bin-1.4.0\abcl.jar" Armed Bear Common Lisp 1.4.0 Java 1.8.0_112 Oracle Corporation Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.238 seconds. Startup completed in 3.973 seconds. Loading C:\Users\977315\.abclrc completed in 14.029 seconds. Type ":help" for a list of available commands. CL-USER(1): The abclrc is minimal: load asdf and load quicklisp: (eval-when (:compile-toplevel :load-toplevel :execute) (let ((file "asdf.3.1.7.43.lisp")) (load (merge-pathnames file (user-homedir-pathname))))) (eval-when (:compile-toplevel :load-toplevel :execute) #-quicklisp (let ((quicklisp-init (merge-pathnames "quicklisp/setup.lisp" (user-homedir-pathname)))) (if (probe-file quicklisp-init) (load quicklisp-init) (error "Did not find ~a ... quicklisp not loaded" "~/quicklisp/setup.lisp")))) I posted this on the ASDF mailing list, and Fare suggested this may be an ABCL-related issue. I hope all the problems I am having have one single root cause - and that we discover it :-)

2 2

Bug in STABLE-SORT on empty vector
by Eric Marsden 05 Jan '17

05 Jan '17

Hello, A bug in STABLE-SORT on empty vectors. CL-USER(1): (lisp-implementation-version) "1.5.0-dev-svn-14939" "OpenJDK_64-Bit_Server_VM-Oracle_Corporation-1.7.0_111-b01" "amd64-Linux-3.2.0-4-amd64" CL-USER(2): (stable-sort #() '<) #<THREAD "interpreter" {7454F875}>: Debugger invoked on condition of type TYPE-ERROR Invalid array index 0 for #() -- Eric Marsden https://risk-engineering.org/

1 0