armedbear-devel

armedbear-devel@common-lisp.net

1 participants
1200 discussions

Start a nNew thread

[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 03 Mar '10

03 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

[armedbear-devel] Changes to CHANGES
by Mark Evenson 28 Feb '10

28 Feb '10

I've updated the [CHANGES][1] file on trunk in preparation for the upcoming release. Erik asked me to write up my changes, but I took at stab at recapitulating everything as best I could interpret it. [1]: http://code.google.com/p/abcl-dynamic-install/source/detail?r=8a0bf88cca6dd… Deliberately missing from this summary: 1) Alessio's recent work on lambda inlining. In my opinion we have to address the bug Alan Ruttenberg has found or backout these changes before release. 2) Ville's work on string functions, as it's incomplete. And it was hard to understand from the commit messages if it is purely optimization or if it involves bug fixing as well. Anything else is something I missed. I've adopted a little more verbose format than previously, including references to svn changesets and tickets where possible. There are now three sections: "Features" which tries to summarize the features that would be interesting to end users "Fixes/Optimizations" summarizing all the fixes or optimizations that might prompt an end user to retry something that previously didn't work or was too slow, and "Other" which mostly summarizes changes to implementation details of interest to ABCL development. Comments (or direct changes in SVN) are welcome. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

6 14

[armedbear-devel] some questions about r12503
by Ville Voutilainen 22 Feb '10

22 Feb '10

The separate pathname matcher for jars looks odd to me. I'd expect the listing to give whatever it gives, and the matching condition in directory.lisp to filter it. Is jar filtering so different that it requires a different matcher? Same question applies to the wildcard matching, jar listing seems to do the wildcard matching in java, rather than in lisp? That's also different from the way directory listings are handled. The list-directory primitive sorely needs to be split into two functions (listJar and listDirectory), it's getting long-winded. That's not a high-priority issue, but we need to mind function length, it's a huge readability issue.

2 2

[armedbear-devel] commit r12491
by Ville Voutilainen 21 Feb '10

21 Feb '10

I object to this patch. We have previously rejected code that sprinkles jnews and jcalls all over directory.java. I believe the proper way to introduce jar support for DIRECTORY would be to do it in the list-directory primitive in Pathname.java. At any rate, if we don't want that and want to do the jar logic in directory.lisp, then fine, add whatever primitives you need for the bare minimum, but _don't_ implement it as lisp code that only calls java code. That makes no sense (*). (*) Yes, it may make sense for user code that has to call java. I don't, however, think it makes sense for abcl internals, or namely directory.lisp. It looks ugly as sin, and it prevents using the code in non-java environments, if such ever arrive. We have a design where lisp code calls primitives that provide the bare minimum support from the java side, I think we should stick to that design.

2 4

[armedbear-devel] TypeError woes
by Ville Voutilainen 21 Feb '10

21 Feb '10

The String constructor for TypeError doesn't result in the message string to be printed. That's because the message is never set anywhere. Condition will give the message in getMessage(), and TypeError.getMessage() will use that if non-null, but nothing sets it. I'll attach a patch that corrects this, but I don't want to commit it yet - it looks woefully incorrect to me. Is this really what we have to do in all Condition-extending classes? Set a protected member? We already set the formatControl, why does that not work?

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel