#412: Using FASLs from a Jar
----------------------+----------------------
Reporter: mevenson | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: (A)MOP | Version:
Keywords: | Parent Tickets:
----------------------+----------------------
Vibhu notes in <http://article.gmane.org/gmane.lisp.armedbear.devel/3600>
that he is unable to use FASLs from a Jar
{{{
I've got #'asdf-jar:package to create a jar file containing lisp sources
and fasls. With abcl-1.0.1,
(asdf:operate 'asdf:load-op ...)
uses the fasls from the jar, whereas with abcl-1.1.0 onwards those fasls
are ignored and the jarred sources are compiled into ~/.cache/... again.
Is this a bug, or is it a feature (as easyE seems to think it is, in the
last two sentences at:
http://stackoverflow.com/questions/4763910/abcl-compilation-and-primitives
)?
If it's a bug, here is how far I've got in my diagnosis.
(asdf-jar:add-to-asdf "wispym.jar")
shows this in abcl-1.0.1
((#P"jar:file:/Users/vibhu/t3/wispym-all.jar!/**/*.*" T)
(#P"jar:file:/Users/vibhu/t3/wispym-all.jar!/**/*.*"
#P"jar:file:/Users/vibhu/t3/wispym-all.jar!/**/*.*")
(#P"/Users/vibhu/.cache/common-
lisp/abcl-1.0.1-svn-13750-13751-fasl38-solaris-x86/**/*.*"
T) (#P"/___jar___file___root___/**/*.*"
#P"/Users/vibhu/.cache/common-
lisp/abcl-1.0.1-svn-13750-13751-fasl38-solaris-x86/**/*.*")
(#P"jar:file:/**/*.jar!/**/*.*" #<TRANSLATE-JAR-PATHNAME {2B63F8AD}>) (T
#P"/Users/vibhu/.cache/common-
lisp/abcl-1.0.1-svn-13750-13751-fasl38-solaris-x86/**/*.*"))
but this in abcl-1.3.2,
((#P"/**/*.*" T) (#P"/**/*.*" #P"/**/*.*")
(#P"/Users/vibhu/.cache/common-lisp/abcl-1.3.2-fasl42-macosx-x64/**/*.*"
T) (#P"/___jar___file___root___/**/*.*"
#P"/Users/vibhu/.cache/common-lisp/abcl-1.3.2-fasl42-macosx-x64/**/*.*")
(#P"jar:file:/**/*.jar!/**/*.*" #<TRANSLATE-JAR-PATHNAME {4F340027}>) (T
#P"/Users/vibhu/.cache/common-lisp/abcl-1.3.2-fasl42-macosx-x64/**/*.*"))
I think these are asdf output-translations, each specifying a source
directory and a corresponding destination directory.
The first two entries are significantly different between abcl-1.0.1 and
abcl-1.3.2.
----
The reason I'd like to use the jarred fasls is that I'm distributing my
program to customers. I don't want to spew fasls around their hard
disks. I also don't want to get into having to explain to them to clear
caches. (I do have to do this locally on occasion, e.g. when timestamps
on files confuse the cache). But most importantly, I've got a large
cl-yacc grammar that takes ages to macroexpand and compile. I don't want
them to wait so long even though it's just on the first load.
}}}
--
Ticket URL: <http://abcl.org/trac/ticket/412>
armedbear <http://abcl.org>
armedbear
#409: CL:FORMAT ~$ buglet
-------------------------------+----------------------------
Reporter: mevenson | Owner:
Type: defect | Status: new
Priority: minor | Milestone: 1.3.4
Component: (A)MOP | Version: 1.4.0-dev
Keywords: low-hanging-fruit | Parent Tickets:
-------------------------------+----------------------------
Scott notes in the mailing list
{{{
In 1.3.2,
> (format nil "~$" -32.17)
--32.17
Negative values are getting a double minus sign.
The right fix seems to be, in 'format-dollars', to pass '(abs number)'
rather than 'number' to 'sys::flonum-to-string'.
}}}
--
Ticket URL: <http://abcl.org/trac/ticket/409>
armedbear <http://abcl.org>
armedbear
#407: build-from-lisp.sh script doesn't work
-------------------------+----------------------
Reporter: dkochmanski | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: build | Version:
Keywords: | Parent Tickets:
-------------------------+----------------------
I've checked out the repository head of ABCL and tried building it with
with the build-from-lisp.sh script with the result below (same applies to
sbcl implementation used). ANT build works fine.
{{{
[lisps-user@pandora abcl]$ ./build-from-lisp.sh ccl
> Error: File #P"/home/lisps-user/sources/abcl/customizations.lisp" does
not exist.
> While executing: CCL::%LOAD, in process listener(1).
> Type :GO to continue, :POP to abort, :R for a list of available
restarts.
> If continued: Skip evaluation of (progn (build-abcl:build-abcl :clean t
:full t :batch t) (ccl:quit))
> Type :? for other options.
1 >
}}}
--
Ticket URL: <http://abcl.org/trac/ticket/407>
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
#404: Problems with binding to local addresses
------------------------------------------+----------------------------
Reporter: mevenson | Owner:
Type: defect | Status: new
Priority: major | Milestone: 1.3.4
Component: libraries | Version: 1.4.0-dev
Keywords: quicklisp-2015-10-31 usocket | Parent Tickets:
------------------------------------------+----------------------------
Something in the usocket code seems to have problems interpreting ip6
addresses, so people have been running into the following error message in
attempting to run hunchentoot, clack, et. al. on localhost:
{{{
<madnificent> synchromesh: I get #(0 0 0 0 0 0 0) where usocket expects
something of length 4 ... interesting
[20:06]
}}}
I suspect that ABCL is binding to *all* local addresses, and has an active
ip6 stack. I think that the dotted quad routines within USOCKET are
getting fed ip6 addresses in some form.
WORKAROUND: use {{{http://127.0.0.1:5000}}} instead of {{{localhost}}} in
HTTP User Agent.
--
Ticket URL: <http://abcl.org/trac/ticket/404>
armedbear <http://abcl.org>
armedbear