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

[armedbear-devel] anonymous inner class in abcl
by Patrice Seyed 17 Aug '11

17 Aug '11

Right, Hello abcl developers, Let's say I want to implement an anonymous inner class, just for example ActionListener with method actionPerformed: JButton button = new JButton("Enter"); button.addActionListener(new ActionListener (){ public void actionPerformed(ActionEvent e){ System.out.println("The Enter button was pressed"); } }); What is the best way to do this in abcl? Cheers, Patrice On Tue, Aug 16, 2011 at 4:09 PM, Alan Ruttenberg <alanruttenberg(a)gmail.com>wrote: > > > On Tue, Aug 16, 2011 at 3:55 PM, Patrice Seyed <apseyed(a)gmail.com> wrote: > >> How about a boolean? >> > > (make-immediate-object nil :boolean) > (make-immediate-object t :boolean) > > >> Next, I'm trying to work my way up to defining anonymous inner classes >> from within abcl. >> > > That's a bit more problematic, at least for me. > Can you write up a specific small code example you want to implement and > send a note the armedbear-devel(a)common-lisp.net asking for what the > recommended approach would be? > > -Alan > > > >> >> Patrice >> >> On Mon, Aug 15, 2011 at 5:53 PM, Alan Ruttenberg < >> alanruttenberg(a)gmail.com> wrote: >> >>> null = (make-immediate-object nil :ref) >>> >>> On Mon, Aug 15, 2011 at 4:06 PM, Patrice Seyed <apseyed(a)gmail.com> >>> wrote: >>> > Alan, >>> > >>> > If I wanted to pass as an argument that I would specify as null in >>> > java, from abcl to java, how would I do that? >>> > >>> > For example a method called method1 that takes two argument that I >>> > want to pass a string and the second argument null: >>> > >>> > (#"method1" 'ClassName "string" nil) >>> > >>> > If I specify nil as i did here I get a java exception "argument type >>> mismatch". >>> > >>> > Patrice >>> > >>> >> >> >

3 2

Re: [armedbear-devel] lsw2
by Alan Ruttenberg 17 Aug '11

17 Aug '11

On Tue, Aug 16, 2011 at 3:55 PM, Patrice Seyed <apseyed(a)gmail.com> wrote: > How about a boolean? > (make-immediate-object nil :boolean) (make-immediate-object t :boolean) > Next, I'm trying to work my way up to defining anonymous inner classes from > within abcl. > That's a bit more problematic, at least for me. Can you write up a specific small code example you want to implement and send a note the armedbear-devel(a)common-lisp.net asking for what the recommended approach would be? -Alan > > Patrice > > On Mon, Aug 15, 2011 at 5:53 PM, Alan Ruttenberg <alanruttenberg(a)gmail.com > > wrote: > >> null = (make-immediate-object nil :ref) >> >> On Mon, Aug 15, 2011 at 4:06 PM, Patrice Seyed <apseyed(a)gmail.com> wrote: >> > Alan, >> > >> > If I wanted to pass as an argument that I would specify as null in >> > java, from abcl to java, how would I do that? >> > >> > For example a method called method1 that takes two argument that I >> > want to pass a string and the second argument null: >> > >> > (#"method1" 'ClassName "string" nil) >> > >> > If I specify nil as i did here I get a java exception "argument type >> mismatch". >> > >> > Patrice >> > >> > >

2 1

[armedbear-devel] readtable-case :invert does not invert uninterned symbols
by Ole Arndt 16 Aug '11

16 Aug '11

This prevents loading a newer parenscript, which uses an inverted readtable case via named-readtables: Armed Bear Common Lisp 0.26.0-dev-svn-13273 Java 1.6.0_17 Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.712 seconds. Startup completed in 3.154 seconds. Type ":help" for a list of available commands. CL-USER(1): (setf (readtable-case *readtable*) :invert) :invert CL-USER(2): (string :cl) "CL" CL-USER(3): (string '#:cl) "cl" Cheers Ole -- Ole Arndt http://www.sugarshark.com

3 5

[armedbear-devel] Refactoring compile-file.lisp
by Erik Huelsmann 14 Aug '11

14 Aug '11

Yesterday while refactoring compiler-pass2 I found that moving a function from the top of the file to the bottom can cause serious performance degradation (and performance win, the other way around). That somehow doesn't feel like what one would expect of a good enough compiler these days. To see if I can create a change to our file-compiler which doesn't exhibit this issue, I'm preparing an experiment where COMPILE-FILE will batch up all class files to be generated until the end of the processing of the input file. Then, all functions will be known in advance and calling functions being forward-referenced should have the same properties as calling backward referenced functions. In order to be able to even start working on the above, compile-file.lisp should at least be readable and understandable. My refactoring of today is in preparation of the experiment (which I could conduct on a branch), to clean up compile-file.lisp and cut it down to readable chunks of code with well-defined calling conventions. Just thought I'd explain my current work on compile-file.lisp. Bye, Erik.

1 0

[armedbear-devel] Bad Windows regression fixed; time for abcl-0.26.2?
by Mark Evenson 11 Aug '11

11 Aug '11

Today, [I fixed a bad bug in which fasls with whitespace in their path under Windows were failing to load][13460]. Given how common whitespace in pathnames under Windows should be, I would suggest that we should make an abcl-0.26.2 release in the next week or so. Maybe we can use this as an exercise for someone other than Erik to make a release (namely me)? I think Erik has signed my PGP key at this point, although I haven't checked. [13460]: http://trac.common-lisp.net/armedbear/changeset/13460 -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

[armedbear-devel] Fwd: [armedbear-cvs] r13450 - trunk/abcl/src/org/armedbear/lisp
by Erik Huelsmann 07 Aug '11

07 Aug '11

Hi Mark, Maybe you want to check if CL-CONTAINERS now wants to load? At least we now support SETF of APPLY with user-defined functions. And, yes, I did check that the order of evaluation of the arguments remains in tact: (defvar b 0) --> B (defun m () (incf b)) --> M (defvar v nil) -->V (defun (SETF MYFUN) (new-value &rest rest) (setf v new-value)) --> (SETF MYFUN) (setf (apply #'myfun (list (m) (m) (m))) (m)) --> 4 Bye, Erik. ---------- Forwarded message ---------- From: <ehuelsmann(a)common-lisp.net> Date: Sun, Aug 7, 2011 at 10:18 PM Subject: [armedbear-cvs] r13450 - trunk/abcl/src/org/armedbear/lisp To: armedbear-cvs(a)common-lisp.net Author: ehuelsmann Date: Sun Aug 7 13:17:59 2011 New Revision: 13450 Log: Fix #141 (SETF of APPLY not working with arbitrary function) by "adding" the feature. Modified: trunk/abcl/src/org/armedbear/lisp/late-setf.lisp Modified: trunk/abcl/src/org/armedbear/lisp/late-setf.lisp ============================================================================== --- trunk/abcl/src/org/armedbear/lisp/late-setf.lisp Sun Aug 7 07:20:58 2011 (r13449) +++ trunk/abcl/src/org/armedbear/lisp/late-setf.lisp Sun Aug 7 13:17:59 2011 (r13450) @@ -88,11 +88,6 @@ `(getf ,get ,ptemp ,@(if default `(,def-temp))))))) (define-setf-expander apply (functionoid &rest args) - (unless (and (listp functionoid) - (= (length functionoid) 2) - (eq (first functionoid) 'function) - (memq (second functionoid) '(aref bit sbit))) - (error "SETF of APPLY is only defined for #'AREF, #'BIT and #'SBIT.")) (let ((function (second functionoid)) (new-var (gensym)) (vars (make-gensym-list (length args)))) _______________________________________________ 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] Building support for inspection of local variables in (compiled) code
by Erik Huelsmann 07 Aug '11

07 Aug '11

This summer, Mark and I met in person. We discussed several things, we wanted to improve on ABCL. One of the most important things to improve on ABCL, or so it seems to us, is to be able to inspect - given high enough debug settings - the locals in the current stackframe. Since I have had a good idea how to do this for a long time now, I'm writing down how I want to do it, making it work for both compiled and interpreted functions. The basic requirements are simple: while walking the stack, being able to focus on any single frame and retrieving the locals from it, as well as their values for inspection, of course. Being able to STEP code isn't a requirement - although that may be subject to another change later. My idea is really actually very simple. We already have an interpreter which creates Environment objects to record the lexical variables and their values (as well as temporary "specialness"). The missing bit is the link between the environment and the stack frame. Note that within the scope of a single stack frame, multiple environments may be cycled through, one after another. This typically happens with new binding blocks such as DO/DO*, LET/LET*, M-V-B, etc. Since this information is all readily available, I'm envisioning a method on LispThread which sets the environment of the current stack frame. Then, when the debugger is invoked, the environment object of the stack frame to be inspected can be retrieved and the bindings referred to it can be walked to print the state of the lexical environment. The impact of this change is relatively limited: everywhere we find a "new Environment", we want to review if adding the environment to the stackframe is applicable. So far so good. Now about compiled code. It doesn't have Environment objects, because the environment is hard coded into the compiled functions. If we were to step away from that concept, we might as well completely stop compiling the program. So now what? I see a middle road: values reachable through an Environment are stored in a linked list of Binding objects. We could create these Binding objects, adding them to the environment, but still keeping a reference to them. Then, our performance would only suffer a single additional level of indirection. The thing to be figured out would be how to 'model' closures. The environment model works well with closures in interpreted mode, but with this 'faked' environment it works less well. One solution would be to add the closure variables to the Environment upon function entry. That might cost some performance, but would require no access to the outer Environment. Other solutions - which I haven't evaluated yet - might involve the array of ClosureBindings, which is a way to carry information from one closure to another. Comments? Bye, Erik.

1 0

[armedbear-devel] About fixing #90 (resetSpecialBindings efficiency)
by Erik Huelsmann 07 Aug '11

07 Aug '11

Yesterday, I was looking at some of our tickets and decided to hack the compiler to support ticket #90 [1]. As with earlier special bindings fixes, I've tested this feature on Maxima which - at least in older versions - is highly sensible to the performance of special variables. The performance test shows no relevant difference in performance between the clean and the patched version (1140sec patched, 1087sec unpatched - I attribute the difference to statistical variation). So, the question is: even though the generated code is cleaner and smaller, do we want to make the compiler more complex to support it? The patch in question is attached for those interested. Bye, Erik. [1] http://trac.common-lisp.net/armedbear/ticket/90

1 0

Re: [armedbear-devel] ABCL threading questions
by David Wang 04 Aug '11

04 Aug '11

Thanks for that very helpful reply. I'll look into both threading libraries. In the meantime, I created a ".swank.lisp" in my home directory, and added the text "(setf swank:*globally-redirect-io* t)". I restarted emacs and abcl, and now my threading example as well as my actual code works great. I can see all the formats.

1 0

[armedbear-devel] ABCL threading questions
by David Wang 03 Aug '11

03 Aug '11

Hello, I just started working with ABCL's (version 0.26.1) threading functionality and had two questions along those lines: 1. Is there documentation for the threading support somewhere? Even a list of applicable methods and which src files they are defined in would be useful. I already found threads.lisp and abcl's swank interface. I was wondering if there were conditional-variables or conditional-waits, and was just interested in seeing what other functionality is currently supported. 2. This question is a little more complicated, and deals with when (format t "text") will print to std-out/repl and when it won't. When I make a thread that uses (format t ...), I can see the output on the std-out/repl when I run abcl from a terminal, but not when I run it from emacs/slime. I'm guessing the reason for this is that swank doesn't redirect output from the other threads to emacs. a.) Is there a reason for not redirecting this output? i.e. will it interfere with swank's operation? b.) Is there a fix or some places I should look to see if I can write a fix? For those interested in code, I've included some below, the following code starts two threads that send "thread1" and "thread2" messages to one mailbox. It then starts a third thread that reads from that mailbox and prints its contents. The third thread's output can be seen if this code is loaded from a terminal/prompt, but not within slime. - Thank you. ============================================================ (in-package #:cl-user) (defun mailbox-send (mailbox item) "Sends an item into the mailbox, notifying 1 waiter to wake up for retrieval of that object. Copied and fixed from threads.lisp" (threads:synchronized-on mailbox (setf (threads::mailbox-queue mailbox) (nconc (threads::mailbox-queue mailbox) `(,item))) (threads:object-notify mailbox))) (defun mailbox-read (mailbox &key (blocking t)) "Blocks on the mailbox until an item is available for reading. When an item is available, it is returned." (threads:synchronized-on mailbox (when blocking (loop (unless (threads:mailbox-empty-p mailbox) (return)) (threads:object-wait mailbox))) (if (threads:mailbox-empty-p mailbox) (values nil nil) (values (pop (threads::mailbox-queue mailbox)) t)) )) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; THREAD TEST (defparameter *mailbox* (threads:make-mailbox)) (defvar *stop-mailbox* (threads:make-mailbox)) (defun send-stop () (mailbox-send *stop-mailbox* :stop)) (defun read-stop () (eq (threads:mailbox-peek *stop-mailbox*) :stop)) (defun clear-stop () (threads:synchronized-on *stop-mailbox* (setf (threads::mailbox-queue *stop-mailbox*) '()))) (defun tfn1 () (loop (when (read-stop) (return)) (mailbox-send *mailbox* (format nil "thread1")) (sleep 1))) (defun tfn2 () (loop (when (read-stop) (return)) (mailbox-send *mailbox* (format nil "thread2")) (sleep 1))) (defun tprint-mailbox () (loop (when (read-stop) (return)) (format t "~s~%" (mailbox-read *mailbox*)))) (defparameter *thread1* (threads:make-thread #'tfn1)) (defparameter *thread2* (threads:make-thread #'tfn2)) (defparameter *thread3* (threads:make-thread #'tprint-mailbox))

2 1