#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
#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
#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
#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
#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
#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