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