armedbear-ticket August 2014

armedbear-ticket@common-lisp.net

1 participants
9 discussions

[Armedbear-ticket] [armedbear] #355: cl+ssl/drakma fails on https requests
by armedbear 17 Nov '16

17 Nov '16

#355: cl+ssl/drakma fails on https requests ---------------------+----------------- Reporter: charmon | Owner: Type: defect | Status: new Priority: major | Milestone: Component: (A)MOP | Version: Keywords: | ---------------------+----------------- The following shows what happens if you try to fetch a URL using DRAKMA and https: CL-USER> (ql:quickload 'cl+ssl) To load "cl+ssl": Load 1 ASDF system: cl+ssl ; Loading "cl+ssl" ......... 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. . ARTIFACT_RESOLVING net.java.dev.jna:jna:pom:4.0.0 ARTIFACT_RESOLVED net.java.dev.jna:jna:pom:4.0.0 (/Users/sly/.m2/repository/net/java/dev/jna/jna/4.0.0/jna-4.0.0.pom) @ central (http://repo1.maven.org/maven2/, releases+snapshots) ARTIFACT_RESOLVING net.java.dev.jna:jna:jar:4.0.0 ARTIFACT_RESOLVED net.java.dev.jna:jna:jar:4.0.0 (/Users/sly/.m2/repository/net/java/dev/jna/jna/4.0.0/jna-4.0.0.jar) @ central (http://repo1.maven.org/maven2/, releases+snapshots) ... (CL+SSL) CL-USER> (ql:quickload 'drakma) To load "drakma": Load 1 ASDF system: drakma ; Loading "drakma" .... (DRAKMA) CL-USER> (drakma:http-request "https://www.google.com/") A failure in the SSL library occurred on handle #<com.sun.jna.Pointer native@0x7ffe7cc007f0 {6777A3D7}> (return code: 1). SSL error queue: error:140C5042:SSL routines:SSL_UNDEFINED_FUNCTION:called a function you should not call [Condition of type CL+SSL::SSL-ERROR-SSL] Restarts: 0: [RETRY] Retry SLIME REPL evaluation request. 1: [*ABORT] Return to SLIME's top level. 2: [ABORT] Abort thread. Backtrace: 0: (#<FUNCTION {4026A35B}> #<CL+SSL::SSL-ERROR-SSL {306F7D00}> #<FUNCTION {4026A35B}>) 1: (APPLY #<FUNCTION {4026A35B}> (#<CL+SSL::SSL-ERROR-SSL {306F7D00}> #<FUNCTION {4026A35B}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<CL+SSL::SSL-ERROR- SSL {306F7D00}> #<FUNCTION {4026A35B}>) 3: (INVOKE-DEBUGGER #<CL+SSL::SSL-ERROR-SSL {306F7D00}>) 4: (ERROR CL+SSL::SSL-ERROR-SSL :HANDLE #<com.sun.jna.Pointer native@0x7ffe7cc007f0 {6777A3D7}> :RET 1 ...) 5: (#<FUNCTION {28AECC44}> (#<CL+SSL::SSL-STREAM {6BE49939}>)) 6: (#<FUNCTION {6D07A485}> (#<CL+SSL::SSL-STREAM {6BE49939}>)) 7: (GRAY-STREAMS:STREAM-FINISH-OUTPUT #<CL+SSL::SSL-STREAM {6BE49939}>) 8: (SYSTEM::%FINISH-OUTPUT #<CL+SSL::SSL-STREAM {6BE49939}>) 9: (FINISH-OUTPUT #<CL+SSL::SSL-STREAM {6BE49939}>) 10: (#<FUNCTION (LAMBDA (CL+SSL::CALLBACK-ARG-BIO- CL+SSL::CALLBACK-ARG- BUF- CL+SSL::CALLBACK-ARG-N-)) {10C24FAF}> #<com.sun.jna.Pointer native@0x7ffe7cb929c0 {44FD72C1}> #<com.sun.jna.Pointer native@0x7f.. 11: (JCALL #<java.lang.reflect.Method public java.lang.Object com.sun..... {6008072D}> #<com.sun.jna.Function native function SSL_connect(<pro.... {2F0F4C9C}> #<java.lang.Class class java.lang.Integer {15.. 12: (CL+SSL::SSL-CONNECT #<com.sun.jna.Pointer native@0x7ffe7cc007f0 {6777A3D7}>) 13: (CL+SSL:MAKE-SSL-CLIENT-STREAM #<TWO-WAY-STREAM {7FB606A}> :CLOSE- CALLBACK #<FUNCTION {876D33E}> :CERTIFICATE NIL ...) 14: (DRAKMA::MAKE-SSL-STREAM #<TWO-WAY-STREAM {7FB606A}> :CERTIFICATE NIL :KEY NIL ...) 15: (DRAKMA:HTTP-REQUEST "https://www.google.com/") 16: (SYSTEM::%EVAL (DRAKMA:HTTP-REQUEST "https://www.google.com/")) 17: (EVAL (DRAKMA:HTTP-REQUEST "https://www.google.com/")) --more-- I'm not sure if this is an ABCL problem, a DRAKMA problem, a CFFI problem, or a CL+SSL problem, but my guess is it's a ABCL problem. -- Ticket URL: <http://abcl.org/trac/ticket/355> armedbear <http://abcl.org> armedbear

1 1

[Armedbear-ticket] [armedbear] #368: define-setf-expander is not available for expansion later in the file on ABCL unless we wrap it in an eval-when
by armedbear 28 Apr '15

28 Apr '15

#368: define-setf-expander is not available for expansion later in the file on ABCL unless we wrap it in an eval-when ----------------------+----------------------- Reporter: mevenson | Owner: Type: defect | Status: new Priority: major | Milestone: 1.4.0 Component: java | Version: 1.4.0-dev Keywords: | ----------------------+----------------------- define-setf-expander is not available for expansion later in the file on ABCL unless we wrap it in an eval-when https://github.com/easye/cffi/commit/03624e609cd48cc065bd15c8dcea715f287b6b… Slyrus ran into this while working on CFFI. -- Ticket URL: <http://abcl.org/trac/ticket/368> armedbear <http://abcl.org> armedbear

1 9

[Armedbear-ticket] [armedbear] #365: ABCL-Jar not working on Mac OS X
by armedbear 28 Apr '15

28 Apr '15

#365: ABCL-Jar not working on Mac OS X ----------------------------+----------------- Reporter: robert goldman | Owner: Type: defect | Status: new Priority: major | Milestone: Component: abcl-contrib | Version: Keywords: | ----------------------------+----------------- When I tried to package a system of mine, I got cryptic errors and an empty jar file. Turning on debugging, I see this: {{{ PRISM> (asdf-jar:package :abcl-prism) Packaging ASDF definition of #<ASDF/SYSTEM:SYSTEM "abcl-prism"> Packaging contents in /var/tmp/abcl-prism-all.jar with recursive dependencies ITERATE, JSS. /Users/rpg/prismatic/code/quiksilver/abcl/package.lisp => abcl-prism/package.lisp /Users/rpg/.cache/common-lisp/abcl-1.4.0-dev- fasl42-macosx-x64/Users/rpg/prismatic/code/quiksilver/abcl/package.abcl => Serious printing error: org.armedbear.lisp.Go Serious printing error: org.armedbear.lisp.Go Serious printing error: org.armedbear.lisp.Go Serious printing error: org.armedbear.lisp.Go Serious printing error: org.armedbear.lisp.Go Serious printing error: org.armedbear.lisp.Go Serious printing error: org.armedbear.lisp.Go Serious printing error: org.armedbear.lisp.Go Serious printing error: org.armedbear.lisp.Go ; Evaluation aborted on #<SIMPLE-ERROR {58717F69}>. PRISM> }}} I can't say for sure, but it looks suspiciously like the results of ASDF output translations might be causing ASDF-JAR to fail. Is there any chance that these pathnames are simply too long? Or contain characters that ABCL treats as illegal? What's the appropriate solution for packaging up fasls so that I can load them from jars (I have no idea how else to package up Lisp so that it can be called from Java...)? BTW, there is a long-standing, unresolved bug in the ABCL implementation of the ASDF bundling operations on Mac OSX, so that's not a solution. Thanks! -- Ticket URL: <http://abcl.org/trac/ticket/365> armedbear <http://abcl.org> armedbear

1 17

[Armedbear-ticket] [armedbear] #364: ASDF-JAR:PACKAGE breaks with simple usage.
by armedbear 28 Apr '15

28 Apr '15

#364: ASDF-JAR:PACKAGE breaks with simple usage. -----------------------------+----------------- Reporter: eduardo bellani | Owner: Type: defect | Status: new Priority: major | Milestone: Component: abcl-contrib | Version: Keywords: jar package | -----------------------------+----------------- An application such as {{{ #!common-lisp (asdf-jar:package :a-test-system) }}} will produce the error: {{{ Unsupported directory component "servlet-test". [Condition of type FILE-ERROR] }}} The purpose of the attached patch is to fix that, and to provide better documentation through the abstraction of parts of the package function into new functions. -- Ticket URL: <http://abcl.org/trac/ticket/364> armedbear <http://abcl.org> armedbear

1 6

[Armedbear-ticket] [armedbear] #362: GET-JAVA-FIELD doesn't behave orthogonally when TRY-HARDER is T
by armedbear 28 Apr '15

28 Apr '15

#362: GET-JAVA-FIELD doesn't behave orthogonally when TRY-HARDER is T ----------------------------+----------------- Reporter: robert goldman | Owner: Type: defect | Status: new Priority: major | Milestone: Component: JSS | Version: Keywords: | ----------------------------+----------------- `GET-JAVA-FIELD`, when its optional `TRY-HARDER` argument is `NIL`, will return any public field on its argument object, whether defined locally or inherited. When `TRY-HARDER` argument is true, on the other hand, it will return ''non-public'' fields as well as public ones but only non-public fields that are defined locally -- not non-public fields that are inherited. This non-orthogonality seems wrong (just read the contorted description above and imagine it as a docstring!). I am attaching a proposed patch which searches up the class hierarchy to find inherited non-public fields when `TRY-HARDER` is true. -- Ticket URL: <http://abcl.org/trac/ticket/362> armedbear <http://abcl.org> armedbear

1 9

[Armedbear-ticket] [armedbear] #360: Unable to load hunchentoot via quicklisp (maven, asdf problem?)
by armedbear 05 Jan '15

05 Jan '15

#360: Unable to load hunchentoot via quicklisp (maven, asdf problem?) ----------------------------+----------------- Reporter: david creelman | Owner: Type: defect | Status: new Priority: major | Milestone: Component: other | Version: Keywords: | ----------------------------+----------------- After successfully setting up quicklisp, I try to do :- (ql:quickload "hunchentoot") and get the following (apologies for bad formatting, copying from a Windows cmd window. ..... [package jss]..................................... [package abcl-asdf]............................... [package abcl-asdf-test]. ; 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 The file http://repo1.maven.org/maven2/net/java/ dev/jna/jna/4.1.0/jna-4.1.0.jar does not exist.. #<THREAD "interpreter" {938BE3}>: Debugger invoked on condition of type FILE-ERR OR The file http://repo1.maven.org/maven2/net/java/dev/jna/jna/4.1.0/jna-4.1.0.ja r does not exist. Restarts: 0: RETRY Retry loading #<ASDF/INTERFACE:MVN "jna" "net.java.dev.jna/jna/4. 1.0">. 1: ACCEPT Continue, treating loading #<ASDF/INTERFACE:MVN "jna" "net.java.d ev.jna/jna/4.1.0"> as having been successful. 2: RETRY Retry compiling #<ASDF/LISP-ACTION:CL-SOURCE-FILE "cffi" "src" "c ffi-abcl">. 3: ACCEPT Continue, treating compiling #<ASDF/LISP-ACTION:CL-SOURCE- FILE "c ffi" "src" "cffi-abcl"> as having been successful. 4: ABORT Give up on "hunchentoot" 5: TOP-LEVEL Return to top level. [1] CL-USER(5): 0 jnaASDF could not load because The file http://repo1.maven.org/maven2/net/java/ dev/jna/jna/4.1.0/jna-4.1.0.jar does not exist.. #<THREAD "interpreter" {938BE3}>: Debugger invoked on condition of type FILE-ERR OR The file http://repo1.maven.org/maven2/net/java/dev/jna/jna/4.1.0/jna-4.1.0.ja r does not exist. Restarts: 0: RETRY Retry loading #<ASDF/INTERFACE:MVN "jna" "net.java.dev.jna/jna/4. 1.0">. 1: ACCEPT Continue, treating loading #<ASDF/INTERFACE:MVN "jna" "net.java.d ev.jna/jna/4.1.0"> as having been successful. 2: RETRY Retry compiling #<ASDF/LISP-ACTION:CL-SOURCE-FILE "cffi" "src" "c ffi-abcl">. 3: ACCEPT Continue, treating compiling #<ASDF/LISP-ACTION:CL-SOURCE- FILE "c ffi" "src" "cffi-abcl"> as having been successful. 4: ABORT Give up on "hunchentoot" 5: TOP-LEVEL Return to top level. Please let me know if you would like more information. This may be strictly speaking a quicklisp issue, but it seems to be calling in the ABCL asdf stuff. Regards, David -- Ticket URL: <http://abcl.org/trac/ticket/360> armedbear <http://abcl.org> armedbear

