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

[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 03 Feb '11

03 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 31 Jan '11

31 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

[armedbear-devel] ext:run-shell-program
by Alex Mizrahi 30 Jan '11

30 Jan '11

hi I'd like to recieve output of external program as a stream, i.e. without getting it all in one (potentially) huge string but processing it in small portions as it comes. But it looks like this is not possible to do this with ext:run-shell-program -- it accepts output stream as parameter, but I can't read from output stream, and there is no way to translate output stream into input string in CL. (make-echo-stream does the opposite.) So ... am I missing something? If not, what is the best way to implement this?

1 0

[armedbear-devel] Thanks for the error message fix
by Blake McBride 26 Jan '11

26 Jan '11

Greetings, Thanks a lot for fixed the error messages. I can't tell you how much easier debugging has been. Thanks! Blake McBride

1 0

[armedbear-devel] Filename errors in Windows
by Arie van Wingerden 26 Jan '11

26 Jan '11

Hi, I just started with ABCL using the J editor on WinXP SP3. I replaced the ABCL jar in the J lib with the latest 0.23.1, but also in the old version ABCL 0.19 I had the same errors. I am able to create and save a very simple lisp file. However, when I use the menu function: Mode | Compile and load file I get this: [1] CL-USER(3): ;;; Compiling and loading D:\src\lisp\plus.lisp ... #<THREAD "JLisp interpreter" {FD5428}>: Debugger invoked on condition of type FILE-ERROR The file "D:/src/lisp/srclispplus.lisp" does not exist. It seems that somewhere under the hood the filename gets corrupted. Trying to change the name using double backslashes in the text box above the source file does have no effect. Can I change this behaviour? Thx, Arie

3 8

Re: [armedbear-devel] Infinite loop loading compiled file
by Greg Baryza 26 Jan '11

26 Jan '11

Sent, Erik. Thank you. Please confirm that you have it in hand. At 10:11 PM 1/25/2011, Erik Huelsmann wrote: >Hi Greg, > >On Tue, Jan 25, 2011 at 10:01 PM, Greg Baryza <baryza(a)intersystems.com> wrote: > > I have a self-contained directory that has only the QI files needed to > > reproduce the problem. Â In it there is a subdirectory called JAR where you > > should place the ABCL jar file of your choice. Â _COMPILE.bat compiles > files > > and then loads them; it hangs trying to load the fourth file. _BUILD.bat > > uses the same files but just loads the lisp sources; it works. > >That looks like a manageable size reproduction. Interesting. > >Could you send directly to me on my sender address? I'll check it out. > >Bye, > >Erik. > > > > I have all this in a 16KB zip file ready to go. Â Where do you want it? > > > > <G> > > > > At 09:23 PM 1/25/2011, Erik Huelsmann wrote: > >> > >> Hi Greg, > >> > >> On Tue, Jan 25, 2011 at 3:33 PM, Greg Baryza <baryza(a)intersystems.com> > >> wrote: > >> > I recently became interested in the language QI. Ã Since it did not run > >> > on > >> > ABCL (it does on SBCL, Allegro, LispWorks and others), I decided to see > >> > what it would take to move it there. Ã From the QI mailing list, I > found > >> > several others had tried on earlier versions of ABCL with inconclusive > >> > results. Ã I decided to give it a try on 0.23.1. > >> > > >> > When I tried the standard script with compiles and then loads the > >> > compiled > >> > files, ABCL hangs it what appears to be an infinite loop try to load one > >> > of > >> > the compiled files. Ã When I switch to just loading them in as Lisp > >> > sources, > >> > things seem to work (though some of the QI tests later fail). > >> > > >> > I tried the compile/load script under 0.24.0 today and the same hang > >> > happens. > >> > > >> > I have a small test case consisting only of the needed sources and a > >> > couple > >> > of .bat files for Windows that demonstrates the problem, but before I > >> > proceed further, has anyone seem anything like this. Ã The file in > >> > question > >> > DEFUNs about 85 functions. Ã Is that too many to provoke the "large > >> > file" > >> > problem I see mentioned here? > >> > >> Could you provide us with a transcript for downloading/installing Qi > >> so we/I can test? > >> > >> If this is the same old bug, the ball is really in Qi's park, but if > >> it's not, we're really happy to fix what we can! > >> > >> Thanks! > >> > >> > >> Bye, > >> > >> > >> Erik. > > > >

1 0

[armedbear-devel] initialization of shared slots
by Didier Verna 26 Jan '11

26 Jan '11

Hello, it seems that until now, I've been relying on a non-standard behavior, namely the fact that shared slots with an :initform are initialized before the first actual class instance is created: (defclass test () ((slot :allocation :class :initform t))) (defmethod initialize-instance :before ((test test) &key) (format t "Slot boundp: ~A~%" (slot-boundp test 'slot))) CL-USER> (make-instance 'test) Slot boundp: NIL #<TEST {C5D3B8}> CL-USER> (make-instance 'test) Slot boundp: T #<TEST {14563D4}> CL-USER> I just fell on this because every other Common Lisp implementation I've tried gives T and T here. Is it due to the way CLOS is implemented in ABCL, and is there a chance that this can be improved? Thanks. -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com

3 4