armedbear-devel May 2010

armedbear-devel@common-lisp.net

14 participants
36 discussions

[armedbear-devel] json-rpc?
by Axel Rauschmayer 27 Apr '11

27 Apr '11

I think ABCL would make an excellent Ajax server. As such, it would have to support json-rpc. Any suggestions as to how to make this happen? The first part is obviously the server, where the two choices that I can see are Hunchentoot and a servlet container such as Tomcat. In the latter case, I would expect to use a technique like abcl-web (which seems a little bit complicated, but doable). The second part is the JSON parsing. How would I do that? Via CL-JSON? Via Yason? Via a Java library? Sorry for these newbie questions. I’m just getting started with Common Lisp and ABCL. Thanks, Axel -- Axel.Rauschmayer(a)ifi.lmu.de http://www.pst.ifi.lmu.de/~rauschma/

4 10

[armedbear-devel] is there a good method to read/write java byte arrays?
by David Kirkman 01 Dec '10

01 Dec '10

Does anybody know of a good way to serialize lisp objects into java byte arrays? I've got a method that almost works, but if anybody has a better/canonical way of doing this I'd love to know! I've been trying to use cl-store, outputting to a stream I create with sys::%make-byte-array-output-stream, and then getting the byte array with sys::%get-output-stream-bytes. I've only been using abcl for a few days, and I found those functions by grepping through the sources, so I apologize if I'm inviting trouble by messing around with functions you never meant users to play with. Anyway, the output works fine. But I can't find the equivalent of sys::%make-byte-array-output-stream to create an input stream, so I attempted to make my own (defun make-byte-array-input-stream (bytes) (let ((bis (jnew (jconstructor "java.io.ByteArrayInputStream" "[B") bytes))) (jnew (jconstructor "org.armedbear.lisp.Stream" "java.io.InputStream") bis))) This almost seems to work, but if I try to use it I get a java exception and a (very long) java stack trace. I put a copy of the stack trace at the end of this message. Here is an expression which will produce the problem in abcl-18.1 (let ((outbytes (with-open-stream (stream (sys::%make-byte-array-output-stream)) (write-byte 101 stream) (sys::%get-output-stream-bytes stream)))) ;; now open the byte array as an input stream (with-open-stream (stream (make-byte-array-input-stream outbytes)) ;; all works fine until here (read-byte stream))) I don't need to read the stream, asking for the element type of the input stream is enough to cause trouble ... (let ((outbytes (with-open-stream (stream (sys::%make-byte-array-output-stream)) (write-byte 101 stream) (sys::%get-output-stream-bytes stream)))) (with-open-stream (stream (make-byte-array-input-stream outbytes)) (stream-element-type stream))) I can fix the problem and make my code work, but I have to change Stream.java to make it work. I added elementType = UNSIGNED_BYTE_8; to the initAsBinaryInputStream(InputStream in) method. I did this because the stack trace suggested that the problem was stream_element_type.execute() was returning null. Anyway, that fixes the problem, and I'm happily serializing/deserializing lisp objects to a Berkeley DB ... so I guess I'm happy! But I don't know how rational that fix is, because I don't really know how Stream is supposed to work. I suspect that my 'fix' probably breaks something else that I'm just not using yet. Any ideas? Thanks, -david k. Here's the first few lines of the stack trace ... CL-USER(2): Debugger invoked on condition of type SIMPLE-TYPE-ERROR: java.lang.NullPointerException at org.armedbear.lisp.Primitives$49.execute(Primitives.java:795) at org.armedbear.lisp.Symbol.execute(Symbol.java:781) at org.armedbear.lisp.LispThread.execute(LispThread.java:579) at org.armedbear.lisp.print_8.execute(print.lisp:127) at org.armedbear.lisp.Symbol.execute(Symbol.java:781) at org.armedbear.lisp.LispThread.execute(LispThread.java:579) at org.armedbear.lisp.print_14.execute(print.lisp:279) ... (and it ends with) at org.armedbear.lisp.AutoloadedFunctionProxy.execute(AutoloadedFunctionProxy.java:139) at org.armedbear.lisp.Symbol.execute(Symbol.java:760) at org.armedbear.lisp.LispThread.execute(LispThread.java:546) at org.armedbear.lisp.top_level_51.execute(top-level.lisp:415) at org.armedbear.lisp.AutoloadedFunctionProxy.execute(AutoloadedFunctionProxy.java:139) at org.armedbear.lisp.LispThread.execute(LispThread.java:546) at org.armedbear.lisp.Interpreter.run(Interpreter.java:310) at org.armedbear.lisp.Main$1.run(Main.java:50) at java.lang.Thread.run(Thread.java:613) READ-BYTE: unsupported element type Debugger invoked on condition of type ERROR: Caught java.lang.NullPointerException. Restarts: 0: TOP-LEVEL Return to top level.

