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

[armedbear-devel] json-rpc?
by Axel Rauschmayer 27 Apr '11

27 Apr '11

I think ABCL would make an excellent Ajax server. As such, it would have to support json-rpc. Any suggestions as to how to make this happen? The first part is obviously the server, where the two choices that I can see are Hunchentoot and a servlet container such as Tomcat. In the latter case, I would expect to use a technique like abcl-web (which seems a little bit complicated, but doable). The second part is the JSON parsing. How would I do that? Via CL-JSON? Via Yason? Via a Java library? Sorry for these newbie questions. I’m just getting started with Common Lisp and ABCL. Thanks, Axel -- Axel.Rauschmayer(a)ifi.lmu.de http://www.pst.ifi.lmu.de/~rauschma/

4 10

[armedbear-devel] is there a good method to read/write java byte arrays?
by David Kirkman 01 Dec '10

01 Dec '10

Does anybody know of a good way to serialize lisp objects into java byte arrays? I've got a method that almost works, but if anybody has a better/canonical way of doing this I'd love to know! I've been trying to use cl-store, outputting to a stream I create with sys::%make-byte-array-output-stream, and then getting the byte array with sys::%get-output-stream-bytes. I've only been using abcl for a few days, and I found those functions by grepping through the sources, so I apologize if I'm inviting trouble by messing around with functions you never meant users to play with. Anyway, the output works fine. But I can't find the equivalent of sys::%make-byte-array-output-stream to create an input stream, so I attempted to make my own (defun make-byte-array-input-stream (bytes) (let ((bis (jnew (jconstructor "java.io.ByteArrayInputStream" "[B") bytes))) (jnew (jconstructor "org.armedbear.lisp.Stream" "java.io.InputStream") bis))) This almost seems to work, but if I try to use it I get a java exception and a (very long) java stack trace. I put a copy of the stack trace at the end of this message. Here is an expression which will produce the problem in abcl-18.1 (let ((outbytes (with-open-stream (stream (sys::%make-byte-array-output-stream)) (write-byte 101 stream) (sys::%get-output-stream-bytes stream)))) ;; now open the byte array as an input stream (with-open-stream (stream (make-byte-array-input-stream outbytes)) ;; all works fine until here (read-byte stream))) I don't need to read the stream, asking for the element type of the input stream is enough to cause trouble ... (let ((outbytes (with-open-stream (stream (sys::%make-byte-array-output-stream)) (write-byte 101 stream) (sys::%get-output-stream-bytes stream)))) (with-open-stream (stream (make-byte-array-input-stream outbytes)) (stream-element-type stream))) I can fix the problem and make my code work, but I have to change Stream.java to make it work. I added elementType = UNSIGNED_BYTE_8; to the initAsBinaryInputStream(InputStream in) method. I did this because the stack trace suggested that the problem was stream_element_type.execute() was returning null. Anyway, that fixes the problem, and I'm happily serializing/deserializing lisp objects to a Berkeley DB ... so I guess I'm happy! But I don't know how rational that fix is, because I don't really know how Stream is supposed to work. I suspect that my 'fix' probably breaks something else that I'm just not using yet. Any ideas? Thanks, -david k. Here's the first few lines of the stack trace ... CL-USER(2): Debugger invoked on condition of type SIMPLE-TYPE-ERROR: java.lang.NullPointerException at org.armedbear.lisp.Primitives$49.execute(Primitives.java:795) at org.armedbear.lisp.Symbol.execute(Symbol.java:781) at org.armedbear.lisp.LispThread.execute(LispThread.java:579) at org.armedbear.lisp.print_8.execute(print.lisp:127) at org.armedbear.lisp.Symbol.execute(Symbol.java:781) at org.armedbear.lisp.LispThread.execute(LispThread.java:579) at org.armedbear.lisp.print_14.execute(print.lisp:279) ... (and it ends with) at org.armedbear.lisp.AutoloadedFunctionProxy.execute(AutoloadedFunctionProxy.java:139) at org.armedbear.lisp.Symbol.execute(Symbol.java:760) at org.armedbear.lisp.LispThread.execute(LispThread.java:546) at org.armedbear.lisp.top_level_51.execute(top-level.lisp:415) at org.armedbear.lisp.AutoloadedFunctionProxy.execute(AutoloadedFunctionProxy.java:139) at org.armedbear.lisp.LispThread.execute(LispThread.java:546) at org.armedbear.lisp.Interpreter.run(Interpreter.java:310) at org.armedbear.lisp.Main$1.run(Main.java:50) at java.lang.Thread.run(Thread.java:613) READ-BYTE: unsupported element type Debugger invoked on condition of type ERROR: Caught java.lang.NullPointerException. Restarts: 0: TOP-LEVEL Return to top level.

