December 2010 - armedbear-devel - mailman3.common-lisp.net

Re: [armedbear-devel] [armedbear-cvs] r13094 - in trunk/abcl/src/org/armedbear/lisp/scripting: . util
by Erik Huelsmann 12 Dec '10

12 Dec '10

Hi Alessio, Could you review my commit below? I've removed the ReaderInput/WriterOutput streams, because I think their functionality is available in our general Stream class. Thanks in advance! Bye, Erik. On Sun, Dec 12, 2010 at 11:04 AM, Erik Huelsmann <ehuelsmann(a)common-lisp.net> wrote: > Author: ehuelsmann > Date: Sun Dec 12 05:04:45 2010 > New Revision: 13094 > > Log: > Eliminate flushes after every character in javax.scripting support. > > This fixes Ant output for embedded scriptlets in Ant files. > > Removed: > trunk/abcl/src/org/armedbear/lisp/scripting/util/ > Modified: > trunk/abcl/src/org/armedbear/lisp/scripting/AbclScriptEngine.java > > Modified: trunk/abcl/src/org/armedbear/lisp/scripting/AbclScriptEngine.java > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/scripting/AbclScriptEngine.java (original) > +++ trunk/abcl/src/org/armedbear/lisp/scripting/AbclScriptEngine.java Sun Dec 12 05:04:45 2010 > @@ -25,15 +25,11 @@ > import java.io.InputStream; > import java.io.Reader; > import java.io.StringWriter; > -import java.math.BigInteger; > import java.util.Map; > -import java.util.Properties; > > import javax.script.*; > > import org.armedbear.lisp.*; > -import org.armedbear.lisp.scripting.util.ReaderInputStream; > -import org.armedbear.lisp.scripting.util.WriterOutputStream; > > > public class AbclScriptEngine extends AbstractScriptEngine implements Invocable, Compilable { > @@ -230,22 +226,14 @@ > } > > Object eval(Function evaluator, LispObject code, ScriptContext ctx) throws ScriptException { > - ReaderInputStream in = null; > - WriterOutputStream out = null; > LispObject retVal = null; > - try { > - in = new ReaderInputStream(ctx.getReader()); > - out = new WriterOutputStream(ctx.getWriter()); > - Stream outStream = new Stream(Symbol.SYSTEM_STREAM, out, Symbol.CHARACTER); > - Stream inStream = new Stream(Symbol.SYSTEM_STREAM, in, Symbol.CHARACTER); > + Stream outStream = new Stream(Symbol.SYSTEM_STREAM, ctx.getWriter()); > + Stream inStream = new Stream(Symbol.SYSTEM_STREAM, ctx.getReader()); > retVal = evaluator.execute(makeBindings(ctx.getBindings(ScriptContext.GLOBAL_SCOPE)), > makeBindings(ctx.getBindings(ScriptContext.ENGINE_SCOPE)), > inStream, outStream, > code, new JavaObject(ctx)); > return retVal.javaInstance(); > - } catch (IOException e) { > - throw new ScriptException(e); > - } > } > > @Override > > _______________________________________________ > armedbear-cvs mailing list > armedbear-cvs(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-cvs >

1 0

[armedbear-devel] r12092 breaks build
by Mark Evenson 12 Dec '10

12 Dec '10

With [r12092][1] we apparently need to change the private to protected as in the attached patch. abcl.compile.java: Compiling 270 source files to /Users/evenson/work/abcl/build/classes /Users/evenson/work/abcl/src/org/armedbear/lisp/Interpreter.java:530: JAVA_EXCEPTION_CAUSE has private access in org.armedbear.lisp.JavaException .JAVA_EXCEPTION_CAUSE.execute(condition).javaInstance()); [1]: http://trac.common-lisp.net/armedbear/changeset/13092 -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 2

[armedbear-devel] Environment not found
by Gabriel Dos Reis 11 Dec '10

11 Dec '10