3 14

[armedbear-devel] CLOS thread safety
by Erik Huelsmann 03 Oct '10

03 Oct '10

Hi David, > Are there any known thread safety issues with CLOS? I've been > getting some weird MOP errors that I made go away by redefining > slot-value such that it has to acquire a global lock before it can do > anything. I assume that the problem is in my code: but the threads > that are executing when I get the failures share no code (or > variables), and every time the errors pop up slot-value is on the > callstack someplace. Well, there have not been any specific threading issues mentioned. Over two years ago, back when I started doing ABCL, there were threading issues which looked like threading issues in CLOS. They turned out to be threading issues in the compiler though. Having said that, I see there have not been taken synchronization measures on a high level: there are no locks and threads:synchronized-on blocks in clos.lisp. There are some synchronized calls on the Java side; I'm not sure the low-level protection is good enough to maintain consistency though. Can you share some examples which show the issues here? Adding thread-safety to clos.lisp - in specific, targeted places - should be well doable. Bye, Erik.

5 15

[armedbear-devel] r12666 breaks ASDF compilation on Linux
by Alessio Stalla 17 Jul '10

17 Jul '10

I just tried abcl 0.20 with Snow, and compilation (done with asdf:compile-op) fails early with: Compilation failed: Not an absolute pathname #P"\\___jar___file___root___\\**\\*.*" r11664 works fine. Sorry that I didn't check before the release, I remembered checking it not much time ago but evidently I was wrong (r12666 is two weeks old). Alessio

5 24

[armedbear-devel] generated abcl shell script executable
by Matthias Cords 08 Jun '10

08 Jun '10

Hi there, just a suggestion. would it be possible to change the generated "abcl" shell script to not use the -cp parameter to the java executable, but set up the classpath like e.g. so export CLASSPATH=`dirname $0`/dist/abcl.jar:$CLASSPATH and then invoke exec .../java org.armedbear.lisp.Main "$@" i.e. without the -cp parameter. This would result in the CLASSPATH environment variable that was in effect before the call to the abcl script to remain available to the lisp interpreter. i.e. jdbc driver classes etc. apart from that I think abcl is a great great piece of software making life a lot more convenient. thanks to everyone participating! Kindly, Matthias

4 3

[armedbear-devel] ABCL introductory user documentation
by Paul Reiners 07 Jun '10

07 Jun '10

Some introductory user documentation I wrote on ABCL if anyone's interested: http://www.automatous-monk.com/jvmlanguages/abcl/Armed_Bear_Common_Lisp.html It's spread across a bunch of slides right now, because I first prepared it as a multi-slide presentation. I think I want to combine it all into one HTML page later this week when I get around to it. At the very least, I want to give each slide a meaningful title so that the Table of Contents is more meaningful. Any criticism, constructive or destructive, is welcome. Paul

5 11

[armedbear-devel] ASDF 2.000 released!
by Faré 31 May '10

31 May '10

