armedbear-ticket February 2015

armedbear-ticket@common-lisp.net

1 participants
14 discussions

[Armedbear-ticket] [armedbear] #383: Build standalone JARs which contain additional application code
by armedbear 13 Feb '19

13 Feb '19

#383: Build standalone JARs which contain additional application code -------------------------+----------------------- Reporter: mevenson | Owner: Type: enhancement | Status: new Priority: major | Milestone: 1.4.0 Component: other | Version: 1.4.0-dev Keywords: | -------------------------+----------------------- Clojure ("lein uberjar") as well as jruby ("warbler jar") have facilities for creating a standalone JAR which contains the runtime plus application. Other than creating the necessary assembly instructions, the only substantial problem would seem to be the need to further abstract the mechanism for finding ABCL-CONTRIB to something that could work on a pathname as well as an entire JAR. -- Ticket URL: <http://abcl.org/trac/ticket/383> armedbear <http://abcl.org> armedbear

1 1

[Armedbear-ticket] [armedbear] #384: Binary release has no invocation wrapper
by armedbear 15 Jun '17

15 Jun '17

#384: Binary release has no invocation wrapper ----------------------+----------------------- Reporter: mevenson | Owner: Type: defect | Status: new Priority: major | Milestone: 1.4.0 Component: other | Version: 1.4.0-dev Keywords: | ----------------------+----------------------- ABCL binary release should contain an invocation wrapper ('abcl{,.bat}'). -- Ticket URL: <http://abcl.org/trac/ticket/384> armedbear <http://abcl.org> armedbear

1 1

[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] #375: CL:OPEN failure
by armedbear 28 Apr '15

28 Apr '15

#375: CL:OPEN failure ----------------------+----------------------- Reporter: mevenson | Owner: Type: defect | Status: new Priority: major | Milestone: 1.4.0 Component: java | Version: 1.4.0-dev Keywords: | ----------------------+----------------------- The following form {{{ (open #p"~/xx" :direction :output :if-exists :append :external-format '(:latin-1 :eol-style :lf)) }}} fails with the following message {{{ ; Evaluation aborted on NIL. }}} -- Ticket URL: <http://abcl.org/trac/ticket/375> armedbear <http://abcl.org> armedbear

1 6

[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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-ticket February 2015