From: Didier V. <di...@lr...> - 2012-05-21 09:58:29
|
Hello, The current behavior of EXT:STREAM-HANDLES is to return two file descriptors (input and output) when possible, and error otherwise. The problem I have with this behavior is that (apparently) there's no way to predict whether it is possible to perform this operation or not on a random stream (notably when it's just of class STREAM): IIUC, stream_handles does the validity check based on information which is only available at the C level. I can currently work around this by catching STREAM-SIMPLE-ERROR but this is not satisfactory (too coarse a grain). So my question is: - would it hurt if EXT:STREAM-HANDLES were changed to return nil instead of error'ing? CCL does this with his STREAM-DEVICE function for instance. - otherwise, could we have a predicate such as STREAM-HAS-HANDLES-P please? Or, we could enrich the STREAM class hierarchy with a mixin for streams with handles, or, expose the current implementation details (the strmtype field) to the Lisp level. But maybe we don't want to go that far :-) Thanks! -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com |
From: Pascal J. B. <pj...@in...> - 2012-05-21 10:09:06
|
Didier Verna <di...@lr...> writes: > Hello, > > The current behavior of EXT:STREAM-HANDLES is to return two file > descriptors (input and output) when possible, and error otherwise. > > The problem I have with this behavior is that (apparently) there's no > way to predict whether it is possible to perform this operation or not > on a random stream (notably when it's just of class STREAM): IIUC, > stream_handles does the validity check based on information which is > only available at the C level. > > I can currently work around this by catching STREAM-SIMPLE-ERROR but > this is not satisfactory (too coarse a grain). So my question is: > > - would it hurt if EXT:STREAM-HANDLES were changed to return nil instead > of error'ing? CCL does this with his STREAM-DEVICE function for > instance. (defun stream-device (stream) (handler-case (ext:stream-handle stream) (error () nil))) > - otherwise, could we have a predicate such as STREAM-HAS-HANDLES-P > please? (defun stream-ahs-handle-p (stream) (stream-device stream)) IMO, Lisp is not C. It's not bad to signal an error if a function cannot access the wanted attribute. -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}. |
From: Didier V. <di...@lr...> - 2012-05-21 11:05:38
|
"Pascal J. Bourguignon" <pj...@in...> wrote: > (defun stream-device (stream) > (handler-case (ext:stream-handle stream) (error () nil))) Could you please read the mails you're replying to ? ;-) I said: >> I can currently work around this by catching STREAM-SIMPLE-ERROR but >> this is not satisfactory (too coarse a grain). Catching just ERROR is even coarser and unsatisfactory for the same reason. You catch more than you actually want, and this is dangerous in principle. -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com |
From: Pascal J. B. <pj...@in...> - 2012-05-21 13:10:10
|
Didier Verna <di...@lr...> writes: > "Pascal J. Bourguignon" <pj...@in...> wrote: > >> (defun stream-device (stream) >> (handler-case (ext:stream-handle stream) (error () nil))) > > Could you please read the mails you're replying to ? ;-) Sorry. > I said: > >>> I can currently work around this by catching STREAM-SIMPLE-ERROR but >>> this is not satisfactory (too coarse a grain). > > Catching just ERROR is even coarser and unsatisfactory for the same > reason. You catch more than you actually want, and this is dangerous in > principle. Right, but this is another topic. Indeed, it would be nice if all the CL operators, and all the libraries defined always specific conditions, so we could write: (defun stream-device (stream) (handler-case (ext:stream-handle stream) (ext:stream-has-no-handle-error () nil))) But often it's not expected to have any other errors either, so just error is acceptable. The downside, is that the condition ontology is often as complex if not more complex than the main object ontology of a library or program. (But nothing that couldn't be handled with a few nice macros). -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}. |
From: Didier V. <di...@lr...> - 2012-05-21 13:41:51
|
"Pascal J. Bourguignon" <pj...@in...> wrote: > Indeed, it would be nice if all the CL operators, and all the > libraries defined always specific conditions > > The downside, is that the condition ontology is often as complex if > not more complex than the main object ontology of a library or > program. (But nothing that couldn't be handled with a few nice > macros). Yup. Now, let's work a couple of years on a CDR which describes all the precise errors we need in the standard :-) -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com |
From: Sam S. <sd...@gn...> - 2012-05-21 14:37:10
|
Hi, > * Didier Verna <qv...@ye...> [2012-05-21 11:58:07 +0200]: > > The current behavior of EXT:STREAM-HANDLES is to return two file > descriptors (input and output) when possible, and error otherwise. > > The problem I have with this behavior is that (apparently) there's no > way to predict whether it is possible to perform this operation or not > on a random stream (notably when it's just of class STREAM): IIUC, > stream_handles does the validity check based on information which is > only available at the C level. > > I can currently work around this by catching STREAM-SIMPLE-ERROR but > this is not satisfactory (too coarse a grain). So my question is: why "too coarse a grain"? could you please be more specific? > - would it hurt if EXT:STREAM-HANDLES were changed to return nil instead > of error'ing? CCL does this with his STREAM-DEVICE function for > instance. > > - otherwise, could we have a predicate such as STREAM-HAS-HANDLES-P > please? 1. STREAM-HANDLES is just a thin interface to stream_handles() which is used in many places (including modules) and which I am very reluctant to change. 2. looking through clisp/src/stream.d it appears that this is the function you want: (defun stream-device (object) (and (or (sys::built-in-stream-p object) (eq 'socket:socket-server (type-of object))) (handler-case (ext:stream-handles object) (stream-error (e) nil)))) the only errors signaled by stream-handles are errors on invalid argument. (stream-device 1) ==> NIL (stream-device *terminal-io*) ==> 0 ; 1 -- Sam Steingold (http://sds.podval.org/) on Ubuntu 12.04 (precise) X 11.0.11103000 http://www.childpsy.net/ http://mideasttruth.com http://thereligionofpeace.com http://iris.org.il Shady characters are often very bright. |
From: Didier V. <di...@lr...> - 2012-05-21 15:27:49
|
Sam Steingold <sd...@gn...> wrote: > why "too coarse a grain"? could you please be more specific? What I mean is that in general (maybe not in this particular case though), I don't like to rely on catching errors for testing whether I have the right to do something or not. The general problem is that many times, a single error is used for different reasons (this is what I call "coarse grain", and the standard doesn't help in this matter) but you are only interested in one of them. When you catch such an error, you're actually catching a whole bunch of situations, including the one you're looking for, but not only, and there's no way to know. The consequence is that in principle, catching too many situations may in fact hide bugs. > 2. looking through clisp/src/stream.d it appears that this is the > function you want: > > (defun stream-device (object) > (and (or (sys::built-in-stream-p object) > (eq 'socket:socket-server (type-of object))) > (handler-case (ext:stream-handles object) > (stream-error (e) nil)))) > > the only errors signaled by stream-handles are errors on invalid > argument. > > (stream-device 1) > ==> NIL > (stream-device *terminal-io*) > ==> 0 ; 1 It looks perfect, thanks! -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com |