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

[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] #370: Failure to use ABCL as SBCL compilation host
by armedbear 04 Feb '16

04 Feb '16

#370: Failure to use ABCL as SBCL compilation host -------------------------+----------------------- Reporter: mevenson | Owner: Type: defect | Status: new Priority: major | Milestone: 1.4.0 Component: interpreter | Version: 1.4.0-dev Keywords: sbcl | -------------------------+----------------------- loke noticed that ABCL is no longer able to host a compilation of SBCL. This failure occurs on both 1.4.0-dev and 1.3.1, so the problem has been present for a while. From <http://pastebin.com/KUCzCNd5>: {{{ ; Wrote /root/sbcl-1.2.3/obj/from-host/src/compiler/policies.abcl-tmp (0.307 seconds) ; Compiling /root/sbcl-1.2.3/src/compiler/macros.lisp ... ; (IN-PACKAGE "SB!C") ; (DECLAIM (SPECIAL *COMPILER-ERROR-CONTEXT*)) ; (DEFMACRO DEF-IR1-TRANSLATOR ...) ; (DEFMACRO SOURCE-TRANSFORM-LAMBDA ...) ; (DEFMACRO DEFINE-SOURCE-TRANSFORM ...) ; (DEFTYPE ATTRIBUTES ...) ; (DEFUN COMPUTE-ATTRIBUTE-MASK ...) ; (DEF!MACRO !DEF-BOOLEAN-ATTRIBUTE ...) ; (DEFUN GUTS-OF-!DEF-BOOLEAN-ATTRIBUTE-SETTER ...) ; (DEFMACRO !DEF-BOOLEAN-ATTRIBUTE-SETTER ...) ; (DEFMACRO ATTRIBUTES-UNION ...) ; (DEFMACRO ATTRIBUTES-INTERSECTION ...) ; (DECLAIM (FTYPE # ...)) ; (DECLAIM (INLINE ATTRIBUTES=)) ; (DEFUN ATTRIBUTES= ...) ; (DEFUN PARSE-DEFTRANSFORM ...) ; (DEFMACRO DEFTRANSFORM ...) ; (DEFMACRO DEFKNOWN ...) ; (DEFMACRO DEFOPTIMIZER ...) #<THREAD "interpreter" {5B9A5111}>: Debugger invoked on condition of type UNDEFINED-FUNCTION The function SB!IMPL::DECL-EXPR is undefined. Restarts: 0: CONTINUE Try again. 1: USE-VALUE Specify a function to call instead. 2: RETURN-VALUE Return one or more values from the call to SB!IMPL ::DECL-EXPR. 3: TOP-LEVEL Return to top level. [1] SB!C(11): ; Compilation unit finished ; The following functions were used but not defined: ; SB!INT:PARSE-LAMBDA-LIST }}} -- Ticket URL: <http://abcl.org/trac/ticket/370> armedbear <http://abcl.org> armedbear

1 4

[Armedbear-ticket] [armedbear] #372: ABCL-ASDF:RESOLVE not working correcting
by armedbear 28 Apr '15

28 Apr '15

#372: ABCL-ASDF:RESOLVE not working correcting --------------------------+----------------------- Reporter: mevenson | Owner: Type: defect | Status: new Priority: major | Milestone: 1.4.0 Component: abcl-contrib | Version: 1.4.0-dev Keywords: | --------------------------+----------------------- The documented use of ABCL-ASDF:RESOLVE in {{{contrib/abcl- asdf/README.markdown}}} no longer works. {{{ (abcl-asdf:resolve "com.google.gwt:gwt-user") }}} produces {{{ Wrong number of arguments for #<RESOLVE-DEPENDENCIES {1FF23F1D}>; at least 2 expected. [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 {79DA9F8F}> #<PROGRAM-ERROR {232C571D}> #<FUNCTION {79DA9F8F}>) 1: (APPLY #<FUNCTION {79DA9F8F}> (#<PROGRAM-ERROR {232C571D}> #<FUNCTION {79DA9F8F}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<PROGRAM-ERROR {232C571D}> #<FUNCTION {79DA9F8F}>) 3: (INVOKE-DEBUGGER #<PROGRAM-ERROR {232C571D}>) 4: org.armedbear.lisp.Lisp.error(Lisp.java:382) 5: org.armedbear.lisp.ArgumentListProcessor$FastMatcher.match(ArgumentListProcessor.java:671) 6: org.armedbear.lisp.ArgumentListProcessor.match(ArgumentListProcessor.java:483) 7: org.armedbear.lisp.Closure.processArgs(Closure.java:230) 8: org.armedbear.lisp.maven_embedder_TMP_58.execute(maven- embedder.lisp:406) 9: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) 10: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 11: org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2794) 12: (ABCL-ASDF:RESOLVE-DEPENDENCIES "com.google.gwt:gwt-user") }}} -- Ticket URL: <http://abcl.org/trac/ticket/372> armedbear <http://abcl.org> armedbear

