September 2009 - armedbear-devel - mailman3.common-lisp.net

[armedbear-devel] [OT] best way to structure and deploy a project
by Alessio Stalla 09 Sep '09

09 Sep '09

Hello everyone, I have a question which is not exactly pertinent with the development of ABCL, but which imho can start a useful discussion. Please forgive me if this is too OT. I have a project with sources in two languages, Java and Lisp. It is an Eclipse project, but the IDE does not make difference. The project is a library, not an end-user application. Currently it is structured as follows: src/java - Java source code src/lisp - Lisp source code lib/ - third-party libraries, both Java (jars) and Lisp (directories). The Java code is compiled by the IDE and put in an output directory. The Lisp source files are treated by the IDE as normal, non-source files, and copied verbatim into the same ouput folder as the Java classes. When I run the project from the IDE, I launch a class which compiles and loads the Lisp systems using asdf. This works for me locally, but thinking about distributing the project to users, this approach has some drawbacks: - Lisp files must be true files, they can't be in a Jar (asdf doesn't understand jars). - Lisp files are recompiled every time, since the IDE always overwrites the Lisp source files in the output directory. - If I make a jar, it will contain Lisp source files, not binaries, since binaries are unknown to the IDE. Ideally I'd like to do what ABCL does, i.e. create one big jar containing .class files and compiled Lisp files. Lisp sources could be compiled by the IDE or by a script, I don't care. Still, I would like to maintain the use of asdf (since some of my dependencies use it and loading them manually is too much of a hassle). I don't know how I can do this. I have also thought about leaving everything as-is, and when I'll distribute the library as a jar, have it extract at runtime the Lisp source files from the jar in a temporary directory and instruct asdf to search for systems in that directory. I will also need the lib/ folder to be in a known place, since asdf has to load stuff from there too (but this is less of a problem since I can make the library user configure that place, and use a sensible default otherwise). I am wondering if a cleaner approach exists, and if someone has experience in this regard. Cheers, Alessio

7 19

[armedbear-devel] In-memory compilation status
by John Pallister 08 Sep '09

08 Sep '09

Hello list, I'm interested in trying to get ABCL running (and preferably REPL-ing & compiling) on a certain cloud computing platform that has a JVM with no access to a file system. The Wiki page for JSR-223 and the sample code both mention that "compilation using the runtime compiler has been removed due to inconsistencies with evaluation and file-based compilation", since May '09. Browsing the mailing list archives suggests that people have been working on removing the need for temporary files since then, but I can't find any mention of "inconsistencies". The thread "Save-image w/Serialization - progress report" from April ends with Sig. Stalla in the process of implementing a byte-array-output-stream, then silence... Can someone comment on the state of runtime compilation, preferably entirely in-memory without reference to a file system? Basically I'd like to be able to compile stuff to a byte array, store the array as a blob in a memcache and/or other datastore, then pull it out again as required and load it via a custom classloader. Is this doable, or would it be easier to port ParenScript to Clojure (which is currently my Plan B)? Cheers, and it's great to see the ABCL project still going strong! John :^P P.S. If anyone is going to be in Hamburg at the weekend and wants to chat about this stuff, that'd be great! -- John Pallister john(a)johnp.net john(a)synchromesh.com

3 9

[armedbear-devel] Passing FORMAT.C.4A and FORMATTER.C.4A
by logicmoo＠gmail.com 06 Sep '09

06 Sep '09

