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

[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] :case :common
by pjb＠informatimago.com 27 Feb '11

27 Feb '11

CLHS says: 19.2.2.1.2.2 Common Case in Pathname Components For the functions in Figure 19-2, a value of :common for the :case argument that these functions should receive and yield strings in component values according to the following conventions: * All uppercase means to use a file system's customary case. * All lowercase means to use the opposite of the customary case. * Mixed case represents itself. Note that these conventions have been chosen in such a way that translation from :local to :common and back to :local is information-preserving. [pjb@kuiper :0.0 lisp]$ abcl Armed Bear Common Lisp 0.20.0 Java 1.6.0_22 Sun Microsystems Inc. Java HotSpot(TM) Server VM Low-level initialization completed in 0.265 seconds. Startup completed in 0.718 seconds. Type ":help" for a list of available commands. CL-USER(1): (make-pathname :name "TEST" :type "LISP" :case :common) #P"TEST.LISP" CL-USER(2): (namestring (make-pathname :name "TEST" :type "LISP" :case :common)) "TEST.LISP" I'm on a linux system on a ext3 file system. The customary case is lower case (case significant on this particular file system, but 99.999% of the files on unix are lower case). Therefore I would expect to get #P"test.lisp" Notice that: (make-pathname :name "test" :type "lisp" :case :common) should produce #P"TEST.LISP" and that: (make-pathname :name "Test" :type "Lisp" :case :common) should produce #P"Test.Lisp" And that I understand "yeld strings in component values" to mean that the processing should be done on each parameter independently. -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}.

3 4

[armedbear-devel] (defstruct (teststruct (:type list) :named) testslot)))
by Alan Ruttenberg 03 Feb '11

03 Feb '11

(defstruct (teststruct (:type list) :named) testslot))) causes the following defun to be compiled: (DEFUN NIL (SYSTEM::INSTANCE) (ELT SYSTEM::INSTANCE 0)) That shouldn't be. Particularly if (fdefinition nil) gives an error. -Alan

2 2

[armedbear-devel] [rfc] Preventing stack inconsistencies - structurally
by Erik Huelsmann 01 Jan '11

01 Jan '11

Every now and then (see ticket 117 for a current example), an issue pops up where we fail class file verification with a stack inconsistency error. The problem is that in some specific cases, it's impossible to accumulate function call argument values on the stack: the JVM clears out the stack in these cases. Next to storing values on the stack, the JVM offers local variables. These don't get cleared out. Historically, we have solved the problem by 'rewriting' the code being compiled in a way that made it store its values in local variables. This rewriting happens in pass1 of the compiler, based on the outcome of a the 'safety scanning function' UNSAFE-P. However, this function is overeager (will classify too many cases as unsafe) and it needs to be manually added to all cases which may end up being problematic in pass2. My proposal is now to add infrastructure to pass2 to handle the situation: Some blocks of code need to be marked as "collecting function call arguments". Then, upon the compilation of each argument, the new infrastructure would analyse the form being compiled. If that form will contain 'unsafe' bits, the compiler will automatically switch collection of function call arguments to local variables instead of on the stack. My idea would be to add a macro called WITH-STACK-PARAMETER-COLLECTION and an accompanying COMPILE-STACK-PARAMETER. The macro would set up some special variables for the COMPILE-STACK-PARAMETER to inspect and set. At the end of the macro, code will be emitted to make sure all the values are correctly loaded on the stack, just as if they had always been there. The pass1 form rewriting could be eliminated and our decision rules about what's 'unsafe' and what's not would be completely correct, instead of "overeager, but at least not missing any cases" [the latter it obviously does, since pass1 needs to estimate what pass2 will be compiling]. Any comments? Regards, Erik.

4 12

[armedbear-devel] Release time?
by Erik Huelsmann 31 Dec '10

31 Dec '10

If our Trac milestones are still correct, it's time to start preparing a release again! Does anybody have local changes which urgently require a release? If so, please commit, so we can start the release process. In the mean time, it'd be great if a volunteer would step up to update CHANGES and the 0.24 release notes page. Thanks in advance! Bye, Erik.

3 3

[armedbear-devel] Pathname.java, or: trying to understand the Java URL/URI/File universe
by Erik Huelsmann 27 Dec '10

27 Dec '10

As a result of the failure I just fixed in r13105, I tried to understand more broadly about our interaction with the URL/URI/File Java universe. What I found: * We're constantly converting URL->URI->file-based pathname * When converting an absolute URI to a file object using the File(URI uri) constructor for file: URIs, the process strips the leading slash that preceeds the windows drive letter * We can't "just" convert paths to URIs by doing ["file:" + path], because that's not a valid URI. However, it seems that we should be able to do [new URI("file", null, path, null, null);] as it seems that the URI does its own encoding, *if* we use the multi-argument constructors. Any single-string should be pre-encoded. * We seem to be required to support relative URIs in a non-standard way (like "jar:file:baz.jar"); the standards do allow relative path URIs, but those are requred to be without a schema. All of the above has me thinking: 1. Should we separate the different types of supported pathnames into separate Java classes, with a single entry point (factory?) 2. Would it make sense to separate internal representation from external presentation? Hopefully, this way we can circumvent the fact that the URI<->File conversion really wants absolute paths, while the external presentation is relative. 3. It seems that any URL/URI->path conversion should go through the normalization routines defined by the File(URI uri) constructor, because it seems to do the right thing with URI's - even on Windows. Comments? Regards, Erik.

1 0

[armedbear-devel] Failed to install cl-unicode via quicklisp
by Tomohiro Matsuyama 18 Dec '10

18 Dec '10

Hi all, Today, I have investigated ABCL about is it possible to install libraries via quicklisp and how many libraries can be installed via quicklisp. Installation quicklisp itself has been successful and (surprisingly) it seems to be almost perfect. However, I have finally confront the following errors during installing (compiling?) cl-unicode library after installed some other libraries. ================================================== ; Loading "cl-unicode" ... ;;; Parsing Unicode file UnicodeData.txt ;;; Parsing Unicode file Scripts.txt ;;; Parsing Unicode file Blocks.txt ;;; Parsing Unicode file PropList.txt ;;; Parsing Unicode file DerivedAge.txt ;;; Parsing Unicode file BidiMirroring.txt ;;; Parsing Unicode file Jamo.txt ;;; Building hash tables ;;; Writing source file methods.lisp ;;; Writing source file hash-tables.lisp ;;; Writing source file lists.lisp ;;; Writing source file derived-properties ;;; Parsing Unicode file DerivedCoreProperties.txtjava.lang.ClassFormatError: Unknown constant tag 41 in class file org/armedbear/lisp/ASDF_TMP_hash_tables_2 at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:634) at java.lang.ClassLoader.defineClass(ClassLoader.java:480) at org.armedbear.lisp.FaslClassLoader.findClass(FaslClassLoader.java:95) at org.armedbear.lisp.FaslClassLoader.loadClass(FaslClassLoader.java:77) at java.lang.ClassLoader.loadClass(ClassLoader.java:266) at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406) at java.lang.Class.getConstructor0(Class.java:2716) at java.lang.Class.newInstance0(Class.java:343) at java.lang.Class.newInstance(Class.java:325) ... ================================================== Reproduce: 1. Install Quicklisp 2. (ql:quickload :cl-unicode) Is there any solution? Regards, Tomohiro Matsuyama

1 0

[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