armedbear-devel August 2010

armedbear-devel@common-lisp.net

11 participants
20 discussions

[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

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel August 2010