#55: Clearing LispThread.currentThread()._values more efficiently
-------------------------+--------------------------------------------------
Reporter: ehuelsmann | Owner: ehuelsmann
Type: enhancement | Status: new
Priority: major | Milestone:
Component: compiler | Version:
Keywords: |
-------------------------+--------------------------------------------------
We currently clear _values all over the place; we could be more efficient
some times.
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/55>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#34: adjust generated '*.cls' filenames
------------------------+---------------------------------------------------
Reporter: mevenson | Owner: somebody
Type: defect | Status: new
Priority: major | Milestone:
Component: component1 | Version:
Keywords: |
------------------------+---------------------------------------------------
dmiles:
it be nice to eventually name the coerce-666.cls coerce_666.cls as the
same name of the way classpaths think about them (they'd continue to
work).. one argument agaist is our autoloader at least gets a better whack
at finding them in the right context apart from classloader
--
Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/34>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#30: Lisp debugger, for both compiled and interpreted code
----------------------------+-----------------------------------------------
Reporter: vvoutilainen | Owner: somebody
Type: enhancement | Status: new
Priority: major | Milestone: unscheduled
Component: component1 | Version:
Keywords: debug debugger |
----------------------------+-----------------------------------------------
ABCL code can be debugged with normal java debuggers, but it
is somewhat painful for the portions implemented in lisp(1). So we need a
lisp debugger.
(1) It's possible, although a bit tedious, to step through
eval calls in a java debugger by examining the cars and
cdrs of eval parameters when stepping the code.
--
Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/30>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#127: SLIME fails to EXTENSION:QUIT
-------------------------+--------------------------------------------------
Reporter: mevenson | Owner: ehuelsmann
Type: defect | Status: new
Priority: major | Milestone: unscheduled
Component: interpreter | Version: 0.24
Keywords: slime |
-------------------------+--------------------------------------------------
Alan Ruttenberg reports that "(QUIT) in SLIME doesn't"
{{{
CL-USER> (quit)
; Evaluation aborted on NIL.
}}}
The REPL used by SLIME is failing to catch and properly interpret the new
ProcessingTerminated exception thrown by QUIT.
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/127>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#143: CLOSURE-HTML 20101006-git fails to compile
------------------------------------+---------------------------------------
Reporter: mevenson | Owner: mevenson
Type: defect | Status: new
Priority: major | Milestone: 0.26
Component: libraries | Version: 0.24
Keywords: quicklisp closure-html |
------------------------------------+---------------------------------------
Attempting to install closure-html from Quicklisp produces a stack
overflow when the compiler attempts to process the CLEX:DEFLEXER SGML:DTD
form on line 89 of "src/parse/sgml-dtd.lisp".
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/143>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#84: jcall and t/nil boolean arguments
------------------------+---------------------------------------------------
Reporter: ehuelsmann | Owner: nobody
Type: defect | Status: new
Priority: major | Milestone:
Component: java | Version:
Keywords: |
------------------------+---------------------------------------------------
Can it be made so that within jcall, t or nil is understood as a java
boolean argument?
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/84>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#115: Generate specific classes for compiled Go/Return
-------------------------+--------------------------------------------------
Reporter: ehuelsmann | Owner: ehuelsmann
Type: enhancement | Status: new
Priority: major | Milestone:
Component: compiler | Version:
Keywords: |
-------------------------+--------------------------------------------------
By using specific classes for Go/Return, we could make our exception
handling more targetted; there would be no sifting through all the
unwinding levels for the right level (unpacking the 'return-tag' or 'go-
tag').
Instead, the jump would hit all the finally clauses without further
checking; straight through to the right handler.
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/115>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#121: p2-test-* infrastructure should use COMPILE-TEST-FORM
------------------------+---------------------------------------------------
Reporter: ehuelsmann | Owner: ehuelsmann
Type: defect | Status: new
Priority: major | Milestone:
Component: compiler | Version:
Keywords: |
------------------------+---------------------------------------------------
Where it sometimes uses COMPILE-FORM and tests for NIL.
Another idea is to use FAIL/SUCCESS labels as argument to the compile-
test-function, which may result in more more efficient code. For example,
in that case, a NOT compilation only requires reversing the labels.
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/121>
armedbear <http://common-lisp.net/project/armedbear>
armedbear