September 2009 - armedbear-devel - mailman3.common-lisp.net

[armedbear-devel] ABCL introductory user documentation
by Paul Reiners 07 Jun '10

07 Jun '10

Some introductory user documentation I wrote on ABCL if anyone's interested: http://www.automatous-monk.com/jvmlanguages/abcl/Armed_Bear_Common_Lisp.html It's spread across a bunch of slides right now, because I first prepared it as a multi-slide presentation. I think I want to combine it all into one HTML page later this week when I get around to it. At the very least, I want to give each slide a meaningful title so that the Table of Contents is more meaningful. Any criticism, constructive or destructive, is welcome. Paul

5 11

[armedbear-devel] [BUG] EXT:ARGLIST produces bogus case-sensitive arglists
by Tobias C. Rittweiler 29 Jan '10

29 Jan '10

`arglist' in `arglist.java' calls `readObjectFromString' which uses the FASL Readtable which is case sensitive. This ain't good because this way the lambda-list keywords (&OPTIONAL etc.) are not properly read back (EXTENSIONS:|&optional|) -T. -- Diese Nachricht wurde auf Viren und andere gefaerliche Inhalte untersucht und ist - aktuelle Virenscanner vorausgesetzt - sauber. Freebits E-Mail Virus Scanner

2 1

[armedbear-devel] No restarts available on error in thread
by Tobias C. Rittweiler 29 Jan '10

29 Jan '10

Evaluating the following (threads:make-thread #'(lambda () (error "foof")) :name "foof") will get you into the debugger. But there's not restart available. As it does not make sense to provide a RETURN-TO-TOPLEVEL restart for an error occuring in a thread, I think there should be a TERMINATE-THREAD restart instead. And the debugger should probably print the thread's name the error occured in. -T.

2 1

[armedbear-devel] Autoloads
by Tobias C. Rittweiler 29 Jan '10

29 Jan '10

I *always* forget what the autoload stuff is about, and when I have to add something to it. Could anyone please add a comment to Autoload.java and autoloads.lisp? -T.

2 3

[armedbear-devel] Error in 'test.lisp' to create .abcl_completions
by John Pallister 23 Oct '09

23 Oct '09

Hello list, I think there's an error in the 'test.lisp' code used to create .abcl_completions at http://common-lisp.net/project/armedbear/doc/abcl-install-with-java.html . Basically it should start with (defvar symbols nil) or somesuch to avoid an UNBOUND-VARIABLE error. Cheers, John :^P -- John Pallister john(a)johnp.net john(a)synchromesh.com

2 1

[armedbear-devel] Bug: Attempt to GO to a tag whose extent has ended quits ABCL
by Brian Mastenbrook 23 Oct '09

23 Oct '09

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$ -- Brian Mastenbrook brian(a)mastenbrook.net http://brian.mastenbrook.net/

2 1

[armedbear-devel] Serious bug involving UWP
by Tobias C. Rittweiler 18 Oct '09

18 Oct '09

Steps to reproduce: * ABCL from svn, updated a few minutes ago. * Slime from CVS. * M-x slime-scratch * Put (defun test (x) ,bar) in the buffer * Press C-c C-c You'll see "Evaluation aborted." in the minibuffer even though the debugger should have popped up complaining about comma not being inside backquote. C-c C-c is SWANK-COMPILE-STRING in swank-abcl.lisp. If you follow the control flow, you'll see that in SLDB-LOOP (we come here through *DEBUGGER-HOOK*) in swank.lisp, __the UNWINDED-PROTECT's protected form is *never* executed and it goes straight to the cleanup forms.__ -T.

4 13

[armedbear-devel] bug with initialize-instance and keyword arguments
by Steve Rolls 09 Oct '09

09 Oct '09

This is present in 0.16 and latest from svn, but not in 0.15. Specifying a keyword arg in an initialize-instance method does not make the keyword a valid initarg for make-instance. Armed Bear Common Lisp 0.16.0 Java 1.6.0_12 Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.425 seconds. Startup completed in 2.086 seconds. Type ":help" for a list of available commands. CL-USER(1): (defclass c1() (x)) #<STANDARD-CLASS C1 {5A347448}> CL-USER(2): (defmethod initialize-instance :after ((c c1) &key x2) (setf (slot-value c 'x) x2)) #<STANDARD-METHOD INITIALIZE-INSTANCE :AFTER (C1) {79A1EA46}> CL-USER(3): (make-instance 'c1 :x2 1) Debugger invoked on condition of type PROGRAM-ERROR: Invalid initarg :X2. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(4): Works as expected in 0.15 Armed Bear Common Lisp 0.15.0 Java 1.6.0_12 Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.45 seconds. Startup completed in 2.021 seconds. Type ":help" for a list of available commands. CL-USER(1): (defclass c1() (x)) #<STANDARD-CLASS C1 {615E7597}> CL-USER(2): (defmethod initialize-instance :after ((c c1) &key x2) (setf (slot-value c 'x) x2)) #<STANDARD-METHOD INITIALIZE-INSTANCE :AFTER (C1) {7346B111}> CL-USER(3): (make-instance 'c1 :x2 1) #<C1 {772EDF9A}> CL-USER(4):

3 8

[armedbear-devel] Making tags (in tagbody) and block names unique
by Erik Huelsmann 29 Sep '09

29 Sep '09

On IRC, we had a discussion some days ago where it was found that ABCL doesn't use unique tag-identifications in tagbody, leading to somewhat dynamically scoped tagbodies, instead of perfectly lexically scoped. BLOCK also uses non-unique names (think NIL), leading to the same issue. Both the compiler and the interpreter exhibit the problem. Consider the following code: (labels ((p (b) (tagbody (if (not b) (p #'(lambda () (go :foo))) (funcall b)) (return-from p :bar) :foo (return-from p :foo)))) (p nil)) It should return :foo, but returns :bar on ABCL's interpreter instead. (The fact that the compiler works, means there's probably a bug in it somewhere, because there's no explanation why it would.) I'm now thinking of ways to make the tags/blocknames unique. The one way I could come up with for the interpreter is this: Adding a second identifier (created using "new Object();") to the blocks and tags registered in the interpreter environment. Then, when a Go or Return is thrown, it should include the identifier. The catching tagbodies and blocks can verify that the Go or Return is meant for that block by checking the identifier. The approach above requires an additional "identifier" field in the Binding object. For the compiler, this could work similarly, except that the identifier can't be stored in the environment (because there is none), meaning it should probably be stored in a closure variable which any throwing function can then use when creating the Go or Return object. Any comments? Bye, Erik.

