armedbear-devel May 2012

armedbear-devel@common-lisp.net

16 participants
17 discussions

[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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel May 2012