gmane.lisp.cmucl.devel

Re: Bug in 19d when declaiming (safety 3) (debug 3)

Raymond Toy — 2008-10-09T15:11:27

Thanks for the report. This bug exists in current CVS too, unfortunately. I believe there are quite a few issues with various combinations of optimize qualities, especially with high safety and or debug. Ray

Re: Octoberfest snapshots

Raymond Toy — 2008-10-08T00:44:50

Ok. The Linux issue has been fixed and the snapshot has been tagged. Binaries coming soon. Ray

Bug in 19d when declaiming (safety 3) (debug 3)

Utz-Uwe Haus — 2008-10-07T16:13:26

Hi, the following code results in a compile-time failure on CMUCL 19d (debian etch build): --- xx.lisp --- (declaim (optimize (safety 3) (debug 3))) (defun foo () (make-string 0)) --------------- When doing * (handler-case (compile-file "xx.lisp") (error (e) (format nil "~A" e))) ; Python version 1.1, VM version Intel x86 on 07 OCT 08 06:11:40 pm. ; Compiling: /home/haus/work/cl-opossum/xx.lisp 07 OCT 08 06:11:03 pm ; Converted FOO. ; Compiling DEFUN FOO: ; Compilation unit aborted. ; Compilation aborted after 0:00:01. "Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER: NIL is not of type C::CONTINUATION" I did not have time to check other versions (19d is old, admittedly). Reducing to (safety 2) fixes the problem; (declare ...) inside the definition of FOO does not have the problem that the (declaim ...) has. Yours, Utz

Octoberfest snapshots

Raymond Toy — 2008-10-01T16:29:37

The snapshots for October have been tagged. Binaries will be available soon. Ray

Re: Octoberfest snapshots

Raymond Toy — 2008-10-01T16:50:59

Ray> The snapshots for October have been tagged. Binaries will be Ray> available soon. No they won't. I am unable to build on Linux right now, so I need to investigate why. For some reason it's linking with undefineds.c but I don't think it used to do that. So the Octoberfest snapshots will be delayed. I'm deleting the current tag, and will retag at at later time. I wish I could say it was because I had too much beer, but I didn't. Ray

[CfPart] Lisp50< at >OOPSLA

Pascal Costanza — 2008-09-18T18:53:40

Lisp50< at >OOPSLA ...celebrating the 50th birthday of Lisp at OOPSLA 2008 Monday, October 20, 2008 Nashville, Tennessee, USA co-located with OOPSLA 2008 participation is free for all OOPSLA participants registration for at least one conference day at OOPSLA is required URL: http:www.lisp50.org Feed: http://lisp50.blogspot.com Invited Speakers + William Clinger, Northeastern University, USA + Pascal Costanza, Vrije Universiteit Brussel, Belgium + Richard Gabriel, IBM Research, USA + Rich Hickey, Independent Consultant, USA + Alan Kay, Viewpoints Research Institute, USA + Fritz Kunze, USA + Ora Lassila, Nokia Research Center, USA + John McCarthy, USA + Kent Pitman, PTC, USA + Guy Steele, Sun Microsystems Laboratories, USA + Herbert Stoyan, University of Erlangen, Germany + Warren Teitelman, Google Inc., USA + JonL White, USA Titles, abstracts, biographies and schedule will be announced at the Lisp50 webpage and blog in the coming days and weeks. Abstract In October 1958, John McCarthy published one in a s

Re: wait-until-fd-usable

Raymond Toy — 2008-09-16T13:06:37

I had a pretty repeatable test case before, but now that I took out the wait-until-fd-usable change, I can't seem to cause the issue again. I occasionally type stuff into *inferior-lisp*, but haven't ever seen this issue. I guess I didn't have the slime debugger open. Your test case shows pretty clearly something bad happens with the current scheme. 100% CPU without your change, and essentially 0% CPU with it. Ray

Re: wait-until-fd-usable

Madhu — 2008-09-16T11:21:17

|From: Helmut Eller common-lisp.net> |Date: Tue, 16 Sep 2008 08:45:21 +0200 | |* Madhu [2008-09-16 02:09+0200] writes: | |> I'm not saying Helmut is wrong, but there have been |> misunderstandings in the past like Luke Gorries' article on |> serve-event. Concurrency is tricky; I'd exercise caution when |> using use expertise/skill in other areas as clues to judge |> soundness/skill on other tricky areas. :) | |Which misunderstandings? [Please forgive me for being too general and using too many scare quotes: that assumptions, experience, or "expectations" from "pthreads" or "java thread" style programming carry over when youre doing Asynchronous Programming.] |A problem is that there are no guidlelines how serve-event should |or can be used or what can and can't done in fd-handlers. E.g. is |it allowed to call read-char or any other operation on a fd-stream |in a fd-handler? The only experience I have is with some cooperative multitasking programs in the past

