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

[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 03 Aug '11

03 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

[armedbear-devel] [ANNOUNCE] ABCL 0.26.1 released
by Erik Huelsmann 30 Jul '11

30 Jul '11

On behalf of the developers of ABCL (Armed Bear Common Lisp) I'm glad to be able to announce the 0.26.1 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 lots of other things - a major reduction in the number of failures in the ANSI test suite: dropping from 26 to 16 failures on some systems (of 21699 tests in total). Additionally, ABCL now runs Hunchentoot and several other packages from the top downloads from Quicklisp. http://common-lisp.net/project/armedbear/release-notes-0.26.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.26.1/abcl-src-0.26.1.ta… http://common-lisp.net/project/armedbear/releases/0.26.1/abcl-src-0.26.1.zip Signatures are available under: http://common-lisp.net/project/armedbear/0.26.1/releases/abcl-src-0.26.1.ta… http://common-lisp.net/project/armedbear/0.26.1/releases/abcl-src-0.26.1.zi… In addition, binaries are also available: http://common-lisp.net/project/armedbear/releases/0.26.1/abcl-bin-0.26.1.ta… http://common-lisp.net/project/armedbear/releases/0.26.1/abcl-bin-0.26.1.zip With associated signatures: http://common-lisp.net/project/armedbear/releases/abcl-bin-0.26.1.tar.gz.asc http://common-lisp.net/project/armedbear/releases/abcl-bin-0.26.1.zip.asc

2 2

[armedbear-devel] Release 0.26.1 -- status?
by Erik Huelsmann 26 Jul '11

26 Jul '11

The two issues below have been fixed and a few other issues which were resolved in the mean time have been backported to 0.26.1 as well. I was able to build the binaries using the abcl.release target (instead of using the separate abcl.binary.* targets), so it seems all our issues are now fixed and we can move to 0.26.1 next week. Is there anybody with any remaining issues or fixes up his sleeve? Anybody wants to report an issue with the current 0.26.x branch? If not, I'm planning to roll the 0.26.1 release mid next week. Bye, Erik. On Mon, Jul 11, 2011 at 10:18 PM, Erik Huelsmann <ehuels(a)gmail.com> wrote: > Hi, > > On Mon, Jul 11, 2011 at 7:51 PM, Mark Evenson <evenson(a)panix.com> wrote: > >> On 7/10/11 12:53 AM, Erik Huelsmann wrote: >> >>> I've created the 0.26 release branch after updating CHANGES. >>> >>> If there are no further objections, I'll continue the release process by >>> signing the release. >>> >>> It'd be very helpful if one of the other committers can update the >>> webpages, as I won't have time to do that today or tomorrow. >>> >> >> Unfortunately, the abcl-0.26.0-src release won't build because that >> archive is missing the newly added org.armedbear.lisp.protocol package. >> >> [Fixed and backported to the abcl-0.26.x branch][1]. >> >> [1]: http://trac.common-lisp.net/**armedbear/changeset/13391<http://trac.common-lisp.net/armedbear/changeset/13391> >> >> My vote would be to figure out the stack overflow reported in [ticket >> #154][2] as well as whatever is causing the ansi-interpreted errors that >> Ville is noticing, and move to releasing an abcl-0.26.1. >> >> [2]: http://trac.common-lisp.net/**armedbear/ticket/154<http://trac.common-lisp.net/armedbear/ticket/154> >> >> Erik is on his first day of vacation, and probably has limited upload >> bandwidth, so we may be a bit constrained here. >> > > Yea, it'd be very convenient for me to fix any remaining issues and go for > a 0.26.1 in 2 weeks. Also because my signing key is most easily operated at > home. > > Let's take some time to solve these regressions and scrap the brown paper > bag release :-) > > > Bye, > > > Erik. >

3 3

[armedbear-devel] Adjustable arrays and Java
by Theam Yong Chew 20 Jul '11

20 Jul '11

Hi all, I might have found an interop issue with adjustable arrays. First create an adjustable array with some "empty unfilled space". (defparameter *arr* (let ((x (make-array 0 :fill-pointer 0 :adjustable t :element-type 'base-char))) (vector-push-extend #\a x) (vector-push-extend #\b x) (vector-push-extend #\c x) (vector-push-extend #\d x) x)) Pass the array into Java and copy it back into Lisp. CL-USER> (jcall "getText" (jnew "javax.swing.JButton" *arr*)) "abcd^@^@^@" CL-USER> (jcall "getText" (jnew "javax.swing.JButton" (copy-seq *arr*))) "abcd" I've hand edited the above -- the ^@ character is actually a #\Null of course. More examples: CL-USER> (jnew "java.lang.String" *arr*) #<java.lang.String abcd^@^@^@ {F10A53}> Yong.

2 2

[armedbear-devel] Anybody going to ECLM (Amsterdam) in October?
by Erik Huelsmann 18 Jul '11

18 Jul '11

This morning, I completed my own registration process for my own entry. Will I be seeing any other ABCL users/ developers? Bye, Erik.

3 2

[armedbear-devel] The purpose of the writeToString() method (before we can rename it to printObject() or anything else)
by Erik Huelsmann 17 Jul '11

17 Jul '11

Today I thought I'd address ticket #160. That ticket is about %OUTPUT-OBJECT (a primitive) checking the string returned for the non-readable "#<" marker. The problem is that it'll raise a PRINT-NOT-READABLE error on any output containing that marker, even if it's part the serialized presentation which *is* readable, like the uninterned symbol #:|#<32|. The solution I'm aiming at is to make every writeToString() method raise an error when it can't return a readable representation when a readable representation is requested. In preparation of this change I'm investigating the uses of writeToString(). There are 213 occurrences of the string ".writeToString()", many of which are related to the creation of error messages. It'd be particularly impractical to generate errors while creating an error message. On the other hand, there are also uses, such as the one by %OUTPUT-OBJECT which typically *should* obey those values and generate the PRINT-NOT-READABLE error accordingly. So, simply renaming writeToString() to printObject() is still an option. We can even make the printObject() functions check whether they are allowed to return unreadable output. However, it seems to me we additionally need a function which returns - optionally unreadable - output without generating errors. I'm thinking of a function which resets the variables to the values WITH-STANDARD-IO-SYNTAX except that it binds *PRINT-READABLY* to NIL. Maybe that function should be called printUnreadableObject() or something alike. I've also thought about renaming writeToString() to printObjectInternal() and creating a new printObject(boolean requireReadable) which does the required work if the argument is true. Hmm. I hope the above is something people want to comment on. At least I've tried to describe my findings so far. I'm interested to know what others think. Bye, Erik.

1 1

[armedbear-devel] Fixing PRINT.RANDOM-STATE.1
by Erik Huelsmann 17 Jul '11

17 Jul '11

Today I was looking at fixing some of our PRINT.* failures in the ansi test suite. Hoping to get an easy start, I started looking PRINT.RANDOM-STATE.1 The problem shown by the test is that our RANDOM-STATEs are not printable. From the perspective of ABCL, that's logical: Java's Random objects are serializable, but as everywhere in Java, it's serialization is internal to the implementation. The Random object is initialized using a 'seed' long value, but there's no way to extract a 'seed' value from the object to be used to initialize an object into the same state. So, I'm now pondering what action to take. I'm seeing several options: 1. build our own pseudo random number generator with its own random state 2. serialize the Random object to a byte array and use that array as some sort of printed representation (sure, we'll definitely need to look into ways to load) The advantage of (1) is that we can create it all in Lisp, however, it's pure additional code, since we won't be leveraging what's already there. The advantage of (2) is that we can use what Java maintains for us and even better: we can use the random number generator shared between Lisp and Java code. I imagine the disadvantage of this solution is that the serialization of the random state can differ between Java versions and implementations. Any ideas?? Bye, Erik.

4 6

Re: [armedbear-devel] [armedbear-cvs] r13407 - trunk/abcl/src/org/armedbear/lisp
by Erik Huelsmann 16 Jul '11

16 Jul '11

This commit fixes a number of test cases related to circularity detection. Some of these cases showed loss of data. Even in the remaining failures, there's no longer any loss of data. The cases that still fail do however show loss of structure. That's on my list to be fixed. As it stands, I'm very happy to finally be fixing this long standing issue in our pretty printer. Bye, Erik. On Fri, Jul 15, 2011 at 11:18 PM, <ehuelsmann(a)common-lisp.net> wrote: > Author: ehuelsmann > Date: Fri Jul 15 14:18:28 2011 > New Revision: 13407 > > Log: > Eliminate a series of PPRINT.* ansi test suite failures > (dropping my test failure count from 27 to 20!). > > Modified: > trunk/abcl/src/org/armedbear/lisp/pprint.lisp > > Modified: trunk/abcl/src/org/armedbear/lisp/pprint.lisp > > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/pprint.lisp Fri Jul 15 09:34:23 > 2011 (r13406) > +++ trunk/abcl/src/org/armedbear/lisp/pprint.lisp Fri Jul 15 14:18:28 > 2011 (r13407) > @@ -611,12 +611,14 @@ > (if (xp-structure-p stream) > (apply fn stream args) > (let ((*abbreviation-happened* nil) > - (sys::*circularity-hash-table* > - (if (and *print-circle* (null sys::*circularity-hash-table*)) > - (make-hash-table :test 'eq) > - sys::*circularity-hash-table*)) > (*result* nil)) > - (xp-print fn (sys:out-synonym-of stream) args) > + (if (and *print-circle* (null sys::*circularity-hash-table*)) > + (let ((sys::*circularity-hash-table* (make-hash-table :test > 'eq))) > + (xp-print fn (make-broadcast-stream) args) > + (let ((sys::*circularity-counter* 0)) > + (xp-print fn (sys:out-synonym-of stream) args) > + )) > + (xp-print fn (sys:out-synonym-of stream) args)) > *result*))) > > (defun xp-print (fn stream args) > > _______________________________________________ > armedbear-cvs mailing list > armedbear-cvs(a)common-lisp.net > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-cvs >

1 0