armedbear-devel

armedbear-devel@common-lisp.net

1199 discussions

[armedbear-devel] [BUG] SET-SYNTAX-FROM-CHAR should clear dispatch tables
by Tobias C. Rittweiler 22 Sep '09

22 Sep '09

(let ((rt (copy-readtable nil))) (set-syntax-from-char #\# #\A rt (copy-readtable nil)) (get-dispatch-macro-character #\# #\x rt)) should signal an error as #\# is no longer a dispatching macro character. -T.

1 0

[armedbear-devel] packaging external libs with abcl
by Matthew D. Swank 22 Sep '09

22 Sep '09

I've been messing with running abcl on the google appengine, and I was wondering what was the best way to package libraries, especially the results of loading an asdf system and its dependencies? Thanks, Matt -- "You do not really understand something unless you can explain it to your grandmother." -- Albert Einstein.

3 8

[armedbear-devel] Bug: Attempt to GO to a tag whose extent has ended quits ABCL
by Brian Mastenbrook 21 Sep '09

21 Sep '09

When attempting to GO to a tag whose dynamic extent has ended, ABCL quits and prints the name of the exception used for internally handling GO (org.armedbear.lisp.Go). I see the same behavior in compiled or interpreted code. CL-USER(1): (lisp-implementation-version) "0.16.0" CL-USER(2): (let ((f nil)) (tagbody (setf f (lambda () (go foo))) foo) (funcall f)) org.armedbear.lisp.Go abcl-src-0.16.0 chandler$ -- Brian Mastenbrook brian(a)mastenbrook.net http://brian.mastenbrook.net/

6 10

[armedbear-devel] [BUG] make-thread and :NAME nil
by Tobias C. Rittweiler 21 Sep '09

21 Sep '09

Not providing a :NAME parameter to MAKE-THREAD will currently fail: CL-USER(1): (threads:make-thread (constantly t)) Debugger invoked on condition of type TYPE-ERROR: The value NIL is not of type STRING. Funnily enough, explicitly providing NIL kind of works: CL-USER(2): (threads:make-thread (constantly t) :name nil) #<THREAD "NIL" {1EEB372}> But, as you can see, the passed NIL is taken as a string designator, but probably shouldn't. -T.

2 1

[armedbear-devel] Your NAMED-READTABLES test
by Erik Huelsmann 21 Sep '09

21 Sep '09

Hi Tobias, The named-readtables test you sent me, does show an obvious bug in ABCL, but not the one you're trying to point me at: when loading your files on Windows, I'm getting an Index out of bounds error: the dispatch tables think our characters range from 0 - 255 in value whereas in practice that number is much higher. I'm working on a fix right now (setting CHAR_MAX to a higher value) but I don't feel too comfortable with it: it'll make us consume much more memory on a number of things. However, what's a K of memory worth these days... ? Bye, Erik.

2 2

[armedbear-devel] JSR-223: Returning immutable lists in ScriptEngineFactory
by Clemens Blamauer 20 Sep '09

20 Sep '09

Hi everyone, I was looking through the JSR-223 code in org.armedbear.lisp.scripting as I noticed that AbclScriptEngineFactory is not fully compliant to JSR-223 [1] (p. 101-102 in the Final Draft Specification, v1.0). For the methods: - java.util.List<java.lang.String> getExtensions() - java.util.List<java.lang.String> getMimeTypes() - java.util.List<java.lang.String> getNames() _immutable_ Lists should be returned. Please find a remedying patch below. Cheerz, Clemens [1] http://jcp.org/en/jsr/detail?id=223 ---- Index: AbclScriptEngineFactory.java =================================================================== --- AbclScriptEngineFactory.java (revision 12157) +++ AbclScriptEngineFactory.java (working copy) @@ -21,6 +21,7 @@ package org.armedbear.lisp.scripting; import java.util.ArrayList; +import java.util.Collections; import java.util.List; import javax.script.ScriptEngine; @@ -44,7 +45,7 @@ public List<String> getExtensions() { List<String> extensions = new ArrayList<String>(1); extensions.add("lisp"); - return extensions; + return Collections.unmodifiableList(extensions); } @Override @@ -89,7 +90,7 @@ @Override public List<String> getMimeTypes() { - return new ArrayList<String>(); + return Collections.unmodifiableList(new ArrayList<String>()); } @Override @@ -99,7 +100,7 @@ names.add("cl"); names.add("Lisp"); names.add("Common Lisp"); - return names; + return Collections.unmodifiableList(names); } @Override -- # Trust in code: # lynx http://lxr.linux.no/linux+v2.6.23.14/arch/i386/kernel/cpu/common.c#L677

2 1

[armedbear-devel] [PATCH] incorporating java stack frames into backtrace
by Tobias C. Rittweiler 20 Sep '09

20 Sep '09

When evaluating (ext:make-thread #'(lambda ())) you get an error "The value NIL is not of type STRING." -- this is a bug in ABCL itself, by the way, but that's not the matter of this mail. The concern of this mail is the backtrace that'd you get: Backtrace: 0: (INVOKE-DEBUGGER #<TYPE-ERROR {B1A201}>) 1: (MAKE-THREAD #<FUNCTION (LAMBDA ()) {15343C2}>) 2: (SYSTEM::%EVAL (MAKE-THREAD #'(LAMBDA NIL))) 3: (EVAL (MAKE-THREAD #'(LAMBDA NIL))) ... The only thing the backtrace reveales is that the error was signalled somewhere in MAKE-THREAD. With the patch of this mail, the backtrace will also contain the relevant Java stack frames for errors that were signalled from within ABCL's Java runtime: Backtrace: 0: (INVOKE-DEBUGGER #<TYPE-ERROR {B1A201}>) 1: org.armedbear.lisp.Lisp.error(Lisp.java:375) 2: org.armedbear.lisp.Lisp.type_error(Lisp.java:390) 3: org.armedbear.lisp.LispObject.getStringValue(LispObject.java:1061) 4: org.armedbear.lisp.LispThread.<init>(LispThread.java:111) 5: org.armedbear.lisp.LispThread.<init>(LispThread.java:39) 6: org.armedbear.lisp.LispThread$3.execute(LispThread.java:909) 7: org.armedbear.lisp.Primitive.execute(Primitive.java:108) 8: (MAKE-THREAD #<FUNCTION (LAMBDA ()) {15343C2}>) 9: (SYSTEM::%EVAL (MAKE-THREAD #'(LAMBDA NIL))) 10: (EVAL (MAKE-THREAD #'(LAMBDA NIL))) Another example: (LENGTH 12) Backtrace: 0: (INVOKE-DEBUGGER #<TYPE-ERROR {814AF5}>) 1: org.armedbear.lisp.Lisp.error(Lisp.java:375) 2: org.armedbear.lisp.Lisp.type_error(Lisp.java:390) 3: org.armedbear.lisp.LispObject.length(LispObject.java:403) 4: org.armedbear.lisp.LispObject.LENGTH(LispObject.java:410) 5: org.armedbear.lisp.Primitives$24.execute(Primitives.java:427) 6: (LENGTH 12) 7: (SYSTEM::%EVAL (LENGTH 12)) 8: (EVAL (LENGTH 12)) -T. -- Diese Nachricht wurde auf Viren und andere gefaerliche Inhalte untersucht und ist - aktuelle Virenscanner vorausgesetzt - sauber. Freebits E-Mail Virus Scanner

4 18

[armedbear-devel] JSR-223: Return immutable lists in ScriptEngineFactory
by Clemens Blamauer 20 Sep '09

20 Sep '09

Hi everyone, I was looking through the JSR-223 code in org.armedbear.lisp.scripting as I noticed that AbclScriptEngineFactory is not fully compliant to JSR-223 [1]. For the methods: - java.util.List<java.lang.String> getExtensions() - java.util.List<java.lang.String> getMimeTypes() - java.util.List<java.lang.String> getNames() _immutable_ Lists should be returned. Please find a remedying patch below. Cheerz, Clemens [1] http://jcp.org/en/jsr/detail?id=223 ---- Index: AbclScriptEngineFactory.java =================================================================== --- AbclScriptEngineFactory.java (revision 12157) +++ AbclScriptEngineFactory.java (working copy) @@ -21,6 +21,7 @@ package org.armedbear.lisp.scripting; import java.util.ArrayList; +import java.util.Collections; import java.util.List; import javax.script.ScriptEngine; @@ -44,7 +45,7 @@ public List<String> getExtensions() { List<String> extensions = new ArrayList<String>(1); extensions.add("lisp"); - return extensions; + return Collections.unmodifiableList(extensions); } @Override @@ -89,7 +90,7 @@ @Override public List<String> getMimeTypes() { - return new ArrayList<String>(); + return Collections.unmodifiableList(new ArrayList<String>()); } @Override @@ -99,7 +100,7 @@ names.add("cl"); names.add("Lisp"); names.add("Common Lisp"); - return names; + return Collections.unmodifiableList(names); } @Override

1 0

[armedbear-devel] Build problem
by Paul 20 Sep '09

20 Sep '09

Can anybody help with this build problem? I'm on MACOSX 10.5.8 trying to build from SVN, which I updated a few minutes ago. Buildfile: build.xml abcl.copy.lisp: [copy] Copying 171 files to /Users/pdo/Lisp/ABCL/build/classes abcl.init: [echo] java.version: 1.5.0_19 [echo] Implementation-Source: ${version.src} abcl.java.warning: abcl.jsr-223.notice: [echo] [echo] Notice: JSR-223 support won't be built since it is not [echo] supported, neither natively by your JVM nor by [echo] libraries in the CLASSPATH. [echo] abcl.compile.java: [javac] Compiling 268 source files to /Users/pdo/Lisp/ABCL/build/ classes abcl.fasls.uptodate: abcl.compile.lisp: [java] Armed Bear Common Lisp 0.15.0 [java] Java 1.5.0_19 Apple Inc. [java] Java HotSpot(TM) Client VM [java] Low-level initialization completed in 1.627 seconds. [java] Startup completed in 7.773 seconds. [java] [java] Caught SIMPLE-ERROR while processing --eval option "(compile-system :zip nil :quit t)": [java] *LISP-HOME* is NIL or invalid. [java] Please set *LISP-HOME* to the full pathname of the directory containing the Lisp system files. BUILD FAILED /Users/pdo/Lisp/ABCL/build.xml:211: Java returned: 2 Thanks, Paul

2 2

[armedbear-devel] [PATCH] Add SYS::*INVOKE-DEBUGGER-HOOK*
by Tobias C. Rittweiler 20 Sep '09

20 Sep '09

The first patch adds SYS::*INVOKE-DEBUGGER-HOOK* which is like *DEBUGGER-HOOK* but is observed by INVOKE-DEBUGGER even when BREAK is called. This obliterates the need to redefine SYS::BREAK in swank-abcl.lisp. A patch for swank-abcl is also attached. -T.

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel