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

Errors loading CFFI: BAD-SYSTEM-NAME, missing Maven executable
by Mirko Vukovic 04 Jan '17

04 Jan '17

Loading CFFI, I get BAD-SYSTEM-NAME errors related to followed by a huge stack dump, and then debugger related to the Maven executable. I tested this with --noinit. Thanks for your help. Here are more details: Starting ABCL on Windows 10 like so: >/c/Windows/SysWOW64/java.exe -jar /c/mv-program-files/abcl-bin-1.4.0/abcl.jar Armed Bear Common Lisp 1.4.0 Java 1.7.0_51 Oracle Corporation Java HotSpot(TM) Client VM Low-level initialization completed in 0.23 seconds. Now I try to load cffi with quicklisp. Following quickload, I get many style-warnings about redefining UIOP: CL-USER(1): (ql:quickload :cffi) To load "cffi": Load 1 ASDF system: cffi ; Loading "cffi" .................................................. .................................................. .................................................. .................................................. .................................... ; Caught STYLE-WARNING: ; redefining UIOP/PACKAGE:FIND-PACKAGE* in #P"C:/mv-program-files/my-lisp-libraries/asdf/uiop/package.lisp" (previously defined in #P"C:/Users/977315/asdf.3.1.7.43.lisp") ; Caught STYLE-WARNING: ; redefining UIOP/PACKAGE:FIND-SYMBOL* in #P"C:/mv-program-files/my-lisp-libraries/asdf/uiop/package.lisp" (previously defined in #P"C:/Users/977315/asdf.3.1.7.43.lisp") .... many such warnings ... After finishing the style-warning messages, come ASDF load messages, the BAD-SYSTEM-NAME messages, followed by a long java stack dump: 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. . ; Caught BAD-SYSTEM-NAME: ; System definition file #P"jar:file:C:/mv-program-files/abcl-bin-1.4.0/abcl-contrib.jar!/jss/jss.asd" contains definition for system "jss-tests". Please only define "jss" and secondary systems with a name starting with "jss/" (e.g. "jss/test") in that file. ; Caught BAD-SYSTEM-NAME: ; System definition file #P"jar:file:C:/mv-program-files/abcl-bin-1.4.0/abcl-contrib.jar!/abcl-asdf/abcl-asdf.asd" contains definition for system "abcl-asdf-test". Please only define "abcl-asdf" and secondary systems with a name starting with "abcl-asdf/" (e.g. "abcl-asdf/test") in that file. 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.ja va:165) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) ... At the end I get into the ABCL debugger: Caused by: org.armedbear.lisp.Go ; 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" {472108}>: 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:SYSTE M "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.

2 4

[CfP] ELS'17, 10th European Lisp Symposium, April 3-4 2017, Brussels
by Didier Verna 03 Jan '17

03 Jan '17

ELS'17 - 10th European Lisp Symposium VUB - Vrije Universiteit Brussel Belgium April 3-4, 2017 In co-location with <Programming> 2017 Sponsored by Brunner Software GmbH http://www.european-lisp-symposium.org/ 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. The 10th European Lisp Symposium 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. Topics include but are 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 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 2 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. The symposium will also provide slots for lightning talks, to be registered on-site every day. All submissions should be formatted following the ACM SIGS guidelines and include ACM classification categories and terms. For more information on the submission guidelines and the ACM keywords, see: http://www.acm.org/sigs/publications/proceedings-templates and http://www.acm.org/about/class/1998. The conference proceedings will be published in the ACM Digital Library. Submissions should be uploaded to Easy Chair, at the following address: https://www.easychair.org/conferences/?conf=els17 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. Important dates: - 30 Jan 2017 Submission deadline - 27 Feb 2017 Notification of acceptance - 20 Mar 2017 Final papers due - 03-04 Apr 2017 Symposium 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 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 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

Examples of new vs old stacktrace (in slime)
by Alan Ruttenberg 03 Jan '17

03 Jan '17

