#182: ADJUST-ARRAY failure
--------------------------------------------+-------------------------------
Reporter: mevenson | Owner: somebody
Type: defect | Status: new
Priority: major | Milestone: unscheduled
Component: other | Version: 1.0
Keywords: adjust-array, ansi conformance |
--------------------------------------------+-------------------------------
[http://article.gmane.org/gmane.lisp.armedbear.devel/2114 Helmut Eller
reported on armedbear-devel]:
Evaluating this form
{{{
(adjust-array (make-array 2 :element-type '(unsigned-byte 8)) 4)
}}}
prints a longish stacktrace that doesn't seem right:
{{{
Armed Bear Common Lisp 1.1.0-dev-svn-13692M
Java 1.6.0_18 Sun Microsystems Inc.
OpenJDK Client VM
Low-level initialization completed in 0.771 seconds.
Startup completed in 2.209 seconds.
Type ":help" for a list of available commands.
CL-USER(1): (adjust-array (make-array 2 :element-type '(unsigned-byte 8))
4)
java.lang.ArrayStoreException
at java.lang.System.arraycopy(Native Method)
at
org.armedbear.lisp.BasicVector_UnsignedByte8.adjustArray(BasicVector_UnsignedByte8.java:291)
at
org.armedbear.lisp.BasicVector_UnsignedByte8.adjustArray(BasicVector_UnsignedByte8.java:40)
at org.armedbear.lisp.adjust_array.execute(adjust_array.java:95)
at org.armedbear.lisp.Symbol.execute(Symbol.java:896)
at org.armedbear.lisp.Autoload.execute(Autoload.java:258)
at org.armedbear.lisp.Symbol.execute(Symbol.java:896)
at org.armedbear.lisp.LispThread.execute(LispThread.java:798)
at org.armedbear.lisp.arrays_2.execute(arrays.lisp:46)
at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:112)
at org.armedbear.lisp.LispThread.execute(LispThread.java:666)
at org.armedbear.lisp.Lisp.evalCall(Lisp.java:548)
at org.armedbear.lisp.Lisp.eval(Lisp.java:506)
at org.armedbear.lisp.Primitives$pf__eval.execute(Primitives.java:345)
at org.armedbear.lisp.LispThread.execute(LispThread.java:649)
at org.armedbear.lisp.Lisp.evalCall(Lisp.java:541)
at org.armedbear.lisp.Lisp.eval(Lisp.java:506)
at org.armedbear.lisp.Lisp.progn(Lisp.java:675)
at org.armedbear.lisp.Primitives$sf_block.execute(Primitives.java:3733)
at org.armedbear.lisp.Lisp.eval(Lisp.java:496)
at org.armedbear.lisp.Lisp.progn(Lisp.java:675)
at org.armedbear.lisp.Closure.bindParametersAndExecute(Closure.java:451)
at org.armedbear.lisp.Closure.execute(Closure.java:484)
at org.armedbear.lisp.LispThread.execute(LispThread.java:649)
at org.armedbear.lisp.Lisp$1.execute(Lisp.java:277)
at org.armedbear.lisp.Symbol.execute(Symbol.java:785)
at org.armedbear.lisp.LispThread.execute(LispThread.java:649)
at org.armedbear.lisp.top_level_50.execute(top-level.lisp:415)
at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:92)
at org.armedbear.lisp.Symbol.execute(Symbol.java:775)
at org.armedbear.lisp.LispThread.execute(LispThread.java:633)
at org.armedbear.lisp.top_level_51.execute(top-level.lisp:423)
at org.armedbear.lisp.LispThread.execute(LispThread.java:633)
at org.armedbear.lisp.Interpreter.run(Interpreter.java:360)
at org.armedbear.lisp.Main$1.run(Main.java:48)
at java.lang.Thread.run(Thread.java:636)
#<THREAD "interpreter" {3DC13D}>: Debugger invoked on condition of type
ERROR
Caught java.lang.ArrayStoreException.
Restarts:
0: TOP-LEVEL Return to top level.
[1] CL-USER(2):
}}}
Reproduced.
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/182>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#183: build.xml needlessly compiling Lisp sources
-------------------------------------------+--------------------------------
Reporter: mevenson | Owner: mevenson
Type: defect | Status: new
Priority: minor | Milestone: unscheduled
Component: build | Version: 1.0
Keywords: build.xml, system compilation |
-------------------------------------------+--------------------------------
The correspondence between the source and the targets of the Lisp
compilation is out of sync again so that the (timewise) expensive loading
of the interpreted version of ABCL to compile its system source is always
done (this is good for testing perhaps, but the average developer should
have the fastest possible compile).
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/183>
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