1 2

[armedbear-devel] Performance of ABCL?
by Žiga Lenarčič 27 Sep '09

27 Sep '09

Hi! I've tested Maxima with ABCL. While it runs, which is rather cool, it's fairly slow! On my computer (with -server) Maxima on ABCL is about 10x - 20x slower than SBCL for various operations in Maxima (and using 3-4x more RAM). I don't know much about implementation details - but as far as I know, every lisp object is encapsulated in a Java object, so there is a lot of allocation going on. Compiler is also very slow (compared to SBCL). My question is, is performance ever increase dramatically (perhaps with java 7?) or is ABCL inherently slower because of the JVM? Clojure performs better than ABCL usually and is also running on JVM. I don't know about KAWA. Is JVM bytecode not flexible enough to perhaps reuse some compilation techniques of native compilers (CCL, SBCL) ? I was thinking about writing a GUI for maxima in java, using ABCL to run Maxima. This way the gui could interact directly with the lisp functions of Maxima. But the main advantage of Maxima is IMO that it can be easily extended via Lisp, which can compile to near C speed on native compilers such as SBCL and CCL. Using ABCL (if it is as slow as it is now), this would not be true and the only fast extensions to Maxima could be written in Java perhaps, which is fine, but is not portable to other CLs and Java code is verbose. Regards, Ziga

6 6

[armedbear-devel] Ugh! java.lang.OutOfMemoryError: PermGen space
by Alessio Stalla 26 Sep '09

26 Sep '09