Dear ABCL hackers, I have finally released ASDF 2, officially starting with release 2.000. http://common-lisp.net/project/asdf/ ASDF 2 is an evolution of ASDF that tries to be backwards compatible with previous releases and their many extensions, while at the same time improving the user experience in many important ways. I have worked hard towards reaching the current state, which I believe is now suitable for release and for inclusion in all Common Lisp implementations. I thank all those who helped develop and test this release, including Robert P. Goldman, James Anderson, Juan-Jose Garcia-Ripoll, and many more. We welcome bug reports on our launchpad site: https://launchpad.net/asdf I'm using ASDF 2 at ITA. Recent versions are already included in ABCL, CCL, CMUCL, ECL. Several hackers have tried building plenty of packages with it. While it's far from my ideal of perfection, and admittedly only a relatively small limited of previous code, I believe it's enough of an advance over the previous generation of ASDF that I'd like to get it out to the world. The code has been extensively cleaned up while preserving previous semantics everywhere that it was well-defined. Our testing has revealed no regressions from ASDF 1. What has changed since ASDF 1 is documented at the following page: http://common-lisp.net/project/asdf/asdf/FAQ.html Improvements include: * portable naming of files wrt directory, type, host/device, etc. * a builtin user-configurable output translation mechanism, superseding asdf-binary-locations and previous hacks in common-lisp-controller and cl-launch. * a user-configurable source registry system for finding systems (the old *central-registry* is still available). * improved portability to many implementations. * improved support for Windows. * many bug fixes * better documentation * the test suite, while still largely incomplete, covers more cases and is more robust across implementations. * substantial performance improvements when processing large systems with thousands of components. * API improvements: load-system, system-relative-pathname, etc. * a sensible versioning system for ASDF 2 itself. * ASDF can be now be upgraded in a running lisp image. Using this in-place upgrade, ASDF releases can be decoupled from implementation releases. * better support for various extensions used by ECL and ABCL, and also by POIU, ASDF-DEPENDENCY-GROVEL. Pitfalls include: * Output translations is enabled by default. This may surprise some users, most of them in pleasant way (we hope), a few of them in an unpleasant way. It is trivial to disable output translations. Simply put (ASDF:DISABLE-OUTPUT-TRANSLATIONS) in a Lisp startup file. * Some systems in the large have been known not to play well with asdf output translations. They were easy to fix. The most likely issue is to have chaining of operations (e.g., a preprocessing before a load) where the INPUT-FILES of one operation are related to the OUTPUT-FILES of another. In this case many issues can be avoided by simply making the OUTPUT-FILES primary, and having later operations' INPUT-FILES be defined in terms of the OUTPUT-FILES of other operations instead of directly defining the INPUT-FILES. It is also easy to disable output translations or override its configuration. * ASDF 2 output translations do not work with ASDF-Binary-Locations. They replace A-B-L, and include a compatibility mode to emulate your previous A-B-L configuration. See ENABLE-ASDF-BINARY-LOCATIONS-COMPATIBILITY. But you shouldn't load ABL on top of ASDF 2. * A notable performance bug on SBCL (and possibly other implementations, too): the recursive search of configured paths in your source-registry with (DIRECTORY "/configured/path/**/*.asd") can waste a few seconds when initially searching for asd files (depending on your configuration). If it is essential for you to avoid this pause, you should override the default source-registry and only use non-recursive :DIRECTORY options (or shallow trees). Or just keep the default directory hierarchies being searched empty. * Windows support may have been insufficiently well tested. As to how to best include ASDF in your implementation, here is an excerpt from the FAQ section of our manual: 12.3.2 "I'm a Common Lisp implementation vendor. When and how should I upgrade ASDF?" Starting with current candidate releases of ASDF 2, it should always be a good time to upgrade to a recent version of ASDF. You may consult with the maintainer for which specific version they recommend, but the latest RELEASE should be correct. We trust you to thoroughly test it with your implementation before you release it. If there are any issues with the current release, it's a bug that you should report upstream and that we will fix ASAP. In order to report bugs, please use the launchpad bug tracker. Information about launchpad is contained in the manual. As to how to include ASDF, we recommend the following: * If ASDF isn't installed yet, then (require :asdf) should load the version of ASDF that is bundled with your system. You may have it load some other version configured by the user, if you allow such configuration. * If your system provides a mechanism to hook into CL:REQUIRE, then it would be nice to add ASDF to this hook the same way that SBCL, ECL, CMUCL, CCL and ABCL do. * You may, like SBCL, have ASDF be implicitly used to require systems that are bundled with your Lisp distribution. If you do have a few magic systems that come with your implementation in a precompiled way such that one should only use the binary version that goes with your distribution, like SBCL does, then you should add them in the beginning of wrapping-source-registry. Please consult with the ASDF maintainers about that. * If you have magic systems as above, then we explicitly ask you to NOT distribute asdf.asd as part of those magic systems. You should still include the file asdf.lisp in your source distribution and precompile it in your binary distribution, but asdf.asd if included at all, should be secluded from the magic systems, in a separate file hierarchy, or you may otherwise rename the system and its file to e.g. asdf-ecl and asdf-ecl.asd, or sb-asdf and sb-asdf.asd. If you make asdf.asd a magic system, then users will no longer be able to upgrade ASDF using ASDF itself. It is helpful to be able to do this in order for users to be able to use an ASDF version of their own choosing that they maintain independently from your Lisp distribution. * If you do not have any such magic systems, or have other non-magic systems that you want to bundle with your implementation, then you may add them to the default-source-registry, and you are welcome to include asdf.asd amongst them. * Please send us upstream any patches you make to ASDF itself, so we can merge them back in for the benefit of your users when they upgrade to the upstream version. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] When a pamphlet was published entitled "100 Authors Against Einstein", Einstein retorted "If I were wrong, one would be enough."

