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

[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

[armedbear-devel] Fwd: [armedbear-cvs] r13516 - svn:log
by Erik Huelsmann 20 Aug '11

20 Aug '11

Hi Alessio, Thanks for the read tables research last week. I went ahead and implemented a fix. Could you confirm the fix works for your testing? Bye, Erik. ---------- Forwarded message ---------- From: <ehuelsmann(a)common-lisp.net> Date: Sat, Aug 20, 2011 at 12:06 PM Subject: [armedbear-cvs] r13516 - svn:log To: armedbear-cvs(a)common-lisp.net Author: ehuelsmann Revision: 13516 Property Name: svn:log Action: modified Property diff: --- old property value +++ new property value @@ -1 +1,3 @@ -Fix #161: READTABLE-CASE setting of *readtable* affects FASL content. \ No newline at end of file +Fix #161: READTABLE-CASE setting of *readtable* affects FASL content. + +Note: Fix based on research by Alessio Stalla. \ No newline at end of file _______________________________________________ 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] type mismatch for "asList"
by Patrice Seyed 19 Aug '11

19 Aug '11

Hello, With the following expression: (#"asList" 'Arrays "test") I get the error: Java exception 'SchemeException: java.lang.IllegalArgumentException: argument type mismatch ARGUMENT MISMATCH for method public static java.util.List java.util.Arrays.asList(java.lang.Object[]) called with ("test")'. [Condition of type JAVA-EXCEPTION] But "test" is of java.lang.String, which is a subclass of java.lang.Object, so I'm not sure what the mismatch is. Any help appreciated. Patrice

2 1

[armedbear-devel] Using ABCL in Android
by Joe Mendoza 18 Aug '11

18 Aug '11

To ABCL developers, I tried to use the java to lisp interpreter in Android, however, I received an error message; "Could not find method java.beans.Introspector.getBeanInfo, referenced from method org.armedbear.lisp.Java.getPropertyDescriptor". I've learned that Android doesn't support the use of Java beans. Would there be another way to compile ABCL without implementing Java beans? Thanks, Joe

3 4