1 22

[Armedbear-ticket] [armedbear] #367: Add easy way to load ASDF systems (and other software?) from classpath jars
by armedbear 18 Aug '14

18 Aug '14

#367: Add easy way to load ASDF systems (and other software?) from classpath jars ----------------------------+----------------- Reporter: robert goldman | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: other | Version: Keywords: | ----------------------------+----------------- I have been writing a Java program that uses some code implemented in ABCL. I packaged everything up with `ASDF-JAR` and put the Jar file in the command line. The original idea was to provide an easy way for the program to find my code. But it hasn't panned out that well for me. Here's a bit of extremely ugly code that I wrote to find and load the jar file out of the class path. I don't know if this code can be improved using the existing API (in which case, this is my bad, not an enhancement request). Alternatively, perhaps it would be good to find a way to add jars from the classpath to the ASDF registry. Or even preload the systems in the jar files. {{{ interpreter = Interpreter.createInstance(); interpreter.eval("(require :abcl-contrib)"); interpreter.eval("(require :asdf)"); interpreter.eval("(require :asdf-jar)"); interpreter.eval("(defparameter *my-jar-name* \"abcl-prism-all\")"); interpreter.eval("(defparameter *jar* (find *my-jar-name* (loop for x in (dump-classpath) appending (remove-if-not \'pathnamep (rest x))) :test \'equalp :key \'pathname-name))"); interpreter.eval("(if *jar* (if (probe-file *jar*) (format t \"Adding ~a to ASDF searchpath.\" *jar*) (error \"Found ~A in classpath, but jar file doesn't exist.\" *my-jar-name*)) (error \"Can\'t find ~a in ~s\" *my-jar- name* (dump-classpath)))"); interpreter.eval("(asdf-jar:add-to-asdf *jar*)"); interpreter.eval("(asdf:load-system :abcl-prism)"); }}} Mark has also expressed a desire to better support adding jars to the ASDF configuration. -- Ticket URL: <http://abcl.org/trac/ticket/367> armedbear <http://abcl.org> armedbear

1 0

[Armedbear-ticket] [armedbear] #366: ABCL-JAR tmp directory usage seems conflicting
by armedbear 17 Aug '14

17 Aug '14

#366: ABCL-JAR tmp directory usage seems conflicting ----------------------------+----------------- Reporter: robert goldman | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: abcl-contrib | Version: Keywords: | ----------------------------+----------------- There's a function `TMPDIR` in asdf-jar.lisp that AFAICT is never called. But there are also a couple of instances of `/var/tmp` hard-coded as defaults. I'm not sure this is a problem, per se, but it seems like an oddity. Stumbled on it while trying to make ASDF-jar work for me. -- Ticket URL: <http://abcl.org/trac/ticket/366> armedbear <http://abcl.org> armedbear

1 1

Re: [Armedbear-ticket] [armedbear] #346: runtime-class constructors not supported
by armedbear 17 Aug '14

17 Aug '14

#346: runtime-class constructors not supported ----------------------+----------------------- Reporter: charmon | Owner: mevenson Type: defect | Status: accepted Priority: major | Milestone: 1.4.0 Component: java | Version: 1.3.0-dev Resolution: | Keywords: ----------------------+----------------------- Changes (by mevenson): * owner: => mevenson * status: new => accepted Comment: I've get a [set of patches][1] that at least contains failing tests. Actually a lot of basic tests with JAVA:JNEW-RUNTIME-CLASS fail, so this will take a bit of work. [1]: ssh://lisp.not.org/home/evenson/work/abcl/.hg/patches/ -- Ticket URL: <http://abcl.org/trac/ticket/346#comment:5> armedbear <http://abcl.org> armedbear

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-ticket August 2014