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

[armedbear-devel] Clarification proposal for CLHS 22.3
by Didier Verna 11 Feb '11

11 Feb '11

Hello, I'm planning to submit a CDR for clarifying some aspects of the syntax and semantics of format directives. As this could involve modifying ABCL's behavior, I'd like to have some comments before I submit a first document. I'm attaching a plain text version below (the source is in Texinfo format). -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com

1 0

[armedbear-devel] Maven & ABCL
by Alessio Stalla 11 Feb '11

11 Feb '11

Hello folks, I'm in the process of integrating Dynaspring [1] in a yet-to-be-released open source utilities project developed together with some (ex-)colleagues. The utilities project is built with Maven, so in order to use Dynaspring (and transitively ABCL) I had to write a simple pom.xml (Maven project descriptor) for ABCL to make it known to Maven (i.e. usable as a dependency in Maven projects). For the other developers' convenience, it would be nice if the poms were available from a publicly accessible Maven repository (Sonatype provides a free one, [2]). I'm going to create one there for Dynaspring, but if you're ok with it, I can create a separate one for ABCL, and from now on, publish ABCL releases there as well. What do you think? Bye, Alessio [1] http://code.google.com/p/dynaspring/ [2] https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+…

4 14

[armedbear-devel] Release signing (was Maven & ABCL)
by Erik Huelsmann 10 Feb '11

10 Feb '11

>> Morale: this is not terribly complicated, and it would make ABCL >> available through another distribution channel. OTOH, I can't hide the >> fact that - besides my own personal convenience for my shared project >> - probably no-one is using ABCL in Maven projects right now, and >> having ABCL released through Maven would complicate its release >> process, not much for technical reasons but for organizational ones >> (e.g. who keeps ABCL's GPG key? How is it managed?). > > Currently Erik maintains the GPG key we currently use for signing. Does > anyone have a model by which we could somehow share it? It might be > nice to start "rotating" the responsibility for the releases among the > four core committers to help take some work off of Erik's plate. Yes. The key I use for signing as really my own though: I use it to sign all packages I put up for distribution: usocket (when I last did), cl-irc, ABCL, Subversion, py-configparser and maybe others. Within the Subversion project we had a discussion about having a project key or not. We considered that a project key would have to be passed from one to another person, increasing chances of the key getting compromised. Also, the process with a single key means single point of failure. What we considered back then - and are still doing today - is that as many committers as possible sign the release. Each committer signs the variants of the release he/she verified and tested to work well. (There is a tgz and a zip release, exactly like ours, one meant for *nix, the other for Windows). Having many committers sign each release reduces the dependency on every single one of them, but also allows others to join in and maybe have some of the older contributors flow out. Due to the fact that the core stays the same from one release to another, the signatures are still very well recognizable as "the official Subversion release with its regular signatures". I'm interested in your opinions (and how this might work with Maven). Do you think this approach would help to lift work off my shoulders? Do you think it's a good idea to make the signatures "mean" anything? Do you think our group of contributors is large enough to start collecting multiple signatures at all? By the way, I think it's really great that we're actually having this discussion. To me it says something about the maturity of the ABCL project and the attitude of the committers in its community: we're a group dedicated to setting steps in the direction of delivering mature software with solid processes to ensure that our users are getting the quality they deserve. Bye, Erik.'

2 1

Re: [armedbear-devel] [armedbear-cvs] r13209 - trunk/abcl/src/org/armedbear/lisp
by Erik Huelsmann 08 Feb '11

08 Feb '11

This fixes the regression I introduced a few days ago. Bye, Erik. On Tue, Feb 8, 2011 at 10:46 PM, Erik Huelsmann <ehuelsmann(a)common-lisp.net> wrote: > Author: ehuelsmann > Date: Tue Feb 8 16:46:47 2011 > New Revision: 13209 > > Log: > Add documentation to STD-SHARED-INITIALIZE and > add initarg checking to REINITIALIZE-INSTANCE. > > Modified: > trunk/abcl/src/org/armedbear/lisp/clos.lisp > > Modified: trunk/abcl/src/org/armedbear/lisp/clos.lisp > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/clos.lisp (original) > +++ trunk/abcl/src/org/armedbear/lisp/clos.lisp Tue Feb 8 16:46:47 2011 > @@ -2650,18 +2650,23 @@ > ;; slots should be initialized according to their initforms), and the initargs > ;; it received." > (defmethod reinitialize-instance ((instance standard-object) &rest initargs) > + (check-initargs (list #'reinitialize-instance) (list* instance initargs) > + instance () initargs) > (apply #'shared-initialize instance () initargs)) > > (defun std-shared-initialize (instance slot-names all-keys) > (when (oddp (length all-keys)) > (error 'program-error :format-control "Odd number of keyword arguments.")) > + ;; do a quick scan of the arguments list to see if it's a real > + ;; 'initialization argument list' (which is not the same as > + ;; checking initarg validity > (do* ((tail all-keys (cddr tail)) > - (initarg (car tail) (car tail))) > + (initarg (car tail) (car tail))) > ((null tail)) > (when (and initarg (not (symbolp initarg))) > (error 'program-error > - :format-control "Invalid initarg ~S." > - :format-arguments (list initarg)))) > + :format-control "Invalid initarg ~S." > + :format-arguments (list initarg)))) > (dolist (slot (class-slots (class-of instance))) > (let ((slot-name (slot-definition-name slot))) > (multiple-value-bind (init-key init-value foundp) > > _______________________________________________ > armedbear-cvs mailing list > armedbear-cvs(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-cvs >

