#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
#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
#196: STABLE-SORT is only stable for lists
------------------------------+---------------------------------------------
Reporter: mevenson | Owner: ehuelsmann
Type: defect | Status: new
Priority: major | Milestone: 1.1.0
Component: interpreter | Version: 1.0.1
Keywords: ansi-conformance |
------------------------------+---------------------------------------------
[http://article.gmane.org/gmane.lisp.armedbear.devel/2204 Jorge Tavares
reports on armedbear-devel@]:
{{{
Recently I started to investigate the different CL sort implementations
and found that stable-sort in ABCL does not execute as required. The
problem is that stable-sort is only stable for lists and not for all type
of sequences (i.e., elements considered equal by the predicate should stay
in their original order).
A very simple test shows this error:
idesk:~ jast$ abcl
Armed Bear Common Lisp 1.0.1
Java 1.6.0_29 Apple Inc.
Java HotSpot(TM) 64-Bit Server VM
Low-level initialization completed in 0.399 seconds.
Startup completed in 1.069 seconds.
Loading /Users/jast/.abclrc completed in 4.8 seconds.
Type ":help" for a list of available commands.
CL-USER(1): (defparameter *stuff* #((1 0.31648433) (0 0.2704757) (0
0.48931926) (1 0.9958766) (0 0.49251676)))
*STUFF*
CL-USER(2): (setf *stuff* (stable-sort *stuff* #'< :key #'first))
#((0 0.49251676) (0 0.2704757) (0 0.48931926) (1 0.31648433) (1
0.9958766))
The above test is short and simple to understand: *stuff* contains an
array where each element is a pair. The first element of a pair is the key
and the second the data. With this in mind, the expected result should
have been: #((0 0.2704757) (0 0.48931926) (0 0.49251676) (1 0.31648433) (1
0.9958766)).
The same error happens with larger arrays and other types of data. I also
tested it in SBCL, CCL, ECL and CLisp and for these implementations the
results are the expected. Only ABCL differs form the major open source
implementations (I didn't test in ACL or LW).
The reason for this bug is actually quite simple. In sort.lisp, in the
definition of stable-sort, seq-dispatch calls for the non-list sequences
the quicksort algorithm, which is not stable. For lists it calls merge
sort (which is stable) and the problem does not arise.
As a quick fix, I send in attach a patch that uses in stable-sort merge
sort for all sequences. This is done by coercing the sequence to list,
calling merge sort and coercing it back to the original sequence type.
However, as a long term improvement, the best solution would be to
implement a merge sort for non-list sequences.
}}}
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/196>
armedbear <http://common-lisp.net/project/armedbear>
armedbear