armedbear-devel

armedbear-devel@common-lisp.net

2 participants
1202 discussions

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

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel