OK, Sounds like a nice afternoon project. Here's a patch that does what I think you're asking in FaslReader and LispReader.
But I ran into some trouble testing the changes. Following the instructions at http://common-lisp.net/project/armedbear/contributing.shtml I end up with an OutOfMemoryError when running both test.ansi.interpreted and test.ansi.compiled
Is there an enviroment variable that needs to be set to get these to run? I can make it work by putting <jvmarg value="-Xmx500M"> lines in build.xml, which I've attached as a second patch.
When I ran the tests after I made the change, I got one additional error when running test.ansi.interpreted: PRINT.BACKQUOTE.RANDOM.14. I've also attached the error. I can't figure it out. I eventually decided that a 'random' test might give a different result if I run it again ... so I ran it again (and again and again) ... and the error did not happen again. So I now suspect that my patch does not introduce any new errors, but that PRINT.BACKQUOTE.RANDOM.14 fails randomly from time to time.
Cheers,
-david k.
On Sun, Apr 11, 2010 at 1:26 AM, Erik Huelsmann ehuels@gmail.com wrote:
Yesterday Ville and I dedicated some time to the consolidation of copy/paste code and unnecessary virtual methods.
There's quite a bit of copy/paste code in ABCL. A good example are LispReader, FaslReader and Stream.java. FaslReader had a number of functions which were *exactly* equal to functions in LispReader. A number of functions contained the same logic, but used different readtables. The same applies to functions in Stream.java where functions were declared twice - once with a faslRead* prefix and once with a read* prefix.
The solution is - in this case, of course - to abstract the code from the readtable to be used. In other places the reasons for copy/pasting will be different.
If you're lurking at this list, thinking of contributing but you don't know how: this is a much appreciated way to help out!
We try to reduce the number of (copy/pasted) lines of code in ABCL; not at the expense of functionality, but as a way to ensure consistent maintenance in the future.
Still no idea where to start? I left some remaining work in LispReader.java and FaslReader.java where there is more copy/pasted code. My idea is that the common bits get moved to Stream.java, using the ReadtableAccessor class to abstract from the readtables themselves.
Looking forward to your contributions!
Bye,
Erik.
armedbear-devel mailing list armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel