#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
#391: "bad place for a wild pathname" on EXT:PROBE-DIRECTORY for NAME containing
#\*
-----------------------------------------------+------------------------
Reporter: mevenson | Owner:
Type: defect | Status: new
Priority: major | Milestone: 1.3.3
Component: interpreter | Version:
Keywords: cl:probe-file ext:probe-directory | Parent Tickets:
-----------------------------------------------+------------------------
John Pallister on #abcl reported problems with configuring ASDF via {{{
(asdf:initialize-source-registry '(:source-registry (:tree (:home
"src/synchromesh")) :inherit-configuration))}}} for which he later traced
down to problems with a pathname NAME containing a #\* character:
{{{
<synchromesh> Ooh, that's interesting - EXTENSIONS:PROBE-DIRECTORY has
found a filename in the specified directory tree that contains a "*".
<synchromesh> Then (much deeper)
org.armedbear.lisp.probe_file$pf_probe_directory.execute(probe_file.java:88)
throws the error.
}}}
The exact error cases here still needs to be determined.
TBD: What does it mean to PROBE-{DIRECTORY,FILE} on a PATHNAME containing
#\*?
--
Ticket URL: <http://abcl.org/trac/ticket/391>
armedbear <http://abcl.org>
armedbear
#402: Start publishing abcl binary maven artifacts
----------------------+----------------------------
Reporter: mevenson | Owner:
Type: defect | Status: new
Priority: major | Milestone: 1.3.4
Component: other | Version: 1.4.0-dev
Keywords: | Parent Tickets:
----------------------+----------------------------
We should figure out how to get the abcl binary artifacts back into the
public Maven repository system
--
Ticket URL: <http://abcl.org/trac/ticket/402>
armedbear <http://abcl.org>
armedbear
#390: ABCL-ASDF:RESOLVE not working
--------------------------+----------------------------
Reporter: mevenson | Owner:
Type: defect | Status: new
Priority: critical | Milestone: 1.4.0
Component: abcl-contrib | Version: 1.4.0-dev
Keywords: abcl-asdf | Parent Tickets:
--------------------------+----------------------------
Without the presence of a <file:~/.m2/> directory, populated by command
line mvn usage, the ABCL-ASDF mechanism is not working:
{{{
CL-USER> (ABCL-ASDF:RESOLVE-DEPENDENCIES "net.java.dev.jna" "jna" :VERSION
"4.1.0")
}}}
{{{
Java exception
'org.eclipse.aether.collection.DependencyCollectionException: Failed to
read artifact descriptor for net.java.dev.jna:jna:jar:4.1.0'.
[Condition of type JAVA-EXCEPTION]
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: [RETRY] Retry ASDF operation.
3: [CLEAR-CONFIGURATION-AND-RETRY] Retry ASDF operation after resetting
the configuration.
4: [RETRY] Retry SLIME REPL evaluation request.
5: [*ABORT] Return to SLIME's top level.
}}}
Switching between Maven versions 3.2.5 and 3.3.3 seems to give the same
problems.
--
Ticket URL: <http://abcl.org/trac/ticket/390>
armedbear <http://abcl.org>
armedbear
#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