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

[armedbear-devel] Maxima compilation profiling results
by Erik Huelsmann 14 Aug '10

14 Aug '10

To be sure our generic class writer isn't too much of a performance hit when we move it to trunk, I've run a profiling session compiling Maxima sources. The outcome is here: http://paste.lisp.org/display/113517. Conclusion: the old "lets store .cls files before we create a fasl out of them" is still the performance bottleneck (on Windows at least). So, the good thing is that the change in the generator doesn't show up in the list of hot spots (not to be confused with HotSpot). Bye, Erik.

1 0

[armedbear-devel] Long form of D-M-C
by Mark Evenson 11 Aug '10

11 Aug '10

Unbelievably, I seem to have [hacked the version of long DEFINE-METHOD-COMBINATION from Sacla/XCL o pass the long form D-M-C ANSI tests][1]. I'm slightly incredulous that my patch works, because I don't totally understand the code I've integrated here. In particular, neither method combinations which use CALL-METHOD with the optional NEXT-METHOD-LIST, nor use of the MAKE-METHOD macro will work, although their implementation would not be terribly hard if I have the basics correct. An aside: The more I work with our CLOS, the more I want to re-implement it from scratch, or at least separate the base out from the AMOP as a starting point to clean it up. Maybe this wouldn't help as much as I would hope, but reading clos.lisp is an exercise in frustration that doesn't end in admiration for clarity. So, I hereby solicit additional source of tests or failing test cases. I can't promise rapid response to fix things, but I will get to them eventually. If this work doesn't turn out to be too broken, I might commit to trunk in the next few days if the other developers acquiesce, with the rational that an incomplete long D-M-C implementation is better than none. [1]: http://trac.common-lisp.net/armedbear/attachment/ticket/66/run-d-m-c-201008… -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

Re: [armedbear-devel] [armedbear-cvs] r12882 - branches/generic-class-file/abcl/src/org/armedbear/lisp
by Ville Voutilainen 09 Aug '10

09 Aug '10

On 9 August 2010 15:23, Erik Huelsmann <ehuelsmann(a)common-lisp.net> wrote: > Author: ehuelsmann > Date: Mon Aug 9 08:23:20 2010 > New Revision: 12882 > Log: > Move the u2, s1 and s2 helper functions to jvm.lisp. Could you please give these functions a bit saner names as the next step? :)

3 4

[armedbear-devel] Automatic grovelling for (lisp-defined) autoloads
by Erik Huelsmann 05 Aug '10

05 Aug '10

Today, I had an idea: what if we were to find all symbols which are being declared EXPORTED during the ABCL system compilation in each file? Then, we'd generate a list of all exported symbols and the files they are exported from. The given file would be included in our JAR. At boot-time, the file would be read and the appropriate autoloaders would be installed. The consequence would be that we would not need to maintain 'autoloads.lisp' anymore. It would require us to think better about which symbols need to be in the export lists, though. (I guess that's a good thing in the long run, though.) I'm thinking about groveling macro-expanded forms, because that would allow us to grovel clos.lisp and detect many of its exported symbols. Anybody up for the task? (I'm expecting it to be 4 or 5 evenings of work.) Bye, Erik.

2 1

[armedbear-devel] Ideas about the integration of WITH-CODE-TO-METHOD
by Erik Huelsmann 04 Aug '10

04 Aug '10

The other day, I started to write a mail about integrating the generic class file generator into pass2 in more detail. The main idea being that the macro WITH-CODE-TO-METHOD needed to be used to do the main integration between the generator and pass2. Although I still think the macro is the ticket, I'm refining my ideas about where the macro belongs and why. I'll take some time to write down here what I think the architectural separation between jvm-class-file and pass2 should be. My realization today was that the class file generator should really be independent from whatever source the methods and their instructions are coming from. The same should be true for the opcode-resolvers and other parts. Given the above, I think that concepts as 'current method', 'current code attribute', 'current class file' etc, are really concepts of pass2, not of the class file generator, which doesn't deal with "catching code" itself. As a consequence, I think the specials *code*, *current-code-attribute*, *pool* and *this-class* as well as the to-be-created specials *method* and *class-file* all belong to pass2 managing its submodules. When this is the role of pass2 and its specials, the need to remove the pool-* methods (for example) from pass2 would be less obvious. What still remains is that the resolvers should be side-effect free, meaning that they can't be used anymore to resolve their arguments into pool methods/field references/etc. When this has happened, they can be moved to their own file (or module if you will), but that's an issue to be addressed later. They *can* be used to check instruction arguments, as they are today. Hmm. I hope the above makes sense, or at least provides some material for further discussion. Bye, Erik.

