Hi, I am new to ABCL and have a question to it's capabilities:My goal is to load an exsting part of a system coded in lisp into Java and to use the lisp code as basic library for a java application. Currently my approach is to load the lisp code with:Interpreter interpreter = Interpreter.createInstance();interpreter.eval("(load \"my-lisp-code.lisp\")");... So the lisp code must be present in the project every time it is running.Is there any chance to translate the lisp code to a Java source file by using ABCL? So it would not be necessary to provide the lisp code in the java application after it is translated once. Best regards Lukas
On Wed, Feb 16, 2011 at 10:33 AM, Lukas Georgieff <lukas.georgieff@hotmail.com> wrote:
Hi, I am new to ABCL and have a question to it's capabilities: My goal is to load an exsting part of a system coded in lisp into Java and to use the lisp code as basic library for a java application. Currently my approach is to load the lisp code with: Interpreter interpreter = Interpreter.createInstance(); interpreter.eval("(load \"my-lisp-code.lisp\")"); ... So the lisp code must be present in the project every time it is running. Is there any chance to translate the lisp code to a Java source file by using ABCL? So it would not be necessary to provide the lisp code in the java application after it is translated once.
Hello Lukas, ABCL does not translate Lisp source to Java source; you can compile your Lisp code to JVM bytecode, but you'll still have to load it with (load "my-compiled-code.abcl"), because only functions are compiled to classes, not top-level forms. You can provide a Java facade over the Lisp code/library, so that the API user is unaware of Lisp; but you'll have to do it yourself. One improvement that we eventually want to implement (actually, to restore and improve) is the ability for ABCL to generate a Java class with methods implemented in Lisp (more or less what Clojure does with gen-class, if you know it). With that feature, you'll still have to bundle your Lisp code with the Java application, but the loading of your code could be handled by the generated class. Keep in mind that you can bundle your Lisp code as resources inside the Jar of your application, so the end user won't see any extra files. Kind regards, Alessio
Lukas Georgieff <lukas.georgieff@hotmail.com> writes:
Hi,
I am new to ABCL and have a question to it's capabilities: My goal is to load an exsting part of a system coded in lisp into Java and to use the lisp code as basic library for a java application.
Currently my approach is to load the lisp code with: Interpreter interpreter = Interpreter.createInstance(); interpreter.eval("(load \"my-lisp-code.lisp\")"); ...
So the lisp code must be present in the project every time it is running. Is there any chance to translate the lisp code to a Java source file by using ABCL? So it would not be necessary to provide the lisp code in the java application after it is translated once.
Once compiled, the lisp code is provided as a .class file. Wouldn't that be enough? Why would you need the java source? Try: (compile-file "my-lisp-code.lisp") -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}.
On Wed, Feb 16, 2011 at 11:30 AM, Pascal J. Bourguignon <pjb@informatimago.com> wrote:
Lukas Georgieff <lukas.georgieff@hotmail.com> writes:
Hi,
I am new to ABCL and have a question to it's capabilities: My goal is to load an exsting part of a system coded in lisp into Java and to use the lisp code as basic library for a java application.
Currently my approach is to load the lisp code with: Interpreter interpreter = Interpreter.createInstance(); interpreter.eval("(load \"my-lisp-code.lisp\")"); ...
So the lisp code must be present in the project every time it is running. Is there any chance to translate the lisp code to a Java source file by using ABCL? So it would not be necessary to provide the lisp code in the java application after it is translated once.
Once compiled, the lisp code is provided as a .class file.
That's incorrect. It is provided as a distinct .abcl file for each .lisp file, which is a zip containing a text file (generated from the top-level forms in the .lisp file) + a .cls file for each function (top-level or non-inlined local) in the .lisp file. .cls files are in JVM class file format, but they're not loadable as-is because they don't obey the JVM naming conventions (they ought to be ending in .class and placed in a org/armedbear/lisp/ directory). What you *can* do is package .abcl files in a .jar file and use ASDF to load them with a single function call. Bye, Alessio
Alessio Stalla <alessiostalla@gmail.com> writes:
On Wed, Feb 16, 2011 at 11:30 AM, Pascal J. Bourguignon <pjb@informatimago.com> wrote:
Lukas Georgieff <lukas.georgieff@hotmail.com> writes:
Hi,
I am new to ABCL and have a question to it's capabilities: My goal is to load an exsting part of a system coded in lisp into Java and to use the lisp code as basic library for a java application.
Currently my approach is to load the lisp code with: Interpreter interpreter = Interpreter.createInstance(); interpreter.eval("(load \"my-lisp-code.lisp\")"); ...
So the lisp code must be present in the project every time it is running. Is there any chance to translate the lisp code to a Java source file by using ABCL? So it would not be necessary to provide the lisp code in the java application after it is translated once.
Once compiled, the lisp code is provided as a .class file.
That's incorrect. It is provided as a distinct .abcl file for each .lisp file, which is a zip containing a text file (generated from the top-level forms in the .lisp file) + a .cls file for each function (top-level or non-inlined local) in the .lisp file. .cls files are in JVM class file format, but they're not loadable as-is because they don't obey the JVM naming conventions (they ought to be ending in .class and placed in a org/armedbear/lisp/ directory). What you *can* do is package .abcl files in a .jar file and use ASDF to load them with a single function call.
I see. Thanks for the correction. -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}.
On 2/16/11 12:07 , Pascal J. Bourguignon wrote: […]
Once compiled, the lisp code is provided as a .class file.
That's incorrect. It is provided as a distinct .abcl file for each .lisp file, which is a zip containing a text file (generated from the top-level forms in the .lisp file) + a .cls file for each function (top-level or non-inlined local) in the .lisp file. .cls files are in JVM class file format, but they're not loadable as-is because they don't obey the JVM naming conventions (they ought to be ending in .class and placed in a org/armedbear/lisp/ directory). What you *can* do is package .abcl files in a .jar file and use ASDF to load them with a single function call.
To use more CL-like language: a file "test.lisp" has a FASL "test.abcl". Our FASL is a zip of the initialization code ('%%%._'), the classes our bytecode compiler emits ('%%%-nnn.cls') for each top-level form in the corresponding ('%%%.lisp') source file. The contents of the bootstraip ('%%%._') are executed when this FASL is (re)loaded. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
On Wed, Feb 16, 2011 at 5:23 PM, Mark Evenson <evenson@panix.com> wrote:
To use more CL-like language: a file "test.lisp" has a FASL "test.abcl". Our FASL is a zip of the initialization code ('%%%._'), the classes our bytecode compiler emits ('%%%-nnn.cls') for each top-level form in the corresponding ('%%%.lisp') source file. The contents of the bootstraip ('%%%._') are executed when this FASL is (re)loaded.
Replace "for each top-level form" with "for each function definition" and it's 100% correct ;) A.
participants (4)
-
Alessio Stalla -
Lukas Georgieff -
Mark Evenson -
Pascal J. Bourguignon