#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
#369: Put a link to the manual in ABCL homepage
-----------------------------+-----------------
Reporter: mariano montone | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: other | Version:
Keywords: |
-----------------------------+-----------------
Can someone put a link to the ABCL PDF manual in the ABCL homepage
http://abcl.org ?
There not reference to it either there, or from http://abcl.org/doc/abcl-
user.html
I know it is a draft, but it contains information not available otherwise,
like a quick intro to jss, etc.
Or it is already easily available and I'm missing something?
--
Ticket URL: <http://abcl.org/trac/ticket/369>
armedbear <http://abcl.org>
armedbear
#367: Add easy way to load ASDF systems (and other software?) from classpath jars
----------------------------+-----------------
Reporter: robert goldman | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: other | Version:
Keywords: |
----------------------------+-----------------
I have been writing a Java program that uses some code implemented in
ABCL. I packaged everything up with `ASDF-JAR` and put the Jar file in the
command line.
The original idea was to provide an easy way for the program to find my
code. But it hasn't panned out that well for me.
Here's a bit of extremely ugly code that I wrote to find and load the jar
file out of the class path. I don't know if this code can be improved
using the existing API (in which case, this is my bad, not an enhancement
request). Alternatively, perhaps it would be good to find a way to add
jars from the classpath to the ASDF registry. Or even preload the systems
in the jar files.
{{{
interpreter = Interpreter.createInstance();
interpreter.eval("(require :abcl-contrib)");
interpreter.eval("(require :asdf)");
interpreter.eval("(require :asdf-jar)");
interpreter.eval("(defparameter *my-jar-name* \"abcl-prism-all\")");
interpreter.eval("(defparameter *jar* (find *my-jar-name* (loop for x in
(dump-classpath) appending (remove-if-not \'pathnamep (rest x))) :test
\'equalp :key \'pathname-name))");
interpreter.eval("(if *jar* (if (probe-file *jar*) (format t \"Adding ~a
to ASDF searchpath.\" *jar*) (error \"Found ~A in classpath, but jar file
doesn't exist.\" *my-jar-name*)) (error \"Can\'t find ~a in ~s\" *my-jar-
name* (dump-classpath)))");
interpreter.eval("(asdf-jar:add-to-asdf *jar*)");
interpreter.eval("(asdf:load-system :abcl-prism)");
}}}
Mark has also expressed a desire to better support adding jars to the ASDF
configuration.
--
Ticket URL: <http://abcl.org/trac/ticket/367>
armedbear <http://abcl.org>
armedbear
#366: ABCL-JAR tmp directory usage seems conflicting
----------------------------+-----------------
Reporter: robert goldman | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: abcl-contrib | Version:
Keywords: |
----------------------------+-----------------
There's a function `TMPDIR` in asdf-jar.lisp that AFAICT is never called.
But there are also a couple of instances of `/var/tmp` hard-coded as
defaults.
I'm not sure this is a problem, per se, but it seems like an oddity.
Stumbled on it while trying to make ASDF-jar work for me.
--
Ticket URL: <http://abcl.org/trac/ticket/366>
armedbear <http://abcl.org>
armedbear
#346: runtime-class constructors not supported
----------------------+-----------------------
Reporter: charmon | Owner: mevenson
Type: defect | Status: accepted
Priority: major | Milestone: 1.4.0
Component: java | Version: 1.3.0-dev
Resolution: | Keywords:
----------------------+-----------------------
Changes (by mevenson):
* owner: => mevenson
* status: new => accepted
Comment:
I've get a [set of patches][1] that at least contains failing tests.
Actually a lot of basic tests with JAVA:JNEW-RUNTIME-CLASS fail, so this
will take a bit of work.
[1]: ssh://lisp.not.org/home/evenson/work/abcl/.hg/patches/
--
Ticket URL: <http://abcl.org/trac/ticket/346#comment:5>
armedbear <http://abcl.org>
armedbear
#16: Re-evaluation of DEFPACKAGE form is ignored
--------------------------+-------------------------
Reporter: mevenson | Owner: somebody
Type: enhancement | Status: new
Priority: minor | Milestone: unscheduled
Component: other | Version: 1.0
Resolution: | Keywords:
--------------------------+-------------------------
Comment (by mariano montone):
There's no need to restart to export a symbol. It is enough to eval
(export <symbol>) from the package.
See: http://osdir.com/ml/armedbear-devel/2012-04/msg00032.html
But yes, this is annoying.
--
Ticket URL: <http://abcl.org/trac/ticket/16#comment:3>
armedbear <http://abcl.org>
armedbear
#359: Failure in TRANSLATE-PATHNAME on Windows
-------------------------------------------------+-------------------------
Reporter: robert goldman | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: other | Version:
Keywords: translate-pathname, translate- |
directory-components |
-------------------------------------------------+-------------------------
I received a bug report about ABCL failing ASDF tests on Windows. This is
ABCL version 1.2.1, which I understand not to be the newest version, but
seems to be what's commonly distributed to users.
Here are five key frames in backtrace:
{{{
17: (ERROR "Unsupported case in TRANSLATE-DIRECTORY-COMPONENTS.")
18: (SYSTEM::TRANSLATE-DIRECTORY-COMPONENTS (:ABSOLUTE "users" "dcooper8"
"genworks" "cl" "tests" "asdf" "asdf-windows" "test" "preflight-checks")
(:ABSOLUTE "Users" "dcooper8" "genworks" "cl" "tests" "asdf" "asdf-
windows" :WILD-INFERIORS) (:ABSOLUTE "Users" "dcooper8" "genworks" "cl"
"tests" "asdf" "asdf-windows" "build" "fasls" "abcl-1.2.1-fasl42-win-x64"
"asdf" :WILD-INFERIORS) NIL)
19: (SYSTEM::TRANSLATE-DIRECTORY (:ABSOLUTE "users" "dcooper8" "genworks"
"cl" "tests" "asdf" "asdf-windows" "test" "preflight-checks") (:ABSOLUTE
"Users" "dcooper8" "genworks" "cl" "tests" "asdf" "asdf-windows" :WILD-
INFERIORS) (:ABSOLUTE "Users" "dcooper8" "genworks" "cl" "tests" "asdf"
"asdf-windows" "build" "fasls" "abcl-1.2.1-fasl42-win-x64" "asdf" :WILD-
INFERIORS) NIL)
20: (TRANSLATE-PATHNAME #P"C:/users/dcooper8/genworks/cl/tests/asdf/asdf-
windows/test/preflight-checks/preflight.abcl"
#P"C:/Users/dcooper8/genworks/cl/tests/asdf/asdf-windows/**/*.*"
#P"C:/Users/dcooper8/genworks/cl/tests/asdf/asdf-
windows/build/fasls/abcl-1.2.1-fasl42-win-x64/asdf/**/*.*")
21: (UIOP/PATHNAME:TRANSLATE-PATHNAME*
#P"C:/users/dcooper8/genworks/cl/tests/asdf/asdf-windows/test/preflight-
checks/preflight.abcl" #P"C:/Users/dcooper8/genworks/cl/tests/asdf/asdf-
windows/**/*.*" #P"C:/Users/dcooper8/genworks/cl/tests/asdf/asdf-
windows/build/fasls/abcl-1.2.1-fasl42-win-x64/asdf/**/*.*" NIL
#P"C:/Users/dcooper8/genworks/cl/tests/asdf/asdf-windows/**/*.*")
22: (ASDF/OUTPUT-TRANSLATIONS:APPLY-OUTPUT-TRANSLATIONS
#P"C:/users/dcooper8/genworks/cl/tests/asdf/asdf-windows/test/preflight-
checks/preflight.abcl")
}}}
Reading from the bottom, frames 22 and 21 show ASDF trying to translate a
pathname for an abcl file to its fasl store. Then we move to the ANSI CL
function `translate-pathname` which I ''believe'' should handle this case
successfully.
--
Ticket URL: <http://abcl.org/trac/ticket/359>
armedbear <http://abcl.org>
armedbear