May 2012 - armedbear-devel - mailman3.common-lisp.net

[armedbear-devel] ASDF: Cannot handle the special form EXTENSIONS:TRULY-THE
by Blake McBride 24 Mar '13

24 Mar '13

Greetings, Trying to load a package with ASDF I ran into the following error: ASDF could not load because Cannot (currently) handle the special form EXTENSIONS:TRULY-THE. #<THREAD "interpreter" {4BC78066}>: Debugger invoked on condition of type SIMPLE-ERROR Cannot (currently) handle the special form TRULY-THE Restarts: ... I traced the problem to ASDF and not the package I was attempting to load. Does anyone know anything about this? (I am running the latest SVN head of ABCL) Thanks. Blake McBride

6 14

[armedbear-devel] Double printing of the prompt
by Blake McBride 12 Aug '12

12 Aug '12

Greetings, The latest version of ABCL is double printing the prompt at times as follows: Armed Bear Common Lisp 1.1.0-dev-svn-13783 Java 1.6.0_29 Apple Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.465 seconds. Startup completed in 1.453 seconds. Type ":help" for a list of available commands. CL-USER(1): 3 3 CL-USER(2): 'hello HELLO CL-USER(3): '(a b c) (A B C) CL-USER(4): nil NIL CL-USER(5): CL-USER(5): 77 77 CL-USER(6): (cdr '(hello)) NIL CL-USER(7): nil NIL CL-USER(8): CL-USER(8): 3 3 CL-USER(9):

3 3

[armedbear-devel] destroy-thread and unwind-protect
by James Lawrence 08 Aug '12

08 Aug '12

(defun test-cleanup () (let* ((cleanedp nil) (thread (threads:make-thread (lambda () (unwind-protect (sleep 999) (setf cleanedp t)))))) (sleep 0.5) (threads:destroy-thread thread) (sleep 0.5) cleanedp)) (test-cleanup) ABCL-1.0.0 and ABCL-0.27.0 return NIL. Other implementations I tested all return T -- Allegro, Clozure, LispWorks, SBCL (changing "threads" to "bordeaux-threads"). Of course this isn't a bug since ABCL is free to do what it wishes. Does ABCL wish that?

5 5

[armedbear-devel] Patch to quicklisp/cffi-0.7.1 for abcl-1.1.0-dev
by Mark Evenson 30 May '12

30 May '12

Mebbe [this can help somewhat with the problems loading JNA automatically for CFFI on ABCL][1]. I still need to figure out exactly what is broken under which JVM/OS combinations. Interesting stuff in analyzing regressions. [1]: http://slack.net/~evenson/quicklisp/cffi-abcl-1.1.0-dev-20120530a.patch -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

[armedbear-devel] Is anybody interested in jfli-abcl?
by Alex Mizrahi 29 May '12

29 May '12

jfli-abcl, basically, allows one to quickly create Lisp function wrappers for Java classes. E.g. (def-java-class "java.sql.DriverManager") (use-package :|java.sql|) (DriverManager.getConnection ...) The benefit over java:jcall and JSS is that it looks more-or-less like normal Lisp function calls, pretty similar to a wrapper you could write yourself. Also, potentially, it might carry less runtime overhead because everything can be resolved at compile-time. And if you use SLIME, auto-completion works. It doesn't like mixed case, though, so you need to write it like (|java.sql|:drivermanager.getcollection ...) Still, better than nothing. As far as I can tell, jfli-abcl isn't currently maintained. But as I'm used to jfli-abcl I maintain my own version with some fixes. If there is any interest in jfli-abcl I could, perhaps,. publish my version and polish it a bit. (I'm personally not interested in new-class functionality which allows one to create Java class from Lisp.) (I've found this updated version: https://gist.github.com/avodonosov/abcl-idea/blob/master/src/abclidea/lisp/… But haven't yet checked if it works with latest ABCL and what are improvements against old one.)

6 11

[armedbear-devel] Fwd: Is anybody interested in jfli-abcl?
by Anton Vodonosov 28 May '12

28 May '12

