armedbear-devel

armedbear-devel@common-lisp.net

1 participants
1200 discussions

[armedbear-devel] Speculative use of #\unnnn reader forms
by Mark Evenson 16 Dec '10

16 Dec '10

The attached patch attempts to add the ability for ABCL to interpret the form #\unnnn as referring to the unicode character at the hexadecimal codepoint nnnn. I'd commit it to trunk for wider experimentation but ran into an erroneous interaction with Babel's own version of a sharp backslash reader in trying to run the CFFI tests, indicating that I probably missed something rather fundamental here. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

[armedbear-devel] [CfP] 4th European Lisp Symposium, March 31 - April 1, 2010, Hamburg
by Didier Verna 14 Dec '10

14 Dec '10

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 4th European Lisp Symposium Special Focus on Parallelism & Efficiency March 31 - April 1st, 2011 TUHH, Hamburg University of Technology Hamburg, Germany http://www.european-lisp-symposium.org/ Sponsored by EPITA, Lispworks, Franz Inc. and Nova Sparks ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Invited Speakers: ~~~~~~~~~~~~~~~~~ Marc Battyani (Nova Sparks) Craig Zilles (University of Illinois) Important Dates ~~~~~~~~~~~~~~~~ + Submission Deadline: January 09, 2011 + Author Notification: February 06, 2011 + Final Paper Due: February 28, 2011 + Symposium: March 31 - April 1st, 2011 Authors of accepted research contributions will be invited to submit an extended version of their papers for journal publication. Scope ~~~~~~ The purpose of the European Lisp Symposium is to provide a forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, ACL2, ECMAScript, Racket and so on. We encourage everyone interested in Lisp to participate. The European Lisp Symposium 2011 invites high quality papers about novel research results, insights and lessons learned from practical applications, and educational perspectives. We also encourage submissions about known ideas as long as they are presented in a new setting and/or in a highly elegant way. This year's focus will be directed towards "Parallelism & Efficiency". We especially invite submissions in the following areas: + Parallel and distributed computing + Code generation for multi-core architectures + Code generation for HTM + Large and ultra-large systems + Optimization techniques + Embedded applications Contributions are also welcome in other areas, including but not limited to: + Context-, aspect-, domain-oriented and generative programming + Macro-, reflective-, meta- and/or rule-based development approaches + Language design and implementation + Language integration, inter-operation and deployment + Development methodologies, support and environments + Educational approaches and perspectives + Experience reports and case studies Technical Program: ~~~~~~~~~~~~~~~~~~ We invite submissions in the following forms: * Papers: Technical papers of up to 15 pages that describe original results or explain known ideas in new and elegant ways. * Demonstrations: Abstracts of up to 4 pages for demonstrations of tools, libraries, and applications. * Tutorials: Abstracts of up to 4 pages for in-depth presentations about topics of special interest for at least 90 minutes and up to 180 minutes. * Lightning talks: Abstracts of up to one page for talks to last for no more than 5 minutes. All submissions should be formatted following the ACM SIGS guidelines and include ACM classification categories and terms. For more information on the submission guidelines and the ACM keywords, see: http://www.acm.org/sigs/publications/proceedings-templates http://www.acm.org/about/class/1998 Submissions should be uploaded to Easy Chair, at the following address: http://www.easychair.org/conferences/?conf=els2011 Programme Chair ~~~~~~~~~~~~~~~~ Didier Verna - EPITA Research and Development Laboratory, France Local Chair ~~~~~~~~~~~~ Ralf Moeller - Hamburg University of Technology, Germany Programme Committee ~~~~~~~~~~~~~~~~~~~~ Antonio Leitao - Instituto Superior Tecnico/INESC-ID, Portugal Christophe Rhodes - Goldsmiths College, University of London, UK David Edgar Liebke - Relevance Inc., USA Didier Verna - EPITA Research and Development Laboratory, France Henry Lieberman - MIT Media Laboratory, USA Jay McCarthy - Brigham Young University, USA Jose Luis Ruiz Reina - Universidad de Sevilla, Spain Marco Antoniotti - Universita Milano Bicocca, Italy Manuel Serrano - INRIA, France Michael Sperber - DeinProgramm, Germany Pascal Costanza - Vrije Universiteit of Brussel, Belgium Scott McKay - ITA Software, USA -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com

1 0

[armedbear-devel] Using ABCL's JSR-223 support for Ant integration
by Erik Huelsmann 12 Dec '10

12 Dec '10

Together with Alex Mizrahi, I'm working on resurrecting (and improving) ABCL-web, the Java<->ABCL servlet bridge. Because the ABCL-web project consists of both Java and lisp files which need to be distributed in compiled form in a JAR, I'm looking at ways to extend the (NetBeans generated) Ant based build for the ABCL-web project. So far, I've come up with 2 solutions (the third approach turns out to be no solution): 1. Create a custom Ant task - which isn't exactly a lot of work, but still... 2. Integrate with Ant using our JSR-223 implementation based on the Ant SCRIPT tag The latter turned out to be two minutes work for a trivial project file (run from the ABCL project directory root): ================= <project name="squares" default="main" basedir="."> <target name="main"> <script language="ABCL" classpath="dist/abcl.jar"> <![CDATA[ (print "ok") ]]> </script> </target> </project> ================= However, the output is a bit peculiar [note the 4 characters each being on their own line!]: C:\Users\Erik\Documents\abcl-j>ant -f b.xml Buildfile: b.xml main: [script] #<PACKAGE "ABCL-SCRIPT"> [script] #<PACKAGE "ABCL-SCRIPT-USER"> [script] #<PACKAGE "ABCL-SCRIPT"> [script] +GLOBAL-SCOPE+ [script] +ENGINE-SCOPE+ [script] +PUT-BINDING+ [script] +GET-BINDINGS+ [script] GENERATE-BINDINGS [script] GENERATE-SPECIAL-DECLARATIONS [script] GENERATE-JAVA-BINDINGS [script] EVAL-IN-SCRIPT-CONTEXT [script] EVAL-FUNCTION [script] EVAL-SCRIPT [script] EVAL-COMPILED-SCRIPT [script] COMPILE-SCRIPT [script] *INTERFACE-IMPLEMENTATION-MAP* [script] FIND-JAVA-INTERFACE-IMPLEMENTATION [script] REGISTER-JAVA-INTERFACE-IMPLEMENTATION [script] REMOVE-JAVA-INTERFACE-IMPLEMENTATION [script] ("CLOS" "PRINT-OBJECT" "FORMAT" "PPRINT" "ASDF") [script] #<PACKAGE "ABCL-SCRIPT"> [script] *LAUNCH-SWANK-AT-STARTUP* [script] *SWANK-DIR* [script] *SWANK-PORT* [script] *USE-THROWING-DEBUGGER* [script] CONFIGURE-ABCL [script] ABCL: configured [script] [script] [script] " [script] o [script] k [script] " [script] BUILD SUCCESSFUL Total time: 5 seconds So, now I have two questions: 1. Can we silence the ABCL+Script boot up? 2. What's happening with the 1-character-per-line output of my script???? Any help would be appreciated! Bye, Erik.

2 2

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel