#96: Lambda list &rest compilation error
-----------------------------+----------------------------------------------
Reporter: mevenson | Owner: ehuelsmann
Type: defect | Status: new
Priority: minor | Milestone: unscheduled
Component: compiler | Version:
Keywords: compiler lambda |
-----------------------------+----------------------------------------------
The following lambda list
{{{
(defun hashmap-to-hashtable (&key (k #'identity) &rest rest)
(let ((foo)))
}}}
fails to compile with the error
{{{
&REST/&BODY must be followed by a variable.
}}}
Reported by Alan Ruttenberg
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/96>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#122: writeToString infrastructure doesn't support *PRINT-CIRCLE*
------------------------+---------------------------------------------------
Reporter: ehuelsmann | Owner: nobody
Type: defect | Status: new
Priority: major | Milestone:
Component: java | Version:
Keywords: |
------------------------+---------------------------------------------------
From a reaction of mine to a mail by Kevin Reid:
> I don't think it's a good idea to explicitly bind *print-circle* to
> nil in anything debugging-related, including error printing, because
> then it's a source of nontermination (silent until out of memory, if
> the output is going to a string) if user code is working with circular
> structure.
That's a good point. Rather, it may even be better to explicitly bind it
to T.
This remark made me realize that our Java side writeToString actually
doesn't support *PRINT-CIRCLE* which can be an issue when trying to debug
ABCL before it has loaded the ERROR and PRINT-OBJECT infrastructures.
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/122>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#145: Support running ABCL on JamVM
-----------------------------+----------------------------------------------
Reporter: mevenson | Owner: nobody
Type: defect | Status: new
Priority: major | Milestone: 0.26
Component: java | Version: 0.24
Keywords: jamvm classpath |
-----------------------------+----------------------------------------------
A request to support ABCL running on the [http://jamvm.sourceforge.net/
JamVM].
This may be roughly equivalent to working through the idiosyncrasies of
running with [http://www.gnu.org/software/classpath GNU classpath], as GCJ
seems to give similar errors.
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/145>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#149: Cannot load ASDF systems from *.asd definition in base of JAR hierarchy
-------------------------------+--------------------------------------------
Reporter: mevenson | Owner: mevenson
Type: defect | Status: new
Priority: minor | Milestone: 0.26
Component: other | Version: 1.0
Keywords: asdf url-pathname |
-------------------------------+--------------------------------------------
For an ASDF definition packaged in a JAR file in the topmost directory,
viz
{{{
mama:~/work/abcl/bugs$ jar tfv trivial.jar
76 Thu May 12 13:58:30 CEST 2011 trivial.asd
52 Thu May 12 13:58:52 CEST 2011 trivial.lisp
}}}
The ASDF definition cannot be properly loaded after placing
"jar:file:~/work/abcl/bugs/trivial.jar!/" in the ASDF:*CENTRAL-REGISTRY*.
One can see that something has gone wrong in the ASDF/MERGE-PATHNAMES with
URL-PATHNAMES as after the unsucessful load the following shows that ASDF
has thrown away the JAR-PATHNAME reference
{{{
CL-USER> (asdf:component-pathname (asdf:find-system :trivial))
#P"/Users/evenson/work/abcl/"
}}}
The workaround is simple: always package ASDF definition in at least one
top-level directory, viz:
{{{
mama:~/work/abcl/bugs$ jar tfv trivial.jar
0 Thu May 12 14:18:18 CEST 2011 META-INF/
60 Thu May 12 14:18:18 CEST 2011 META-INF/MANIFEST.MF
0 Thu May 12 13:58:52 CEST 2011 trivial/
76 Thu May 12 13:58:30 CEST 2011 trivial/trivial.asd
52 Thu May 12 13:58:52 CEST 2011 trivial/trivial.lisp
}}}
When I get a change, I'll go through the URL-PATHNAME code with ASDF to
understand where this is breaking.
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/149>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#56: Eliminate use of temporary files in COMPILE and COMPILE-FILE
-------------------------+--------------------------------------------------
Reporter: ehuelsmann | Owner: ehuelsmann
Type: enhancement | Status: new
Priority: major | Milestone:
Component: compiler | Version:
Keywords: |
-------------------------+--------------------------------------------------
The functions COMPILE and COMPILE-FILE use temporary files for the class
files generated by the compiler.
However, COMPILE directly loads them back into memory and deletes the temp
file, while COMPILE-FILE deletes the temp file after adding it to a ZIP
archive.
This ticket exists to indicate that infrastructure is required to better
manage where output goes to, abstracting from the temp files.
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/56>
armedbear <http://common-lisp.net/project/armedbear>
armedbear