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

[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

[armedbear-devel] Fix for being able to read latin1 files with scandinavian characters in them
by Ville Voutilainen 19 Jul '10

19 Jul '10

After a lot of headbanging, this patch seems to work. It does one sort of manual replacing, but I've tested with all sorts of evil test data and it seems to survive those, and it still parses valid utf-8 multibyte correctly.

1 0

[armedbear-devel] Working toward a release: objections to branching tomorrow at the latest?
by Erik Huelsmann 17 Jul '10

17 Jul '10

Hi, The time has already past that we should have branched for stabilization of the new release. However, with the recent flurry of activity, I don't want to make the branching decision alone; hence my question: Are we ready for branching? Note: this does not necessarily mean that we need to create a release immediately after that, if we anticipate fixes, we can always backport. Bye, Erik.

1 0

[armedbear-devel] r12666 breaks ASDF compilation on Linux
by Alessio Stalla 17 Jul '10

17 Jul '10

I just tried abcl 0.20 with Snow, and compilation (done with asdf:compile-op) fails early with: Compilation failed: Not an absolute pathname #P"\\___jar___file___root___\\**\\*.*" r11664 works fine. Sorry that I didn't check before the release, I remembered checking it not much time ago but evidently I was wrong (r12666 is two weeks old). Alessio

5 24

[armedbear-devel] Fixing regressions in preparation for the next release
by Alessio Stalla 17 Jul '10

17 Jul '10

Hello everyone, the time for a new release is approaching, and we've found a few regressions that should be fixed before the release happens. With r12804 and r12805 I fixed a few bugs introduced by me lately and one introduced by Erik. Two more tests still fail with respect to 0.20: PATHNAMES-PRINT-AND-READ-PROPERLY and PRINT.PATHNAME.1. I think they are related with Mark's latest changes in how pathnames are printed; for example, #P(:type "txt") is now incorrectly printed as #P(":TYPE "txt")", which then can't be read back. Mark, can you check? If anyone has other outstanding bug reports or feature requests for the new release, I'd say this is the right time for telling :) Cheers, Alessio

2 2

[armedbear-devel] win32 fix for TAGS ant target
by Matt Seddon 17 Jul '10

17 Jul '10

Before I can start actually fixing the TAGS target, I figured making it run under win32 at all would help :) The problem is that with parallel="true", ant seems to send too many parameters to CreateProcess, which then sobs about error=87: the parameter is invalid. The attached patch addresses this issue by specifying maxparallel to prevent argument list overflow, and appending the results to the TAGS file incrementally. This results in two invokations to etags, rather than one. Does this behave as expected for you Mark? Cheers, Matt

3 6