#172: DOCUMENTATION does not work for generic functions
-------------------------+--------------------------------------------------
Reporter: mevenson | Owner: ehuelsmann
Type: defect | Status: new
Priority: minor | Milestone: 0.28
Component: interpreter | Version: 0.27
Keywords: |
-------------------------+--------------------------------------------------
DOCUMENTATION does not seem to be able to retrieve the docstring for
generic functions:
{{{
(defgeneric foo nil (:documentation "Ipso facto"))
#<STANDARD-GENERIC-FUNCTION FOO {6901DFA5}>
CL-USER> (documentation 'foo 'function)
NIL
}}}
If one inspects the generic function in SLIME, one sees that the
documentation slot does have a value, so this is a problem in
DOCUMENTATION.
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/172>
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
#170: Make COMPILE-FILE a multi-pass operation
------------------------+---------------------------------------------------
Reporter: ehuelsmann | Owner: ehuelsmann
Type: defect | Status: new
Priority: major | Milestone:
Component: compiler | Version:
Keywords: |
------------------------+---------------------------------------------------
The single-pass implementation of COMPILE-FILE has several drawbacks:
1. Only backward referenced function calls can be inlined (since forward
referenced functions are unknown at the time of compilation)
1. It's much harder to build an fasl-literal-object table with objects
being referenced multiple times in the fasl; we need this item for
compliance with
[http://www.lispworks.com/documentation/HyperSpec/Body/03_bdd.htm section
3.2.4.4 of the CLHS]
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/170>
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