#456: SYSTEM:AVAILABLE-ENCODINGS symbols strangeness
----------------------+---------------------------
Reporter: mevenson | Owner: mevenson
Type: defect | Status: new
Priority: minor | Milestone: 1.6.0
Component: other | Version:
Keywords: | Parent Tickets:
----------------------+---------------------------
In https://github.com/armedbear/abcl/issues/82 Robert Dodier reports
I see that SYSTEM:AVAILABLE-ENCODINGS returns a list of symbols which
represent the various encodings that are discovered via
Charset.availableCharsets. That's great, but the symbols are
apparently not interned in the keyword package, so it makes it
somewhat confusing to determine whether a given encoding is on the
list.
e.g. {{{(member :utf-16 (system:available-encodings))}}} returns NIL,
although looking at the list, you can see that {{{:UTF-16}}} is there.
Confusingly, {{{{(mapcar #'symbol-package (system:available-
encodings))}}}} shows that all symbols are in the keyword package, but
{{{(find-symbol "UTF-16" :keyword)}}} returns NIL.
I believe the problem is that {{{availableEncodings}}} in
src/org/armedbear/lisp/Stream.java says, in part, (at line 399 in the
current version)
{{{
new Symbol(charset, PACKAGE_KEYWORD)
}}}
but I think more appropriate would be
{{{
PACKAGE_KEYWORD.intern(charset)
}}}
Here is a patch which implements that change, and fixes the bug, from what
I can tell.
{{{
Index: src/org/armedbear/lisp/Stream.java
===================================================================
--- src/org/armedbear/lisp/Stream.java (revision 15113)
+++ src/org/armedbear/lisp/Stream.java (working copy)
@@ -396,7 +396,7 @@
SortedMap<String, Charset> available = Charset.availableCharsets();
Set<String> encodings = available.keySet();
for (String charset : encodings) {
- result.add(new Symbol(charset, PACKAGE_KEYWORD));
+ result.add (PACKAGE_KEYWORD.intern (charset));
}
return result;
}
}}}
--
Ticket URL: <http://abcl.org/trac/ticket/456>
armedbear <http://abcl.org>
armedbear
#452: Pathname functions do the wrong thing when faced with actual filename with
embedded asterisk
----------------------+----------------------
Reporter: mevenson | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: (A)MOP | Version:
Keywords: | Parent Tickets:
----------------------+----------------------
From <https://github.com/armedbear/abcl/issues/63>
In a shell:
{{{
touch /tmp/*
(probe-file "/tmp/")
; Evaluation aborted on #<FILE-ERROR {7DF4B809}>.
CL-USER> (probe-file "/tmp/\")
; Evaluation aborted on #<FILE-ERROR {4D5E9779}>.
CL-USER> (probe-file "/tmp/%2A")
nil
CL-USER> (probe-file "file:///tmp/%2A")
; Evaluation aborted on #<FILE-ERROR {7DF4B809}>.
}}}
The error is: Bad place for a wild pathname.
I had a quick look to see how this could be repaired, but wasn't sure what
the right approach is. This stackoverflow answer suggests using "\" as a
quote, which is probably the best solution, and would be compatible with
what Clozure CL, SBCL and LispWorks do. I also think the percent escaped
character should be made to work.
The specific screw case I had was that there was an accidentally created
file with a "*" in a directory that was being scanned for ASDF's system
registry, which crapped out because the directory function returned the
"*" pathname, and subsequently did a probe on the file.
--
Ticket URL: <http://abcl.org/trac/ticket/452>
armedbear <http://abcl.org>
armedbear
#450: Structure redefinition warning for closure-common
----------------------+------------------------
Reporter: mevenson | Owner:
Type: defect | Status: new
Priority: major | Milestone: 1.6.0
Component: java | Version:
Keywords: | Parent Tickets:
----------------------+------------------------
From <https://github.com/armedbear/abcl/issues/59>:
<https://github.com/mcna/closure-common> fails to load properly because
the xstream structure causes a redefinition failure, the reason being that
the slot buffer of type {{{(simple-array buffer-byte (*))}}} (which is
also what's in the FASL, {{{(#5=SYSTEM::DEFSTRUCT-SLOT-DESCRIPTION BUFFER
#6=0 XSTREAM-BUFFER +NULL-BUFFER+ (#7=SIMPLE-ARRAY BUFFER-BYTE (#8=*)) #2#
))}}} has the expanded type {{{(SIMPLE-ARRAY (INTEGER 0 65535) (*))}}}
loaded in the runtime (c.f. {{{(nth 0 (system::dd-slots (get
'runes::xstream 'system::structure-definition))))}}}.
{{{
Structure redefinition not supported in DEFSTRUCT for XSTREAM
[Condition of type PROGRAM-ERROR]
Restarts:
0: [TRY-RECOMPILING] Recompile xstream and try loading it again
...
Backtrace:
...
4: (ERROR PROGRAM-ERROR :FORMAT-CONTROL "Structure redefinition not
supported ~
in DEFSTRUCT for ~A" :FORMAT-ARGUMENTS
(RUNES:XSTREAM))
5: (SYSTEM:COMPILER-DEFSTRUCT RUNES:XSTREAM :CONC-NAME #:XSTREAM-
:DEFAULT-CONSTRUCTOR RUNES::MAKE-XSTREAM/LOW ...)
}}}
--
Ticket URL: <http://abcl.org/trac/ticket/450>
armedbear <http://abcl.org>
armedbear
#422: SYSTEM:RUN-PROGRAM does not work on Java 5/6
------------------------------------------------+------------------------
Reporter: mevenson | Owner:
Type: defect | Status: new
Priority: major | Milestone: 1.5.0
Component: interpreter | Version: 1.4.0
Keywords: cffi sys:run-progrom java-5 java-6 | Parent Tickets:
------------------------------------------------+------------------------
In chasing down the errors with CFFI on CL-TEST-GRID <https://mailman
.common-lisp.net/pipermail/armedbear-devel/2016-October/003719.html>, I
have found that the [java.lang.ProcessBuilder$Redirect][] interface used
by Elias and Olof to extend SYS:RUN-PROGRAM for different types of I/O
abstractions was introduced with Java 7, and will hence not work on
earlier Java implementations.
[java.lang.ProcessBuilder$Redirect]:
https://docs.oracle.com/javase/8/docs/api/java/lang/ProcessBuilder.Redirect…
Invoking ABCL-ASDF:ENSURE-MVN-VERSION, the following form causes the error
{{{
(JFIELD "java.lang.ProcessBuilder$Redirect" "INHERIT")
}}}
TODO: investigate the Java 6 APIs to see if there is a way to do I/O
redirection with backwards compatibility. I currently suspect that there
is no way to support Java 5/6 for this usage, which is why we never
implemented I/O redirection previously.
There is undoubtedly a way re-write the SYS:RUN-PROGRAM interface so that
we may invoke a process to read its output as a string in Java 5/Java 6,
as it worked before. But we will have to figure out a way to advertise
the different features of SYS:RUN-PROGRAM depending on the hosting VM.
Longer term, we may want to deprecate Java 5/6, but I would really have
the compiler emit Java 7-compatible bytecode (mainly by passing the Java 6
verification process) before we begin that.
--
Ticket URL: <http://abcl.org/trac/ticket/422>
armedbear <http://abcl.org>
armedbear