Here are some examples of new versus old stacktrace. "!" means the frame was in the java exception stacktrace, but are no longer present because the exception was caught #### Generate error with: (#"new" 'bloh) ________________ New stacktrace Java exception 'java.lang.ClassNotFoundException: BLOH'. [Condition of type java-exception] Restarts: 0: [retry] Retry SLIME REPL evaluation request. 1: [*abort] Return to SLIME's top level. 2: [abort] Abort thread. Backtrace: 0: (invoke-debugger #<java:java-exception java.lang.ClassNotFoundException: BLOH {5C19BF31}>) 1: org.armedbear.lisp.Lisp.error(Lisp.java:382) 2: ! java.net.URLClassLoader.findClass(URLClassLoader.java:381) 3: ! java.lang.ClassLoader.loadClass(ClassLoader.java:424) 4: ! org.armedbear.lisp.JavaClassLoader.loadClass(JavaClassLoader.java:60) 5: ! java.lang.Class.forName0(Native Method) 6: ! java.lang.Class.forName(Class.java:348) 7: ! java.lang.reflect.Method.invoke(Method.java:497) 8: (java:jstatic #<method public static java.lang.Class java.lang.Class.forName(java.lang.String,boolean,java.lang.ClassLoader) throws java.lang.ClassNotFoundException> "java.lang.Class" "BLOH" #<java.la .. 9: (jss:find-java-class "BLOH") 10: (#"new" common-lisp-user::bloh) 11: (#<anonymous-interpreted-function {7D30E302}> common-lisp-user::bloh) 12: (system::%eval (#"new" 'common-lisp-user::bloh)) 13: (eval (#"new" 'common-lisp-user::bloh)) ________________ Old stacktrace Java exception 'java.lang.ClassNotFoundException: BLOH'. [Condition of type java-exception] Restarts: 0: [retry] Retry SLIME REPL evaluation request. 1: [*abort] Return to SLIME's top level. 2: [abort] Abort thread. Backtrace: 0: (system:backtrace) 1: (system::new-backtrace #<java:java-exception java.lang.ClassNotFoundException: BLOH {48D709DB}>) 2: (#<local-function in make-invoke-debugger-hook {FB48C75}> #<java:java-exception java.lang.ClassNotFoundException: BLOH {48D709DB}> #<local-function in make-invoke-debugger-hook {FB48C75}>) 3: (apply #<local-function in make-invoke-debugger-hook {FB48C75}> (#<java:java-exception java.lang.ClassNotFoundException: BLOH {48D709DB}> #<local-function in make-invoke-debugger-hook {FB48C75}>)) 4: (system::run-hook system::*invoke-debugger-hook* #<java:java-exception java.lang.ClassNotFoundException: BLOH {48D709DB}> #<local-function in make-invoke-debugger-hook {FB48C75}>) 5: (invoke-debugger #<java:java-exception java.lang.ClassNotFoundException: BLOH {48D709DB}>) 6: org.armedbear.lisp.Lisp.error(Lisp.java:382) 7: org.armedbear.lisp.Java.jstatic(Java.java:484) 8: org.armedbear.lisp.Java$pf_jstatic.execute(Java.java:510) 9: org.armedbear.lisp.Primitive.execute(Primitive.java:163) 10: (java:jstatic #<method public static java.lang.Class java.lang.Class.forName(java.lang.String,boolean,java.lang.ClassLoader) throws java.lang.ClassNotFoundException> "java.lang.Class" "BLOH" #<java.la .. 11: (jss:find-java-class "BLOH") 12: (#"new" common-lisp-user::bloh) 13: (#<anonymous-interpreted-function {641792AC}> common-lisp-user::bloh) 14: (system::%eval (#"new" 'common-lisp-user::bloh)) 15: (eval (#"new" 'common-lisp-user::bloh)) ################ Generate error with: (+ 1 nil) ________________ New stacktrace The value nil is not of type number. [Condition of type type-error] Restarts: 0: [retry] Retry SLIME REPL evaluation request. 1: [*abort] Return to SLIME's top level. 2: [abort] Abort thread. Backtrace: 0: (invoke-debugger #<type-error {4848F05A}>) 1: org.armedbear.lisp.Lisp.error(Lisp.java:382) 2: org.armedbear.lisp.Lisp.type_error(Lisp.java:435) 3: (+ 1 nil) 4: (system::%eval (+ 1 nil)) 5: (eval (+ 1 nil)) ________________ Old stacktrace The value nil is not of type number. [Condition of type type-error] Restarts: 0: [retry] Retry SLIME REPL evaluation request. 1: [*abort] Return to SLIME's top level. 2: [abort] Abort thread. Backtrace: 0: (system:backtrace) 1: (system::new-backtrace #<type-error {631F4DD}>) 2: (#<local-function in make-invoke-debugger-hook {FB48C75}> #<type-error {631F4DD}> #<local-function in make-invoke-debugger-hook {FB48C75}>) 3: (apply #<local-function in make-invoke-debugger-hook {FB48C75}> (#<type-error {631F4DD}> #<local-function in make-invoke-debugger-hook {FB48C75}>)) 4: (system::run-hook system::*invoke-debugger-hook* #<type-error {631F4DD}> #<local-function in make-invoke-debugger-hook {FB48C75}>) 5: (invoke-debugger #<type-error {631F4DD}>) 6: org.armedbear.lisp.Lisp.error(Lisp.java:382) 7: org.armedbear.lisp.Lisp.type_error(Lisp.java:435) 8: org.armedbear.lisp.Fixnum.add(Fixnum.java:387) 9: org.armedbear.lisp.Primitives$pf_add.execute(Primitives.java:752) 10: (+ 1 nil) 11: (system::%eval (+ 1 nil)) 12: (eval (+ 1 nil)) #### Generate error by typing #< then return into the slime repl ________________ New stacktrace Illegal # macro character: #\< [Condition of type reader-error] Restarts: 0: [retry] Retry SLIME REPL evaluation request. 1: [*abort] Return to SLIME's top level. 2: [abort] Abort thread. Backtrace: 0: (invoke-debugger #<reader-error {25D021FB}>) 1: (error #<reader-error {25D021FB}>) 2: org.armedbear.lisp.Lisp.error(Lisp.java:382) 3: org.armedbear.lisp.LispReader$22.execute(LispReader.java:350) = #<function sharp-illegal {2EF7C108}> 4: org.armedbear.lisp.Stream.readDispatchChar(Stream.java:813) 5: org.armedbear.lisp.LispReader$6.execute(LispReader.java:130) = #<function read-dispatch-char {153CFE29}> 6: org.armedbear.lisp.Stream.processChar(Stream.java:588) 7: org.armedbear.lisp.Stream.readPreservingWhitespace(Stream.java:557) 8: org.armedbear.lisp.Stream.readPreservingWhitespace(Stream.java:566) 9: (read #S(system::string-input-stream) nil #S(system::string-input-stream)) ________________ Old stacktrace Illegal # macro character: #\< [Condition of type reader-error] Restarts: 0: [retry] Retry SLIME REPL evaluation request. 1: [*abort] Return to SLIME's top level. 2: [abort] Abort thread. Backtrace: 0: (system:backtrace) 1: (system::new-backtrace #<reader-error {35F15D9A}>) 2: (#<local-function in make-invoke-debugger-hook {FB48C75}> #<reader-error {35F15D9A}> #<local-function in make-invoke-debugger-hook {FB48C75}>) 3: (apply #<local-function in make-invoke-debugger-hook {FB48C75}> (#<reader-error {35F15D9A}> #<local-function in make-invoke-debugger-hook {FB48C75}>)) 4: (system::run-hook system::*invoke-debugger-hook* #<reader-error {35F15D9A}> #<local-function in make-invoke-debugger-hook {FB48C75}>) 5: (invoke-debugger #<reader-error {35F15D9A}>) 6: (error #<reader-error {35F15D9A}>) 7: (#<local-function in eval-region {12C6FD1A}> #<reader-error {35F15D9A}>) 8: (signal #<reader-error {35F15D9A}>) 9: org.armedbear.lisp.Lisp.error(Lisp.java:382) 10: org.armedbear.lisp.LispReader$22.execute(LispReader.java:350) = #<function sharp-illegal {2EF7C108}> 11: org.armedbear.lisp.Stream.readDispatchChar(Stream.java:813) 12: org.armedbear.lisp.LispReader$6.execute(LispReader.java:130) = #<function read-dispatch-char {153CFE29}> 13: org.armedbear.lisp.Stream.processChar(Stream.java:588) 14: org.armedbear.lisp.Stream.readPreservingWhitespace(Stream.java:557) 15: org.armedbear.lisp.Stream.readPreservingWhitespace(Stream.java:566) 16: org.armedbear.lisp.Stream.read(Stream.java:501) 17: org.armedbear.lisp.Stream$16.execute(Stream.java:2436) = #<function read {7905182E}> 18: org.armedbear.lisp.Symbol.execute(Symbol.java:826) 19: org.armedbear.lisp.LispThread.execute(LispThread.java:851) 20: org.armedbear.lisp.swank_528.execute(swank.lisp:1732) = #<function eval-region {6A067578}> 21: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 22: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 23: org.armedbear.lisp.swank_repl_47.execute(swank-repl.lisp:270) = #<local-function in repl-eval {7AA59573}> 24: org.armedbear.lisp.LispThread.execute(LispThread.java:798) 25: org.armedbear.lisp.swank_repl_48.execute(swank-repl.lisp:283) = #<function track-package {24491179}> 26: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 27: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 28: org.armedbear.lisp.swank_repl_46.execute(swank-repl.lisp:270) = #<local-function in repl-eval {6A4AF4AE}> 29: org.armedbear.lisp.LispThread.execute(LispThread.java:798) 30: org.armedbear.lisp.swank_272.execute(swank.lisp:490) = #<function call-with-retry-restart {4E68726}> 31: org.armedbear.lisp.Symbol.execute(Symbol.java:814) 32: org.armedbear.lisp.LispThread.execute(LispThread.java:832) 33: org.armedbear.lisp.swank_repl_45.execute(swank-repl.lisp:270) = #<local-function in repl-eval {18F59278}> 34: org.armedbear.lisp.LispThread.execute(LispThread.java:798) 35: abcl_027941ee_2c60_4fe0_8ae7_0a41efb34cac.execute(Unknown Source) = #<function call-with-syntax-hooks {16BB516F}> 36: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 37: org.armedbear.lisp.Lisp.funcall(Lisp.java:172) 38: org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2827) = #<function apply {61157D6}> 39: (read #S(system::string-input-stream) nil #S(system::string-input-stream)) 40: (swank::eval-region "#<\n") 41: (#<local-function in repl-eval {78DF6AB0}>) 42: (swank-repl::track-package #<local-function in repl-eval {78DF6AB0}>) 43: (#<local-function in repl-eval {5C2443A9}>) 44: (swank::call-with-retry-restart "Retry SLIME REPL evaluation request." #<local-function in repl-eval {5C2443A9}>) 45: (#<local-function in repl-eval {6386D83A}>) 46: (swank/backend:call-with-syntax-hooks #<local-function in repl-eval {6386D83A}>) 47: (apply #<function call-with-syntax-hooks {16BB516F}> #<local-function in repl-eval {6386D83A}> nil) 48: (swank/backend:call-with-syntax-hooks #<local-function in repl-eval {6386D83A}>) 49: (swank::call-with-buffer-syntax nil #<local-function in repl-eval {6386D83A}>) 50: (swank-repl::repl-eval "#<\n") 51: (swank-repl:listener-eval "#<\n") 52: (system::%eval (swank-repl:listener-eval "#<\n")) 53: (eval (swank-repl:listener-eval "#<\n")) 54: (swank:eval-for-emacs (swank-repl:listener-eval "#<\n") "COMMON-LISP-USER" 418) 55: (apply #<function eval-for-emacs {347BE911}> ((swank-repl:listener-eval "#<\n") "COMMON-LISP-USER" 418)) 56: (swank::process-requests nil) 57: (#<local-function in handle-requests {468DC77D}>) 58: (#<local-function in handle-requests {1FC34DCD}>) 59: (swank/backend:call-with-debugger-hook #<function swank-debugger-hook {1C78BEE7}> #<local-function in handle-requests {1FC34DCD}>) 60: (apply #<function call-with-debugger-hook {2F2A561F}> #<function swank-debugger-hook {1C78BEE7}> #<local-function in handle-requests {1FC34DCD}> nil) 61: (swank/backend:call-with-debugger-hook #<function swank-debugger-hook {1C78BEE7}> #<local-function in handle-requests {1FC34DCD}>) 62: (#<local-function in handle-requests {2E4ADDE3}>) 63: (swank::call-with-bindings ((*standard-input* . #S(extensions:slime-input-stream)) (*standard-output* . #S(extensions:slime-output-stream)) (*trace-output* . #S(extensions:slime-output-stream)) ..) #<.. 64: (swank::handle-requests #<swank::multithreaded-connection {245DAD99}>) 65: (swank-repl::repl-loop #<swank::multithreaded-connection {245DAD99}>) 66: (#<local-function in spawn-repl-thread {376522E}>) 67: (swank::call-with-bindings nil #<local-function in spawn-repl-thread {376522E}>) 68: (#<local-function in spawn-repl-thread {5F73C8D9}>) 69: (#<local-function in g27583 {7AC7193C}>) 70: (threads::thread-function-wrapper #<local-function in g27583 {7AC7193C}>) On Mon, Jan 2, 2017 at 6:35 PM, Alan Ruttenberg <alanruttenberg(a)gmail.com> wrote: > Well, I've gone and made an attempt at a "less leaky" version. (It became > an obsession :( ) > > Some features: > - tries not to show internals of swank and abcl debugging calls > - shows top of exception trace for java exceptions, marked with "!" to > indicate they were caught. > - names local functions, even if we only would see the java frame. > - And some other nuisances. Read the code? > > > I am soliciting beta testers - need to see whether it holds up under > stress of use by other. > You will need to check out my branch of ABCL https://github.com/ > alanruttenberg/abcl.git - use branch "stage" > and you will need my branch of slime https://github.com/ > alanruttenberg/slime/ - use branch "beta" > > Build abcl with: ant abcl-aio.jar > > There are a number of other debugging goodies here, also worth testing: > - Better inspectors for some things, like java classes > - View source and disassemble from debugger should work on every frame > - Most definition sources are recorded, including those compiled in a > buffer. > Try edit definitions 'print-object and you will see all the methods and > their source locations > - slime-edit-callers > > Alan > > > > On Sun, Jan 1, 2017 at 6:11 AM, Mark Evenson <evenson(a)panix.com> wrote: > >> >> >> On 12/31/16 20:37, Alan Ruttenberg wrote: >> > 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 >> >> The ABCL backtrace abstraction is perhaps a little bit leaky and noisy >> with respect to its representation of Java calls, but it has been useful >> in improving the implementation in its present form since Tobias and I >> introduced it back in 2006-7 (?). >> >> My strong claim is that a user of ABCL never will see Java calls in the >> backtrace, as they only result in errors in the ABCL implementation >> which causes the "Lisp computation" to fail, thunking out into the >> surrounding Java Try/Catch/Exception mechanism. So, "normally" (i.e. >> when there are more bugs in your code than the implementation), these >> verbose, confusing messages are not seen by the user. >> >> In your example, frames 87-69 show the Lisp-side computation which got >> to the error being signaled in the ABCL implmentation. Then frames 4-68 >> provide the trace of Java attempting to deal with the error signaled by >> the JVM when executing Primitives.java:2845. Frames 0-2 show the error >> propagating back into the Lisp-side debugger machinery. >> >> I think the only real information I get as a developer here is that >> there is an error occuring in org.armedbear.lisp.Primitives:2845; the >> rest of the Java calls don't need to be shown. The backtrace from 4-67 >> can confirm/deny hypothesis about what exacly caused the Java error on >> that line, but usually I would figure things out by starting ABCL under >> JPDA, setting a break point before Primitives:2845, replicating the >> error, and single-stepping through the JVM execution until I understand >> the problem. >> >> The "logic" of javaPushStackFrames() (my code) is trying to elide noisy >> frames. Here it fails to elide frames in your example, as the entry >> point is in Primitive.java not Primitives.java, so this code should be >> changed. I would go with a simpler implementation of >> javaPushStackFrames() that doesn't try to elide frames, and place such a >> mechanism on actually viewing the stack. Perhaps we can get SLIME to >> "collapse" the Java portion of the backtrace (ala "the inspector") into >> a single statement of the source location that the Lisp computation >> enter the JVM error condition? >> >> Hopefully that provides some background for a proposal for a less noisy >> backtrace for your purposes to be possible. Since I often get bug >> reports consisting of little or more reproduction instructions than: "I >> have a problem with ABCL: it gave me this error." and a paste of the >> stack trace, it has been useful to have more information present than not. >> >> One could certainly somehow collapse frames 0-3 somehow into a single >> frame that represents the debugger invocation. >> >> >> >> >> >> >> > >> > 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-F >> ILE >> > "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.ja >> va: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-maco >> sx-x64/Volumes/upstairs/repos/jnil/lisp/jnil/cl-utils-tmpUYPFRO0B.abcl" >> > #P"/Users/lor.. >> > 86: (COMPILE-FILE #P"/Volumes/upstairs/repos/jni >> l/lisp/jnil/cl-utils.lisp" >> > :OUTPUT-FILE >> > #P"/Users/lori/.cache/common-lisp/abcl-1.5.0-dev-fasl43-maco >> sx-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-maco >> sx-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--; >> > } >> > } >> > >> >> -- >> "A screaming comes across the sky. It has happened before, but there >> is nothing to compare to it now." >> >> >