(dotimes (i 100000) (compile 'f (lambda () 42))) abcl dies with java.lang.OutOfMemoryError: PermGen space if I use nil instead of f it doesn't die. Also with nil is noticeably faster. Adding (when (= 999 (mod i 1000)) (room)) in the loop shows that gc is performed and memory is reclaimed, but apparently there's a leak somewhere. I'll try to find out more. Later, Ale

2 2

[armedbear-devel] In-memory compilation!
by Alessio Stalla 26 Sep '09

26 Sep '09

Hello list, I managed to get temp-file-less compilation with COMPILE working. And the hilarious things is: the classloader experiment was not necessary for this, as the compiler already behaved differently according the the value of *file-compilation*, and the use of loadCompiledFunction that troubled me was only done for the file compiler! So it's sufficient to move file creation from inner functions to outer ones and to pass an additional stream parameter to inner functions. Things can be made clearer - now the structure used to represent compilation results, class-file, is required to always have a pathname set, even when no file is created, for example. But I believe we're on the right track. I cannot provide a patch now because I have still have to clean up the classloader changes. Btw I believe that the use of classloaders is a good thing even if it's not used for memory compilation (for one thing, it would play nicer with serialization of lisp functions, if we ever want that). Cheers, Ale

1 1

[armedbear-devel] Some thoughts on classloaders, inner classes and in-memory compilation
by Alessio Stalla 24 Sep '09

24 Sep '09

Hello folks, I'd like to share some thoughts on the "usual" problem of in-memory compilation in abcl. I haven't written any code to support my thoughts - I just hope to make things clearer for me and other people on the list, and I'm asking you to share your ideas and comment mine. Warning - this is going to be a long post. Let's start by describing how abcl works now. Every piece of code in the JVM needs to be contained in a method of some class, so when abcl compiles a function it produces - surprise - a class, or better, a stream of bytes that the JVM knows how to interpret to create a class. Classes produced by the compiler extend a common abcl class providing the methods that will be used to actually invoke the function; the compiler, among other things, will override some of those methods. When using the runtime compiler, the class is immediately loaded; when using the file compiler, it is stored on the filesystem for later use. So far, nothing requires temporary files to work. However, a Lisp function can contain nested functions introduced with FLET or LABELS, and those have to be compiled to classes as well. Also, they need to be loaded contextually with the main function. How does abcl solve this? By adding instructions in the main class to load the local functions when the class itself is loaded, relatively to where it is loaded from. And here lies the problem. That location is always assumed to be a file in some filesystem subtree. So even when using the runtime compiler all the classes must be, at least temporarily, stored in files for the load machinery to work. Changing this is hard; classes are resolved from strings, how do know when a given string represents a file and when it represents some object in memory instead? There are workarounds, but I think it's the approach itself that's brittle. So let's step back a bit and take a look at how the JVM and Java the language work with respect to loading classes. The JVM uses dedicated objects called classloaders. They are responsible of translating from a class' symbolic name (a string) to a class metaobject, much like the CLOS find-class function does. Classloaders are organized hierarchically: every classloader has a parent which is first consulted to see if it already has the class (there is of course a built-in bootstrap classloader to break the circularity); if it has, it returns it, if it hasn't, it is loaded in a manner dependent to the particular classloader (e.g. from a file, from http, from memory, ...). The process of loading a class from a byte array is native in the JVM, so classloaders only get to decide where the byte array comes from and what it contains. Now to the more interesting things: 1. A class never exists in isolation; to do its work it will need to refer to other classes (at a bare minimum, its superclass and any interface it implements). The JVM - automatically! - uses the same classloader to load a class and, at linking time, all of its dependencies. 2. If I had to manually redo in Java what the abcl compiler does with functions, I'd use static inner classes to represent local functions. Inner classes are classes which are textually defined inside another class and share some data with it. Inner classes do not exist at the bytecode level, only at the Java language level: the compiler (javac) translates them to regular classes, with their name mangled. For example, a class Inner defined inside a class Outer will be referred to Outer.Inner in Java, but compiled to Outer$Inner.class by javac. 3. Inner classes then are treated exactly like the others: referred using strings inside code, resolved by a classloader (generally - always? - by the classloader of the containing class). Return to abcl. As you may have guessed, I propose that we no longer make classes autoload their dependencies, but properly use classloaders instead, in a fashion similar to how inner classes work. We will have an InMemoryClassLoader which will load classes from a Map<String, byte[]>, and a slightly extended URLClassLoader to load classes from the filesystem. Both, in addition to load classes, will be used by the compiler to write classes as well, so it will continue to use the class-file abstraction, changing only the code that actually writes the bytes. Every time the compiler would have written a call to loadCompiledFunction(classname) it will now use something like functionFoo.class.getClassLoader().loadClass(classname) where functionFoo is the compiler-generated name of the class representing the compiled Lisp function. Everything else should stay the same. Does this sound convincing? I admit I have left many things to elaborate on, and I haven't rehashed the code in the compiler, going mainly from memory instead. But I believe this approach has not been proposed before and looks doable. The next few days I'll try writing some sketch code to back up my ideas, if no-one finds any serious problem with them. Peace, Alessio

7 23

[armedbear-devel] [BUG] SET-SYNTAX-FROM-CHAR should clear dispatch tables
by Tobias C. Rittweiler 22 Sep '09

22 Sep '09

(let ((rt (copy-readtable nil))) (set-syntax-from-char #\# #\A rt (copy-readtable nil)) (get-dispatch-macro-character #\# #\x rt)) should signal an error as #\# is no longer a dispatching macro character. -T.

1 0

[armedbear-devel] packaging external libs with abcl
by Matthew D. Swank 21 Sep '09

21 Sep '09

I've been messing with running abcl on the google appengine, and I was wondering what was the best way to package libraries, especially the results of loading an asdf system and its dependencies? Thanks, Matt -- "You do not really understand something unless you can explain it to your grandmother." -- Albert Einstein.

3 8

[armedbear-devel] Bug: Attempt to GO to a tag whose extent has ended quits ABCL
by Brian Mastenbrook 21 Sep '09

21 Sep '09

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$ -- Brian Mastenbrook brian(a)mastenbrook.net http://brian.mastenbrook.net/

6 10

[armedbear-devel] [BUG] make-thread and :NAME nil
by Tobias C. Rittweiler 21 Sep '09

21 Sep '09

Not providing a :NAME parameter to MAKE-THREAD will currently fail: CL-USER(1): (threads:make-thread (constantly t)) Debugger invoked on condition of type TYPE-ERROR: The value NIL is not of type STRING. Funnily enough, explicitly providing NIL kind of works: CL-USER(2): (threads:make-thread (constantly t) :name nil) #<THREAD "NIL" {1EEB372}> But, as you can see, the passed NIL is taken as a string designator, but probably shouldn't. -T.

2 1

[armedbear-devel] Your NAMED-READTABLES test
by Erik Huelsmann 20 Sep '09

20 Sep '09

Hi Tobias, The named-readtables test you sent me, does show an obvious bug in ABCL, but not the one you're trying to point me at: when loading your files on Windows, I'm getting an Index out of bounds error: the dispatch tables think our characters range from 0 - 255 in value whereas in practice that number is much higher. I'm working on a fix right now (setting CHAR_MAX to a higher value) but I don't feel too comfortable with it: it'll make us consume much more memory on a number of things. However, what's a K of memory worth these days... ? Bye, Erik.

2 2

[armedbear-devel] JSR-223: Returning immutable lists in ScriptEngineFactory
by Clemens Blamauer 20 Sep '09

20 Sep '09

Hi everyone, I was looking through the JSR-223 code in org.armedbear.lisp.scripting as I noticed that AbclScriptEngineFactory is not fully compliant to JSR-223 [1] (p. 101-102 in the Final Draft Specification, v1.0). For the methods: - java.util.List<java.lang.String> getExtensions() - java.util.List<java.lang.String> getMimeTypes() - java.util.List<java.lang.String> getNames() _immutable_ Lists should be returned. Please find a remedying patch below. Cheerz, Clemens [1] http://jcp.org/en/jsr/detail?id=223 ---- Index: AbclScriptEngineFactory.java =================================================================== --- AbclScriptEngineFactory.java (revision 12157) +++ AbclScriptEngineFactory.java (working copy) @@ -21,6 +21,7 @@ package org.armedbear.lisp.scripting; import java.util.ArrayList; +import java.util.Collections; import java.util.List; import javax.script.ScriptEngine; @@ -44,7 +45,7 @@ public List<String> getExtensions() { List<String> extensions = new ArrayList<String>(1); extensions.add("lisp"); - return extensions; + return Collections.unmodifiableList(extensions); } @Override @@ -89,7 +90,7 @@ @Override public List<String> getMimeTypes() { - return new ArrayList<String>(); + return Collections.unmodifiableList(new ArrayList<String>()); } @Override @@ -99,7 +100,7 @@ names.add("cl"); names.add("Lisp"); names.add("Common Lisp"); - return names; + return Collections.unmodifiableList(names); } @Override -- # Trust in code: # lynx http://lxr.linux.no/linux+v2.6.23.14/arch/i386/kernel/cpu/common.c#L677

2 1

[armedbear-devel] [PATCH] incorporating java stack frames into backtrace
by Tobias C. Rittweiler 20 Sep '09

20 Sep '09

When evaluating (ext:make-thread #'(lambda ())) you get an error "The value NIL is not of type STRING." -- this is a bug in ABCL itself, by the way, but that's not the matter of this mail. The concern of this mail is the backtrace that'd you get: Backtrace: 0: (INVOKE-DEBUGGER #<TYPE-ERROR {B1A201}>) 1: (MAKE-THREAD #<FUNCTION (LAMBDA ()) {15343C2}>) 2: (SYSTEM::%EVAL (MAKE-THREAD #'(LAMBDA NIL))) 3: (EVAL (MAKE-THREAD #'(LAMBDA NIL))) ... The only thing the backtrace reveales is that the error was signalled somewhere in MAKE-THREAD. With the patch of this mail, the backtrace will also contain the relevant Java stack frames for errors that were signalled from within ABCL's Java runtime: Backtrace: 0: (INVOKE-DEBUGGER #<TYPE-ERROR {B1A201}>) 1: org.armedbear.lisp.Lisp.error(Lisp.java:375) 2: org.armedbear.lisp.Lisp.type_error(Lisp.java:390) 3: org.armedbear.lisp.LispObject.getStringValue(LispObject.java:1061) 4: org.armedbear.lisp.LispThread.<init>(LispThread.java:111) 5: org.armedbear.lisp.LispThread.<init>(LispThread.java:39) 6: org.armedbear.lisp.LispThread$3.execute(LispThread.java:909) 7: org.armedbear.lisp.Primitive.execute(Primitive.java:108) 8: (MAKE-THREAD #<FUNCTION (LAMBDA ()) {15343C2}>) 9: (SYSTEM::%EVAL (MAKE-THREAD #'(LAMBDA NIL))) 10: (EVAL (MAKE-THREAD #'(LAMBDA NIL))) Another example: (LENGTH 12) Backtrace: 0: (INVOKE-DEBUGGER #<TYPE-ERROR {814AF5}>) 1: org.armedbear.lisp.Lisp.error(Lisp.java:375) 2: org.armedbear.lisp.Lisp.type_error(Lisp.java:390) 3: org.armedbear.lisp.LispObject.length(LispObject.java:403) 4: org.armedbear.lisp.LispObject.LENGTH(LispObject.java:410) 5: org.armedbear.lisp.Primitives$24.execute(Primitives.java:427) 6: (LENGTH 12) 7: (SYSTEM::%EVAL (LENGTH 12)) 8: (EVAL (LENGTH 12)) -T. -- Diese Nachricht wurde auf Viren und andere gefaerliche Inhalte untersucht und ist - aktuelle Virenscanner vorausgesetzt - sauber. Freebits E-Mail Virus Scanner

4 18

[armedbear-devel] JSR-223: Return immutable lists in ScriptEngineFactory
by Clemens Blamauer 20 Sep '09

20 Sep '09

Hi everyone, I was looking through the JSR-223 code in org.armedbear.lisp.scripting as I noticed that AbclScriptEngineFactory is not fully compliant to JSR-223 [1]. For the methods: - java.util.List<java.lang.String> getExtensions() - java.util.List<java.lang.String> getMimeTypes() - java.util.List<java.lang.String> getNames() _immutable_ Lists should be returned. Please find a remedying patch below. Cheerz, Clemens [1] http://jcp.org/en/jsr/detail?id=223 ---- Index: AbclScriptEngineFactory.java =================================================================== --- AbclScriptEngineFactory.java (revision 12157) +++ AbclScriptEngineFactory.java (working copy) @@ -21,6 +21,7 @@ package org.armedbear.lisp.scripting; import java.util.ArrayList; +import java.util.Collections; import java.util.List; import javax.script.ScriptEngine; @@ -44,7 +45,7 @@ public List<String> getExtensions() { List<String> extensions = new ArrayList<String>(1); extensions.add("lisp"); - return extensions; + return Collections.unmodifiableList(extensions); } @Override @@ -89,7 +90,7 @@ @Override public List<String> getMimeTypes() { - return new ArrayList<String>(); + return Collections.unmodifiableList(new ArrayList<String>()); } @Override @@ -99,7 +100,7 @@ names.add("cl"); names.add("Lisp"); names.add("Common Lisp"); - return names; + return Collections.unmodifiableList(names); } @Override

1 0

[armedbear-devel] Build problem
by Paul 20 Sep '09

20 Sep '09

Can anybody help with this build problem? I'm on MACOSX 10.5.8 trying to build from SVN, which I updated a few minutes ago. Buildfile: build.xml abcl.copy.lisp: [copy] Copying 171 files to /Users/pdo/Lisp/ABCL/build/classes abcl.init: [echo] java.version: 1.5.0_19 [echo] Implementation-Source: ${version.src} abcl.java.warning: abcl.jsr-223.notice: [echo] [echo] Notice: JSR-223 support won't be built since it is not [echo] supported, neither natively by your JVM nor by [echo] libraries in the CLASSPATH. [echo] abcl.compile.java: [javac] Compiling 268 source files to /Users/pdo/Lisp/ABCL/build/ classes abcl.fasls.uptodate: abcl.compile.lisp: [java] Armed Bear Common Lisp 0.15.0 [java] Java 1.5.0_19 Apple Inc. [java] Java HotSpot(TM) Client VM [java] Low-level initialization completed in 1.627 seconds. [java] Startup completed in 7.773 seconds. [java] [java] Caught SIMPLE-ERROR while processing --eval option "(compile-system :zip nil :quit t)": [java] *LISP-HOME* is NIL or invalid. [java] Please set *LISP-HOME* to the full pathname of the directory containing the Lisp system files. BUILD FAILED /Users/pdo/Lisp/ABCL/build.xml:211: Java returned: 2 Thanks, Paul

2 2

[armedbear-devel] [PATCH] Add SYS::*INVOKE-DEBUGGER-HOOK*
by Tobias C. Rittweiler 20 Sep '09

20 Sep '09

The first patch adds SYS::*INVOKE-DEBUGGER-HOOK* which is like *DEBUGGER-HOOK* but is observed by INVOKE-DEBUGGER even when BREAK is called. This obliterates the need to redefine SYS::BREAK in swank-abcl.lisp. A patch for swank-abcl is also attached. -T.

2 1

[armedbear-devel] r12147
by Ville Voutilainen 17 Sep '09

17 Sep '09

Thanks to Douglas Miles, I committed a fix to PRINT-LENGTH.INIT.1 ansi test. I'll commit the rest of Douglas' fixes shortly. Douglas, thanks for the contributions!

1 0

Re: [armedbear-devel] [j-devel] slime swank-abcl.lisp
by Mark Evenson 17 Sep '09

17 Sep '09

On 9/12/09 7:45 AM, Alan Ruttenberg wrote: > Here's a patch against the current swank-abcl.lisp to make a couple of > things work for the trunk abcl. > > I don't want to check it in, as I don't know whether there are issues > with it working for older versions of abcl. > > The fixes make edit definition work, and arglists for generic functions. > > Is there anyone out there who is currently active on slime development > that is comfortable checking these in? Applied to SLIME CVS HEAD. Thanks for the patch! I tested with abcl-0.{15,16} and HEAD with the patch working as I expected. Keeping compatibility with more ancient versions of ABCL takes a too much of my scant resources, but if someone is stuck with a previous version of ABCL they wish to maintain compatibility with SLIME CVS HEAD, drop me an email to work something out. For those following the "old" armedbear-j-devel(a)lists.sourceforge.net list, and perhaps wondering why things have been so quiet lately, note that we moved [ABCL specific traffic to common-lisp.net][1] some months ago. [1]: http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel September 2009