1 0

[armedbear-devel] Cannot RENAME-FILE to a file without extensions
by Theam Yong Chew 07 Feb '11

07 Feb '11

Dear developers of ABCL, I found a problem recently in both ABCL 0.21.0 and 0.24.0, where I could not rename a file to any file without an extension. For example, with an existing file /tmp/a.txt, CL-USER> (rename-file "/tmp/a.txt" "/tmp/a") #P"/tmp/a.txt" #P"/tmp/a.txt" #P"/tmp/a.txt" The file does not change at all. With any extension, everything works as expected. Thanks in advance. Yong.

2 1

[armedbear-devel] compiler-pass2, dump-form and the dreaded 64k constant string size limit
by Alessio Stalla 06 Feb '11

06 Feb '11

I found another limitation caused by the class file format: constant strings are limited to a size of 64k bytes. The compiler uses dump-form to externalize objects to FASLs, and this means that not only literal strings are limited to 64k, but every object that is dumped is limited by its printed representation. I found that out while trying to compile closure-html [1], which creates a big vector to hold generated parser states and stores it as a constant in the code [2]. So we need to split big dumped forms over multiple strings. I'll attempt a solution in the following days. Bye, Alessio [1] http://common-lisp.net/project/closure/closure-html [2] Incidentally, I also found out that dump-vector causes a stack overflow error for such a vector (probably because it contains other vectors that form circular references). What's the reason for dump-vector not to use the normal vector printing code?

1 0

[armedbear-devel] (quit) in slime doesn't
by Alan Ruttenberg 03 Feb '11

03 Feb '11

CL-USER> (quit) ; Evaluation aborted on NIL.

2 1

[armedbear-devel] (defstruct (teststruct (:type list) :named) testslot)))
by Alan Ruttenberg 02 Feb '11

02 Feb '11

(defstruct (teststruct (:type list) :named) testslot))) causes the following defun to be compiled: (DEFUN NIL (SYSTEM::INSTANCE) (ELT SYSTEM::INSTANCE 0)) That shouldn't be. Particularly if (fdefinition nil) gives an error. -Alan

2 2

[armedbear-devel] [RFC] How to better support disposal of class objects
by Erik Huelsmann 31 Jan '11

31 Jan '11

To prevent any confusion beforehand: The mail below talks about class objects, objects which store class definitions, not the actual instances of those classes, which use those class definitions and store class-allocated or instance values. We have fixed a few bugs where memory would be allocated during (package creation or) FASL loading, but would not be freed upon package deletion. That was an issue because it's an explicit use-case for Blake. Last weekend I came up with another "leak" in ABCL. The word "leak" is between quotes, because depending on how you look at it, not all of it may technically be leaky. My point: it's easy to create a class; simply use a DEFCLASS form. However, unlike package creation, which can be "undone" through DELETE-PACKAGE, there's no DELETE-CLASS function to undo the result of a DEFCLASS. I started to think about supporting the use-case of deleting a class. Digging around in our implementation, I found there are several reasons why a class won't be automatically cleaned up when the package containing its naming symbol is deleted: 1. Every parent maintains a list of subclasses The list contains class objects, meaning that the actual class-object is referenced in this list and for that reason can't be GC-ed 2. Every generic function maintains a list of specializing methods The methods in the list refer to the dispatch types, meaning that the class-objects are strongly referenced from there too 3. Our FIND-CLASS implementation contains strong references to both the naming symbols as well as the class-objects. 4. Our implementation uses a cache to speed up the calls to generic functions. This cache uses strong references too. The issue in item (3) can be solved (relatively) easy by developing a weak hash table which contains both weak keys and values. This hash table could even be made available as regular Lisp objects. Item (4) currently uses an explicitly specialized hash table implemented on the Java side. The hash table could be adapted to use weak references as well - the effort wouldn't be as generally usable, but that's just tough luck. Items (1) and (2) are something to think about though: Is it wise to implement a function which removes the methods and the class from its parent? What if the class itself has direct subclasses? Do we signal an error? Do we provide a parameter forcing the deletion of a whole tree? Or maybe we should just document how potential users of our CLOS should proceed if they have the intention to do this, since it won't be portable anyway? Myself, I'm currently contemplating "just document" on one hand and "do whatever we can, even if they're whole trees" on the other... What do other people think? Bye, Erik.

2 2

[armedbear-devel] Start up message suggestion
by Blake McBride 30 Jan '11

30 Jan '11

Greetings, I've got a suggestion regarding the startup message on development versions of abcl. Rather that just saying "-dev" why don't we say "-dev (XXX)" where XXX is the subversion revision number? This would make it much more clear about what you are running, and I'm pretty sure subversion can automatically provide and update this (I am doing it elsewhere). Thanks. Blake McBride

6 12