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

[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

[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 27 Jul '11

27 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