#195: prompt is displayed twice when evaluating NIL at the REPL
-------------------------+--------------------------------------------------
Reporter: rschlatte | Owner: ehuelsmann
Type: defect | Status: new
Priority: trivial | Milestone:
Component: interpreter | Version:
Keywords: |
-------------------------+--------------------------------------------------
{{{
$ abcl
Armed Bear Common Lisp 1.1.0-dev
Java 1.6.0_29 Apple Inc.
Java HotSpot(TM) 64-Bit Server VM
Low-level initialization completed in 0.724 seconds.
Startup completed in 2.336 seconds.
Loading /home/rudi/.abclrc completed in 11.57 seconds.
Type ":help" for a list of available commands.
CL-USER(1): NIL
NIL
CL-USER(2): CL-USER(2):
}}}
Reported by Blake McBride Jan 16, 2012
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/195>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#73: "normalize-type" buffering
-------------------------+--------------------------------------------------
Reporter: ehuelsmann | Owner: somebody
Type: task | Status: new
Priority: major | Milestone:
Component: CLOS | Version:
Keywords: performance |
-------------------------+--------------------------------------------------
Peter Graves points out that with his "canonicalize-type" buffering, he
achieved measurable performance gain in XCL. We want to do the same in
ABCL.
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/73>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#175: abcl.release target fails occasionally
--------------------------+-------------------------------------------------
Reporter: mevenson | Owner: mevenson
Type: defect | Status: new
Priority: major | Milestone: 1.0
Component: build | Version: 0.27
Keywords: abcl.release |
--------------------------+-------------------------------------------------
The central abcl.release target can fail unpredictably, so it is current
best to clean the intermediate build targets before making a release.
'abcl.release' currently *always* fails under MSFT Windows.
@erik had noted this in #abcl.
http://trac.common-lisp.net/armedbear/changeset/12419
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/175>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#60: Implement USE-FAST-CALLS properly
-------------------------+--------------------------------------------------
Reporter: trittweiler | Owner: ehuelsmann
Type: defect | Status: new
Priority: minor | Milestone:
Component: compiler | Version:
Keywords: |
-------------------------+--------------------------------------------------
USE-FAST-CALLS is implemented at the moment by flipping
an essentially global variable.
The proper implementation would be to make turn it into
a ABCL-specific declaration, and making sure it affects
its lexically enclosing code only.
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/60>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#32: Modify the currently disabled runtime-class.lisp code to not require ASM
--------------------------------------------------------------------+-------
Reporter: vvoutilainen | Owner: somebody
Type: enhancement | Status: new
Priority: major | Milestone:
Component: component1 | Version:
Keywords: jvm bytecode compiler runtime dynamic class generation |
--------------------------------------------------------------------+-------
It's possible to define classes at runtime, by generating bytecode and
loading it from the generated binary data, without ever writing it to a
temporary file. runtime-class.lisp does that, but it requires an external
bytecode library (ASM). ABCL has all the functionality for this to be done
without ASM, so the task is to modify the runtime-class.lisp code so that
ASM is no longer required and the code can be taken to be part of the
build.
--
Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/32>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#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
#192: ASDF::IMPLEMENTATION-IDENTIFIER contains information on which ABCL was
compiled
------------------------------+---------------------------------------------
Reporter: mevenson | Owner: ehuelsmann
Type: defect | Status: new
Priority: trivial | Milestone: unscheduled
Component: (A)MOP | Version: 1.0
Keywords: asdf, bite-sized |
------------------------------+---------------------------------------------
[http://article.gmane.org/gmane.lisp.armedbear.devel/2169 Anton Vodonosov
reports on armedbear-develop@] that the ASDF IMPLEMETATION-IDENTIFIER
contains a reference to the system that ABCL was compiled on:
For the [http://common-lisp.net/project/armedbear/release-
notes-1.0.1.shtml Recent abcl-1.0.1 release] which was compiled on
[http://wiki.openindiana.org/oi/oi_151a+Release+Notes OpenIndiana oi_151a]
system one sees:
{{{
CL-USER> (asdf::implementation-identifier)
abcl-1.0.1-svn-13750-13751-fasl38-solaris-x86
}}}
I vaguely remember discussing this with Faré, suggesting the right value
might be the current JVM version that ABCL finds itself hosted upon.
Patches solicited.
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/192>
armedbear <http://common-lisp.net/project/armedbear>
armedbear