3 14

[armedbear-devel] [PATCH] Eliminate duplicate lookups in JHandler
by Mario Lang 09 Nov '10

09 Nov '10

Hi. A simple thing, but I spotted it during reading of the code. Index: src/org/armedbear/lisp/JHandler.java =================================================================== --- src/org/armedbear/lisp/JHandler.java (revision 12738) +++ src/org/armedbear/lisp/JHandler.java (working copy) @@ -66,21 +66,22 @@ public static void callLisp (String s, Object o, String as[], int ai[]) { if (table.containsKey(o)) { - Map<String,Entry> entryTable = (Map<String,Entry>)table.get(o); + Map<String,Entry> entryTable = (Map<String,Entry>)table.get(o); if (entryTable.containsKey(s)) { - Function f = ((Entry)entryTable.get(s)).getHandler(); - LispObject data = ((Entry)entryTable.get(s)).getData(); - Fixnum count = ((Entry)entryTable.get(s)).getCount(); - Fixnum[] lispAi = new Fixnum[ai.length]; + final Entry entry = entryTable.get(s); + final Function f = entry.getHandler(); + final LispObject data = entry.getData(); + final Fixnum count = entry.getCount(); + final Fixnum[] lispAi = new Fixnum[ai.length]; for (int i = 0; i < ai.length; i++) { lispAi[i] = Fixnum.getInstance(ai[i]); } - LispObject lispAiVector = new SimpleVector(lispAi); - SimpleString[] lispAs = new SimpleString[as.length]; + final LispObject lispAiVector = new SimpleVector(lispAi); + final SimpleString[] lispAs = new SimpleString[as.length]; for (int i = 0; i < as.length; i++) { lispAs[i] = new SimpleString(as[i]); } - LispObject lispAsVector = new SimpleVector(lispAs); + final LispObject lispAsVector = new SimpleVector(lispAs); LispObject[] args = new LispObject[] //FIXME: count -> seq_num { data, new JavaObject(o), lispAiVector, lispAsVector, internKeyword(s), count }; f.execute(args); -- CYa, ⡍⠁⠗⠊⠕

2 1

[armedbear-devel] failure to compile big files
by Carlos Ungil 19 Oct '10

19 Oct '10

Dear ABCL developers, trying to "compile-file" the following fragment of code using the latest release results in an error "s2 argument 32778 out of 16-bit signed range." ----------------------------------------------------- (defmacro many-functions (n) (append '(progn) (loop for i from 1 to n collect `(defun ,(intern (format nil "TEST~A" i)) () (print ,i))))) (many-functions 1525) ----------------------------------------------------- There are no problems with 0.20 (even for much bigger values of the parameter, i.e. bigger output files). I encountered the problem with a file containing several calls to the macro def-java-class in Jfli. It took me some time to discover that splitting the file in two was enough to make the problem go away... This is not a critical bug (it's usually easy to reorganize the code to ensure the files are small enough), but you might want to look at it. Cheers, Carlos

3 4

[armedbear-devel] CLOS thread safety
by Erik Huelsmann 03 Oct '10

03 Oct '10

Hi David, > Are there any known thread safety issues with CLOS? I've been > getting some weird MOP errors that I made go away by redefining > slot-value such that it has to acquire a global lock before it can do > anything. I assume that the problem is in my code: but the threads > that are executing when I get the failures share no code (or > variables), and every time the errors pop up slot-value is on the > callstack someplace. Well, there have not been any specific threading issues mentioned. Over two years ago, back when I started doing ABCL, there were threading issues which looked like threading issues in CLOS. They turned out to be threading issues in the compiler though. Having said that, I see there have not been taken synchronization measures on a high level: there are no locks and threads:synchronized-on blocks in clos.lisp. There are some synchronized calls on the Java side; I'm not sure the low-level protection is good enough to maintain consistency though. Can you share some examples which show the issues here? Adding thread-safety to clos.lisp - in specific, targeted places - should be well doable. Bye, Erik.

5 15

Re: [armedbear-devel] [armedbear-cvs] r12908 - trunk/abcl/examples/pure-lisp-to-java
by Erik Huelsmann 31 Aug '10

31 Aug '10

Hi Ville, You're aware it's 2010 by now? :-) Bye, Erik. On Mon, Aug 30, 2010 at 7:57 PM, Ville Voutilainen < vvoutilainen(a)common-lisp.net> wrote: > Author: vvoutilainen > Date: Mon Aug 30 13:57:43 2010 > New Revision: 12908 > > Log: > Add an example for using a java class with CLASSPATH, invoking java > functions from lisp code and finding the java class automagically > as it's in CLASSPATH. > > > Added: > trunk/abcl/examples/pure-lisp-to-java/ > trunk/abcl/examples/pure-lisp-to-java/Main.java (contents, props > changed) > trunk/abcl/examples/pure-lisp-to-java/README > trunk/abcl/examples/pure-lisp-to-java/lispfunctions.lisp (contents, > props changed) > > Added: trunk/abcl/examples/pure-lisp-to-java/Main.java > > ============================================================================== > --- (empty file) > +++ trunk/abcl/examples/pure-lisp-to-java/Main.java Mon Aug 30 13:57:43 > 2010 > @@ -0,0 +1,39 @@ > +/* > + * Main.java > + * > + * Copyright (C) 2008 Ville Voutilainen > + * $Id$ > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License > + * as published by the Free Software Foundation; either version 2 > + * of the License, or (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, > USA. > + */ > + > +import org.armedbear.lisp.*; > + > +public class Main > +{ > + /** > + * This example creates an Interpreter instance, loads our > + * lisp code from a file and then looks up a function defined > + * in the loaded lisp file and executes the function. > + * > + * The function takes a single parameter and invokes a java method > + * on the object provided. We provide our Main object as the > parameter. > + * > + */ > + public static int addTwoNumbers(int a, int b) > + { > + return a + b; > + } > +} > > Added: trunk/abcl/examples/pure-lisp-to-java/README > > ============================================================================== > --- (empty file) > +++ trunk/abcl/examples/pure-lisp-to-java/README Mon Aug 30 13:57:43 > 2010 > @@ -0,0 +1,38 @@ > +ABCL Examples Building and Running Instructions > +=============================================== > + > +To compile > + > + cmd$ javac -cp ../../dist/abcl.jar Main.java > + > +where the "../../../dist/abcl.jar" represents the path to your > +abcl.jar file, which is built via the Ant based build. This path > +could be slightly different depending on how the system was > +constructed, and possibly due to operating system conventions for > +specifying relative paths. However you resolve this locally, we'll > +refer to this as '$ABCL_ROOT/dist/abcl.jar' for the rest of these > +instructions. > + > +This compiles the Java source file "Main.java" into a JVM runtime or > +class file named "Main.class". > + > +To run the example (Main.class for example) from a Unix-like OS use: > + > + cmd$ export CLASSPATH=. > + cmd$ $ABCL_ROOT/abcl > + > +then, in abcl repl, use: > +(load "lispfunctions") > +(void-function) > + > +or in Windows use: > + > + cmd$ set CLASSPATH=. > + cmd$ $ABCL_ROOT/abcl > + > +then, in abcl repl, use: > +(load "lispfunctions") > +(void-function) > + > +This will result in the Main class being found from the CLASSPATH, and you > +can invoke the functions of the Main class from lisp code. > > Added: trunk/abcl/examples/pure-lisp-to-java/lispfunctions.lisp > > ============================================================================== > --- (empty file) > +++ trunk/abcl/examples/pure-lisp-to-java/lispfunctions.lisp Mon Aug 30 > 13:57:43 2010 > @@ -0,0 +1,34 @@ > +;;; lispfunctions.lisp > +;;; > +;;; Copyright (C) 2008 Ville Voutilainen > +;;; $Id$ > +;;; > +;;; This program is free software; you can redistribute it and/or > +;;; modify it under the terms of the GNU General Public License > +;;; as published by the Free Software Foundation; either version 2 > +;;; of the License, or (at your option) any later version. > +;;; > +;;; This program is distributed in the hope that it will be useful, > +;;; but WITHOUT ANY WARRANTY; without even the implied warranty of > +;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > +;;; GNU General Public License for more details. > +;;; > +;;; You should have received a copy of the GNU General Public License > +;;; along with this program; if not, write to the Free Software > +;;; Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, > USA. > + > +; we need to get the > +; 1) class (Main) > +; 2) classes of the parameters (int) > +; 3) method reference (getting that requires the class > +; of our object and the classes of the parameters > + > +; After that we can invoke the function with jcall, > +; giving the method reference, the object and the parameters. > +; The result is a lisp object (no need to do jobject-lisp-value), > +; unless we invoke the method > +; with jcall-raw. > +(defun void-function () > + (let* ((result (jstatic "addTwoNumbers" "Main" 2 4))) > + (format t "in void-function, result of calling addTwoNumbers(2, 4): > ~a~%" result))) > + > > _______________________________________________ > armedbear-cvs mailing list > armedbear-cvs(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-cvs >

2 1

[armedbear-devel] ABCL bug report: defstruct :include with :conc-name
by Juliusz Chroboczek 26 Aug '10

26 Aug '10

Hi. The following bug in abcl breaks CL-Yacc. Consider the following: (defstruct item a) (defstruct (item1 (:include item) (:conc-name item-)) b) (defun abcl-bug () (item-a (make-item :a 'a))) According to the last paragraph of the description of the description of :conc-name in the defstruct section of the CLHS, this is legal. However, abcl says: ABCL-BUG(6): (abcl-bug) #<THREAD "interpreter" {108F8E0}>: Debugger invoked on condition of type SIMPLE-TYPE-ERROR The value #<ABCL-BUG::ITEM {537935}> is not of type ABCL-BUG::ITEM1. Restarts: 0: TOP-LEVEL Return to top level. [1] ABCL-BUG(7): Regards, Juliusz

1 0

[armedbear-devel] Can't use ABCL to host SNePS
by David Zhang 26 Aug '10

26 Aug '10

Hello! I just tried to use ABCL to load SNePS, but can't make it anyway. There's always an error message saying "#<THREAD "interpreter" {E1E567}>: Debugger invoked on condition of type PACKAGE-ERROR Package "SNEPS" not found." How can I pass it though? Awaiting David Zhang

2 2

[armedbear-devel] how to load fasls from jar via asdf
by Robert Dodier 26 Aug '10

26 Aug '10

Hi, After looking through various web pages, emails, etc, I gather it's possible to load all the fasls for some program from a jar via asdf. However, I tried the obvious things and I couldn't get it to work. Can someone explain how it's supposed to work? I have all the fasls for Maxima in a subdirectory. (require 'asdf) (asdf:operate 'asdf:load-op :maxima) has the desired effect. So far, so good. I put all the fasls in a jar (either in the subdirectory or without the subdirectory), and then (pushnew "jar:file:/path/to/my.jar" asdf:*central-repository*) But when I try (require 'asdf) (asdf:operate 'asdf:load-op :maxima) I eventually get a message about trying to find the first Lisp file mentioned in the maxima.asd, which I'm pretty sure it didn't find the fasls. Can someone explain how loading all of the fasls from a jar is supposed to work? Or any other method of conglomerating fasls; for example, is it possible to combine multiple fasls into one? Thanks for any info, Robert Dodier

3 5

Re: [armedbear-devel] java/abcl hello-world example
by Robert Dodier 22 Aug '10

22 Aug '10

David, have you seen this page? http://common-lisp.net/project/armedbear/doc/abcl-user.html It has some simple examples of calling from Java to ABCL and vv. Hope this helps, Robert Dodier

3 2

[armedbear-devel] java/abcl hello-world example
by David Dreisigmeyer 21 Aug '10

21 Aug '10

Hi, I'm new to both abcl and java. I was wondering if someone could provide a "hello world" example (the more details the better) where I write the program in java, create a jar file, and then use that from the repl? An example of what I'd like to do using Clojure is (see http://pramode.net/clojure/2010/05/01/clojure-java-interop/ ): 1) counter.java: package demo public class counter{ int c = 0; public void increment() { ++c; } public int get() { return c; } public static int sqr(int x) { return x*x; } } 2) Using in Clojure: ; To get this to run in SLIME do the following (where we're in demo/ to start): ;; ;; > javac counter.java ;; > cd ../ ;; > jar cvf demo.jar demo ;; > mv demo.jar lib/ ;; ;; Remember we were in demo/ to start. The directory lib/ is created when we ;; run lein new. So now we have the jar file we created placed with all of the ;; other jar files on the classpath. So we can continue: ;; ;; > lein swank ;; ;; Now start up emacs and M-x slime-connect (accepting 127.0.0.1 and 4005 defaults). ;; At the repl in emacs do ;; ;; user> (import '(demo counter)) ;; user> (counter/sqr 4) Thanks, I really appreciate any help! -Dave

1 0

[armedbear-devel] jcall jmethod java.lang
by David Dreisigmeyer 20 Aug '10

20 Aug '10

Hi, I don't understand why this doesn't work: (jcall (jmethod "java.lang.Math" "sqrt") 4.0) The error I get is: No such method: java.lang.Math.sqrt() Also, this works: CL-USER> (jcall (jmethod "java.lang.Float" "intValue") 4.0) 4 but when I try this: (jcall (jmethod "java.lang.Float" "compare") 4.0 5.0) I get: No such method: java.lang.Float.compare() I'm not sure if this is the correct forum for these questions. If there's a better place to ask them let me know. Thanks, -Dave

2 4

[armedbear-devel] abcl-contrib.jar
by David Dreisigmeyer 20 Aug '10

20 Aug '10

I downloaded abcl-src-0.21.0 from http://common-lisp.net/project/armedbear/. I ran: ant -f build.xml abcl.conrtib Without creating the directory ./contrib/asdf-install/ 'by hand' the install would not run to completion, complaining that /contrib/asdf-install/ was not a valid directory. -Dave

2 3

[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