Passing FORMAT.C.4A and FORMATTER.C.4A Index: src/org/armedbear/lisp/LispCharacter.java =================================================================== --- src/org/armedbear/lisp/LispCharacter.java (revision 12140) +++ src/org/armedbear/lisp/LispCharacter.java (working copy) @@ -32,6 +32,8 @@ */ package org.armedbear.lisp; +import java.util.HashMap; +import java.util.Map; public final class LispCharacter extends LispObject { @@ -44,7 +46,7 @@ } public final char value; - + private String name; public static LispCharacter getInstance(char c) { try @@ -256,8 +258,11 @@ case 127: sb.append("Rubout"); break; - default: - sb.append(value); + default: + if (name!=null) + sb.append(name); + else + sb.append(value); break; } } @@ -541,6 +546,8 @@ public static final int nameToChar(String s) { String lower = s.toLowerCase(); + LispCharacter lc = namedToChar.get(lower); + if (lc!=null) return lc.value; if (lower.equals("null")) return 0; if (lower.equals("bell")) @@ -605,7 +612,8 @@ case 127: return "Rubout"; } - return null; + if (c<0 || c>255) return null; + return constants[c].name; } // ### char-name @@ -627,6 +635,39 @@ return Character.toUpperCase(c); } + static int maxNamedChar = 0; + static Map<String, LispCharacter> namedToChar = new HashMap<String, LispCharacter>(); + + static void setCharNames(int i, String[] string) { + int settingChar = i; + int index = 0; + int stringLen = string.length; + while(stringLen-->0) { + setCharName(settingChar,string[index]); + index++; + settingChar++; + } + if (maxNamedChar<settingChar) maxNamedChar = settingChar; + } + + static void setCharName(int settingChar, String string) { + if (settingChar>=CHAR_MAX) return; + LispCharacter c = constants[settingChar]; + c.name = string; + namedToChar.put(string.toLowerCase(), c); + } + + static { + new CharNameMaker0(); + } + + static class CharNameMaker0{ + { + setCharNames(0,new String[]{"Null", "Soh", "Stx", "Etx", "Eot", "Enq", "Ack", "Bell", "Backspace", "Tab", "Newline", "Vt", "Page", "Return", "So", "Si", "Dle", "Dc1", "Dc2", "Dc3", "Dc4", "Nak", "Syn", "Etb", "Can", "Em", "Sub", "Escape", "Fs", "Gs", "Rs", "Us"}); + setCharNames(128,new String[]{"U0080", "U0081", "U0082", "U0083", "U0084", "U0085", "U0086", "U0087", "U0088", "U0089", "U008a", "U008b", "U008c", "U008d", "U008e", "U008f", "U0090", "U0091", "U0092", "U0093", "U0094", "U0095", "U0096", "U0097", "U0098", "U0099", "U009a", "U009b", "U009c", "U009d", "U009e", "U009f"}); + } + } + private static final char[] UPPER_CASE_CHARS = new char[128]; static

1 0

[armedbear-devel] [ANNOUNCE] ABCL 0.16.0
by Erik Huelsmann 06 Sep '09

06 Sep '09

On behalf of the developers of ABCL (Armed Bear Common Lisp) - a lisp implementation running on the JVM - I'm glad to be able to announce the 0.16.0 release. This release features - among lots of other things - performance improvements, better type checking for the THE form and ANSI tests fixes. You can find the release notes at: http://common-lisp.net/project/armedbear/release-notes-0.16.shtml If you have questions regarding its license or use, or you find issues, please report back to the development list: armedbear-devel at common-lisp dot net The sources can be downloaded in ZIP or .tar.gz form from SourceForge: http://common-lisp.net/project/armedbear/releases/abcl-src-0.16.0.tar.gz http://common-lisp.net/project/armedbear/releases/abcl-src-0.16.0.zip Signatures are available under: http://common-lisp.net/project/armedbear/releases/abcl-src-0.16.0.tar.gz.asc http://common-lisp.net/project/armedbear/releases/abcl-src-0.16.0.zip.asc Bye, Erik.

1 0

[armedbear-devel] Branching 0.16.x
by Erik Huelsmann 04 Sep '09

04 Sep '09

With the recent changes to our Ant build to create ZIP files with CRLF line endings and LF line endings in the TAR archive, I think we have enough basis to create a branch for release management of our 0.16.x release line. Should further fixes be required, they can be backported. Creating the release branch now frees up the trunk for further development. Are there any last minute fixes that need to be applied? From the silence on the list this last week I concluded there probably are not. I hope to be able to create a release before the end of the weekend, however, no guarantees! Bye, Erik.

2 1

[armedbear-devel] eol-style problem with abcl-src-0.15.tar.gz
by Mark Evenson 01 Sep '09

01 Sep '09

Somehow we seemed to have shipped [the abcl-0.15.0 source][1] with a CR+LF file-ending for 'abcl.in', which means when built under a 'NIX one gets the slightly mysterious message "#!/bin/sh -- interpreter not found. It is slightly surprising that we haven't gotten more complaints on this (or maybe everyone builds from SVN?). The svn:eol-style is now set to 'LF' in SVN for 'abcl.in', which does the "right thing" when building the source tar balls, so abcl-0.16 should be ok, as long as whoever builds the release doesn't somehow override this is local SVN settings Looking through the SVN log for metadata changes to 'abcl.in' doesn't seem to report anything. Maybe there is somehow to report metadata changes, but I don't see how to do this quickly. We have the currently unused ability to fix line endings in the relevant Ant targets. Maybe I should revisit them? If so, what would be the correct policy? [1]: http://downloads.sourceforge.net/armedbear-j/abc/abcl-src-0.15.0.tgz -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 4