1 2

[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] #373: Two-way-streams and gray streams
by armedbear 01 Oct '14

01 Oct '14

#373: Two-way-streams and gray streams --------------------------+----------------- Reporter: helmut eller | Owner: Type: defect | Status: new Priority: major | Milestone: Component: streams | Version: Keywords: | --------------------------+----------------- ABCL runs into troubles with the following example: {{{ shell> cat test.lisp (in-package cl-user) (require 'gray-streams) (defclass out (gray-streams:fundamental-character-output-stream) ((buffer :initform (make-array 200 :element-type 'character :adjustable t :fill-pointer 0) :reader out-buffer))) (defmethod gray-streams:stream-write-char ((s out) (c character)) (vector-push-extend c (out-buffer s))) (let ((out (make-instance 'out))) (write-string "foo" (make-two-way-stream *standard-input* out)) (assert (equal "foo" (out-buffer out)))) shell> abcl Armed Bear Common Lisp 1.4.0-dev-svn-14730 Java 1.7.0_03 Oracle Corporation OpenJDK Client VM Low-level initialization completed in 0.841 seconds. Startup completed in 4.419 seconds. Loading /home/helmut/.abclrc completed in 0.108 seconds. Type ":help" for a list of available commands. CL-USER(1): (load "test.lisp") Error loading /raid/home/helmut/lisp/test.lisp at line 16 (offset 488) #<THREAD "interpreter" {8A408D}>: Debugger invoked on condition of type TYPE-ERROR The value #<OUT {940A15}> is not of type STREAM. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(2): }}} The expected outcome is that assertion the succeeds. -- Ticket URL: <http://abcl.org/trac/ticket/373> armedbear <http://abcl.org> armedbear

1 1

[Armedbear-ticket] [armedbear] #371: Problems with CL:WILD-PATHNAME-P
by armedbear 24 Sep '14

24 Sep '14

#371: Problems with CL:WILD-PATHNAME-P -----------------------------+----------------------- Reporter: mevenson | Owner: Type: defect | Status: new Priority: major | Milestone: 1.4.0 Component: interpreter | Version: 1.4.0-dev Keywords: ansi-compliance | -----------------------------+----------------------- Pascal notes on armedbear-devel@ : {{{ Why do we have? (wild-pathname-p #P"*-blah") -> T (wild-pathname-p #P"*-blah" :name) -> NIL This is inconsistent (and non-conforming). Actually wild-pathname-p returns NIL for all fields: (mapcar (lambda (field) (wild-pathname-p #P"*-blah" field)) (list :host :device :directory :name :type :version))' --> (NIL NIL NIL NIL NIL NIL) If that was true, then (wild-pathname-p #P"*-blah" nil) should return NIL, not true. If field-key is not supplied or nil, wild-pathname-p returns true if pathname has any wildcard components, nil if pathname has none. If field-key is non-nil, wild-pathname-p returns true if the indicated component of pathname is a wildcard, nil if the component is not a wildcard. So we should have: (defun wild-pathname-p (path &optional field-key) (if (null field-key) (some (lambda (field-key) (wild-pathname-p path field-key)) '(:host :device :directory :name :type :version)) …)) }}} -- Ticket URL: <http://abcl.org/trac/ticket/371> armedbear <http://abcl.org> armedbear

1 1