1 0

[armedbear-devel] [ANNOUNCE] ABCL 0.20.0 release includes its first funded feature
by Erik Huelsmann 27 May '10

27 May '10

On behalf of the developers of ABCL (Armed Bear Common Lisp) I'm glad to be able to announce the 0.20.0 release. ABCL is a Common Lisp implementation implemented in Java and running on the JVM, featuring both an interpreter and a compiler. The compiler targets the JVM directly meaning that its output is runnable JVM bytecode. The fact that ABCL is written in Java allows for relatively easy embedding in larger applications. For integration with existing applications ABCL implements Java Specification Request (JSR) 223: Java scripting API. This release is the first to include a funded feature: funds were provided to implement the CLOS METACLASS feature and tests. Next to that, this release contains a large number of fixes and improvements, such as the ability to use JARs and URLs as pathnames and the a new ASDF version (ASDF2). You can find the full release notes at: http://common-lisp.net/project/armedbear/release-notes-0.20.shtml and the list of changes at: http://trac.common-lisp.net/armedbear/browser/trunk/abcl/CHANGES If you have questions regarding use or licensing, or you find issues, please report back to the development list: armedbear-devel at common-lisp dot net Source distribution archives can be downloaded in ZIP or gzipped tar form: http://common-lisp.net/project/armedbear/releases/abcl-src-0.20.0.tar.gz http://common-lisp.net/project/armedbear/releases/abcl-src-0.20.0.zip Signatures are available under: http://common-lisp.net/project/armedbear/releases/abcl-src-0.20.0.tar.gz.asc http://common-lisp.net/project/armedbear/releases/abcl-src-0.20.0.zip.asc In addition, binaries are also available: http://common-lisp.net/project/armedbear/releases/abcl-bin-0.20.0.tar.gz http://common-lisp.net/project/armedbear/releases/abcl-bin-0.20.0.zip With associated signatures: http://common-lisp.net/project/armedbear/releases/abcl-bin-0.20.0.tar.gz.asc http://common-lisp.net/project/armedbear/releases/abcl-bin-0.20.0.zip.asc

1 0

[armedbear-devel] Fixes to LispShell.java for 0.23.0
by Frank Pursel 25 May '10

25 May '10

