A couple of people wrote to me about porting Qi II to Clojure. What
are the specific gains/losses in using ABCL versus Clojure? We've had
several goes with ABCL without success so far. I have no axes to
grind on this matter btw.
Mark
On May 5, 8:03 pm, Mark Tarver <··········@ukonline.co.uk> wrote:
> A couple of people wrote to me about porting Qi II to Clojure. What
> are the specific gains/losses in using ABCL versus Clojure? We've had
> several goes with ABCL without success so far. I have no axes to
> grind on this matter btw.
>
> Mark
I've never used Clojure; I have been using almost only ABCL from the
past few months and I have even contributed some code to it. So take
what I say with a grain of salt, as I am quite certainly biased.
Language:
ABCL is a full CL (with a few bugs left wrt ANSI standard compliance,
and some de-facto standards - most notably MOP - missing or only
partially implemented). Clojure is a young language defined by its
implementation, so it's more subject to change from release to
release. Clojure in general is more functional than CL (for example it
uses immutable data structures by default), and more oriented towards
concurrency, but it misses some of CL's best features like CLOS and
the condition system. Not sure about macros in Clojure. Also CL code
is more regular (it's based completely on lists) while AFAIK Clojure
mixes lists with vectors/tuples. Both are dynamically typed, though I
ignore the details of Clojure's type system.
Maturity:
I guess both implementations have a similar level of maturity. ABCL
has been developed mostly by a single person for a while, and now has
a bunch of regular contributors; it's not far from being able to run
big CL projects like Maxima and AP5, though there are still a few
bugs. Clojure AFAIK is developed by a single individual but has many
third-party contributions. Clojure's community is probably bigger now,
and it's receiving much more hype, but I have heard ABCL has been used
in some production-level projects without problems - not sure about
Clojure.
Performance:
ABCL's performance is not bad (except CLOS is quite slow). It has a
compiler that produces Java bytecode. I don't know anything about
Clojure's performance, except that its immutable data structures are
very well designed and so have little performance impact (for being
immutable). Clojure's greater use of functional programming might
suffer more from the lack of TCO on the JVM, but I'm freely
speculating here (Clojure offers an operator, "recur", that implements
some kind of manual TCO, but I don't know the details).
Java Integration:
I have the feeling (correct me if I'm wrong) that Clojure makes a much
stronger attempt at integrating Lisp with Java, to the point of
porting some of Java's (mis)features to Lisp, e.g. source files are
required to adhere to a fixed filesystem layout based on packages
(namespaces). ABCL gives you the basic building blocks to cooperate
with Java and leaves up to you writing a higher-level abstraction over
them. There's one ("invoke.lisp") floating on the net; I have written
a simpler one myself with little effort. By "basic building blocks" I
mean things like creating new Java objects, invoking methods on them,
and creating "proxies" (implementations of Java interfaces created at
runtime) implemented in Lisp (useful for Java->Lisp callbacks). Also I
have contributed a little patch to ABCL that integrates a bit the Java
type system with CLOS: you get a JAVA-CLASS metaclass that mirrors the
Java inheritance hierarchy, and that can be used to specialize CLOS
methods (using a non-standard (jclass "class") specializer). Ok, I
know Qi doesn't use CLOS :) - I'm just trying to make a general
comparison.
That's all I can think of. I won't say what I think is "better"
between ABCL and Clojure, because you have to judge it by yourself,
and anyway "better" only makes sense relatively to the problem you
have to solve.
hth,
Alessio
On May 5, 2:03 pm, Mark Tarver <··········@ukonline.co.uk> wrote:
> A couple of people wrote to me about porting Qi II to Clojure. What
> are the specific gains/losses in using ABCL versus Clojure? We've had
> several goes with ABCL without success so far. I have no axes to
> grind on this matter btw.
I would go with clojure because, if you arrange your compiler
appropriately, you will be able to generate .class files that will be
callable by any jvm language (just as clojure does), whereas going the
abcl route will require that anyone using Qi II -> abcl will end up
with something that will only run under Qi-abcl.
On May 5, 1:13 pm, Raffael Cavallaro <················@gmail.com>
wrote:
> On May 5, 2:03 pm, Mark Tarver <··········@ukonline.co.uk> wrote:
>
> > A couple of people wrote to me about porting Qi II to Clojure. What
> > are the specific gains/losses in using ABCL versus Clojure? We've had
> > several goes with ABCL without success so far. I have no axes to
> > grind on this matter btw.
>
> I would go with clojure because, if you arrange your compiler
> appropriately, you will be able to generate .class files that will be
> callable by any jvm language (just as clojure does), whereas going the
> abcl route will require that anyone using Qi II -> abcl will end up
> with something that will only run under Qi-abcl.
That's a very good point. Btw, what in the architecture of ABCL stops
generating .class files? (Although my question might sounds like -
what stops us from having flying cars anywhere)...
On May 5, 10:25 pm, "Dimiter \"malkia\" Stanev" <······@gmail.com>
wrote:
> On May 5, 1:13 pm, Raffael Cavallaro <················@gmail.com>
> wrote:
>
> > On May 5, 2:03 pm, Mark Tarver <··········@ukonline.co.uk> wrote:
>
> > > A couple of people wrote to me about porting Qi II to Clojure. What
> > > are the specific gains/losses in using ABCL versus Clojure? We've had
> > > several goes with ABCL without success so far. I have no axes to
> > > grind on this matter btw.
>
> > I would go with clojure because, if you arrange your compiler
> > appropriately, you will be able to generate .class files that will be
> > callable by any jvm language (just as clojure does), whereas going the
> > abcl route will require that anyone using Qi II -> abcl will end up
> > with something that will only run under Qi-abcl.
>
> That's a very good point. Btw, what in the architecture of ABCL stops
> generating .class files? (Although my question might sounds like -
> what stops us from having flying cars anywhere)...
As far as I know ABCL is theoretically capable of generating
proper .class files. This functionality however is not exposed to the
user: the compiler writes a .class (actually .cls) file for every
compiled function, and autogenerates the class (and file) name. I know
little of ABCL's compiler, but I suspect it should not be terribly
complicated to pass to it the name and package of the class to
generate and thus obtain a .class file directly loadable by the Java
classloader. The one-class-per-function limitation is less likely to
be avoidable. Again this might be completely wrong as I'm not at all
an expert on ABCL's internals.
Ale
On May 5, 2:00 pm, Alessio Stalla <·············@gmail.com> wrote:
> On May 5, 10:25 pm, "Dimiter \"malkia\" Stanev" <······@gmail.com>
> wrote:
>
>
>
>
>
> > On May 5, 1:13 pm, Raffael Cavallaro <················@gmail.com>
> > wrote:
>
> > > On May 5, 2:03 pm, Mark Tarver <··········@ukonline.co.uk> wrote:
>
> > > > A couple of people wrote to me about porting Qi II to Clojure. What
> > > > are the specific gains/losses in using ABCL versus Clojure? We've had
> > > > several goes with ABCL without success so far. I have no axes to
> > > > grind on this matter btw.
>
> > > I would go with clojure because, if you arrange your compiler
> > > appropriately, you will be able to generate .class files that will be
> > > callable by any jvm language (just as clojure does), whereas going the
> > > abcl route will require that anyone using Qi II -> abcl will end up
> > > with something that will only run under Qi-abcl.
>
> > That's a very good point. Btw, what in the architecture of ABCL stops
> > generating .class files? (Although my question might sounds like -
> > what stops us from having flying cars anywhere)...
>
> As far as I know ABCL is theoretically capable of generating
> proper .class files. This functionality however is not exposed to the
> user: the compiler writes a .class (actually .cls) file for every
> compiled function, and autogenerates the class (and file) name. I know
> little of ABCL's compiler, but I suspect it should not be terribly
> complicated to pass to it the name and package of the class to
> generate and thus obtain a .class file directly loadable by the Java
> classloader. The one-class-per-function limitation is less likely to
> be avoidable. Again this might be completely wrong as I'm not at all
> an expert on ABCL's internals.
>
> Ale
Actually you are right. And also ABCL is more productive when comes to
disassemble on a function - it calls externally JAD (the famous
javabyte code disassembler) and displays the result.
I wish such feature was ready for clojure (probably people are doing
it other ways - there are lot of tools for introspecting the running
JavaVM - I've basically started typing "j" then TAB on my bash in Mac
OS X - and started discovering all such kinds of tools).
On May 5, 11:18 pm, "Dimiter \"malkia\" Stanev" <······@gmail.com>
wrote:
> On May 5, 2:00 pm, Alessio Stalla <·············@gmail.com> wrote:
>
>
>
> > On May 5, 10:25 pm, "Dimiter \"malkia\" Stanev" <······@gmail.com>
> > wrote:
>
> > > On May 5, 1:13 pm, Raffael Cavallaro <················@gmail.com>
> > > wrote:
>
> > > > On May 5, 2:03 pm, Mark Tarver <··········@ukonline.co.uk> wrote:
>
> > > > > A couple of people wrote to me about porting Qi II to Clojure. What
> > > > > are the specific gains/losses in using ABCL versus Clojure? We've had
> > > > > several goes with ABCL without success so far. I have no axes to
> > > > > grind on this matter btw.
>
> > > > I would go with clojure because, if you arrange your compiler
> > > > appropriately, you will be able to generate .class files that will be
> > > > callable by any jvm language (just as clojure does), whereas going the
> > > > abcl route will require that anyone using Qi II -> abcl will end up
> > > > with something that will only run under Qi-abcl.
>
> > > That's a very good point. Btw, what in the architecture of ABCL stops
> > > generating .class files? (Although my question might sounds like -
> > > what stops us from having flying cars anywhere)...
>
> > As far as I know ABCL is theoretically capable of generating
> > proper .class files. This functionality however is not exposed to the
> > user: the compiler writes a .class (actually .cls) file for every
> > compiled function, and autogenerates the class (and file) name. I know
> > little of ABCL's compiler, but I suspect it should not be terribly
> > complicated to pass to it the name and package of the class to
> > generate and thus obtain a .class file directly loadable by the Java
> > classloader. The one-class-per-function limitation is less likely to
> > be avoidable. Again this might be completely wrong as I'm not at all
> > an expert on ABCL's internals.
>
> > Ale
>
> Actually you are right. And also ABCL is more productive when comes to
> disassemble on a function - it calls externally JAD (the famous
> javabyte code disassembler) and displays the result.
>
> I wish such feature was ready for clojure (probably people are doing
> it other ways - there are lot of tools for introspecting the running
> JavaVM - I've basically started typing "j" then TAB on my bash in Mac
> OS X - and started discovering all such kinds of tools).
Yes, JAD is very nice, although I had some problems finding a version
to run on my Linux box - it seems not to be developed anymore and the
site that distributed it is no longer available.
The same tool, or other decompilers, can probably be used with Clojure
with little or no effort, since you have access to its .class files (I
believe there's a plugin for Eclipse that decompiles a class file on
the fly when you open it in the editor).
You can also launch the JVM in debug mode and connect to it with a
graphical debugger (again, Eclipse supports this) - I've done it with
ABCL, but for things like stepping line-by-line it requires that you
have the Java source code available, which isn't possible with
bytecode generated from Lisp. In any case I think you should still be
able to see method calls, parameters, return values, and evaluate
watch expressions.
Returning on the previous subject (generating class files), I also
know abcl can (*) generate Java classes at runtime, with methods
implemented in Lisp, and maybe those could be dumped to file somehow.
(*) I have seen the code which does this, but never tried it, I don't
know if it is complete, or has issues. Probably the abcl maintainers
know better.
Ale
Dimiter "malkia" Stanev schrieb:
> On May 5, 2:00 pm, Alessio Stalla <·············@gmail.com> wrote:
>> On May 5, 10:25 pm, "Dimiter \"malkia\" Stanev" <······@gmail.com>
>> wrote:
>>
>>
>>
>>
>>
>>> On May 5, 1:13 pm, Raffael Cavallaro <················@gmail.com>
>>> wrote:
>>>> On May 5, 2:03 pm, Mark Tarver <··········@ukonline.co.uk> wrote:
>>>>> A couple of people wrote to me about porting Qi II to Clojure. What
>>>>> are the specific gains/losses in using ABCL versus Clojure? We've had
>>>>> several goes with ABCL without success so far. I have no axes to
>>>>> grind on this matter btw.
>>>> I would go with clojure because, if you arrange your compiler
>>>> appropriately, you will be able to generate .class files that will be
>>>> callable by any jvm language (just as clojure does), whereas going the
>>>> abcl route will require that anyone using Qi II -> abcl will end up
>>>> with something that will only run under Qi-abcl.
>>> That's a very good point. Btw, what in the architecture of ABCL stops
>>> generating .class files? (Although my question might sounds like -
>>> what stops us from having flying cars anywhere)...
>> As far as I know ABCL is theoretically capable of generating
>> proper .class files. This functionality however is not exposed to the
>> user: the compiler writes a .class (actually .cls) file for every
>> compiled function, and autogenerates the class (and file) name. I know
>> little of ABCL's compiler, but I suspect it should not be terribly
>> complicated to pass to it the name and package of the class to
>> generate and thus obtain a .class file directly loadable by the Java
>> classloader. The one-class-per-function limitation is less likely to
>> be avoidable. Again this might be completely wrong as I'm not at all
>> an expert on ABCL's internals.
>>
>> Ale
>
> Actually you are right. And also ABCL is more productive when comes to
> disassemble on a function - it calls externally JAD (the famous
> javabyte code disassembler) and displays the result.
>
> I wish such feature was ready for clojure (probably people are doing
> it other ways - there are lot of tools for introspecting the running
> JavaVM - I've basically started typing "j" then TAB on my bash in Mac
> OS X - and started discovering all such kinds of tools).
But this feature *is* ready for Clojure since several months.
Clojure generates .class files. Run jad on them.
You want to run a very nice profiler that can paint you colorful images?
I am not sure if it was Java 6 Update 8 or later from which on VisualVM
gets shipped with the JDK. Look in the bin folder of the JDK for
jvisualvm.exe (under Windows, Linux probably has a similar name).
Check https://visualvm.dev.java.net/ for screencasts and screenshots.
Or better: run Clojure, start VisualVM and connect into your Clojure
image. You can start memory or cpu profiling and see it at work.
Also code obfuscators and all other kinds of tools work on the .class
files generated by Clojure.
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
On May 5, 10:13 pm, Raffael Cavallaro <················@gmail.com>
wrote:
> I would go with clojure because, if you arrange your compiler
> appropriately, you will be able to generate .class files that will be
> callable by any jvm language (just as clojure does), whereas going the
> abcl route will require that anyone using Qi II -> abcl will end up
> with something that will only run under Qi-abcl.
Well, I think things are a bit more complex here. Sure, Clojure
generates .class files while ABCL does not; however the .class files
will still require Clojure in the classpath, and so you'll still get
something that runs only under Qi-Clojure - only Qi (class files) and
Clojure (jar?) will be hidden to the user of the code, who will see a
"normal" compiled java class, if I understood it correctly.
With ABCL you can do e.g.
Function f = Interpreter.eval("#'my-compiled-function");
f.execute(...args...);
and hide that behind a tiny layer so the user of the code is not aware
of ABCL or Qi. Yes, this requires writing some glue Java code and
making sure the Lisp system is correctly initialized (ABCL
unfortunately lacks a save-image functionality, so you'll have to load
your files manually - for example using asdf - at startup).
Note also that ABCL supports the JSR-223 specification which allows
easier (and standardized) Java->Lisp interoperation, for example:
MyInterface obj = abclScriptEngine.getInterface(MyInterface.class);
obj.myMethodImplementedInLisp(); //Provided a function my-method-
implemented-in-lisp exists
Fixnum f = (Fixnum) abclScriptEngine.invokeFunction("+", 40, 2);
int i = f.value;
In short, with ABCL it's probably not as nice and clean as with
Clojure, but still very usable IMHO.
Alessio
On May 5, 1:53 pm, Alessio Stalla <·············@gmail.com> wrote:
> On May 5, 10:13 pm, Raffael Cavallaro <················@gmail.com>
> wrote:
>
> > I would go with clojure because, if you arrange your compiler
> > appropriately, you will be able to generate .class files that will be
> > callable by any jvm language (just as clojure does), whereas going the
> > abcl route will require that anyone using Qi II -> abcl will end up
> > with something that will only run under Qi-abcl.
>
> Well, I think things are a bit more complex here. Sure, Clojure
> generates .class files while ABCL does not; however the .class files
> will still require Clojure in the classpath, and so you'll still get
> something that runs only under Qi-Clojure - only Qi (class files) and
> Clojure (jar?) will be hidden to the user of the code, who will see a
> "normal" compiled java class, if I understood it correctly.
>
> With ABCL you can do e.g.
>
> Function f = Interpreter.eval("#'my-compiled-function");
> f.execute(...args...);
>
> and hide that behind a tiny layer so the user of the code is not aware
> of ABCL or Qi. Yes, this requires writing some glue Java code and
> making sure the Lisp system is correctly initialized (ABCL
> unfortunately lacks a save-image functionality, so you'll have to load
> your files manually - for example using asdf - at startup).
>
> Note also that ABCL supports the JSR-223 specification which allows
> easier (and standardized) Java->Lisp interoperation, for example:
>
> MyInterface obj = abclScriptEngine.getInterface(MyInterface.class);
> obj.myMethodImplementedInLisp(); //Provided a function my-method-
> implemented-in-lisp exists
>
> Fixnum f = (Fixnum) abclScriptEngine.invokeFunction("+", 40, 2);
> int i = f.value;
>
> In short, with ABCL it's probably not as nice and clean as with
> Clojure, but still very usable IMHO.
>
> Alessio
Thanks for the clarification!
I think I saw that Clojure also supports this JSR, if you are on
1.6.0.
On May 5, 11:19 pm, "Dimiter \"malkia\" Stanev" <······@gmail.com>
wrote:
> On May 5, 1:53 pm, Alessio Stalla <·············@gmail.com> wrote:
>
>
>
> > On May 5, 10:13 pm, Raffael Cavallaro <················@gmail.com>
> > wrote:
>
> > > I would go with clojure because, if you arrange your compiler
> > > appropriately, you will be able to generate .class files that will be
> > > callable by any jvm language (just as clojure does), whereas going the
> > > abcl route will require that anyone using Qi II -> abcl will end up
> > > with something that will only run under Qi-abcl.
>
> > Well, I think things are a bit more complex here. Sure, Clojure
> > generates .class files while ABCL does not; however the .class files
> > will still require Clojure in the classpath, and so you'll still get
> > something that runs only under Qi-Clojure - only Qi (class files) and
> > Clojure (jar?) will be hidden to the user of the code, who will see a
> > "normal" compiled java class, if I understood it correctly.
>
> > With ABCL you can do e.g.
>
> > Function f = Interpreter.eval("#'my-compiled-function");
> > f.execute(...args...);
>
> > and hide that behind a tiny layer so the user of the code is not aware
> > of ABCL or Qi. Yes, this requires writing some glue Java code and
> > making sure the Lisp system is correctly initialized (ABCL
> > unfortunately lacks a save-image functionality, so you'll have to load
> > your files manually - for example using asdf - at startup).
>
> > Note also that ABCL supports the JSR-223 specification which allows
> > easier (and standardized) Java->Lisp interoperation, for example:
>
> > MyInterface obj = abclScriptEngine.getInterface(MyInterface.class);
> > obj.myMethodImplementedInLisp(); //Provided a function my-method-
> > implemented-in-lisp exists
>
> > Fixnum f = (Fixnum) abclScriptEngine.invokeFunction("+", 40, 2);
> > int i = f.value;
>
> > In short, with ABCL it's probably not as nice and clean as with
> > Clojure, but still very usable IMHO.
>
> > Alessio
>
> Thanks for the clarification!
>
> I think I saw that Clojure also supports this JSR, if you are on
> 1.6.0.
Good to know, since I'm the author of the JSR-223 implementation in
ABCL (so now you know who to blame when it'll fail :D), I should take
a look at how the Clojure folks have done it.
PS abcl supports it also on 1.5, provided that it finds javax.script
classes in the classpath when you build it and when you run it: there
are implementations of the JSR you can use on 1.5.
A.
On May 5, 11:03 am, Mark Tarver <··········@ukonline.co.uk> wrote:
> A couple of people wrote to me about porting Qi II to Clojure. What
> are the specific gains/losses in using ABCL versus Clojure? We've had
> several goes with ABCL without success so far. I have no axes to
> grind on this matter btw.
>
> Mark
Hi Mark,
I have one benchmark, based on the code from this document:
http://openmap.bbn.com/~kanderso/performance/postscript/in-poly.ps
The times are taken from my MacBook Pro, and I won't post the results
here, but you can check them out in the links:
ABCL: http://paste.lisp.org/display/79729
Clojure: http://paste.lisp.org/display/79726
The ABCL is (off course) Common Lisp, so it can be compiled (and I've
did) under Allegro, Lispworks, SBCL, CMUCL and others.
I don't think this benchmark represents anything significant, it's too
fixed, but my give you some starting point.
On May 5, 2:03 pm, Mark Tarver <··········@ukonline.co.uk> wrote:
> A couple of people wrote to me about porting Qi II to Clojure. What
> are the specific gains/losses in using ABCL versus Clojure? We've had
> several goes with ABCL without success so far. I have no axes to
> grind on this matter btw.
>
> Mark
I haven't tried this myself, but just so you are aware:
http://clforjava.org/
From the to-do list it looks to be in its infancy, but it may give you
a Java compilation option other than ABCL in the future.
On May 5, 5:34 pm, ··················@gmail.com wrote:
> On May 5, 2:03 pm, Mark Tarver <··········@ukonline.co.uk> wrote:
>
> > A couple of people wrote to me about porting Qi II to Clojure. What
> > are the specific gains/losses in using ABCL versus Clojure? We've had
> > several goes with ABCL without success so far. I have no axes to
> > grind on this matter btw.
>
> > Mark
>
> I haven't tried this myself, but just so you are aware:http://clforjava.org/
>
> From the to-do list it looks to be in its infancy, but it may give you
> a Java compilation option other than ABCL in the future.
I've just downloaded it http://clforjava.org/?page=downloads -->
http://clforjava.org/CL4J-Dist/CLforJava-20090502.zip
Then create a shell script file to run it:
java -server -cp CLforJava.jar lisp.common.CLforJava
But the first impression were... well... duh...
······@malkiaBookPro-2.local:~/p/CLforJava-20090502 > ./cl4java.sh
Loading jar CoreFunctionsLsp
Loading jar LambdaListParsersLsp
Loading jar PrinterLsp
Loading jar MiscMacrosLsp
Loading jar ListsLsp
Loading jar SequencesLsp
Loading jar IteratorsLsp
Loading jar SetfLsp
Loading jar DefstructLsp
Loading jar ArraysLsp
Loading jar HashTablesLsp
Welcome to Common Lisp for Java!
CLforJava Build#: 2009.04.02:0736
Copyright (c) College of Charleston, 2003-2009
Report bugs to http://clforjava.cs.cofc.edu/Bugzilla/index.cgi
1 > (in-package "CL-USER")
#<PACKAGE COMMON-LISP-USER, 1 symbols>
2 > (do-symbols (s) (print s))
; WARNING: Exception condition ->
lisp.common.exceptions.FunctionException: Undefined Function
exception: DO-SYMBOLS
lisp.common.exceptions.FunctionException: Undefined Function
exception: DO-SYMBOLS
at lisp.common.function.SymbolFunction.funcall(SymbolFunction.java:
74)
at lisp.common.function.Eval.funcall(Eval.java:213)
at lisp.extensions.function.ReadEvalPrint.funcall(ReadEvalPrint.java:
157)
at lisp.common.CLforJava.funcall(CLforJava.java:161)
at lisp.common.CLforJava.readEvalPrint(CLforJava.java:190)
at lisp.common.CLforJava.main(CLforJava.java:279)
3 > (apropos "do-")
; WARNING: Exception condition ->
lisp.common.exceptions.FunctionException: Undefined Function
exception: APROPOS
lisp.common.exceptions.FunctionException: Undefined Function
exception: APROPOS
at lisp.common.function.SymbolFunction.funcall(SymbolFunction.java:
74)
at lisp.common.function.Eval.funcall(Eval.java:213)
at lisp.extensions.function.ReadEvalPrint.funcall(ReadEvalPrint.java:
157)
at lisp.common.CLforJava.funcall(CLforJava.java:161)
at lisp.common.CLforJava.readEvalPrint(CLforJava.java:190)
at lisp.common.CLforJava.main(CLforJava.java:279)
4 >
Mark Tarver schrieb:
> A couple of people wrote to me about porting Qi II to Clojure. What
> are the specific gains/losses in using ABCL versus Clojure? We've had
> several goes with ABCL without success so far. I have no axes to
> grind on this matter btw.
As I understood it one of the basic problems for you was to get ABCL
working. Provided that it works it should be easier for you to port
Qi - most of your code should just run.
That's what I see as the biggest advantage of using ABCL.
You won't need to rewrite Qi *again*. Modifying.. probably. But not
the whole thing from scratch.
If you want your port to the JVM be written in Clojure, then you will
need a rewrite. That means you would first have to learn Clojure itself
and then adobt your algorithms.
Also you should check how much of Qi is written in CLOS. Clojure does
not have that (officially and mature). If Qi is mostly written in a
functional style, then there may be benefits in rewriting it in Clojure.
It's minor, but some people prefer Lisp-1 for functional style.
One thing however could be difficult for you to decide if you decide to
rewrite Qi in Clojure for the JVM port: if you want to use Clojures
data structures. If you do it, this would mean that people will need
Clojure for Qi. There is no problem with the license, and in the end
what you will offer will be just one qi.jar file. But that would be
1,3mb bigger with Clojure. Also: if you don't plan to make Qi concurrent
itself, then you will notice a performance hit. Clojures datastructures
can't compete performance-wise in single thread applications against
the native JVM arrays or hashtables.
Of course, you could exclusively use those in Clojure programs as well.
But back to the "if you do it": the advantage would be, that Qi itself
and programs you write in it could be very easily parallelized for
practical matters. In concurrent situations Clojure vectors, sets and
maps perform very good. Rich Hickey markets Clojure as one or even the
fastest dynamic language on the JVM.
Even if you decide in the end to rewrite Qi in Clojure.. I would still
consider to first get it running under ABCL.
Btw, how many LOC is Qi?
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
On May 5, 11:38 pm, André Thieme <address.good.until.
···········@justmail.de> wrote:
> Mark Tarver schrieb:
>
> > A couple of people wrote to me about porting Qi II to Clojure. What
> > are the specific gains/losses in using ABCL versus Clojure? We've had
> > several goes with ABCL without success so far. I have no axes to
> > grind on this matter btw.
>
> As I understood it one of the basic problems for you was to get ABCL
> working. Provided that it works it should be easier for you to port
> Qi - most of your code should just run.
> That's what I see as the biggest advantage of using ABCL.
> You won't need to rewrite Qi *again*. Modifying.. probably. But not
> the whole thing from scratch.
>
> If you want your port to the JVM be written in Clojure, then you will
> need a rewrite. That means you would first have to learn Clojure itself
> and then adobt your algorithms.
>
> Also you should check how much of Qi is written in CLOS. Clojure does
> not have that (officially and mature). If Qi is mostly written in a
> functional style, then there may be benefits in rewriting it in Clojure.
> It's minor, but some people prefer Lisp-1 for functional style.
>
> One thing however could be difficult for you to decide if you decide to
> rewrite Qi in Clojure for the JVM port: if you want to use Clojures
> data structures. If you do it, this would mean that people will need
> Clojure for Qi. There is no problem with the license, and in the end
> what you will offer will be just one qi.jar file. But that would be
> 1,3mb bigger with Clojure.
So Clojure can produce .class files that don't depend on it, if you
don't use its immutable data structures? Then what I said earlier
about .class files is not completely true, and Clojure really has an
advantage here (ABCL always generates code that depends on the ABCL
runtime, as far as I know). This probably also means Clojure is much
more integrated with Java than I thought (again, by comparison, ABCL
does not reuse Java's data types such as strings or numbers directly,
but wraps them in its own classes: every object managed by ABCL
extends a common base class, LispObject).
> Also: if you don't plan to make Qi concurrent
> itself, then you will notice a performance hit. Clojures datastructures
> can't compete performance-wise in single thread applications against
> the native JVM arrays or hashtables.
> Of course, you could exclusively use those in Clojure programs as well.
> But back to the "if you do it": the advantage would be, that Qi itself
> and programs you write in it could be very easily parallelized for
> practical matters. In concurrent situations Clojure vectors, sets and
> maps perform very good. Rich Hickey markets Clojure as one or even the
> fastest dynamic language on the JVM.
>
> Even if you decide in the end to rewrite Qi in Clojure.. I would still
> consider to first get it running under ABCL.
> Btw, how many LOC is Qi?
>
> André
> --
> Lisp is not dead. It’s just the URL that has changed:http://clojure.org/
Alessio Stalla schrieb:
> So Clojure can produce .class files that don't depend on it, if you
> don't use its immutable data structures?
No sorry, I think I was wrong.
Good that you asked explicitly, now that I think about it I believe that
if Mark wants to port Qi via Clojure to the JVM he will need the
clojure.jar in all cases.
And he wrote he would not like to rewrite Qi again manually. In that
case I see not many interesting benefits of targetting Clojure.
Maybe the benefit would be to get running faster, if he can't figure
out what those bugs in ABCL are that stop him from using it right
now.
But if ABCL or Clojure: both solutions sound technically not so
beautiful, as it seems both require Qi to ship with one of them.
ABCL or Clojure themselves however don't depend on that...
but if Mark wants that, then he will need to implement parts in
Java, to bootstrap Qi.
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
On May 6, 1:03 am, André Thieme <address.good.until.
···········@justmail.de> wrote:
> Alessio Stalla schrieb:
>
> > So Clojure can produce .class files that don't depend on it, if you
> > don't use its immutable data structures?
>
> No sorry, I think I was wrong.
> Good that you asked explicitly, now that I think about it I believe that
> if Mark wants to port Qi via Clojure to the JVM he will need the
> clojure.jar in all cases.
It's not a big problem... Java apps already carry with them many
library jars usually, one more won't make the difference.
> And he wrote he would not like to rewrite Qi again manually. In that
> case I see not many interesting benefits of targetting Clojure.
> Maybe the benefit would be to get running faster, if he can't figure
> out what those bugs in ABCL are that stop him from using it right
> now.
> But if ABCL or Clojure: both solutions sound technically not so
> beautiful, as it seems both require Qi to ship with one of them.
Well, isn't this true for Qi in general? If you use Qi with SBCL, for
example, you have to ship your app with Qi and SBCL, or am I missing
something?
Ale
> ABCL or Clojure themselves however don't depend on that...
> but if Mark wants that, then he will need to implement parts in
> Java, to bootstrap Qi.
>
> André
> --
> Lisp is not dead. It’s just the URL that has changed:http://clojure.org/
Alessio Stalla schrieb:
> On May 6, 1:03 am, Andr� Thieme <address.good.until.
> ···········@justmail.de> wrote:
>> But if ABCL or Clojure: both solutions sound technically not so
>> beautiful, as it seems both require Qi to ship with one of them.
>
> Well, isn't this true for Qi in general? If you use Qi with SBCL, for
> example, you have to ship your app with Qi and SBCL, or am I missing
> something?
I also see it this way. Mark said the CL version of Qi is about 8,5k LOC.
By solving the task in Lisp he became dependent on it, but also got
this huge boost in productivity. He outsourced the need to write a VM.
Rich Hickey did the same with Clojure, also the author of ABCL did that.
They decided to target the JVM, as Mark chose (for example) clisp as the
VM to host his Qi. The VM will always be needed, even if he writes his
own.
But if he decides to write Qi in Clojure code, then the compiled result
will under the hood make use of the dynamic features that Clojure offers.
If Mark wants to use them or not, he will be dependent on having Clojure
installed where he wants to run Qi. Sure, he can put Clojure into his
qi.jar file and offer that as a download.
But if he would program it in pure Java, then the generated byte code
would only use the features that the pure JDK offers. So, there would be
no dependency for him, other than the VM itself. The JVM is luckily
installed on tens of millions of computers, and has somewhere near one
billion installations on mobile computers, such as phones.
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
On May 6, 10:20 pm, André Thieme <address.good.until.
···········@justmail.de> wrote:
> Alessio Stalla schrieb:
>
> > On May 6, 1:03 am, André Thieme <address.good.until.
> > ···········@justmail.de> wrote:
> >> But if ABCL or Clojure: both solutions sound technically not so
> >> beautiful, as it seems both require Qi to ship with one of them.
>
> > Well, isn't this true for Qi in general? If you use Qi with SBCL, for
> > example, you have to ship your app with Qi and SBCL, or am I missing
> > something?
>
> I also see it this way. Mark said the CL version of Qi is about 8,5k LOC.
> By solving the task in Lisp he became dependent on it, but also got
> this huge boost in productivity. He outsourced the need to write a VM.
> Rich Hickey did the same with Clojure, also the author of ABCL did that.
> They decided to target the JVM, as Mark chose (for example) clisp as the
> VM to host his Qi. The VM will always be needed, even if he writes his
> own.
> But if he decides to write Qi in Clojure code, then the compiled result
> will under the hood make use of the dynamic features that Clojure offers.
> If Mark wants to use them or not, he will be dependent on having Clojure
> installed where he wants to run Qi. Sure, he can put Clojure into his
> qi.jar file and offer that as a download.
> But if he would program it in pure Java, then the generated byte code
> would only use the features that the pure JDK offers. So, there would be
> no dependency for him, other than the VM itself. The JVM is luckily
> installed on tens of millions of computers, and has somewhere near one
> billion installations on mobile computers, such as phones.
I think these are the issues one faces in general when using a
library: if you use it you get some functionality already implemented
by someone else, but become dependent on the library; if you don't use
it, you're independent but you need to write the functionality from
scratch yourself. In this case, the Lisp system (ABCL, Clojure, clisp
or whatever) is a bit like a "library" for Qi. I think that generally
it's better to be dependent on a library (especially if it's mature
and well tested like a
widely used Lisp system), than to rewrite it from scratch for the sake
of independency. If one day Mark will get Qi to be self-contained and
bootstrappable (e.g. having a Qi compiler written in Qi and targetting
directly machine code or bytecode), maybe he will be able to get rid
of the dependency on the underlying Lisp system, but I don't think
this is a sensible goal.
Ale
> André
> --
> Lisp is not dead. It’s just the URL that has changed:http://clojure.org/
On 5 May, 22:38, André Thieme <address.good.until.
···········@justmail.de> wrote:
> Mark Tarver schrieb:
>
> > A couple of people wrote to me about porting Qi II to Clojure. What
> > are the specific gains/losses in using ABCL versus Clojure? We've had
> > several goes with ABCL without success so far. I have no axes to
> > grind on this matter btw.
>
> As I understood it one of the basic problems for you was to get ABCL
> working. Provided that it works it should be easier for you to port
> Qi - most of your code should just run.
> That's what I see as the biggest advantage of using ABCL.
> You won't need to rewrite Qi *again*. Modifying.. probably. But not
> the whole thing from scratch.
>
> If you want your port to the JVM be written in Clojure, then you will
> need a rewrite. That means you would first have to learn Clojure itself
> and then adobt your algorithms.
>
> Also you should check how much of Qi is written in CLOS. Clojure does
> not have that (officially and mature). If Qi is mostly written in a
> functional style, then there may be benefits in rewriting it in Clojure.
> It's minor, but some people prefer Lisp-1 for functional style.
>
> One thing however could be difficult for you to decide if you decide to
> rewrite Qi in Clojure for the JVM port: if you want to use Clojures
> data structures. If you do it, this would mean that people will need
> Clojure for Qi. There is no problem with the license, and in the end
> what you will offer will be just one qi.jar file. But that would be
> 1,3mb bigger with Clojure. Also: if you don't plan to make Qi concurrent
> itself, then you will notice a performance hit. Clojures datastructures
> can't compete performance-wise in single thread applications against
> the native JVM arrays or hashtables.
> Of course, you could exclusively use those in Clojure programs as well.
> But back to the "if you do it": the advantage would be, that Qi itself
> and programs you write in it could be very easily parallelized for
> practical matters. In concurrent situations Clojure vectors, sets and
> maps perform very good. Rich Hickey markets Clojure as one or even the
> fastest dynamic language on the JVM.
>
> Even if you decide in the end to rewrite Qi in Clojure.. I would still
> consider to first get it running under ABCL.
> Btw, how many LOC is Qi?
>
> André
> --
> Lisp is not dead. It’s just the URL that has changed:http://clojure.org/
Qi II in Qi is only 2,000 lines. In CL its about 8,500. But you're
right. I don't want to write Qi again. This was the last and the
definitive rewrite. I can generate Clojure no problem (like
Python).
I've filed a bug report on ABCL and its been given as fixed but I find
no code to download. Somebody on Qilang did manage to install ABCL
under Linux but again hit a bug whereby the readtable reverted to the
default during loading Qi. See Qilang for details. This is our
second joint attempt to port Qi to ABCL.
My impression is that ABCL has quite a few bugs but from all the
hammering and banging coming from SourceForge, it will eventually
make it as a platform. I'm happy to cooperate with ABCL people in
getting my work to run on top of their platform.
Btw does ABCL have threads?
Mark
On May 6, 12:08 am, Mark Tarver <··········@ukonline.co.uk> wrote:
> On 5 May, 22:38, André Thieme <address.good.until.
>
>
>
> ···········@justmail.de> wrote:
> > Mark Tarver schrieb:
>
> > > A couple of people wrote to me about porting Qi II to Clojure. What
> > > are the specific gains/losses in using ABCL versus Clojure? We've had
> > > several goes with ABCL without success so far. I have no axes to
> > > grind on this matter btw.
>
> > As I understood it one of the basic problems for you was to get ABCL
> > working. Provided that it works it should be easier for you to port
> > Qi - most of your code should just run.
> > That's what I see as the biggest advantage of using ABCL.
> > You won't need to rewrite Qi *again*. Modifying.. probably. But not
> > the whole thing from scratch.
>
> > If you want your port to the JVM be written in Clojure, then you will
> > need a rewrite. That means you would first have to learn Clojure itself
> > and then adobt your algorithms.
>
> > Also you should check how much of Qi is written in CLOS. Clojure does
> > not have that (officially and mature). If Qi is mostly written in a
> > functional style, then there may be benefits in rewriting it in Clojure.
> > It's minor, but some people prefer Lisp-1 for functional style.
>
> > One thing however could be difficult for you to decide if you decide to
> > rewrite Qi in Clojure for the JVM port: if you want to use Clojures
> > data structures. If you do it, this would mean that people will need
> > Clojure for Qi. There is no problem with the license, and in the end
> > what you will offer will be just one qi.jar file. But that would be
> > 1,3mb bigger with Clojure. Also: if you don't plan to make Qi concurrent
> > itself, then you will notice a performance hit. Clojures datastructures
> > can't compete performance-wise in single thread applications against
> > the native JVM arrays or hashtables.
> > Of course, you could exclusively use those in Clojure programs as well.
> > But back to the "if you do it": the advantage would be, that Qi itself
> > and programs you write in it could be very easily parallelized for
> > practical matters. In concurrent situations Clojure vectors, sets and
> > maps perform very good. Rich Hickey markets Clojure as one or even the
> > fastest dynamic language on the JVM.
>
> > Even if you decide in the end to rewrite Qi in Clojure.. I would still
> > consider to first get it running under ABCL.
> > Btw, how many LOC is Qi?
>
> > André
> > --
> > Lisp is not dead. It’s just the URL that has changed:http://clojure.org/
>
> Qi II in Qi is only 2,000 lines. In CL its about 8,500. But you're
> right. I don't want to write Qi again. This was the last and the
> definitive rewrite. I can generate Clojure no problem (like
> Python).
>
> I've filed a bug report on ABCL and its been given as fixed but I find
> no code to download. Somebody on Qilang did manage to install ABCL
> under Linux but again hit a bug whereby the readtable reverted to the
> default during loading Qi. See Qilang for details. This is our
> second joint attempt to port Qi to ABCL.
Installing ABCL is not at all hard. Just grab a release (or checkout
from SVN), and run an Ant task to build it ("ant abcl.jar" from the
abcl directory). You get a single file, abcl.jar, which you can use as
a library, or lanuch as an application (it has a main class).
> My impression is that ABCL has quite a few bugs but from all the
> hammering and banging coming from SourceForge, it will eventually
> make it as a platform. I'm happy to cooperate with ABCL people in
> getting my work to run on top of their platform.
ABCL developers are concentrating their efforts on fixing bugs, both
ANSI compliance bugs and other bugs that affect important
applications. The latest few releases saw a significant drop in the
number of bugs. The easiest way to get a bug solved is probably to
write to the ABCL mailing list and say that you want to port your
library/application to ABCL. Also releases are being planned quite
regularly so if your bug has been marked as fixed the fix is probably
already on SVN, and will be in the next release.
>
> Btw does ABCL have threads?
>
Yes, it uses the JVM threading support. Special bindings are per-
thread as in all multithreaded Lisps I know of. I've never used
threads on ABCL so I don't know which multithreading primitives are
available, I think the usual lock, mutex and similar are there.
Alessio
On 6 May, 08:29, Alessio Stalla <·············@gmail.com> wrote:
> On May 6, 12:08 am, Mark Tarver <··········@ukonline.co.uk> wrote:
>
>
>
>
>
> > On 5 May, 22:38, André Thieme <address.good.until.
>
> > ···········@justmail.de> wrote:
> > > Mark Tarver schrieb:
>
> > > > A couple of people wrote to me about porting Qi II to Clojure. What
> > > > are the specific gains/losses in using ABCL versus Clojure? We've had
> > > > several goes with ABCL without success so far. I have no axes to
> > > > grind on this matter btw.
>
> > > As I understood it one of the basic problems for you was to get ABCL
> > > working. Provided that it works it should be easier for you to port
> > > Qi - most of your code should just run.
> > > That's what I see as the biggest advantage of using ABCL.
> > > You won't need to rewrite Qi *again*. Modifying.. probably. But not
> > > the whole thing from scratch.
>
> > > If you want your port to the JVM be written in Clojure, then you will
> > > need a rewrite. That means you would first have to learn Clojure itself
> > > and then adobt your algorithms.
>
> > > Also you should check how much of Qi is written in CLOS. Clojure does
> > > not have that (officially and mature). If Qi is mostly written in a
> > > functional style, then there may be benefits in rewriting it in Clojure.
> > > It's minor, but some people prefer Lisp-1 for functional style.
>
> > > One thing however could be difficult for you to decide if you decide to
> > > rewrite Qi in Clojure for the JVM port: if you want to use Clojures
> > > data structures. If you do it, this would mean that people will need
> > > Clojure for Qi. There is no problem with the license, and in the end
> > > what you will offer will be just one qi.jar file. But that would be
> > > 1,3mb bigger with Clojure. Also: if you don't plan to make Qi concurrent
> > > itself, then you will notice a performance hit. Clojures datastructures
> > > can't compete performance-wise in single thread applications against
> > > the native JVM arrays or hashtables.
> > > Of course, you could exclusively use those in Clojure programs as well.
> > > But back to the "if you do it": the advantage would be, that Qi itself
> > > and programs you write in it could be very easily parallelized for
> > > practical matters. In concurrent situations Clojure vectors, sets and
> > > maps perform very good. Rich Hickey markets Clojure as one or even the
> > > fastest dynamic language on the JVM.
>
> > > Even if you decide in the end to rewrite Qi in Clojure.. I would still
> > > consider to first get it running under ABCL.
> > > Btw, how many LOC is Qi?
>
> > > André
> > > --
> > > Lisp is not dead. It’s just the URL that has changed:http://clojure.org/
>
> > Qi II in Qi is only 2,000 lines. In CL its about 8,500. But you're
> > right. I don't want to write Qi again. This was the last and the
> > definitive rewrite. I can generate Clojure no problem (like
> > Python).
>
> > I've filed a bug report on ABCL and its been given as fixed but I find
> > no code to download. Somebody on Qilang did manage to install ABCL
> > under Linux but again hit a bug whereby the readtable reverted to the
> > default during loading Qi. See Qilang for details. This is our
> > second joint attempt to port Qi to ABCL.
>
> Installing ABCL is not at all hard. Just grab a release (or checkout
> from SVN), and run an Ant task to build it ("ant abcl.jar" from the
> abcl directory). You get a single file, abcl.jar, which you can use as
> a library, or lanuch as an application (it has a main class).
>
> > My impression is that ABCL has quite a few bugs but from all the
> > hammering and banging coming from SourceForge, it will eventually
> > make it as a platform. I'm happy to cooperate with ABCL people in
> > getting my work to run on top of their platform.
>
> ABCL developers are concentrating their efforts on fixing bugs, both
> ANSI compliance bugs and other bugs that affect important
> applications. The latest few releases saw a significant drop in the
> number of bugs. The easiest way to get a bug solved is probably to
> write to the ABCL mailing list and say that you want to port your
> library/application to ABCL. Also releases are being planned quite
> regularly so if your bug has been marked as fixed the fix is probably
> already on SVN, and will be in the next release.
>
>
>
> > Btw does ABCL have threads?
>
> Yes, it uses the JVM threading support. Special bindings are per-
> thread as in all multithreaded Lisps I know of. I've never used
> threads on ABCL so I don't know which multithreading primitives are
> available, I think the usual lock, mutex and similar are there.
>
> Alessio- Hide quoted text -
>
> - Show quoted text -
Yes; it says
QUOTE
One may use the Ant build tool to create ABCL.
On UNIX, this should be as simple as
unix$ ant abcl.wrapperwill create an executable shell-script
wrapper 'abcl' in the top level directory which then may be invoked
via:
unix$ ./abcl
UNQUOTE
Except I'm running Windows and I chose the Lisp method. It failed
with both SBCL and CLisp. I'll wait until they've put up their next
release..
Mark
On May 6, 1:17 am, Mark Tarver <··········@ukonline.co.uk> wrote:
> On 6 May, 08:29, Alessio Stalla <·············@gmail.com> wrote:
>
>
>
>
>
> > On May 6, 12:08 am, Mark Tarver <··········@ukonline.co.uk> wrote:
>
> > > On 5 May, 22:38, André Thieme <address.good.until.
>
> > > ···········@justmail.de> wrote:
> > > > Mark Tarver schrieb:
>
> > > > > A couple of people wrote to me about porting Qi II to Clojure. What
> > > > > are the specific gains/losses in using ABCL versus Clojure? We've had
> > > > > several goes with ABCL without success so far. I have no axes to
> > > > > grind on this matter btw.
>
> > > > As I understood it one of the basic problems for you was to get ABCL
> > > > working. Provided that it works it should be easier for you to port
> > > > Qi - most of your code should just run.
> > > > That's what I see as the biggest advantage of using ABCL.
> > > > You won't need to rewrite Qi *again*. Modifying.. probably. But not
> > > > the whole thing from scratch.
>
> > > > If you want your port to the JVM be written in Clojure, then you will
> > > > need a rewrite. That means you would first have to learn Clojure itself
> > > > and then adobt your algorithms.
>
> > > > Also you should check how much of Qi is written in CLOS. Clojure does
> > > > not have that (officially and mature). If Qi is mostly written in a
> > > > functional style, then there may be benefits in rewriting it in Clojure.
> > > > It's minor, but some people prefer Lisp-1 for functional style.
>
> > > > One thing however could be difficult for you to decide if you decide to
> > > > rewrite Qi in Clojure for the JVM port: if you want to use Clojures
> > > > data structures. If you do it, this would mean that people will need
> > > > Clojure for Qi. There is no problem with the license, and in the end
> > > > what you will offer will be just one qi.jar file. But that would be
> > > > 1,3mb bigger with Clojure. Also: if you don't plan to make Qi concurrent
> > > > itself, then you will notice a performance hit. Clojures datastructures
> > > > can't compete performance-wise in single thread applications against
> > > > the native JVM arrays or hashtables.
> > > > Of course, you could exclusively use those in Clojure programs as well.
> > > > But back to the "if you do it": the advantage would be, that Qi itself
> > > > and programs you write in it could be very easily parallelized for
> > > > practical matters. In concurrent situations Clojure vectors, sets and
> > > > maps perform very good. Rich Hickey markets Clojure as one or even the
> > > > fastest dynamic language on the JVM.
>
> > > > Even if you decide in the end to rewrite Qi in Clojure.. I would still
> > > > consider to first get it running under ABCL.
> > > > Btw, how many LOC is Qi?
>
> > > > André
> > > > --
> > > > Lisp is not dead. It’s just the URL that has changed:http://clojure.org/
>
> > > Qi II in Qi is only 2,000 lines. In CL its about 8,500. But you're
> > > right. I don't want to write Qi again. This was the last and the
> > > definitive rewrite. I can generate Clojure no problem (like
> > > Python).
>
> > > I've filed a bug report on ABCL and its been given as fixed but I find
> > > no code to download. Somebody on Qilang did manage to install ABCL
> > > under Linux but again hit a bug whereby the readtable reverted to the
> > > default during loading Qi. See Qilang for details. This is our
> > > second joint attempt to port Qi to ABCL.
>
> > Installing ABCL is not at all hard. Just grab a release (or checkout
> > from SVN), and run an Ant task to build it ("ant abcl.jar" from the
> > abcl directory). You get a single file, abcl.jar, which you can use as
> > a library, or lanuch as an application (it has a main class).
>
> > > My impression is that ABCL has quite a few bugs but from all the
> > > hammering and banging coming from SourceForge, it will eventually
> > > make it as a platform. I'm happy to cooperate with ABCL people in
> > > getting my work to run on top of their platform.
>
> > ABCL developers are concentrating their efforts on fixing bugs, both
> > ANSI compliance bugs and other bugs that affect important
> > applications. The latest few releases saw a significant drop in the
> > number of bugs. The easiest way to get a bug solved is probably to
> > write to the ABCL mailing list and say that you want to port your
> > library/application to ABCL. Also releases are being planned quite
> > regularly so if your bug has been marked as fixed the fix is probably
> > already on SVN, and will be in the next release.
>
> > > Btw does ABCL have threads?
>
> > Yes, it uses the JVM threading support. Special bindings are per-
> > thread as in all multithreaded Lisps I know of. I've never used
> > threads on ABCL so I don't know which multithreading primitives are
> > available, I think the usual lock, mutex and similar are there.
>
> > Alessio- Hide quoted text -
>
> > - Show quoted text -
>
> Yes; it says
> QUOTE
> One may use the Ant build tool to create ABCL.
>
> On UNIX, this should be as simple as
>
> unix$ ant abcl.wrapperwill create an executable shell-script
> wrapper 'abcl' in the top level directory which then may be invoked
> via:
>
> unix$ ./abcl
> UNQUOTE
> Except I'm running Windows and I chose the Lisp method. It failed
> with both SBCL and CLisp. I'll wait until they've put up their next
> release..
>
> Mark
On windows I'm using the ANT method too (it works for ABCL, Clojure,
and other things).
Just install ANT somewhere: http://www.apache.org/dist/ant/ant-current-bin.zip
I've also used the Lisp version to build it, but I had to change
certain things there.
Here is Apache ANT: http://www.apache.org/dist/ant/ - download
http://www.apache.org/dist/ant/ant-current-bin.zip
and add to the PATH folder it's bin folder - for example PATH=%PATH%;c:
\ant\bin\ if you decide to extract the zip into c:\ant
On May 6, 4:40 pm, "Dimiter \"malkia\" Stanev" <······@gmail.com>
wrote:
> On windows I'm using the ANT method too (it works for ABCL, Clojure,
> and other things).
>
> Just install ANT somewhere:http://www.apache.org/dist/ant/ant-current-bin.zip
>
> I've also used the Lisp version to build it, but I had to change
> certain things there.
Yes, I've used both methods on windows and linux; the Lisp-based build
requires a little configuration to work. Also I know that some months
ago they fixed some discrepancies between the two build systems.
MT> I've filed a bug report on ABCL and its been given as fixed but I find
MT> no code to download.
i guess it was in SVN repo.. hard to keep up with all these buzzwords, ye?
MT> Somebody on Qilang did manage to install ABCL under Linux
wow, such a feat..
installing ABCL (on Windows, Linux or Solaris -- it does not matter) is
as easy as it can be; if it is a problem, you must be retarded or something.
(nothing personal, i'm just on trolling spree now)