1 0

[armedbear-devel] Ideas about the integration of WITH-CODE-TO-METHOD
by Erik Huelsmann 04 Aug '10

04 Aug '10

The other day, I started to write a mail about integrating the generic class file generator into pass2 in more detail. The main idea being that the macro WITH-CODE-TO-METHOD needed to be used to do the main integration between the generator and pass2. Although I still think the macro is the ticket, I'm refining my ideas about where the macro belongs and why. I'll take some time to write down here what I think the architectural separation between jvm-class-file and pass2 should be. My realization today was that the class file generator should really be independent from whatever source the methods and their instructions are coming from. The same should be true for the opcode-resolvers and other parts. Given the above, I think that concepts as 'current method', 'current code attribute', 'current class file' etc, are really concepts of pass2, not of the class file generator, which doesn't deal with "catching code" itself. As a consequence, I think the specials *code*, *current-code-attribute*, *pool* and *this-class* as well as the to-be-created specials *method* and *class-file* all belong to pass2 managing its submodules. When this is the role of pass2 and its specials, the need to remove the pool-* methods (for example) from pass2 would be less obvious. What still remains is that the resolvers should be side-effect free, meaning that they can't be used anymore to resolve their arguments into pool methods/field references/etc. When this has happened, they can be moved to their own file (or module if you will), but that's an issue to be addressed later. They *can* be used to check instruction arguments, as they are today. Hmm. I hope the above makes sense, or at least provides some material for further discussion. Bye, Erik.

1 0

[armedbear-devel] Progress on generic-class-file branch
by Erik Huelsmann 01 Aug '10

01 Aug '10

Today, updated tests were committed to the branch which allow it to generate ABCL function classes, load them and execute them. That's exciting news! It basically means that the branch is good enough for anybody to write their own lisp code to create new classes (whether or not they are ABCL functions doesn't really matter). So, where does that leave us in the bigger picture? Well, even though it's now possible to generate function classes with your own lisp code, the generator hasn't been fully integrated into the compiler. The bit that I did integrate is the use of the CLASS-NAME structure for identification of classes and class references. Next to that, I adjusted the method invoking emitters to use different pool functions for creation of the method refs. So, what remains to be done? * A test needs to be created which tests nested use of WITH-CODE-TO-METHOD, making sure that register allocation in the nested function generator is correctly transferred to the outer block (more on that below) * The pool handling needs to be switched over to the new pool functions Possibly, there's a quick-path here by changing the pool-* functions in p2 to forward to the ones in j-c-f (jvm-class-file). * The exception handler creation needs to be adjusted to use the new CODE-ADD-EXCEPTION-HANDLER function * Changing the compiler away from *code* and *static-code* toward WITH-CODE-TO-METHOD * Clean up: removal of unused functions (after integration) [especially those currently conflicting] * Documentation: Not all functions in the j-c-f file are documented. All functions except the internal ones (starting with %) should be documented. * API declaration None of the functions in the file are currently exported or autoloaded (unless by accident). In order to help others to create their own classes, we should probably export (some) of the functions, for runtime-class to build upon. It'd be my preference to do the integration work on the branch, unless we find a strategy to keep trunk stable while we change its class file generator - one of the most critical components. When all the above has been completed, I see the following improvements to be made to the code we generate: * multiple methods to handle &optional processing, instead of fastProcessArgs, if the method has less than 8 parameters in total * moving initialization of static variables to a static {} block, instead of in the (re-runnable) constructor; besides being a nice improvement, this is actually a correctness issue: our current constructors call Lisp.recall(), which can't be called more than once for a given string value * Reduction of the number of function classes generated: non-inlined local functions generated as methods in the function class * Re-introduction of XEPs (External entry points): SBCL uses a paradigm where functions which are hard-linked together, use internal entry points: they flatten keywords, pass the right ([un]boxed) values, etc, skipping the "parameter discovery" checks. XEPs discover the right parameters and call the internal entry point. Apart from that, we should (finally) be able to implement runtime-class without depending on ASM. Now, there's the explanation of what should be tested in the test-to-be-written: WITH-CODE-TO-METHOD catches the output from EMIT. Sometimes, pass2 wants to output a small block of code to the constructor method while in the midst of writing an "execute" method. Even fewer times, but in general quite thinkable, you could see the following nesting with output to two methods, method1 and method2: (WITH-CODE-TO-METHOD (file method1) .... (WITH-CODE-TO-METHOD (file method2) .... (WITH-CODE-TO-METHOD (file method1) ...))) The WITH-CODE-TO-METHOD macro provisions for this scenario by saving the values of the compiler-specials to the Code attribute. However, currently, nothing checks if the code works correctly (ie saves enough specials). The test should establish that. Ok. Sorry for the lengthy e-mail :-) Bye, Erik.