All, I downloaded the latest version of J a couple of days ago (J version 0.23.0) and had some difficulties getting it to compile using java-6-sun's compiler version 1.6 update 20. Here are the modifications I made to LispShell.java to get it to compile cleanly against a fresh build of the newest abcl (ver 0.19.1, though I don't think it matters): diff -c /home/fpp/src/tmp/j-0.23.0/src/org/armedbear/j/LispShell.java /home/fpp/src/j-0.23.0/src/org/armedbear/j/LispShell.java *** /home/fpp/src/tmp/j-0.23.0/src/org/armedbear/j/LispShell.java 2010-04-03 15:04:08.000000000 -0400 --- /home/fpp/src/j-0.23.0/src/org/armedbear/j/LispShell.java 2010-05-22 18:42:29.963613502 -0400 *************** *** 110,120 **** } else { ! File lispHome = File.getInstance(Site.getLispHome()); if (lispHome == null) return null; // FIXME Error message? ! File swankLoader = File.getInstance(lispHome, ! "swank-loader.lisp"); if (swankLoader == null) return null; // FIXME Error message? if (shellCommand.indexOf("sbcl") >= 0 --- 110,121 ---- } else { ! Pathname lispHome = (Pathname)Site.getLispHome(); if (lispHome == null) return null; // FIXME Error message? ! File swankLoader = File.getInstance( ! Pathname.mergePathnames(lispHome, ! new Pathname("swank-loader.lisp"))); if (swankLoader == null) return null; // FIXME Error message? if (shellCommand.indexOf("sbcl") >= 0 *************** *** 902,908 **** sb.append(" -Xmx256M"); if (Platform.isPlatformUnix()) { ! Pathname lispHome = org.armedbear.lisp.Site.getLispHome(); if (lispHome != null) { sb.append(" -Xrs -Djava.library.path="); --- 903,909 ---- sb.append(" -Xmx256M"); if (Platform.isPlatformUnix()) { ! Pathname lispHome = (Pathname)org.armedbear.lisp.Site.getLispHome(); if (lispHome != null) { sb.append(" -Xrs -Djava.library.path="); Diff finished. Sun May 23 19:30:24 2010 I hope it's helpful. I was unable to get abcl to compile cleanly using the lisp build method. It failed with messages telling me that it, variously, could not autoload load or that it could not load 'system'. When I used ant I had no problems. Best wishes on an excellent project. Sincerely, Frank Pursel

3 2

[armedbear-devel] HEADS-UP Swing/AWT code moved to examples; ConsoleREPL added to base
by Mark Evenson 25 May '10

25 May '10

As discussed on #abcl some days ago with Alessio (and Erik?), I have moved the unused code from org.armedbear.lisp.java.* to 'examples/gui' as it is a better fit there. Under the examples I created a simple Ant build.xml with the base outline of a README. The domain of using ABCL to take the tedium out of Swing development and/or the combination with [JSS][1] to produce an interactively built GUI is potentially very interesting to a wider audience, but the examples are currently very thin. But maybe we should just direct people to [Snow][2], as that is where a lot of energy has seemingly been spent. [1]: http://code.google.com/p/lsw2/source/browse/#svn/trunk/jss [2]: http://common-lisp.net/project/snow/ I've [placed the code that Alessio wrote for a minimal Swing REPL console in org.armedbear.lisp.java.swing.REPLConsole][3], which has a suitable Main method so that java -cp abcl.jar org.armedbear.lisp.java.swing.REPLConsole will bring it "up" in the local display. [3]: http://trac.common-lisp.net/armedbear/changeset/12734 This console code is [the current basis][4] for the embedding of ABCL in the Protege ontology editor, although that currently uses its own version. I don't like the creation of Threads in the constructor, but haven't had time to figure out if there is a better way to go. The intention is to provide a standard way for people to embed ABCL with a minimal REPL for their domain-specific Java application, so I when I get the time I will revisit the Protege plugin to use this code. [4]: http://svn.neurocommons.org/svn/trunk/protege/org.sciencecommons.protege.li… -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel May 2010