May 2010 - armedbear-ticket - mailman3.common-lisp.net

[armedbear-ticket] [armedbear] #76: Slime (swank) fuzzy completion very slow
by armedbear 04 Oct '10

04 Oct '10

#76: Slime (swank) fuzzy completion very slow -------------------------+-------------------------------------------------- Reporter: ehuelsmann | Owner: somebody Type: enhancement | Status: new Priority: major | Milestone: Component: other | Version: Keywords: | -------------------------+-------------------------------------------------- In [http://common-lisp.net/pipermail/armedbear-devel/2009-July/000062.html a mail to the development list], Anton Vodonosov writes about the relative speed of ABCL, CCL and Clisp on slime fuzzy completion. ABCL is by far the slowest. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/76> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 3

[armedbear-ticket] [armedbear] #24: Ability to load ASDF systems off JAR files in the classpath
by armedbear 04 Oct '10

04 Oct '10

#24: Ability to load ASDF systems off JAR files in the classpath -------------------------+-------------------------------------------------- Reporter: ehuelsmann | Owner: somebody Type: enhancement | Status: new Priority: major | Milestone: Component: component1 | Version: Keywords: | -------------------------+-------------------------------------------------- Alan Ruttenberg writes: I'd really like the ability to pop an asdf central registry directory into the abcl jar and have abcl be able to asdf load from there. Would really simplify packaging apps based on abcl. -- Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/24> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 7

[armedbear-ticket] [armedbear] #68: Extend Load.java to allow loading FASLs from arbitrary streams
by armedbear 04 Oct '10

04 Oct '10

#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

1 5

[armedbear-ticket] [armedbear] #29: Support loading system files off other paths (in a JAR) than the default one
by armedbear 04 Oct '10

04 Oct '10

#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

1 2

[armedbear-ticket] [armedbear] #35: ABCL.Net.dll -- Using IKVM-patch to make ABCL run on .NET and MONO
by armedbear 04 Oct '10

04 Oct '10

#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

1 4

[armedbear-ticket] [armedbear] #58: Lisp-side introspection into java classes
by armedbear 04 Oct '10

04 Oct '10

#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

1 2

[armedbear-ticket] [armedbear] #43: Interface for API users to hook into debugging output
by armedbear 04 Oct '10

04 Oct '10

#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

1 1

[armedbear-ticket] [armedbear] #91: Initial values of special bindings on thread startup
by armedbear 04 Oct '10

04 Oct '10

#91: Initial values of special bindings on thread startup ------------------------+--------------------------------------------------- Reporter: ehuelsmann | Owner: nobody Type: defect | Status: new Priority: major | Milestone: Component: libraries | Version: Keywords: | ------------------------+--------------------------------------------------- We don't set any special variables upon thread startup. This may or may not (to be determined) be fine, however, libraries can't specify their own, nor do we allow users to specify values. CCL uses an :INITIAL-BINDINGS argument for its thread creation function. Note: How to handle threads which aren't started from Lisp, but instead just get 'associated' with Lisp? Those should probably create a set of default bindings. This situation occurs when a thread is created outside the new LispThread() interface, but currentThread() is called as part of the code running on it. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/91> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 1

[armedbear-ticket] [armedbear] #19: SLIME from CVS HEAD needs 'with-mutex.lisp'
by armedbear 04 Oct '10

04 Oct '10

#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

1 4

[armedbear-ticket] [armedbear] #59: Add extensible sequences to ABCL
by armedbear 04 Oct '10

04 Oct '10

#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

1 3