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

[armedbear-devel] Bug in handling of keyword arguments
by Eric Marsden 18 Sep '11

18 Sep '11

Hi, ,---- | Armed Bear Common Lisp 0.27.0-dev-svn-13545M | Java 1.6.0_23 Sun Microsystems Inc. | OpenJDK 64-Bit Server VM | Low-level initialization completed in 1.02 seconds. | Startup completed in 1.96 seconds. | CL-USER(10): (defun foo (a b) | (find a '(1 2 3) b 1)) | FOO | CL-USER(11): (compile 'foo) | #<THREAD "interpreter" {12BC8F01}>: Debugger invoked on condition of type PROGRAM-ERROR | Unrecognized keyword argument B | Restarts: | 0: TOP-LEVEL Return to top level. `---- I should be able to invoke FOO with :start or :end values for B. -- Eric Marsden

2 2

[armedbear-devel] BUG: Stack inconsistency (java.lang.VerifyError)
by eric.marsden＠free.fr 06 Sep '11

06 Sep '11

Hi, Attempting to use ABCL to build a current development checkout of SBCL on Linux/i686, I encountered the following error. ABCL builds SBCL on Linux/AMD64 correctly, with the same openjdk version. ------------------ file foo.lisp ------------------------------------------ (in-package :cl-user) (defun symbolicate (&rest things) (let* ((length (reduce #'+ things :key (lambda (x) (length (string x))))) (name (make-array length :element-type 'character))) (let ((index 0)) (dolist (thing things (values (intern name))) (let* ((x (string thing)) (len (length x))) (replace name x :start1 index) (incf index len)))))) (macrolet ((def (name &optional variant) `(defun ,(if variant (symbolicate name "/" variant) name) (function mutex) (declare (function function)) (flet ((%call-with-system-mutex () (dx-let (got-it) (unwind-protect (when (setf got-it (get-mutex mutex)) (funcall function)) (when got-it (release-mutex mutex)))))) (declare (inline %call-with-system-mutex)) ,(ecase variant (:without-gcing `(without-gcing (%call-with-system-mutex))) (:allow-with-interrupts `(without-interrupts (allow-with-interrupts (%call-with-system-mutex)))) ((nil) `(without-interrupts (%call-with-system-mutex)))))))) (def call-with-system-mutex) (def call-with-system-mutex :without-gcing) (def call-with-system-mutex :allow-with-interrupts)) ---------------------- Armed Bear Common Lisp 0.13.0-dev Java 1.6.0_23 Sun Microsystems Inc. OpenJDK Server VM Low-level initialization completed in 0.344 seconds. Startup completed in 1.453 seconds. Type ":help" for a list of available commands. CL-USER(1): (compile-file "/tmp/foo") ; Compiling /tmp/foo.lisp ... ; (IN-PACKAGE :CL-USER) ; (DEF CALL-WITH-SYSTEM-MUTEX) ; in (MACROLET (#) ...) ; Caught STYLE-WARNING: ; Undefined variable: GOT-IT Stack inconsistency at index 63: found 3, expected 1. java.lang.VerifyError: (class: org/armedbear/lisp/foo_1, method: execute signature: (Lorg/armedbear/lisp/LispObject;Lorg/armedbear/lisp/LispObject;)Lorg/armedbear/lisp/LispObject;) Inconsistent stack height 1 != 3 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.getConstructor(Class.java:1674) at org.armedbear.lisp.Lisp.loadCompiledFunction(Lisp.java:1147) at org.armedbear.lisp.Lisp.loadCompiledFunction(Lisp.java:1074) at org.armedbear.lisp.CompiledFunction$1.execute(CompiledFunction.java:186) at org.armedbear.lisp.Symbol.execute(Symbol.java:720) at org.armedbear.lisp.LispThread.execute(LispThread.java:638) at org.armedbear.lisp.compile_file_4.execute(compile-file.lisp:63) at org.armedbear.lisp.Symbol.execute(Symbol.java:720) at org.armedbear.lisp.LispThread.execute(LispThread.java:638) at org.armedbear.lisp.compile_file_8.execute(compile-file.lisp:103) at org.armedbear.lisp.LispThread.execute(LispThread.java:680) Eric

1 1

[armedbear-devel] [ANNOUNCE] ABCL 0.27.0 released
by Erik Huelsmann 03 Sep '11

03 Sep '11

On behalf of the developers of ABCL (Armed Bear Common Lisp) I'm glad to be able to announce the 0.27.0 release. ABCL is a Common Lisp implementation implemented in Java and running on the JVM, featuring both an interpreter and a compiler. The compiler targets the JVM directly meaning that its output is runnable JVM bytecode. The fact that ABCL is written in Java allows for relatively easy embedding in larger applications. For integration with existing applications ABCL implements JSR 223: Java scripting API. This release features - among other things - wider compatibility for Quicklisp encapsulated systems basedon reports for problems with ABCL: fixes for PARENSCRIPT, NAMED-READTABLES and CL-INTERPOL (CL-UNICODE fix). Additionally, ABCL has regained the ability to build SBCL. The release notes can be found at: http://common-lisp.net/project/armedbear/release-notes-0.27.shtml and the list of changes at: http://trac.common-lisp.net/armedbear/browser/trunk/abcl/CHANGES If you have questions regarding use or licensing, or you find issues, please report back to the development list: armedbear-devel at common-lisp dot net Source distribution archives can be downloaded in ZIP or gzipped tar form: http://common-lisp.net/project/armedbear/releases/0.27.0/abcl-src-0.27.0.ta… http://common-lisp.net/project/armedbear/releases/0.27.0/abcl-src-0.27.0.zip Signatures are available under: http://common-lisp.net/project/armedbear/0.27.0/releases/abcl-src-0.27.0.ta… http://common-lisp.net/project/armedbear/0.27.0/releases/abcl-src-0.27.0.zi… In addition, binaries are also available: http://common-lisp.net/project/armedbear/releases/0.27.0/abcl-bin-0.27.0.ta… http://common-lisp.net/project/armedbear/releases/0.27.0/abcl-bin-0.27.0.zip With associated signatures: http://common-lisp.net/project/armedbear/releases/abcl-bin-0.27.0.tar.gz.asc http://common-lisp.net/project/armedbear/releases/abcl-bin-0.27.0.zip.asc

1 0

[armedbear-devel] Fwd: [armedbear-cvs] r13546 - trunk/abcl
by Erik Huelsmann 29 Aug '11

29 Aug '11

Hi Mark, Could you add the changes related to JSS, JAR packaging and the like that you have been putting on trunk? The current list is compiled based on r13382 (branch point 0.26) up to HEAD, manually eliminating the revisions which have been merged into the 0.26 branch. Looking at the list, I'd like to create another release soon: the pretty printer fixes haven't made it in a public release yet, nor have many of the JAR packaging fixes and improvements that you committed. As always, if you see things differently, discussion welcome, of course! Bye, Erik. ---------- Forwarded message ---------- From: <ehuelsmann(a)common-lisp.net> Date: Sun, Aug 28, 2011 at 10:36 PM Subject: [armedbear-cvs] r13546 - trunk/abcl To: armedbear-cvs(a)common-lisp.net Author: ehuelsmann Date: Sun Aug 28 13:36:34 2011 New Revision: 13546 Log: More CHANGES updates. Modified: trunk/abcl/CHANGES Modified: trunk/abcl/CHANGES ============================================================================== --- trunk/abcl/CHANGES Sun Aug 28 13:11:41 2011 (r13545) +++ trunk/abcl/CHANGES Sun Aug 28 13:36:34 2011 (r13546) @@ -14,6 +14,13 @@ Changes ------- + * Renamed LispObject.writeToString() method to (more lispy) printObject() + + * New LispObject.princToString() for user readable output + + * Changed behaviour of LispObject.unreadableString() to signal + errors when *PRINT-READABLY* is non-NIL + * Static initializers moved to <clinit>() (java: static { }) to prevent repeated execution when invoking the constructor multiple times @@ -24,6 +31,11 @@ * File compiler (COMPILE-FILE) clean-ups + * When calling a function with the wrong number of arguments, + report the expected (range) of arguments + + * Upgraded ASDF to 2.017 + Fixes ----- @@ -39,6 +51,15 @@ * [ticket #163] Local functions shadow global macro and function bindings (fixes PARENSCRIPT support) + * [ticket 158] Readable printing of the string "#<abc>" does not signal + a PRINT-NOT-READABLE error anymore + + * Fixed SYNTAX.SHARP-BACKSLASH.6 and SYNTAX.SHARP-BACKSLASH.7 + + * Fixed many PPRINT.* test suite failures + + * [ticket #151] LOAD fails for whitespace in JAR-PATHNAME + Version 0.26.2 ============== _______________________________________________ armedbear-cvs mailing list armedbear-cvs(a)common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-cvs

2 1

[armedbear-devel] Compiling large Java-classes slow?
by Ole Myren Rohne 24 Aug '11

24 Aug '11

Hi ABCL-developers, Is there a recent change (since May?) that would have made compiling files containing large wrapped Java-classes excessively slow? If so, is there any hope of this eventually improving? Ole

2 3

[armedbear-devel] More efficient compilation of forward references -- WAS: r13536 - trunk/abcl/src/org/armedbear/lisp
by Erik Huelsmann 23 Aug '11

23 Aug '11

When you look at the ### FASLATONCE comments, you may be wondering what I'm doing here. Well, I'm looking at a way to make our own compilation much faster again, but also to make our compiled code much faster. The problem - as I understand it now - with our slow compilation since the introduction of the jvm-class-file.lisp file is NOT so much the fact that we store lots of data in structures now (I thought it was when I did that work though). Rather, my current understanding is that the declaration order of functions in a file is extremely important for the performance of said fasl: Backward referenced functions (those being defined first and called from code "further down the file") are being called through direct calls of the execute() method of a final static field in the class of the calling function. Since the value is final, the JVM is allowed to assume the jump is always going to go to the same class's execute() method which can be very easily optimized. Forward referenced functions (those being called before they are defined -- although still defined in the same file) are being resolved through a call to the getSymbolFunctionOrDie() function of the function's symbol. Since that variable is *not* final, the call to the return value of getSymbolFunctionOrDie() can't be as easily JITted. Hence my idea to compile all toplevel compilands *after* the entire file has been processed and all toplevel functions have been discovered. At that time, the functions can be compiled and all forward references can be resolved and hard coded using final static fields. However: this introduces the risk of circularity during fasl loading. My remarks relate to that problem. Bye, Erik. On Tue, Aug 23, 2011 at 11:34 PM, <ehuelsmann(a)common-lisp.net> wrote: > Author: ehuelsmann > Date: Tue Aug 23 14:34:33 2011 > New Revision: 13536 > > Log: > Move more static field initialization to the static class initializer > <clinit>() code. > > Additionally, place some remarks where I expect issues once I start > compiling forward references the same way as backward references. > > Modified: > trunk/abcl/src/org/armedbear/lisp/compiler-pass2.lisp > > Modified: trunk/abcl/src/org/armedbear/lisp/compiler-pass2.lisp > > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/compiler-pass2.lisp Tue Aug 23 > 13:35:32 2011 (r13535) > +++ trunk/abcl/src/org/armedbear/lisp/compiler-pass2.lisp Tue Aug 23 > 14:34:33 2011 (r13536) > @@ -1392,7 +1392,7 @@ > (local-function-compiland local-function)))) > (field-name (local-function-field local-function))) > (with-code-to-method > - (*class-file* (abcl-class-file-constructor *class-file*)) > + (*class-file* (abcl-class-file-static-initializer *class-file*)) > ;; fixme *declare-inline* > (declare-field field-name +lisp-object+) > (emit-new class-name) > @@ -1416,7 +1416,7 @@ > (with-code-to-method > (*class-file* > (if *declare-inline* *method* > - (abcl-class-file-constructor *class-file*))) > + (abcl-class-file-static-initializer *class-file*))) > ;; strings may contain evaluated bits which may depend on > ;; previous statements > (declare-field g +lisp-object+) > @@ -1432,7 +1432,7 @@ > (with-code-to-method > (*class-file* > (if *declare-inline* *method* > - (abcl-class-file-constructor *class-file*))) > + (abcl-class-file-static-initializer *class-file*))) > ;; The readObjectFromString call may require evaluation of > ;; lisp code in the string (think #.() syntax), of which the outcome > ;; may depend on something which was declared inline > @@ -1455,7 +1455,7 @@ > ;; fixme *declare-inline*? > (remember g obj) > (with-code-to-method > - (*class-file* (abcl-class-file-constructor *class-file*)) > + (*class-file* (abcl-class-file-static-initializer *class-file*)) > (declare-field g +lisp-object+) > (emit 'ldc (pool-string g)) > (emit-invokestatic +lisp+ "recall" > @@ -4149,6 +4149,11 @@ > (emit-load-local-function local-function) > (emit-move-from-stack target)) > ((inline-ok name) > + ;; ### FASLATONCE: when compiling fasl functions after the > + ;; full fasl has been processed, forward referenced functions > + ;; may not be available during the load process > + ;; This case is particularly triggered with circular referencing > + ;; functions, both marked as 'notinline' > (emit-getstatic *this-class* > (declare-function name) +lisp-object+) > (emit-move-from-stack target)) > @@ -4166,6 +4171,11 @@ > (emit-load-local-function local-function)) > ((and (member name *functions-defined-in-current-file* :test > #'equal) > (not (notinline-p name))) > + ;; ### FASLATONCE: when compiling fasl functions after the > + ;; full fasl has been processed, forward referenced functions > + ;; may not be available during the load process > + ;; This case is particularly triggered with circular referencing > + ;; functions, both marked as 'notinline' > (emit-getstatic *this-class* > (declare-setf-function name) +lisp-object+) > (emit-move-from-stack target)) > > _______________________________________________ > armedbear-cvs mailing list > armedbear-cvs(a)common-lisp.net > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-cvs >

1 0

[armedbear-devel] ticket #124: SBCL build host / "the" pretty printer issue
by Erik Huelsmann 23 Aug '11

23 Aug '11

Talking to Mark on IRC, we were discussing about how to restore ABCL's capability of being an SBCL buildhost. We were a buildhost some years back: it was one of the things Peter Graves used to stress test ABCL's conformance. However, we've not been able to build SBCL for quite some time now, as ticket #124 [1] witnesses. In IRC Mark kept referring to this problem as "the issue with our Gray streams conformance". I'm writing this mail to explain that our "Gray streams conformance" is not the issue that's causing this breakage. Basically, we have two issues with our streams: 1. Gray streams conformance 2. Our pretty printer implementation While our Gray streams conformance may not be ideal - I'd have to investigate where we stand exactly on that issue - our pretty printer is breaking our ability to build SBCL. (Our Gray streams conformance is good enough to support flexi-streams, so, that's good enough for me.) The usual way a pretty printer is implemented -and that's the way SBCL implements it as well- is by wrapping a stream around the stream which is being pretty printed to. That way, the pretty printer receives all output being printed and is in a position to appropriately add tabbing, indenting and other formatting. Then it sends the output to the actual target stream. Now, our implementation is a little bit different, but different enough to cause problems, I guess. We wrap the stream being printed to, however, we wrap the stream with a structure object instead of another stream. Then, in order to mitigate the negative effects from our wrapping using a structure-object (XP-STRUCTURE). On the Java side of things, input values are being checked to be a STREAM, however, this XP-STRUCTURE isn't a derived class from a class which is a stream. So, our Java side type checking fails. Any conforming code should expect the stream argument to PRINT-OBJECT to be a stream (but it cannot make more assumptions than that), an expectation we violate. Possibly, there are other spots where we fail to meet the STREAMP checks. My idea to resolve the situation would be to create streams the way SBCL does it: SBCL knows two types of streams: Gray streams and ansi-streams. Anything not an ansi-stream follows the Gray stream dispatch path. ANSI-STREAM is a structure-object which holds slots for input and output functions. The pretty printer structure includes the ANSI-STREAM structure by virtue of which it becomes a stream itself. The STREAM type is simply DEFTYPEd to be equal to ANSI-STREAM. The I/O routines (it only sets the output routine) simply forwards its writes to the to the wrapped stream. This way, their pretty printer wrapper stream doesn't violate any of the expectations user code may have about the STREAM argument of PRINT-OBJECT. My idea would be that we should investigate if and how we can implement a similar approach. Mark or anybody else, could you comment on the above? Bye, Erik. [1] http://trac.common-lisp.net/armedbear/ticket/124

1 0

[armedbear-devel] Read tables
by Blake McBride 22 Aug '11

22 Aug '11

Dear Erik, Based on your input, I have been thinking more about making my interface case sensitive. It would be better. After doing a little research I tried: (setf (readtable-case *readtable*) :invert) This seems to have made all the standard stuff ("car, cons, etc.") lowercase as I'd prefer. After that I tried creating lists: (setq x '(HELLO There how)) and the case seems to be preserved - not inverted. I also tried things like: (defun fun (x) (+ 1 x)) (defun Fun (x) (+ 2 x)) (defun FUN (x) (+ 3 x)) And it worked as expected. I'm a bit confused. Why aren't symbols (as in '(HELLO There how)) inverted? (I understand that :invert doesn't change case on mixed case symbols but then all upper or all lower should be inverted.) Is *print-case* being affected? At first test, it seems like :invert does exactly what most people want - case sensitive lisp that has system symbols all lower case. Are there instances in which this doesn't work? Will this affect lisp-java usage when it comes to case? Any pointers would be appreciated. Thanks. Blake McBride

2 1

Re: [armedbear-devel] [armedbear-ticket] [armedbear] #164: Cannot quit SLIME REPL
by Ville Voutilainen 22 Aug '11

22 Aug '11

On 22 August 2011 12:21, armedbear <armedbear-devel(a)common-lisp.net> wrote: > Further analysis reveals that ProcessingTerminated is a pure Java-side > construct so there is currently no way to hook in from Lisp, so that part > of the concern is unfounded. > Still, calling System.exit() seems really wrong. Need to reconsider the > reason under which ProcessingTerminated exception was introduced. Sounds like ext:exit has been converted to do ProcessingTerminated, but it shouldn't actually do that. This strongly suggests that too much has been changed over to ProcessingTerminated; the original reason for converting some uses over is still valid, because in order to work as a library, abcl should avoid exitting.

3 5

Re: [armedbear-devel] [armedbear-cvs] r13530 - trunk/abcl/src/org/armedbear/lisp
by Ville Voutilainen 22 Aug '11

22 Aug '11

On 22 August 2011 12:52, <mevenson(a)common-lisp.net> wrote: > Author: mevenson > Date: Mon Aug 22 02:52:28 2011 > New Revision: 13530 > > Log: > All LispThread objects can act on a ProcessingTerminated exception. > Without this modifications, threads created with the > THREADS:MAKE-THREADS cannot successfully call the EXT:QUIT or EXT:EXIT > functions. This prevented the SLIME quit implementation from > successfully quitting implementations. > Note that all threads can always execute a form like > (jstatic "exit" "java.lang.System" 0) > to uncermoniously exit the JVM, so there is nothing gained > security-wise by preventing threads from using the official Lisp > interfaces. > + catch (ProcessingTerminated e) { > + System.exit(e.getStatus()); > + } This looks.. ..unfortunate. We should not get into a situation where a LispThread catches this exception, the exception is supposed to be used for terminating the repl if it can't load. It's fine as a stopgap measure, but exit requests from threads shouldn't end up throwing that exception.

1 0