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

[armedbear-devel] Setup changes for cl-test-grid.cloud.efficito.com
by Erik Huelsmann 08 Apr '15

08 Apr '15

Hi Anton, Looking at some of the test grid failures for ABCL, I noticed some of the OpenGL packages failing due to being unable to locate LibGL.so. To resolve that, I ran: $ aptitude install libgl1-mesa-swx11 Then I noticed something wanted to require JSS, but didn't know how to, so I've added "(require :abcl-contrib)" to /home/testgrid/.abclrc. With these in place cl-glfw-opengl-core seems to load just fine. Any other libraries or measures I should take in order to be able to load (currently failing) systems? Bye, Erik.

3 3

[Armedbear-devel] (require 'jna) broken by 0030b89b2
by Cyrus Harmon 06 Mar '15

06 Mar '15

Commit 0030b89b2eb24b0b63b5f1ca4d4c9a7644eea02d breaks the maven JNA resolution: (sly@cyruss-mbp):~/src/abcl$ ./abcl Armed Bear Common Lisp 1.4.0-dev Java 1.7.0_51 Oracle Corporation Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.351 seconds. Startup completed in 1.786 seconds. Loading /Users/sly/.abclrc completed in 9.51 seconds. Type ":help" for a list of available commands. CL-USER(1): (require 'abcl-contrib) Using probed value of abcl-contrib: '/Users/sly/src/abcl/dist/abcl-contrib.jar'. Added jar:file:/Users/sly/src/abcl/dist/abcl-contrib.jar!/quicklisp/ to ASDF. Added jar:file:/Users/sly/src/abcl/dist/abcl-contrib.jar!/mvn/ to ASDF. Added jar:file:/Users/sly/src/abcl/dist/abcl-contrib.jar!/jss/ to ASDF. Added jar:file:/Users/sly/src/abcl/dist/abcl-contrib.jar!/jfli/ to ASDF. Added jar:file:/Users/sly/src/abcl/dist/abcl-contrib.jar!/asdf-jar/ to ASDF. Added jar:file:/Users/sly/src/abcl/dist/abcl-contrib.jar!/asdf-install/ to ASDF. Added jar:file:/Users/sly/src/abcl/dist/abcl-contrib.jar!/abcl-asdf/ to ASDF. ("ABCL-CONTRIB") CL-USER(2): (require 'jna) ARTIFACT_RESOLVING net.java.dev.jna:jna:pom:4.1.0 ARTIFACT_RESOLVED net.java.dev.jna:jna:pom:4.1.0 (/Users/sly/.m2/repository/net/java/dev/jna/jna/4.1.0/jna-4.1.0.pom) @ central (http://repo1.maven.org/maven2/, releases+snapshots) jnaASDF could not load because Java exception 'java.lang.NullPointerException'.. #<THREAD "interpreter" {4323B3D5}>: Debugger invoked on condition of type JAVA-EXCEPTION Java exception 'java.lang.NullPointerException'. Restarts: 0: RETRY Retry compiling #<ASDF/INTERFACE:MVN "jna" "net.java.dev.jna/jna/4.1.0">. 1: ACCEPT Continue, treating compiling #<ASDF/INTERFACE:MVN "jna" "net.java.dev.jna/jna/4.1.0"> as having been successful. 2: TOP-LEVEL Return to top level. [1] CL-USER(3): [1] CL-USER(4): :bt 0: (SYSTEM:BACKTRACE) 1: (INVOKE-DEBUGGER #<JAVA-EXCEPTION java.lang.NullPointerException {1DA02950}>) 2: org.armedbear.lisp.Lisp.error(Lisp.java:382) 3: org.armedbear.lisp.Java$pf_jnew.execute(Java.java:581) 4: org.armedbear.lisp.Primitive.execute(Primitive.java:135) 5: (JNEW #<java class org.eclipse.aether.resolution.DependencyRequest> #<org.eclipse.aether.graph.DefaultDependencyNode net.java.dev.jna:jna:jar:4.1.0 (.... {60206C1}> #<null {6F096BFB}>) 6: (ABCL-ASDF:RESOLVE-DEPENDENCIES "net.java.dev.jna" "jna" "4.1.0") 7: (#<FUNCTION {28D8442C}> (#<ASDF/INTERFACE:MVN "jna" "net.java.dev.jna/jna/4.1.0">)) Any clues? thanks, Cyrus _______________________________________________ Armedbear-devel mailing list Armedbear-devel(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

4 5

[Armedbear-devel] Advancements in preparing ASDF system in ABCL for WAR
by Mark Evenson 06 Mar '15

06 Mar '15

A notice for those interested in my recent work in deploying ABCL as a WAR binary artifact of [an update to abcl-servlet][1], which is where I am collecting my ideas on implementation in an open source form. After locating the ASDF ABCL-SERVLET/BUILD definition, one may CL-USER> (abcl-servlet/prepare :hunchentoot) to create necessary packaging of Hunchentoot and its transitive ASDF dependences to [<file:hunchentoot/build/web/asdf/>][2] for merging into Java Servlet WAR archives. I’ve got a 100 Mib deployment WAR out of this system that has been running in production for six months now, but comments on how to generalise are welcome. [1]: https://bitbucket.org/easye/abcl-servlet/commits/e3bf36e015f2b5168d3e1d3d54… [2]: https://bitbucket.org/easye/abcl-servlet/src/b0e7e5353d6c92a1990ed1bb5500be… -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now." _______________________________________________ Armedbear-devel mailing list Armedbear-devel(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

2 1

[Armedbear-devel] Tail recursion
by Ralf Moeller 06 Mar '15

06 Mar '15

Hi all, ABCL does not seem to support tail call optimization right now. Are there any plans to provide this? Best regards, Ralf Moeller _______________________________________________ Armedbear-devel mailing list Armedbear-devel(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

4 5

[Armedbear-devel] Question about pipes
by Sistemas 27 Sep '14

27 Sep '14

Hi: I'm trying to start some processes and connect them using pipes with ABCL (like Unix shell pipes). I've reviewed the documentation but I haven't found anything. Are I missing something? If not, are there any plans of adding input, output and error parameters for run-program (like SBCL, CCL, etc.)? Greets and thanks in advance. Rafael J. Alcántara Pérez. -- +---------- | Departamento de Sistemas <sistemas(a)dedaloingenieros.com> | Teléfono fijo: 952 602 959 | Fax: 952 602 959 | Dirección: C/ Afligidos 2, 3º Derecha, 29015 Málaga | Dédalo Ingenieros, S.L.: http://www.dedaloingenieros.com/ | PGP: http://pgp.rediris.es:11371/pks/lookup?op=index&search=0x1899F325 +--------------------- _______________________________________________ Armedbear-devel mailing list Armedbear-devel(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

5 7

[Armedbear-devel] Comments on Cyrus's proposal for JSS static calls
by Mark Evenson 27 Sep '14

27 Sep '14

Erik asked me to comment on [Cyrus’s proposed patch][1] to extend JSS’s SHARPSIGN-DOUBLE-QUOTE use in static method calls to accept a string as well as a symbol to designate the object. Unfortunately, changing JSS in the manner means that one can no longer use SHARPSIGN-DOUBE-QUOTE on object descended from java.lang.String, for the reasons described in the [JSS README][2]: […] Static calls are possible as well with the #" macro, but the first argument MUST BE A SYMBOL to distinguish (#"getProperties" "java.lang.System") from (#"getProperties" 'java.lang.System) The first attempts to call a method on the java.lang.String object with the contents "java.lang.System", which results in an error, while the second invokes the static java.lang.System.getProperties() method. […] Other than perhaps for aesthetic reasons, is there some functionality that using strings enables here? To argue about preserving character case in strings as opposed to the case folding implicit in symbols doesn’t seem to be applicable, because JSS currently ignores case when searching for matching JVM symbols. In 2006, when I first understood the ignoring case bit of JSS, I was a bit worried that there would be cases where this resulted in ambiguity and errors, but in the ensuing years I have yet to run into a single problem with this design decision. Therefore, I am not currently persuaded that introducing an asymmetry to SHARPSIGN-DOUBLE-QUOTE (“It works on any java Object except those which descend from java.lang.String; for those instances you have to use the JFI”) to use strings as well as symbols to specify static methods is worth it. But please argue back if you disagree… [1]: https://github.com/slyrus/abcl/commit/9ec0fb26c7b7e9470349b1c4bd9be6fa4b053… [2]: http://abcl.org/trac/browser/trunk/abcl/contrib/jss/README.markdown#L55 -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now." _______________________________________________ Armedbear-devel mailing list Armedbear-devel(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

3 2

[Armedbear-devel] Bug: compile function doesn't work
by Mariano Montone 27 Sep '14

27 Sep '14

Hello, This function is not working in the latest ABCL version: http://clhs.lisp.se/Body/f_cmp.htm This is what I get when I try to evaluate the example in CLHS: (defun foo () "bar") => FOO (compile 'foo) Wrong number of arguments for #<FUNCTION {5236A94B}>. [Condition of type PROGRAM-ERROR] Restarts: 0: [RETRY] Retry SLIME REPL evaluation request. 1: [*ABORT] Return to SLIME's top level. 2: [ABORT] Abort thread. Backtrace: 0: (#<FUNCTION {752CC03}> #<PROGRAM-ERROR {600776A0}> #<FUNCTION {752CC03}>) 1: (APPLY #<FUNCTION {752CC03}> (#<PROGRAM-ERROR {600776A0}> #<FUNCTION {752CC03}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<PROGRAM-ERROR {600776A0}> #<FUNCTION {752CC03}>) 3: (INVOKE-DEBUGGER #<PROGRAM-ERROR {600776A0}>) 4: org.armedbear.lisp.Lisp.error(Lisp.java:382) 5: org.armedbear.lisp.CompiledClosure.notImplemented(CompiledClosure.java:81) 6: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:212) 7: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) 8: org.armedbear.lisp.FuncallableStandardObject.execute(FuncallableStandardObject.java:117) 9: org.armedbear.lisp.Symbol.execute(Symbol.java:826) 10: org.armedbear.lisp.compiler_pass2_387.execute(compiler-pass2.lisp:7495) 11: org.armedbear.lisp.compiler_pass2_370.execute(compiler-pass2.lisp:7450) 12: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) 13: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 14: org.armedbear.lisp.compiler_pass2_386.execute(compiler-pass2.lisp:7495) 15: org.armedbear.lisp.Symbol.execute(Symbol.java:838) 16: org.armedbear.lisp.compiler_pass2_388.execute(compiler-pass2.lisp:7519) 17: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) 18: org.armedbear.lisp.Symbol.execute(Symbol.java:814) 19: org.armedbear.lisp.compiler_pass2_392.execute(compiler-pass2.lisp:7589) 20: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) 21: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 22: org.armedbear.lisp.Lisp.evalCall(Lisp.java:575) 23: org.armedbear.lisp.Lisp.eval(Lisp.java:540) 24: org.armedbear.lisp.Primitives$pf__eval.execute(Primitives.java:345) 25: (COMPILE FOO) I'm not using this directly, but some libraries like closer-mop, need compile to work. Fails here: CL-USER> (lisp-implementation-type) "Armed Bear Common Lisp" CL-USER> (lisp-implementation-version) "1.4.0-dev-svn-14713" "OpenJDK_64-Bit_Server_VM-Oracle_Corporation-1.7.0_55-b14" "amd64-Linux-3.5.0-17-generic" It seems to work in some cases on ABCL 1.3.1, though. CL-USER> (compile 'foo) FOO NIL NIL But something like this signals an error: CL-USER> (compile nil '(lambda (x) x)) ; Evaluation aborted on #<PROGRAM-ERROR {4C62C417}>. With the same error above. CL-USER> (lisp-implementation-version) "1.3.1" "OpenJDK_64-Bit_Server_VM-Oracle_Corporation-1.7.0_55-b14" "amd64-Linux-3.5.0-17-generic" I couldn't put this on the bugs tracker because I don't have permissions. Cheers, Mariano _______________________________________________ Armedbear-devel mailing list Armedbear-devel(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

2 3

Re: [Cffi-devel] Patches to CFFI for ABCL which passes all tests
by Cyrus Harmon 27 Sep '14

27 Sep '14

On Aug 20, 2014, at 2:24 AM, Mark Evenson <evenson(a)panix.com> wrote: > > Even though we are passing all the CFFI tests, > > CL-USER> (drakma:http-request “https://google.com”) > > still times out with an error. Always something further to fix… Yes, I’ve run across this too. The first https call hangs, even if one adds :connection-timeout 120. Could we be improperly initializing something somewhere along the run? After recovering from this error, subsequent calls work. This is probably more of a cl+ssl issue than a cffi (or ABCL) issue, but it definitely seems to be ABCL-specific. Thanks for your work to clean up the CFFI patch set! I look forward to the day when I can run stock CFFI, cl+ss, and ABCL and have all my code working :) Cyrus

3 3