[forwarding Alessio's reply to the list - was my mistake to send the previous letter to him directly, instead of Reply All] ----------------------------------------------------------------------------------------------------- 28.05.2012, 17:25, "Alessio Stalla" <alessiostalla(a)gmail.com>: On Mon, May 28, 2012 at 3:18 PM, Anton Vodonosov <avodonosov(a)yandex.ru> wrote: > 28.05.2012, 17:08, "Alessio Stalla" <alessiostalla(a)gmail.com>: >> On Mon, May 28, 2012 at 2:57 PM, Anton Vodonosov <avodonosov(a)yandex.ru> wrote: >>> 28.05.2012, 16:22, "Anton Vodonosov" <avodonosov(a)yandex.ru>: >>>> If independent version of new-class is not ready, probably it's possible to >>>> deliver runtime-class a a contrib [...] >>> I've checked the ABCL sources and see that runtime-class.lisp is now >>> included into ABCL. So we don't even need to create a contrib for it. >>> >>> Could anyone help me understand the problem with new-class, why removing >>> it? Namely, when the asm.jar will be needed, >>> >>> What I understand now: >>> >>> 1. abcl-jfli function jrc calls java:jnew-runtime-class. >>> 2. java:jnew-runtime-class needs asm.jar. >> 2. is wrong. jnew-runtime-class used to require asm, was disabled, and >> was reintroduced (incomplete) without a dependency to asm and with a >> slightly different API. In other words, jrc right now is probably >> broken. >> >> To restore jrc right now, you'd need to restore runtime-class.lisp >> from version control, and bundle it in contrib under a different >> package (assuming it still works with present-day asm). > Ah I see, it's different runtime-class. Thanks for the explanation. >> That would be possible, but I object that having 2 different APIs for >> the same thing is a potential source for confusion. > Yes, but it's also the way of software evolution: we use some API, > notice it's deficiencies, deprecate it and introduce new, better > API. Let me note that it could have been called runtime-class2 > to avoid confusion and compatibility issues. Yes, maybe it could, but the situation as I saw it was that runtime-class was effectively dead code nobody was using (and in fact, until now nobody asked about it on this list). > Probably now, if packaging the old runtime-class as a contrib, we will > need to rename it to old-runtime-class, or even deprecated-runtime-class. Or just deprecated:runtime-class, or backwards-compatibility:..., so you can shadowing-import-from it and forget about it. > Could you explain about the asm.jar dependency in case of the > deprecated-runtime-class? Would it be a load-time dependency, > or a call-time dependency? IIRC, it is a call-time dependency, but note that I never used the old runtime-class, so I may be wrong. Alessio -- Some gratuitous spam: http://ripple-project.org Ripple, social credit system http://villages.cc Villages.cc, Ripple-powered community economy http://common-lisp.net/project/armedbear ABCL, Common Lisp on the JVM http://code.google.com/p/tapulli my current open source projects http://www.manydesigns.com/ ManyDesigns Portofino, open source model-driven Java web application framework

1 1

[armedbear-devel] Fwd: Is anybody interested in jfli-abcl?
by Anton Vodonosov 28 May '12

28 May '12

28.05.2012, 17:08, "Alessio Stalla" <alessiostalla(a)gmail.com>: > On Mon, May 28, 2012 at 2:57 PM, Anton Vodonosov <avodonosov(a)yandex.ru> wrote: >> 28.05.2012, 16:22, "Anton Vodonosov" <avodonosov(a)yandex.ru>: >>> If independent version of new-class is not ready, probably it's possible to >>> deliver runtime-class a a contrib [...] >> I've checked the ABCL sources and see that runtime-class.lisp is now >> included into ABCL. So we don't even need to create a contrib for it. >> >> Could anyone help me understand the problem with new-class, why removing >> it? Namely, when the asm.jar will be needed, >> >> What I understand now: >> >> 1. abcl-jfli function jrc calls java:jnew-runtime-class. >> 2. java:jnew-runtime-class needs asm.jar. > 2. is wrong. jnew-runtime-class used to require asm, was disabled, and > was reintroduced (incomplete) without a dependency to asm and with a > slightly different API. In other words, jrc right now is probably > broken. > > To restore jrc right now, you'd need to restore runtime-class.lisp > from version control, and bundle it in contrib under a different > package (assuming it still works with present-day asm). Ah I see, it's different runtime-class. Thanks for the explanation. > That would be possible, but I object that having 2 different APIs for > the same thing is a potential source for confusion. Yes, but it's also the way of software evolution: we use some API, notice it's deficiencies, deprecate it and introduce new, better API. Let me note that it could have been called runtime-class2 to avoid confusion and compatibility issues. Probably now, if packaging the old runtime-class as a contrib, we will need to rename it to old-runtime-class, or even deprecated-runtime-class. Could you explain about the asm.jar dependency in case of the deprecated-runtime-class? Would it be a load-time dependency, or a call-time dependency? Best regards, - Anton

1 0

[armedbear-devel] abcl trunk build doesn't work for me
by Alex Mizrahi 27 May '12

27 May '12

hi When I run ABCL built from trunk I get this error when I run it: ---- Armed Bear Common Lisp 1.1.0-dev Java 1.6.0_21 Sun Microsystems Inc. OpenJDK 64-Bit Server VM Low-level initialization completed in 1.072 seconds. org.armedbear.lisp.IntegrityError at org.armedbear.lisp.Primitives$pf_error.execute(Primitives.java:1577) at org.armedbear.lisp.Primitive.execute(Primitive.java:113) at org.armedbear.lisp.Symbol.execute(Symbol.java:802) at org.armedbear.lisp.Lisp.error(Lisp.java:380) at org.armedbear.lisp.Load.loadSystemFile(Load.java:276) at org.armedbear.lisp.Load$load_system_file.execute(Load.java:703) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:550) at org.armedbear.lisp.Lisp.eval(Lisp.java:515) at org.armedbear.lisp.Load.loadStream(Load.java:570) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:538) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:428) at org.armedbear.lisp.Load.loadSystemFile(Load.java:327) at org.armedbear.lisp.Interpreter.initializeLisp(Interpreter.java:172) at org.armedbear.lisp.Interpreter.createDefaultInstance(Interpreter.java:102) at org.armedbear.lisp.Main$1.run(Main.java:46) at java.lang.Thread.run(Thread.java:679) ERROR placeholder called with arguments: Failed to find loadable system file 'autoloads' in boot classpath. ---- I tried both version from SVN and from Mark's (?) hg repo, upgraded OpenJDK to 1.6.0_21, upgraded ant from 1.7.1 to 1.8.0 (that's top version I can get via package manager for Ubuntu 10.04). I was able to build and run ABCL 1.0.1. I noticed a bug on abcl 1.0.1: in certain rather contrived code return-from was ignored, i.e. evaluation continued as if it wasn't called. And was going to check whether it's present in the latest devel version before investigating it further.

4 7

[armedbear-devel] Connection to database via JDBC and classpath
by Francisco Vides Fernández 24 May '12

24 May '12

Hello everyone I intend to use ABCL in one of my projects. I've started to connectiing to a postgresq database via jdbc. I've tried something like: -------8<------- (add-to-classpath (merge-pathnames #p".m2/repository/postgresql/postgresql/8.4-702.jdbc4/postgresql-8.4-702.jdbc4.jar" (user-homedir-pathname))) (jstatic "forName" "java.lang.Class" "org.postgresql.Driver") -------8<------- But it always returns -------8<------- Java exception 'java.lang.ClassNotFoundException: org.postgresql.Driver'. [Condition of type JAVA-EXCEPTION] -------8<------- The jar file exists, and has the proper class inside. I've read the manual, and googled a bit, but still get the same error. I'm using Ubuntu Linux, with OpenJDK 1.6.0_24, and the latest and greatest ABCL downloaded as a binary from ABCL website. Can someone point me what I'm doing wrong? Many thanks for this great project!! -- +----------------- | Francisco Vides Fernández <fvides(a)neoclinic.es> | Director Ejecutivo | Teléfono fijo: 952 60 29 59 | Fax: 952 60 29 59 | Neoclinic http://www.neoclinic.es/ +------

6 13

[armedbear-devel] ABCL has an incorrect belief about hostname and cpu in its fasl storage
by Paul Nathan 18 May '12

18 May '12

Dear all, I installed Armed Bear Common Lisp 1.0.1-svn-13750-13751 in order to run it on my OSX 10.6 (Snow Leopard) 64-bit system (Darwin 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:32:41 PDT 2011; root:xnu-1504.15.3~1/RELEASE_X86_64 x86_64), for the purpose of executing cl-test-grid. However, I observed that the fasls were being stored in ~/.cache/common-lisp/abcl-1.0.1-svn-13750-13751-fasl38-solaris-x86 You will quickly note that my system is neither solaris nor x86. However, I checked some of the environment settings: java -jar abcl.jar Armed Bear Common Lisp 1.0.1-svn-13750-13751 Java 1.6.0_31 Apple Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.619 seconds. Startup completed in 1.511 seconds. Type ":help" for a list of available commands. CL-USER(1): *features* (:JAVA-1.6 :ARMEDBEAR :ABCL :COMMON-LISP :ANSI-CL :UNIX :DARWIN :CDR6) CL-USER(2): (machine-instance) "elendil.local" CL-USER(3): (machine-type) "X86_64" CL-USER(4): (software-type) "Mac OS X" CL-USER(5): (software-version) "10.6.8" CL-USER(6): (machine-version) NIL And they turn out correct. I am not a regular ABCL user, so pardon me if this is already known. If an OSX Snow Leopard system is not available for testing, I volunteer my time and machine to test a patch. Regards, Paul Nathan

2 2

[armedbear-devel] One (probably) stupid question
by Francisco Vides Fernández 18 May '12

18 May '12

I'm aware that this must be a stupid question, but after googling for a while can't find the right answer: How can I invoke a method with a boolean as an argument. I try to do the following: ---8<--- (let* ((jlclass (jclass "java.lang.Class")) (for-name (jmethod jlclass "forName" (jclass "java.lang.String") (jclass "boolean") (jclass "java.lang.ClassLoader")))) (jstatic for-name jlclass "org.postgresql.Driver" t (get-current-classloader))) ---8<--- But it raises the error: The value T is not of class boolean [Condition of type ERROR] I tried replacing '(jclass "boolean") for '(jclass "java.lang.Boolean"), but in that case it doesn't find the for-name method. How am I supposed to invoke the method! Thanks in advance! -- +----------------- | Francisco Vides Fernández <fvides(a)dedaloingenieros.com> | Gerente | Teléfono fijo: 952 60 29 59 | Fax: 952 60 29 59 | igaleno http://www.igaleno.com/ +------

2 1

[armedbear-devel] sockets in CLISP
by Santiago Carbonell 18 May '12

18 May '12

Hi, I'm trying to send some strings using the format function in LISP to a sockets but always I obtain NIL I'm using this function: (defun sockets_fun() (WITH-OPEN-STREAM (socket (SOCKET:SOCKET-CONNECT 49729 "localhost")) (let ((*standard-output* socket)) (format socket "The color is ~A" "red") (force-output socket) (finish-output nil) ))) But always I obtain NIL in the socket Instead of that function I've tried to use this another function: (defun geetings() (print "hi")) and works fine, appears hi in the socket Why there are problems with sockets with the format function? Thanks

2 1

[armedbear-devel] JSS issues: bug in jss::with-constant-signature, jss::invoke-find-method?
by Jonathan P. Bona 16 May '12

16 May '12

I'm working with Alan Ruttenberg to port LSW from the old version of JSS to the JSS that is now part of abcl-contrib. We've run into the following bug when using with-constant-signature: ; these first two work fine: (#"substring" "some string" 2 4) ; "me" (#"substring" "some string" 2) ; "me string" ; and so does this (with-constant-signature ((substring "substring")) (substring "some string" 2 4)) ; "me" ; but this breaks: (with-constant-signature ((substring "substring")) (substring "some string" 2)) ; Wrong number of arguments for public java.lang.String java.lang.String.substring(int,int): expected 2, got 1 ; [Condition of type PROGRAM-ERROR] A problem seems to be in jss::invoke-find-method, which is finding the two argument version of java.lang.String.substring no matter how many arguments its given: (jss::invoke-find-method "substring" "this is a string" '(1)) ; should return the java.lang.String.substring method with one int arg ; #<method public java.lang.String java.lang.String.substring(int,int)> (jss::invoke-find-method "substring" "this is a string" '(1 2) ) ; #<method public java.lang.String java.lang.String.substring(int,int)> (jss::invoke-find-method "substring" "this is a string" '(1 2 3 4 5 6 7 8) ) ; should be an error ; #<method public java.lang.String java.lang.String.substring(int,int)> - Jonathan Bona

3 5

[armedbear-devel] how to redirect format function to a socket stream
by Santiago Carbonell 13 May '12

13 May '12

Hi, I've a socket stream named "socket" in this port and host: 50362 and localhost I've written this function to redirect format function to the socket but only appears NIL. How can I redirect format t lisp function to a socket? (defun colors() (WITH-OPEN-STREAM (socket (SOCKET:SOCKET-CONNECT 50362 "localhost")) (let ((*standard-output* socket)) (format t "The color is ~A" "red") ))) Thanks

2 1

[armedbear-devel] Error building abcl-servet
by aditya siram 09 May '12

09 May '12

Hi all, I am trying to build abcl-servlet and running into the following error: > ant -find build.xml dist -Dlibs.CopyLibs.classpath=/home/deech/Java/netbeans/java/ant/extra/org-netbeans-modules-java-j2seproject-copylibstask.jar ... /home/deech/Lisp/abcl-servlet/build.xml:36: org.armedbear.lisp.Interpreter$UnhandledCondition: Unhandled lisp condition: #<MISSING-COMPONENT {98F805}> at org.armedbear.lisp.Interpreter$1.execute(Interpreter.java:568) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2794) at org.armedbear.lisp.Symbol.execute(Symbol.java:796) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.debug_6.execute(debug.lisp:105) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:124) at org.armedbear.lisp.Symbol.execute(Symbol.java:808) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.debug_7.execute(debug.lisp:114) at org.armedbear.lisp.Symbol.execute(Symbol.java:785) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.signal_2.execute(signal.lisp:63) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:124) at org.armedbear.lisp.Symbol.execute(Symbol.java:808) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.asdf_250.execute(asdf.lisp:1692) at org.armedbear.lisp.LispThread.execute(LispThread.java:633) at org.armedbear.lisp.asdf_241.execute(asdf.lisp:1633) at org.armedbear.lisp.Symbol.execute(Symbol.java:785) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.asdf_249.execute(asdf.lisp:1692) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:112) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2794) at org.armedbear.lisp.Symbol.execute(Symbol.java:796) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.asdf_248.execute(asdf.lisp:1692) at org.armedbear.lisp.clos_297.execute(clos.lisp:2120) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.clos_282.execute(clos.lisp:1934) at org.armedbear.lisp.Symbol.execute(Symbol.java:796) at org.armedbear.lisp.clos_275.execute(clos.lisp:1768) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:112) at org.armedbear.lisp.StandardGenericFunction.execute(StandardGenericFunction.java:138) at org.armedbear.lisp.Symbol.execute(Symbol.java:796) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.asdf_239.execute(asdf.lisp:1623) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:101) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2791) at org.armedbear.lisp.Symbol.execute(Symbol.java:796) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.asdf_238.execute(asdf.lisp:1623) at org.armedbear.lisp.clos_297.execute(clos.lisp:2120) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.clos_282.execute(clos.lisp:1934) at org.armedbear.lisp.Symbol.execute(Symbol.java:796) at org.armedbear.lisp.clos_275.execute(clos.lisp:1768) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:101) at org.armedbear.lisp.StandardGenericFunction.execute(StandardGenericFunction.java:131) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2791) at org.armedbear.lisp.Symbol.execute(Symbol.java:796) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.clos_244.execute(clos.lisp:1381) at org.armedbear.lisp.Symbol.execute(Symbol.java:796) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.clos_247.execute(clos.lisp:1400) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:101) at org.armedbear.lisp.StandardGenericFunction.execute(StandardGenericFunction.java:131) at org.armedbear.lisp.Symbol.execute(Symbol.java:785) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.asdf_493.execute(asdf.lisp:2565) at org.armedbear.lisp.LispThread.execute(LispThread.java:633) at org.armedbear.lisp.asdf_241.execute(asdf.lisp:1633) at org.armedbear.lisp.Symbol.execute(Symbol.java:785) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.asdf_492.execute(asdf.lisp:2565) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:112) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2794) at org.armedbear.lisp.Symbol.execute(Symbol.java:796) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.asdf_491.execute(asdf.lisp:2565) at org.armedbear.lisp.clos_295.execute(clos.lisp:2016) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.clos_282.execute(clos.lisp:1934) at org.armedbear.lisp.Symbol.execute(Symbol.java:796) at org.armedbear.lisp.clos_275.execute(clos.lisp:1768) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:112) at org.armedbear.lisp.StandardGenericFunction.execute(StandardGenericFunction.java:138) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2794) at org.armedbear.lisp.Symbol.execute(Symbol.java:796) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.clos_244.execute(clos.lisp:1381) at org.armedbear.lisp.Symbol.execute(Symbol.java:796) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.clos_247.execute(clos.lisp:1400) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:112) at org.armedbear.lisp.StandardGenericFunction.execute(StandardGenericFunction.java:138) at org.armedbear.lisp.Symbol.execute(Symbol.java:796) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.Lisp.funcall(Lisp.java:174) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2842) at org.armedbear.lisp.Primitive.execute(Primitive.java:148) at org.armedbear.lisp.Symbol.execute(Symbol.java:820) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.asdf_497.execute(asdf.lisp:2625) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:101) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:548) at org.armedbear.lisp.Lisp.eval(Lisp.java:513) at org.armedbear.lisp.Lisp.progn(Lisp.java:682) at org.armedbear.lisp.Primitives$sf_eval_when.execute(Primitives.java:3874) at org.armedbear.lisp.Lisp.eval(Lisp.java:503) at org.armedbear.lisp.Load.loadStream(Load.java:567) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:535) at org.armedbear.lisp.Load.load(Load.java:670) at org.armedbear.lisp.Load$_load_returning_last_result.execute(Load.java:648) at org.armedbear.lisp.Symbol.execute(Symbol.java:820) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.load_2.execute(load.lisp:46) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:101) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:548) at org.armedbear.lisp.Lisp.eval(Lisp.java:513) at org.armedbear.lisp.Lisp.progn(Lisp.java:682) at org.armedbear.lisp.SpecialOperators$sf_progn.execute(SpecialOperators.java:275) at org.armedbear.lisp.Lisp.eval(Lisp.java:503) at org.armedbear.lisp.Primitives$sf_multiple_value_prog1.execute(Primitives.java:3969) at org.armedbear.lisp.Lisp.eval(Lisp.java:503) at org.armedbear.lisp.Primitives$sf_unwind_protect.execute(Primitives.java:3840) at org.armedbear.lisp.Lisp.eval(Lisp.java:503) at org.armedbear.lisp.Lisp.progn(Lisp.java:682) at org.armedbear.lisp.SpecialOperators._let(SpecialOperators.java:169) at org.armedbear.lisp.SpecialOperators$sf_let.execute(SpecialOperators.java:101) at org.armedbear.lisp.Lisp.eval(Lisp.java:503) at org.armedbear.lisp.Lisp.eval(Lisp.java:506) at org.armedbear.lisp.Lisp.eval(Lisp.java:511) at org.armedbear.lisp.Lisp.progn(Lisp.java:682) at org.armedbear.lisp.SpecialOperators$sf_progn.execute(SpecialOperators.java:275) at org.armedbear.lisp.Lisp.eval(Lisp.java:503) at org.armedbear.lisp.SpecialOperators._let(SpecialOperators.java:146) at org.armedbear.lisp.SpecialOperators$sf_let.execute(SpecialOperators.java:101) at org.armedbear.lisp.Lisp.eval(Lisp.java:503) at org.armedbear.lisp.Lisp.eval(Lisp.java:506) at org.armedbear.lisp.Lisp.progn(Lisp.java:682) at org.armedbear.lisp.SpecialOperators._let(SpecialOperators.java:169) at org.armedbear.lisp.SpecialOperators$sf_let.execute(SpecialOperators.java:101) at org.armedbear.lisp.Lisp.eval(Lisp.java:503) at org.armedbear.lisp.Lisp.progn(Lisp.java:682) at org.armedbear.lisp.SpecialOperators._let(SpecialOperators.java:169) at org.armedbear.lisp.SpecialOperators$sf_let.execute(SpecialOperators.java:101) at org.armedbear.lisp.Lisp.eval(Lisp.java:503) at org.armedbear.lisp.Primitives$pf__eval.execute(Primitives.java:345) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:548) at org.armedbear.lisp.Lisp.eval(Lisp.java:513) at org.armedbear.lisp.Lisp.progn(Lisp.java:682) at org.armedbear.lisp.Primitives$sf_block.execute(Primitives.java:3733) at org.armedbear.lisp.Lisp.eval(Lisp.java:503) at org.armedbear.lisp.Lisp.progn(Lisp.java:682) at org.armedbear.lisp.Closure.bindParametersAndExecute(Closure.java:451) at org.armedbear.lisp.Closure.execute(Closure.java:484) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:548) at org.armedbear.lisp.Lisp.eval(Lisp.java:513) at org.armedbear.lisp.Lisp.progn(Lisp.java:682) at org.armedbear.lisp.SpecialOperators._let(SpecialOperators.java:169) at org.armedbear.lisp.SpecialOperators$sf_let.execute(SpecialOperators.java:101) at org.armedbear.lisp.Lisp.eval(Lisp.java:503) at org.armedbear.lisp.Lisp.progn(Lisp.java:682) at org.armedbear.lisp.Primitives$sf_block.execute(Primitives.java:3733) at org.armedbear.lisp.Lisp.eval(Lisp.java:503) at org.armedbear.lisp.Lisp.progn(Lisp.java:682) at org.armedbear.lisp.Closure.bindParametersAndExecute(Closure.java:451) at org.armedbear.lisp.Closure.execute(Closure.java:561) at org.armedbear.lisp.scripting.AbclScriptEngine.eval(AbclScriptEngine.java:234) at org.armedbear.lisp.scripting.AbclScriptEngine.eval(AbclScriptEngine.java:243) at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:247) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tools.ant.util.ReflectUtil.invoke(ReflectUtil.java:108) at org.apache.tools.ant.util.ReflectWrapper.invoke(ReflectWrapper.java:81) at org.apache.tools.ant.util.optional.JavaxScriptRunner.evaluateScript(JavaxScriptRunner.java:103) at org.apache.tools.ant.util.optional.JavaxScriptRunner.executeScript(JavaxScriptRunner.java:67) at org.apache.tools.ant.taskdefs.optional.Script.execute(Script.java:52) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:390) at org.apache.tools.ant.Target.performTasks(Target.java:411) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) at org.apache.tools.ant.Project.executeTarget(Project.java:1368) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) at org.apache.tools.ant.Project.executeTargets(Project.java:1251) at org.apache.tools.ant.Main.runBuild(Main.java:809) at org.apache.tools.ant.Main.startAnt(Main.java:217) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109) My ABCL version is 1.0.1. -deech

2 3

[armedbear-devel] Patch with improvements to stable-sort and sort
by Jorge Tavares 07 May '12

07 May '12

Hi, I send in attach a patch with further improvements to sort and stable-sort for sequences other than lists. In short, the patch includes a merge sort for vectors. To allow different types I've written the algorithm using macros and these generate the appropriate code according to the vector type. This way the algorithm is in a single place avoiding duplication of code. The macros also take care of the situation of when no key is present, avoiding the use of unnecessary funcalls. The quicksort algorithm was also refactored in the same way. I've tested the algorithms and they seem to be working correct. Stable sort is now considerably faster since the fix before converted the sequences to a list and used the sort-list function. I've made some benchmarking to verify how fast is sort and stable-sort. The tables with the results are also in a file sent in attach [1]. For stable-sort I've compare the current trunk version with the patched one while for sort I've compared 1.0.1, the trunk and with the patch. For unsorted vectors sort has a speed up of 7.5 from 1.0.1 and this considers only vectors of size 8 to 8192 (1.0.1 hits the worst-case quite fast). For stable-sort the speed up is around 90.2 from vectors of size 8 to 32768. The sort functions become even faster for the nearly sorted vectors. I think the tables clearly show the speed-ups :-) Naturally these benchmarks cannot be used to draw definite conclusions since they lack rigorous testing but I think they can provide some indications. With this patch, I think ABCL gets good performant sorting functions, especially for large vectors. As for lists, I haven't looked at them so probably they can also be improved (but I really don't know). Cheers, Jorge [1] The tables result from the generation of simple-vectors of sizes 8 to 524288 (powers of 2 from 3 to 19) with distinct integer: unsorted, nearly sorted (distances 0, 4 and 16), sorted and reversed sorted. The nearly sorted vectors were constructed by selecting pairs where they would swap with a neighbor at a certain distance. I did 100 runs and timed only the sorting operation. The tables contain the averages of the 100 runs. They were performed in an iMac (2.5GHz i5, 4GB) with Mac OS X 10.7.3. -- http://jorgetavares.com

2 2

[armedbear-devel] *load-pathname* with incorrect value
by wl chiu 06 May '12

06 May '12

Hi again, I have a file: ---- load-pathname.lisp ----- (print *load-pathname*) ----------------------------- When loaded, I get this: java.exe -cp "abcl.jar" org.armedbear.lisp.Main --load load-path.lisp==> #P"load-path.lisp" According to CLHS, I believe this is wrong? During a call to load, *load-pathname* is bound to the pathname denoted by the the first argument to load, merged against the defaults; that is, it is bound to (pathname (merge-pathnames filespec)). During the same time Cheers, Wei-Lun Chiu

2 1