armedbear-devel

armedbear-devel@common-lisp.net

1 participants
1200 discussions

[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

[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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel