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

[armedbear-devel] No :DARWIN, "No tag" & no ASDF
by John Pallister 06 Oct '09

06 Oct '09

Hello list, I'm inching my way towards working with ABCL (stupid day job) and I thought I'd mention a few things that have cropped up. I'm running on OS X 10.5.8 using the OpenJDK 6 (for JSR-223, and the server VM). I updated the source from the SVN repo this morning. When I build ABCL, I get the warning "Use of Java version 1.6.0-internal not recommended." Perhaps '<matches string="${java.version}" pattern="1\.6\.0-internal"/>' could be added to the appropriate spot in build.xml to suppress this warning. When I run ABCL, I get :JAVA-1.6 in *FEATURES* but not :DARWIN (or any other OS identifier). (*FEATURES* is (:DARWIN :JAVA-1.6 :ARMEDBEAR :ABCL :COMMON-LISP :ANSI-CL :CDR6). What's :CDR6?) When my '(load ".../start-swank.lisp")' fails, I get an error when I enter ':cont 0': shadow:abcl john$ ./abcl Armed Bear Common Lisp 0.17.0-dev Java 1.6.0-internal Sun Microsystems Inc. OpenJDK Server VM Low-level initialization completed in 1.699 seconds. Startup completed in 8.5 seconds. [on my Dell Mini 9, not real Apple h/w] Type ":help" for a list of available commands. CL-USER(1): (load "/Users/john/src/lisp/abcl/start-swank.lisp") Error loading /Users/john/src/lisp/asdf/asdf.lisp at line 193 (offset 7111) Debugger invoked on condition of type SIMPLE-ERROR: The long form of DEFINE-METHOD-COMBINATION is not implemented. Restarts: 0: TOP-LEVEL Return to top level. [1] ASDF(2): :cont 0 Debugger invoked on condition of type CONTROL-ERROR: No tag named #:G140089 is currently visible Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(3): :res CL-USER(4): Which brings me to the last problem: asdf.lisp won't load, since it uses the long form of DEFINE-METHOD-COMBINATION. Is there a workaround for this? If anyone can shed some light on these issues, that would be great. As an aside, does anyone want to share their .emacs settings for Java development? I've installed JDE (which was a PITA FWIW), CC-Mode etc. and I'm curious as to what other (Emacs-minded) people are using. Cheers, John :^P -- John Pallister john(a)johnp.net john(a)synchromesh.com

5 13

Re: [armedbear-devel] [armedbear-cvs] r12153 - trunk/abcl/src/org/armedbear/lisp
by Erik Huelsmann 06 Oct '09

06 Oct '09

Hi Mark, On Fri, Sep 18, 2009 at 3:43 PM, Mark Evenson <mevenson(a)common-lisp.net> wrote: > Author: mevenson > Date: Fri Sep 18 09:43:42 2009 > New Revision: 12153 > > Log: > Tenative fix for #63: transform caught Go throwable to LispError. > > Normalized printStackTrace() calls through Debug.trace() interface. > > > > Modified: > trunk/abcl/src/org/armedbear/lisp/Lisp.java > > Modified: trunk/abcl/src/org/armedbear/lisp/Lisp.java > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/Lisp.java (original) > +++ trunk/abcl/src/org/armedbear/lisp/Lisp.java Fri Sep 18 09:43:42 2009 > @@ -123,7 +123,7 @@ > } > catch (Throwable t) > { > - t.printStackTrace(); > + Debug.trace(t); > } > } > > @@ -277,7 +277,7 @@ > } > catch (Go go) > { > - throw go; > + return error(go.getCondition()); > } > catch (Throw t) > { This hunk causes "havoc" with the command line interface where people select the "go to toplevel" restart. I think this is the major change in this commit? If I want to revert this bit, do I have to revert the rest too, or are those just improvements on what was already there? BTW: With my recent changes, I don't think there's anything wrong with re-throwing the Go anymore: we check for a catching environment before throwing now. > @@ -1042,6 +1042,7 @@ > } > catch (Throwable t) > { > + Debug.trace(t); > return null; > } > } > @@ -2586,7 +2587,7 @@ > } > catch (ClassNotFoundException e) > { > - e.printStackTrace(); > + Debug.trace(e); > } > } > > > _______________________________________________ > armedbear-cvs mailing list > armedbear-cvs(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-cvs >

2 1

[armedbear-devel] Fw: SparseChars patch
by logicmoo＠gmail.com 04 Oct '09

04 Oct '09

ABCL, Here is the SparseChars patch. It shouldn't pass more or less ANSI-TESTs. but will improve performance due to the fact it uses less java heap and copies less. The one thing I might do later is stop using the character iterator (CharHashMap would get a copyToOther(CharHashMap)).. but for now its sane.

2 1