#68: Extend Load.java to allow loading FASLs from arbitrary streams
-------------------------+--------------------------------------------------
Reporter: ehuelsmann | Owner: nobody
Type: enhancement | Status: new
Priority: major | Milestone: 0.18
Component: libraries | Version:
Keywords: |
-------------------------+--------------------------------------------------
Currently, Load.java inspects a file to find whether or not this file is a
ZIP file. From there, it decides on a strategy to continue loading the
file.
However, in many circumstances in Java one has a stream of unknown origin.
It's a requirement for good Java integration to be able to load FASLs off
arbitrary streams (resource streams, e.g.).
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/68>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#29: Support loading system files off other paths (in a JAR) than the default
one
-------------------------+--------------------------------------------------
Reporter: ehuelsmann | Owner: somebody
Type: enhancement | Status: new
Priority: major | Milestone:
Component: component1 | Version:
Keywords: |
-------------------------+--------------------------------------------------
Alan Ruttenberg writes:
In order to enable easy packaging of a system into a jar file, one
that might even be usable as an applet, a small change is needed.
Currently load-system-file can read an .abcl compiled file set from
the abcl jar. Actually, it doesn't load the .abcl directly. That file
is a zip file with a "top level" file with a "._" extension and a
bunch of .cls files. The unpacked contents of these files live in the
abcl jar, with the "._" file renamed to have the extension ".abcl".
The loading happens by first loading the "._" file, a file of lisp
forms, which when evaluated, in turn calls load-compiled-function on
each of the component .cls files (plus does some other stuff). All of
these files live in a single directory in the jar file: org/armedbear/
lisp/
I'd like to be able to load from a subdirectory of that, in which I
would put my files. I can tell load-system-file to load the initial
abcl file from the subdirectory, say, org/armedbear/lisp/util/, but
then load-compiled-function wants to load the components from org/
armedbear/lisp. So the small change is to set *load-truename* in load-
system-file, based on the supplied path, and then to use it as the
pathname defaults when executing the call to load-compiled-function.
It seems to do this for the case where it loads from the regular file
system, but not when working with the jar file.
Once this change is in place, to package up a system, one would unjar
abcl.jar, move one's compiled files in to a subdirectory of org/
armedbear/lisp, unzip all of them, rename *._ to *.abcl, and jar them
back up.
One could them load a file from the jar with: (sys:load-system-file
"mydir/foo.abcl")
loadCompiledFunction is defined in Lisp.java and loadSystemFile in
Load.java
--
Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/29>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#35: ABCL.Net.dll -- Using IKVM-patch to make ABCL run on .NET and MONO
-------------------------+--------------------------------------------------
Reporter: dmiles | Owner: somebody
Type: enhancement | Status: new
Priority: major | Milestone: 0.13
Component: component1 | Version: 1.0
Keywords: ikvm |
-------------------------+--------------------------------------------------
HOWTO:
First Patch the ABCL sources:
[root@titan abcl]# patch -p0 < svn11486-ikvm.patch
(Stripping trailing CRs from patch.)
patching file src/org/armedbear/lisp/Complex.java
(Stripping trailing CRs from patch.)
patching file src/org/armedbear/lisp/IkvmSite.java
(Stripping trailing CRs from patch.)
patching file src/org/armedbear/lisp/Lisp.java
(Stripping trailing CRs from patch.)
patching file src/org/armedbear/lisp/Load.java
(Stripping trailing CRs from patch.)
patching file src/org/armedbear/lisp/Nil.java
(Stripping trailing CRs from patch.)
patching file src/org/armedbear/lisp/Pathname.java
Clean:
[root@titan abcl]# rm -rf build dist
Build ABCL:
[root@titan abcl]#ant abcl.dist
....
Download the latest binaries from http://ikvm.net
I use the "stable" ones: 0.36.0.11
Unzip the binaries to a $ABCL_HOME/bin/
Update MON_PATH:
export MONO_PATH=.:bin
Build the ABCL.Net.dll and abcl.exe
alias ikvmc='mono bin/ikvmc.exe '
[root@titan abcl]# ikvmc -compressresources -recurse:build/classes/
-out:ABCL.Net.dll
Note IKVMC0003: automatically adding reference to "/development/mirrors
/ABCL-SVN/trunk/abcl/bin/IKVM.OpenJDK.ClassLibrary.dll"
[root@titan abcl]# ikvmc -r:ABCL.Net.dll -main:org.armedbear.lisp.Main
-out:abcl.exe
Note IKVMC0003: automatically adding reference to
"bin/IKVM.OpenJDK.ClassLibrary.dll"
Run it:
[root@titan abcl]# mono abcl.exe
Armed Bear Common Lisp 0.13.0-dev (built Fri Dec 26 2008 19:15:42 PST)
Java 1.6.0 Jeroen Frijters
IKVM.NET
Low-level initialization completed in 0.159 seconds.
Startup completed in 3.067 seconds.
Type ":help" for a list of available commands.
CL-USER(1): *FEATURES*
(:IKVM :X86 :JAVA-1.6 :ARMEDBEAR :ABCL :COMMON-LISP :ANSI-CL)
I use the following .dll in a C# project at
http://code.google.com/p/opensim4opencog/source/detail?r=28
Have fun.. how soon can we just have this patch applied to ABCL src?
--
Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/35>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#58: Lisp-side introspection into java classes
-------------------------+--------------------------------------------------
Reporter: trittweiler | Owner: somebody
Type: enhancement | Status: new
Priority: major | Milestone:
Component: CLOS | Version:
Keywords: |
-------------------------+--------------------------------------------------
It'd be nice if ABCL would provide Lisp-side introspection
into Java classes. Including ABCL's own datastructures like
Readtable, Mutex, etc. So it can be used in Slime.
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/58>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#43: Interface for API users to hook into debugging output
-------------------------+--------------------------------------------------
Reporter: ehuelsmann | Owner: somebody
Type: enhancement | Status: new
Priority: major | Milestone:
Component: other | Version:
Keywords: debug |
-------------------------+--------------------------------------------------
Currently, we don't have ways to hook into debugging information in ABCL
from higher-up API users. It would be nice to be able to offer such
interfaces, since it would definitely offer developers better ways to
integrate ABCL into deployed apps.
--
Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/43>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#19: SLIME from CVS HEAD needs 'with-mutex.lisp'
------------------------+---------------------------------------------------
Reporter: mevenson | Owner: ehuselmann
Type: defect | Status: new
Priority: major | Milestone: unscheduled
Component: component1 | Version:
Keywords: SLIME |
------------------------+---------------------------------------------------
SLIME from CVS HEAD fails to load with r11371, as it apparently needs
with-mutex.lisp.
The attached patch adds 'with-mutex.lisp' to the ABCL jar.
--
Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/19>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#59: Add extensible sequences to ABCL
----------------------------------------------+-----------------------------
Reporter: astalla | Owner: somebody
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: other | Version:
Keywords: extensible sequences collections |
----------------------------------------------+-----------------------------
Implement the protocol described in
http://www.doc.gold.ac.uk/~mas01cr/papers/ilc2007/sequences-20070301.pdf
to allow users to provide new types of sequences working with the standard
Common Lisp sequences API. Use this protocol to make Java collections
first-class in abcl.
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/59>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#33: Measure the impact of filling stack trace information when performing
GO/RETURN/THROW
----------------------------------------------------------------------+-----
Reporter: vvoutilainen | Owner: somebody
Type: task | Status: new
Priority: minor | Milestone: unscheduled
Component: component1 | Version: 1.0
Keywords: exception ConditionThrowable go return throw performance |
----------------------------------------------------------------------+-----
Douglas R. Miles reported recently that
java.lang.Throwable.fillInStackTrace() can be a very time consuming
operation when instantiating Throwables or objects the class of which
extends Throwable.
A patch for overriding the fillInStackTrace() function with an empty
implementation was created, it seems to be a performance gain, but a
benchmark is required. ANSI tests test so many other things that it's
difficult to compare the impact of the patch without a test that tests
only GO/RETURN/THROW.
--
Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/33>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#80: REQUIRE should work with ASDF
--------------------------+-------------------------------------------------
Reporter: mevenson | Owner: mevenson
Type: enhancement | Status: new
Priority: major | Milestone: unscheduled
Component: libraries | Version: 1.0
Keywords: asdf require |
--------------------------+-------------------------------------------------
SBCL has the convention that if REQUIRE does not resolve on the
filesystem, the argument is passed off to ASDF to resolve. It would be
nice to include this in ABCL.
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/80>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#63: Attempt to GO to tag whose dynamic extent has ended exits ABCL
----------------------+-----------------------------------------------------
Reporter: mevenson | Owner: somebody
Type: defect | Status: new
Priority: major | Milestone: unscheduled
Component: CLOS | Version: 1.0
Keywords: |
----------------------+-----------------------------------------------------
Reported by Brian Mastenbrook:
When attempting to GO to a tag whose dynamic extent has ended, ABCL quits
and prints the name of the exception used for internally handling GO
(org.armedbear.lisp.Go). I see the same behavior in compiled or
interpreted code.
{{{
CL-USER(1): (lisp-implementation-version)
"0.16.0"
CL-USER(2): (let ((f nil)) (tagbody (setf f (lambda () (go foo))) foo)
(funcall f))
org.armedbear.lisp.Go
abcl-src-0.16.0 chandler$
}}}
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/63>
armedbear <http://common-lisp.net/project/armedbear>
armedbear