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

[armedbear-devel] class-prototype
by Alan Ruttenberg 10 Mar '10

10 Mar '10

Hi, Thanks for adding class-prototype. Unfortunately I realize that the specification doesn't guarantee the behavior I was looking for, so I though I would solicit advise. Basically I want to be able to access class-allocated slot values before I create any real instances. I thought I could grab the class prototype and do slot value on them, but according to the doc below initialize is not called, which I guess is when class-allocated slots are being set up. Is there a portable way of asking for the values of class slots absent the creation of at least one initialized instance? -Alan http://www.franz.com/support/documentation/8.2/doc/mop/dictionary.html#clas… Generic Function class-prototype class Returns a prototype instance of class. Whether the instance is initialized is not specified. The results are undefined if a portable program modifies the binding of any slot of prototype instance. This generic function signals an error if class has not been finalized.

3 11

[armedbear-devel] Problems with compiled PROGV?
by Mark Evenson 09 Mar '10

09 Mar '10

In analyzing the [bug with CL-JSON][1], I think the culprit lies in improper compilation of PROGV forms, although I have yet to come up with a simple example factored out of the CL-JSON codebase. Reading last night's #abcl logs, I saw that Erik made a comment about problems with PROGV as well, without specifics. Thinking that if I had other examples of how PROGV misbehaves it might shed some light on my problems, I'd like to ask for details about other misbehavior of compiled PROGV forms however scant. Cases that are reproducible would be most welcome. [1]: http://trac.common-lisp.net/armedbear/ticket/85 -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

4 7

[armedbear-devel] regarding ticket #87: input history for REPL
by Ville Voutilainen 03 Mar '10

03 Mar '10

We don't necessarily need to use jline for this, there's an utility called rlwrap that provides GNU Readline functionality for the wrapped application. I'm not sure about the availablity of rlwrap on windows, though.

5 4

[armedbear-devel] [PATCH] SYS:GETPID
by Tobias C. Rittweiler 03 Mar '10

03 Mar '10

The following patch adds SYS:GETPID which works by making the abcl wrapper shell script store the current PID as a system property. For some reason, I see the following behaviour: tcr@thaleron:~/src/from-upstream/abcl$ abcl-svn Armed Bear Common Lisp 0.19.0-dev Java 1.6.0_17 Sun Microsystems Inc. Java HotSpot(TM) Client VM Low-level initialization completed in 0.47 seconds. Startup completed in 1.099 seconds. Type ":help" for a list of available commands. CL-USER(1): (sys:getpid) Unable to autoload SYSTEM:GETPID tcr@thaleron:~/src/from-upstream/abcl$ I.e. the patch is not yet finished; I hope that it'll be clear what's missing to the more experienced ABCL hackers on the list. On Windows, (SYS:GETPID) will just return NIL. There may be some way to do similiar magic with batch files, but googling didn't reveal anything promising. -T.

2 1

[armedbear-devel] #P"SRC"
by Tobias C. Rittweiler 03 Mar '10

03 Mar '10

Could ABCL set up a #P"SRC:", or #P"SYS:SRC:" logical pathname to the source directory that was used for the build? -T.

2 5

[armedbear-devel] recording source file locations
by Alan Ruttenberg 03 Mar '10

03 Mar '10

Can anyone summarize what kinds of source information are recorded? Is source location for generic function methods recorded? Variables? Constants? Stuctures? I'd like to extend source recording for functions defined interactively in slime as well, if I can understand what needs to be done on the abcl side. I could hunt around the source but figured I'd ask in case someone has thought of this recently. I'm losing in slime most of the time I meta-point things. On another debugging front, is it possible to get local variables for functions that are interpreted, in the context of an exception? I understand it's more difficult for compiled functions. -Alan

3 3

[armedbear-devel] COMPILE-SYSTEM and file dependencies
by Tobias C. Rittweiler 03 Mar '10

03 Mar '10

How much of a full CL is available for COMPILE-SYSTEM? Have you contemplated using (perhaps a stripped down version of) ASDF for specifying the exact dependencies for the *.lisp files? Getting that right in a descriptive manner is important as the system grows otherwise you end up with a mess like in SBCL where a mere mortal has no idea what in the build may break if you change something. -T.

1 0

[armedbear-devel] tentative patch: extensible sequences (following the same protocol as SBCL)
by Alessio Stalla 02 Mar '10

02 Mar '10

Greetings everyone, I'm happy to announce that I have a preliminary version of user-extensible sequences working on ABCL, following the protocol proposed and implemented by Christophe Rhodes on SBCL ("User-extensible sequences in Common Lisp", http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.65.1604&rep=rep1&t…) This includes: - the possibility for the user to write subclasses of CL:SEQUENCE - all functions operating on sequences have a corresponding generic function in the SEQUENCE package that is called on user-defined sequence types, and for which the user can write methods to implement his/her custom sequences - make-sequence works with user-defined sequences (using sequence:make-sequence-like as in SBCL) - mop::class-prototype has been added (as a tiny wrapper around mop::allocate-instance) - iterating over user-defined sequences integrated with LOOP (untested, but should work as our loop implementation is derived from CMUCL like SBCL's) - MAP and MAP-INTO should work unchanged limitations/things missing wrt. SBCL (that I know of): - no integration with DOSEQUENCE - to use extensible sequences you must explicitly (require :extensible-sequences) in advance - much less attention to precise sequence type information (but probably my patch doesn't improve nor worsen the situation before it) the patch doesn't seem to break any new ANSI tests; however I've tested the extensible sequences proper very lightly, and I don't consider the patch ready for trunk yet. My long-term goal is to use the new extensible sequences support to make Java collections be Lisp sequences. That should include Clojure collections as well, since afaik they implement the Collection API. If anyone has comments or critiques, or wants to help, you're welcome. Cheers, Alessio

2 3

[armedbear-devel] Synthetic Method Removal
by dmiles＠users.sourceforge.net 02 Mar '10

02 Mar '10

This is the .patch file that removes synthetic access to private fields/constructors and methods. Its intention is to make stack traces easier to read. And will have a miniscule speedup. And shrink classfile sizes 1-4%

1 0

[armedbear-devel] Unfair fresh-line.5 ANSI-TEST?
by dmiles＠users.sourceforge.net 01 Mar '10

01 Mar '10

Fresh-line.5 is a when we compare the output string againt a string read from the file.. this means the test is contigent on the line ending style of ABCL matching what SVN checkout did. (deftest (let (result) (values (with-output-to-string (s) (write-char #\Space s) (setq result (list (multiple-value-list (notnot-mv (fresh-line s))) (multiple-value-list (fresh-line s)) (multiple-value-list (fresh-line s))))) result)) " " ((t) (nil) (nil))) I am thinking the compared to litteral needs to be a constant programmatily contructed. Such as a write-char #\Space + write-char #\Newline Any thoughts of patch ideas for the ansi-tests?

1 0