Re: wait-until-fd-usable

Helmut Eller — 2008-09-16T06:50:22

I'm not sure that the output issue in recent SLIME is related to the wait-until-fd-usable problem. Unfortunately, I can't reproduce your problem just by printing something. However, also in older versions of SLIME it was possible to consume 100% cpu, by typing something to the terminal stream (in the *inferior-lisp* buffer) while the SLIME debugger is open. This _is_ the same issue as in the example with the pipes, just replace pipe A with the terminal input stream and pipe B with SLIME's socket. Helmut.

Re: wait-until-fd-usable

Helmut Eller — 2008-09-16T06:45:21

Which misunderstandings? A problem is that there are no guidlelines how serve-event should or can be used or what can and can't done in fd-handlers. E.g. is it allowed to call read-char or any other operation on a fd-stream in a fd-handler? The situation with interrupts is similar. Is it safe to call read-char in a interrupt handler? (that would mean that the I/O subsystem is interrupt safe/reentrant, which is rather unlikely.) I think that those recursive calls are problematic. But it's almost impossible to write a debugger without them. Sure. But you can just paste the pipe example to your CMUCL to see the problem. Helmut.

Re: wait-until-fd-usable

Lynn Quam — 2008-09-16T01:40:39

What I have been seeing with the use of multiple-processes in SLIME causes concern. Based on earlier experiences trying to use asynchronously scheduled processes with a Lisp, I now avoid it like the plague. My first experience was with the mouse-process in Symbolics Zeta-Lisp and Genera. Any accesses to global data from the mouse-process had be performed using the appropriate locking machinery not only by the mouse process, but also by all other processes. This creates a minefield of bugs for code that was developed with the assumption of a single process accessing the global data. Madhu wrote:

Re: wait-until-fd-usable

Madhu — 2008-09-16T01:02:50

* Raymond Toy <48CF008D.7070105< at >gmail.com> : Wrote on Mon, 15 Sep 2008 20:40:45 -0400: | I'm hoping someone with more experience/knowledge in this area will look | at it. I, however, am happy to see it fix the problem I was having with | slime. I've not looked at it but My experience has been that slime itself is a moving target. Stuff works, gets fixed, sometimes gets broken on purpose so a whole portion can be replaced, etc... The impact to be considered should be the other s/w that is affected, not the s/w that is motivating the change in the first place. That is bound to work, by definition. There were earlier MP patches that I tested but found caused serious problems in other modes of operation which CMUCL supported. -- Madhu

Re: wait-until-fd-usable

Raymond Toy — 2008-09-16T00:40:45

Yes, the issue showed up somewhere around 2008-09-11 or so. A few days earlier was working, but the output was getting completely flusdhed. Oh, there was no actual patch. There was Helmut's new with-one-shot-fd-handler, and a comment on replacing with-fd-handler in wait-until-fd-usable with with-one-shot-fd-handler. I'm hoping someone with more experience/knowledge in this area will look at it. I, however, am happy to see it fix the problem I was having with slime. Ray

Re: wait-until-fd-usable

Madhu — 2008-09-16T00:09:54

|From: Raymond Toy ericsson.com> |Date: Mon, 15 Sep 2008 10:50:03 -0400 | |I'm not all familiar with serve-event, but I've patched my running |lisp with this and the problems I had with recent slime CVS and |hanging cmucl are now apparently gone. Without this I could pretty |easily get cmucl to hang by doing lots of output like compiling. |This |doesn't happen anymore. I am still using earlier version of slime, presumably one in which helmut' has not added the serve-event code which causes the above problem. This version works fine without requiring any change to the fd handler code, so I have not investigated the issue I did not see a patch posted. Was it sent to you privately? |Based on just this one test and Helmut's previous contributions to |cmucl, I would like to include this change. I'm not saying Helmut is wrong, but there have been misunderstandings in the past like Luke Gorries' article on serve-event. Concurrency is tricky; I'd exercise caution when usi

Re: wait-until-fd-usable

Raymond Toy — 2008-09-15T14:50:03

Helmut> Blocking reads in fd-handlers can cause repeated calls to Helmut> to serve-event without making progress. [snip test code and with-one-shot-fd-handler] Helmut> The idea behind with-one-shot-fd-handler is that the handler is called Helmut> at most once. We could use it instead of the ordinary with-fd-handler Helmut> in wait-until-fd-usable. I'm not all familiar with serve-event, but I've patched my running lisp with this and the problems I had with recent slime CVS and hanging cmucl are now apparently gone. Without this I could pretty easily get cmucl to hang by doing lots of output like compiling. This doesn't happen anymore. Based on just this one test and Helmut's previous contributions to cmucl, I would like to include this change. Ray

wait-until-fd-usable

Helmut Eller — 2008-09-14T05:48:31

Blocking reads in fd-handlers can cause repeated calls to to serve-event without making progress. To illustrate the problem, consider the following example: (defun test-wait-until-readable () (flet ((pipe () (multiple-value-bind (in out) (unix:unix-pipe) (values (sys:make-fd-stream in :input t) (sys:make-fd-stream out :output t :buffering :none))))) (multiple-value-bind (a-in a-out) (pipe) (multiple-value-bind (b-in b-out) (pipe) (sys:add-fd-handler (sys:fd-stream-fd b-in) :input (lambda (fd) (declare (ignore fd)) (format t "b readable~%") (finish-output) (read-char b-in) (format t "b read 1~%") (finish-output) (write-char #\x a-out) (read-char b-in) (format t "b read 2~%") (finish-output))) (write-

Re: CMUCL Timers

Raymond Toy — 2008-09-13T17:44:55

What to you mean supported? It seems to be supported. Do you have any quick examples of using serve-timer? Yes, it's unfortunate the author is unreachable. I would think he wouldn't mind having it included, since he posted the code. But the only way to know is to ask him. Ray

Snapshot tagged

Raymond Toy — 2008-09-02T17:09:56

The Labor Day snapshot (2008-09) has been tagged. Binaries will be uploaded soon. Ray

Re: run-program: find-a-pty: Newer systems do not support /dev/ttyXX PTYs

Carl Shapiro — 2008-08-18T06:48:55

Is there any reason not to use this method exclusively on Linux? According to the manual pages this functionality has been available for a while on Linux as well as all of the other operating systems CMUCL supports. Having a single code path through find-a-pty shared by all systems would be preferable.

run-program: find-a-pty: Newer systems do not support /dev/ttyXX PTYs

Madhu — 2008-08-17T14:31:16

Recent linux distributions (like os_11.0) which mount devpts on /dev/pts do not seem to support /dev/ttyp0 style ptys. This cause EXT:RUN-PROGRAM :PTY T to barf in FIND-A-PTY. The attached patch which supports opening a POSIX pty is ported over from SBCL. (In SBCL the new api is tried first) --Madhu diff --git a/code/run-program.lisp b/code/run-program.lisp index f465a74..bfdac84 100644 --- a/code/run-program.lisp +++ b/code/run-program.lisp < at >< at > -258,7 +258,6 < at >< at > (defvar *handlers-installed* nil "List of handlers installed by RUN-PROGRAM.") - ;;; FIND-A-PTY -- internal ;;; ;;; Finds a pty that is not in use. Returns three values: the file descriptor < at >< at > -297,7 +296,30 < at >< at > slave-fd slave-name))) (unix:unix-close master-fd)))))) - (error "Could not find a pty.")) + ;; could not find a PTY.. Try the unix98 api + (find-a-unix98-pty)) + +#-irix +(defun find-a-unix98-pty () + "Returns the master fd, the slave fd, and the name of the tty" + (let* ((master-name (coerce (format nil

Re: Solaris users?

Carl Shapiro — 2008-08-09T22:16:42

On Sat, Aug 9, 2008 at 10:38 AM, Chun Tian (binghe) gmail.com>wrote: Whatever you want, as long as it's available, is okay. I forgot to mention that you will need to update the x86-validate.h file with the parameters you specified in parms.lisp. However, I think you discovered this on your own. If you don't know what values to specify in those files (they should be the same) the best way to start is to look at the address space of a running program. I think you can retrieve this information with a call to "pmap -s " on Solaris systems. Look for the free regions of memory find unused space that can be reserved by CMUCL for its core file segments. After you have identified some candidate regions of memory you may want to write a small program that includes your x86-validate.h and tries to map all of those regions. Anyway, once you have confirmed those values are good you are ready to update parms.lisp and x86-validate.h and continue with the rest of your port. As part of the boot