Hi, I was looking for documentation of the standard options that the `abcl' driver accepts -- but could not find one. The FAQ page http://common-lisp.net/project/armedbear/faq.shtml suggests as first option `Our wiki'. Clicking on the link http://trac.common-lisp.net/project/wiki displays the message as indicated in the $SUBJECT. I take that to indicate that ABCL (website) is relying on a dangling reference... That being reported, where is the documentation of the options accepted by the `abcl' driver? Thanks, -- Gaby

3 8

[armedbear-devel] -Xbootclasspath/a: in abcl.bat wrapper
by Erik Huelsmann 08 Dec '10

08 Dec '10

Some months ago, V-ille mentioned that Clojure got a 50% boot speedup by adding their jar(s) using the bootclasspath. Today, I decided to look into what that means. As it turns out, there's an option to the (Sun) java executable called "-Xbootclasspath/a" which can be used to add jars to the bootclasspath. These timings I got from doing the same in our situation: without the bootclasspath option: C:\Users\Erik\Documents\abcl-j>abcl Armed Bear Common Lisp 0.24.0-dev Java 1.6.0_20 Sun Microsystems Inc. Java HotSpot(TM) Client VM Low-level initialization completed in 0.91 seconds. Startup completed in 5.019 seconds. Type ":help" for a list of available commands. CL-USER(1): :exit with the bootclasspath option: C:\Users\Erik\Documents\abcl-j>abcl Armed Bear Common Lisp 0.24.0-dev Java 1.6.0_20 Sun Microsystems Inc. Java HotSpot(TM) Client VM Low-level initialization completed in 0.341 seconds. Startup completed in 4.159 seconds. Type ":help" for a list of available commands. CL-USER(1): :exit As you see, we can achieve a lot of performance gain (66%) by loading our classes off the bootclasspath. The general performance increase (from 5.0 to 4.9 seconds on my machine in powersavings mode) can -presumably- be much higher, if we compile into .class files instead of "manually" loading .cls files. Just noting to share my findings. Bye, Erik.

1 0

[armedbear-devel] An example of using the ability to dynamically create Java interfaces
by Mark Evenson 05 Dec '10

05 Dec '10

This can probably be cleaned up a lot. Among other things, it shows a nearly constant need to protect the "raw" Java values from ABCL's interpretation to do anything useful. For example (let ((c (jclass "java.io.File"))) (jnew-array-from-array "java.lang.Class" #(c c c))) fails to construct an array as the java.lang.Class members are promoted to JAVA-OBJECT. Does this mean we need JNEW-ARRAY-FROM-ARRAY-RAW? Or do we need to try both interpretations? Onwards through callbacks in CFFI… [1]: http://trac.common-lisp.net/armedbear/changeset/13089 -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

[armedbear-devel] Idiomatic conversion of file: URLs to file-paths
by Erik Huelsmann 05 Dec '10

05 Dec '10

Hi Mark, To get back to our earlier (irc) discussion of converting URL.getPath() / URI.getPath() to (Windows) pathnames: I found this page: http://weblogs.java.net/blog/2007/04/25/how-convert-javaneturl-javaiofile which contains code on how to do the conversion. I just checked on Windows it even strips the leading '/' which you get from URL.getPath(). My reaction to these findings is to propose a new static function to be added to the Utilities class, which should be used to convert file:/ urls to paths. Our code should then be searched for invocations of URL/URI.getPath() on file urls, changing it to the utility function. Regards, Erik.

1 0

[armedbear-devel] bug in RandomAccessCharacterFile.java
by David Kirkman 05 Dec '10

05 Dec '10