1 0

How to add abcl.jar to your class path for ABCL projects
by Mirko Vukovic 01 Jan '17

01 Jan '17

Hello, This is a follow-up to my earlier post on stack overflow. That problem is still not solved and here is one question. On the user documentation page I found the instruction to "add abcl.jar to your class path for ABCL projects" How do I do that? Thanks, Mirko

2 3

Re: stack overflow error on library load
by Alessio Stalla 20 Dec '16

20 Dec '16

Hmm, I wasn't actually expecting that :P maybe try updating SLIME... or perhaps this rings a bell for someone using ABCL on Windows regularly. Il 20 dic 2016 14:32, "Mirko Vukovic" <mirko.vukovic(a)gmail.com> ha scritto: > > > On Tue, Dec 20, 2016 at 8:25 AM Alessio Stalla <alessiostalla(a)gmail.com> > wrote: > >> You could try without SLIME, from the bare REPL. Not that SLIME breaks >> anything, but maybe you'll get a more understandable stack trace. >> > > Brilliant! Vecto loads in the Command Window (see below). What now? > > CL-USER(1): (asdf:load-system :vecto) > ; Compiling C:/Users/977315/quicklisp/dists/quicklisp/software/vecto-1.4.10/package.lisp > ... > ; (DEFPACKAGE #:VECTO ...) > ; Wrote C:/Users/977315/AppData/Local/cache/common-lisp/abcl-1.4.0- > fasl42-win-x86/C/Users/977315/quicklisp/dists/quicklisp/ > software/vecto-1.4.10/package-tmpKHDC356G.abcl (0.036 seconds) > ; Compiling C:/Users/977315/quicklisp/dists/quicklisp/software/vecto-1.4.10/utils.lisp > ... > ; (IN-PACKAGE #:VECTO) > ; (DEFUN CLAMP-RANGE ...) > ; (DEFUN FLOAT-OCTET ...) > ; (DEFUN OCTET-FLOAT ...) > ; (DEFVAR *HYPERDOC-BASE-URI* ...) > ; (LET (#) ...) > > >> >> On 20 December 2016 at 14:14, Mirko Vukovic <mirko.vukovic(a)gmail.com> >> wrote: >> >> >> >> On Tue, Dec 20, 2016 at 6:17 AM Alessio Stalla <alessiostalla(a)gmail.com> >> wrote: >> >> Could it be some path-related problem (e.g. spaces in the path, a very >> long path, unusual characters in the path, ...)? >> >> >> On my system the path to vecto is c:\Users\977314\quicklisp\... There >> are not spaces in the path. >> >> vecto depends on cl-vectors, zpng, zpb-ttf. I can load all of them >> without problem. >> >> Example of paths: >> >> ; SLIME 2.18 >> CL-USER> (asdf:system-source-directory :cl-vectors) >> #P"C:/Users/977315/quicklisp/dists/quicklisp/software/cl- >> vectors-20150407-git/" >> CL-USER> (asdf:system-source-directory :vecto) >> #P"C:/Users/977315/quicklisp/dists/quicklisp/software/vecto-1.4.10/" >> CL-USER> >> >> If vecto.asd contains dependencies to those three libraries, the asd will >> load. Once I add a file to the list of components, it fails. >> >> Mirko >> >> >> >> On 18 December 2016 at 23:23, Mirko Vukovic <mirko.vukovic(a)gmail.com> >> wrote: >> >> Hello again, >> >> I have joined the mailing list, and also seen Mark Evenson's reply >> https://mailman.common-lisp.net/pipermail/armedbear-devel/ >> 2016-December/003759.html. >> It is encouraging that he can load Vecto. >> >> A few more details on my environment and more probing results >> >> Implementation details: >> >> CL-USER> (lisp-implementation-version) >> "1.4.0" >> "Java_HotSpot(TM)_Client_VM-Oracle_Corporation-1.7.0_51-b13" >> "x86-Windows_8-6.2" >> >> Does the above look OK? Version wise, it is close to what Mark has, >> except that he has >> JDK, and I have Java_HotSpot. >> >> ASDF Version: >> >> I was wondering if the issue had to do with ASDF's looking for libraries >> and files, i.e., whether >> I was hit by an ASDF bug. So I installed the latest ASDF moving from >> 3.1.7, to 3.1.7.43, >> (which is a release candidate for asdf 3.2) >> >> The stack overflow remains. >> >> Manual loading of dependencies (libraries and files): >> >> I verified that I can manually load all the libraries vecto depends on, >> and also manually >> compile and load all of its component files. >> >> Isolate bug by dividing up the ASDF file: >> >> To investigate further, I started commenting out parts of Vecto's asdf >> file. As long as the components >> list is empty, asdf will load Vecto. >> (asdf:defsystem #:vecto >> :depends-on (#:cl-vectors >> #:zpng >> #:zpb-ttf) >> :version "1.4.10" >> :author "Zach Beane <xach(a)xach.com>" >> :description "Create vector graphics in PNG files." >> :license "BSD" >> :components ()) >> >> But adding a file to the components list will cause stack overflow. For >> example >> this will cause stack overflow: >> >> (asdf:defsystem #:vecto >> :depends-on (#:cl-vectors >> #:zpng >> #:zpb-ttf) >> :version "1.4.10" >> :author "Zach Beane <xach(a)xach.com>" >> :description "Create vector graphics in PNG files." >> :license "BSD" >> :components ((:file "package"))) >> >> >> >> >> >> On Wed, Dec 14, 2016 at 8:54 AM Mirko Vukovic <mirko.vukovic(a)gmail.com> >> wrote: >> >> See below: >> >> On Tue, Dec 13, 2016 at 10:45 PM Mirko Vukovic <mirko.vukovic(a)gmail.com> >> wrote: >> >> Hello, >> >> I have installed ABCL 1.4 on Windows 10 and Java 1.7. >> >> When loading some libraries, I get a stack overflow error. >> >> For example loading vecto fails >> >> vecto passes the cl-test-grid on linux (see >> https://common-lisp.net/project/cl-test-grid/library/vecto.html) >> >> >> I did a bit more probing to try and isolate the cause of the overflow: >> >> - ASDF file manually loads and compiles >> - I could manually load all the pre-requisite libraries >> - I could manually compile and load all the lisp files >> >> Looking at the error message in frame 8 (see below), the cause may be >> in the slime/swank interaction with abcl. >> >> I may take this up at the slime mailing list. >> >> >> >> Running >> (asdf:load-system :vecto) >> >> Gives: >> Stack overflow. >> [Condition of type STORAGE-CONDITION] >> >> Restarts: >> 0: [*ABORT] Return to SLIME's top level. >> 1: [ABORT] Abort thread. >> >> Backtrace: >> 0: (#<FUNCTION {BEB670}> #<STORAGE-CONDITION {14AA1B6}> #<FUNCTION >> {BEB670}>) >> 1: (APPLY #<FUNCTION {BEB670}> (#<STORAGE-CONDITION {14AA1B6}> >> #<FUNCTION {BEB670}>)) >> 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<STORAGE-CONDITION >> {14AA1B6}> #<FUNCTION {BEB670}>) >> 3: (INVOKE-DEBUGGER #<STORAGE-CONDITION {14AA1B6}>) >> 4: org.armedbear.lisp.Lisp.stackError(Lisp.java:388) >> 5: org.armedbear.lisp.swank_513.execute(swank.lisp:1677) >> 6: org.armedbear.lisp.LispThread.execute(LispThread.java:851) >> 7: org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2800) >> 8: (SWANK:EVAL-FOR-EMACS (SWANK-REPL:LISTENER-EVAL "(asdf:load-system >> :vecto) >> ") "COMMON-LISP-USER" 9) >> etc >> >> >> >>

2 1

stack overflow error on library load
by Mirko Vukovic 20 Dec '16

20 Dec '16

Hello, I have installed ABCL 1.4 on Windows 10 and Java 1.7. When loading some libraries, I get a stack overflow error. For example loading vecto fails vecto passes the cl-test-grid on linux (see https://common-lisp.net/project/cl-test-grid/library/vecto.html) Running (asdf:load-system :vecto) Gives: Stack overflow. [Condition of type STORAGE-CONDITION] Restarts: 0: [*ABORT] Return to SLIME's top level. 1: [ABORT] Abort thread. Backtrace: 0: (#<FUNCTION {BEB670}> #<STORAGE-CONDITION {14AA1B6}> #<FUNCTION {BEB670}>) 1: (APPLY #<FUNCTION {BEB670}> (#<STORAGE-CONDITION {14AA1B6}> #<FUNCTION {BEB670}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<STORAGE-CONDITION {14AA1B6}> #<FUNCTION {BEB670}>) 3: (INVOKE-DEBUGGER #<STORAGE-CONDITION {14AA1B6}>) 4: org.armedbear.lisp.Lisp.stackError(Lisp.java:388) 5: org.armedbear.lisp.swank_513.execute(swank.lisp:1677) 6: org.armedbear.lisp.LispThread.execute(LispThread.java:851) 7: org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2800) 8: (SWANK:EVAL-FOR-EMACS (SWANK-REPL:LISTENER-EVAL "(asdf:load-system :vecto) ") "COMMON-LISP-USER" 9) etc

3 6

quicklisp not finding systems in local-projects
by Mike Maul 25 Nov '16

25 Nov '16

Tried in version 1.4 and also built from source.

2 3

[HEADS UP] Fasl bump needed for working on TRUNK for recording SYS:SOURCE information
by Mark Evenson 24 Nov '16

24 Nov '16

HEADS-UP: the fasl version has been bumped on TRUNK for those of you following along at home. Alan Ruttenberg's [enhancements to record source information][415] have now been merged. [415]: http://abcl.org/trac/ticket/415 The interface to recording information on the SYS:%SOURCE plist for a symbol is now deprecated and will be removed with abcl-1.7. Source information for ABCL is now recorded on the SYS:SOURCE property. The appropiate information for type is recorded by the SYS:RECORD-SOURCE-INFORMATION-BY-TYPE function Now we just have to change SLIME… -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

Java-9 support
by Mark Evenson 22 Nov '16

22 Nov '16

Curious about what exactly our situation running on Java 9 would be, I took a stab at compiling/running ABCL under: "1.5.0-dev" "Java_HotSpot(TM)_64-Bit_Server_VM-Oracle_Corporation-9-ea+145" "x86_64-Mac_OS_X-10.12.1" The good news is that setting the javac source/target to "1.6" seems to be fine, so the assertion that the compiler will continue to work, albeit inefficiently as noted by Alessio, seems to be born out. The bad news is that due to the changes for "Project Jigsaw" aka [modular-runtime-images][], ABCL can no longer load ABCL-CONTRIB and therefore prevents ASDF from working. The root problem stems from Java 9 no longer using jar archives for system classes, which means that the boot classloader is no longer a descendant of URLClassloader which our current code relies on. Ticket [424][] tracks this issue, containing a patch that at least gets ABCL compiled/running the base ANSI system under Java 9. [423]: http://abcl.org/trac/ticket/423 [modular-runtime-images] https://bugs.openjdk.java.net/browse/JDK-8061971 -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

Re: SYS:RUN-PROGRAM does not work on pre-Java7 JVMs (was Re: abcl-1.4.0 released)
by Mark Evenson 22 Nov '16

22 Nov '16

On 11/18/16 18:25, Scott Burson wrote: > It's not a miracle at all. JVMs have always been backward-compatible with > older classfiles. The big Java app I work on for my day job is mostly > compiled for 1.8, but ships with libraries compiled for earlier targets. > We've never had the slightest trouble as a result. You only need to > generate a newer bytecode version if you want to use a new feature (like > InvokeDynamic -- wasn't Alessio working on that?). I now accept Scott's reasoning on this: ORCL will probably have to maintain bytecode compatibility for a long time, otherwise there would be chaos with existing libraries that are available binary-only. In practice, most of the libraries are distributed by Maven are effectively binary-only, as the steps to build from source are not always clear or documented. Plus many commercial vendors distribute applications as jars. When we compile our Java, we do get the following warnings: abcl.compile.java: Compiling 1 source file to /Users/evenson/work/abcl/build/classes warning: [options] bootstrap class path not set in conjunction with -source 1.5 warning: [options] source value 1.5 is obsolete and will be removed in a future release warning: [options] target value 1.5 is obsolete and will be removed in a future release warning: [options] To suppress warnings about obsolete options, use -Xlint:-options. which indicates to me that at some point in the future, JDK-N (where N is greater than 9) will not compile to JDK5 bytecode anymore. Can anyone point to a statement of what ORCL intends here for obsolescence? --- As for the compatiblity problems with SYS:RUN-PROGRAM, my current propose is from <http://abcl.org/trac/ticket/422#comment:1>: 1. Un-deprecate SYS:RUN-SHELL-COMMAND. Use the pre Java 7 APIs as best we can to support invoking programs, which essentially boils down to being able to take a string, attempt to invoke it, and return its stdout as a string. 2. Re-code the SYS:RUN-PROGRAM Java callsite linkages so that ABCL may be compiled on pre-Java7 JDKs. Produce an intelligible error if it is invoked on a pre-Java7 JVM. 3. Create an API to determine runtime JVM version. Wrap UIOP/RUN-PROGRAM invocation in some sort of handler that will "fall back" to using SYS:RUN-SHELL-COMMAND if it has compatible behavior via specified args. This will potentially be fairly ugly code ASDF-side so we might provide a shim that UIOP/RUN-PROGRAM invokes that contains the logic outside the ASDF code base. Any objections to this path forward? -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

5 6