#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
#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
#173: Cannot initialize ABCL within .ear
-----------------------------------------------------------------------+----
Reporter: https://me.yahoo.com/a/KvgfiPIMkNAd1zTHUTfXlVJkp92K#3d978 | Owner: ehuelsmann
Type: defect | Status: new
Priority: blocker | Milestone:
Component: interpreter | Version: 0.27
Keywords: |
-----------------------------------------------------------------------+----
Exception is
java.lang.Error: ABCL Debug.assertTrue() assertion failed!
at org.armedbear.lisp.Debug.assertTrue(Debug.java:46)
at org.armedbear.lisp.Pathname.init(Pathname.java:404)
at org.armedbear.lisp.Pathname.<init>(Pathname.java:217)
at org.armedbear.lisp.Site.init(Site.java:60)
at org.armedbear.lisp.Site.getLispHome(Site.java:74)
Truncated. see log file for complete stacktrace
ABCL is initialized from .ear and tries to load boot.lisp
on URL zip:/opt/was/.........abcl-0.27.0.jar!/......../boot.lisp
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/173>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#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