The problem is that in the while loop (line 549), if only part of the byte array is written to the buffer, the position is updated but the length is not. I'm attaching a patch. Here is some code that fails in r13087, and works with the patch. I ran into this while serializing mixed lisp/java objects, which is pretty well reflected in this snippet. Cheers, -david k. (let* ((len 5000) (big-object (jnew-array "double" len))) (dotimes (i len) (setf (jarray-ref big-object i) (+ i 0.1))) (with-open-file (stream "foo.dat" :direction :output :element-type 'unsigned-byte) (let ((p (jnew (jconstructor "java.io.ObjectOutputStream" "java.io.OutputStream") (jcall (jmethod "org.armedbear.lisp.Stream" "getWrappedOutputStream") stream)))) (jcall (jmethod "java.io.ObjectOutputStream" "writeObject" "java.lang.Object") p big-object) (jcall (jmethod "java.io.ObjectOutputStream" "flush") p))) (let ((big-object2 (with-open-file (stream "foo.dat" :direction :input :element-type 'unsigned-byte) (let ((p (jnew (jconstructor "java.io.ObjectInputStream" "java.io.InputStream") (jcall (jmethod "org.armedbear.lisp.Stream" "getWrappedInputStream") stream)))) (jcall (jmethod "java.io.ObjectInputStream" "readObject") p))))) (dotimes (i len) (format t "~A ~A~%" (jarray-ref big-object i) (jarray-ref big-object2 i)))))

2 1

Re: [armedbear-devel] Patch for ABCL against BORDEAUX-THREADS-0.8.0
by Mark Evenson 04 Dec '10

04 Dec '10

On 12/3/10 4:56 PM, Martin Simmons wrote: >>>>>> On Fri, 03 Dec 2010 14:37:52 +0100, Mark Evenson said: >> >> Implement CONDITION-WAIT and CONDITION-NOTIFY for ABCL. > > That version of CONDITION-WAIT won't work properly: Indeed it won't: thanks for the comments, and the kick in the butt. After studying the needed abstractions in more detail I've [reimplemented most of the BORDEAUX-THREADS interfaces for ABCL based on the java.util.concurrent.ReentrantLock][1]. This code should now correctly implement the POSIX-style condition variables, the recursively held locks, and the form of lock acquisition that returns immediately. Please consider the referenced patch for inclusion in BORDEAUX-THREADS. [1]: http://slack.net/~evenson/abcl/hunchentoot/bordeaux-threads-abcl-20101204a.… -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

[armedbear-devel] ASDF 2.011
by Faré 03 Dec '10

03 Dec '10

Dear Lispers, I'm pleased to announce the release of ASDF 2.011. As compared to ASDF 2.010, it only sports a series of minor changes, which I think is sign of ASDF 2 becoming mature: * minor portability tweaks, to make GCL (2.010.1) and Allegro (2.010.5) happy * minor fixes, to an error in error (2.010.8) * minor API cleanups, exporting symbol operation-description (2.010.6) and accepting keywords as component class names (2.010.3) * minor internal refactoring (2.010.4, 2.010.7 + 2.010.9) * minor improvement in dealing with incompatibility, refusing to run if asdf-binary-locations was loaded as it only works with asdf 1, with useful error message (2.010.7) * minor improvements in compatibility with cl-launch (2.010.2) and xcvb (2.010.4) If you missed it, 2.010 had a notable speedup in addition to minor fixes. It would be very nice of vendors to update the version of ASDF they ship with their respective implementations, or to start shipping it when they don't do it yet (LispWorks, SCL; Corman, GCL - if they are still being developed). PS: I think we should create an asdf-announce mailing-list so that vendors may subscribe to it and only get traffic relevant to releases. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Every technique is first developed, then used, important, obsolete, normalized, and finally understood.

2 1

Re: [armedbear-devel] [armedbear-cvs] r13078 - in trunk/abcl: nbproject src/org/armedbear/lisp
by Erik Huelsmann 03 Dec '10

03 Dec '10

Hi Mark, On Wed, Dec 1, 2010 at 11:44 PM, Mark Evenson <mevenson(a)common-lisp.net> wrote: > Author: mevenson > Date: Wed Dec 1 17:44:34 2010 > New Revision: 13078 > > Log: > The classfile writer now handles the creation of interfaces. > Modified: > trunk/abcl/nbproject/build-impl.xml > trunk/abcl/nbproject/genfiles.properties ^^^^ Did you intend to commit the NB project file changes? > trunk/abcl/src/org/armedbear/lisp/jvm-class-file.lisp Bye, Erik.

2 1