1 0

[armedbear-devel] [ANNOUNCE] ABCL 0.21.0 released
by Alessio Stalla 28 Jul '10

28 Jul '10

On behalf of the developers of ABCL (Armed Bear Common Lisp) I'm glad to be able to announce the 0.21.0 release. ABCL is a Common Lisp implementation implemented in Java and running on the JVM, featuring both an interpreter and a compiler. The compiler targets the JVM directly meaning that its output is runnable JVM bytecode. The fact that ABCL is written in Java allows for relatively easy embedding in larger applications. For integration with existing applications ABCL implements Java Specification Request (JSR) 223: Java scripting API. This release features - among other things - a fix for storing literal pathnames in FASLs in an OS-independent way, and enhancements in the CLOS MOP and in Java interop features. You can find the full release notes at: http://common-lisp.net/project/armedbear/release-notes-0.21.shtml and the list of changes at: http://trac.common-lisp.net/armedbear/browser/trunk/abcl/CHANGES If you have questions regarding use or licensing, or you find issues, please report back to the development list: armedbear-devel at common-lisp dot net Source distribution archives can be downloaded in ZIP or gzipped tar form: http://common-lisp.net/project/armedbear/releases/abcl-src-0.21.0.tar.gz http://common-lisp.net/project/armedbear/releases/abcl-src-0.21.0.zip Signatures are available under: http://common-lisp.net/project/armedbear/releases/abcl-src-0.21.0.tar.gz.asc http://common-lisp.net/project/armedbear/releases/abcl-src-0.21.0.zip.asc In addition, binaries are also available: http://common-lisp.net/project/armedbear/releases/abcl-bin-0.21.0.tar.gz http://common-lisp.net/project/armedbear/releases/abcl-bin-0.21.0.zip With associated signatures: http://common-lisp.net/project/armedbear/releases/abcl-bin-0.21.0.tar.gz.asc http://common-lisp.net/project/armedbear/releases/abcl-bin-0.21.0.zip.asc

1 0

[armedbear-devel] DocString Final
by Matt Seddon 25 Jul '10

25 Jul '10

Attached is the final patch for the DocString annotation. It contains documentation for all the functions in Java.java, the functions in LispThread.java, and some miscellaneous others. ETAGs support is also implemented, allowing either ### or @DocString(name="<name>" ...) to name tags. If you find yourself looking at a function with ### instead of @DocString, feel free to update it ;) Awaiting approval, if everyone is happy I will close ticket #99. Regards, Matt

1 1

[armedbear-devel] New patch for latin1 input
by Ville Voutilainen 19 Jul '10

19 Jul '10

This patch contains the same fix for RandomAccessCharacterFile and DecodingReader. The obvious repetition should be refactored away, but this patch should be functionally complete. Holler for any concerns.

1 0