Hello, I need to access the output file descriptor of a stream (so that I can pass it to a CFFI foreign function. Allegro has excl::stream-output-handle and CLISP has ext:stream-handles for instance. What is the equivalent in Lispworks? thank you! -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com
Unable to parse email body. Email id is 11571
Nick Levine wrote: > CL-USER 41 > setf x (open "~/foo") > #<STREAM::LATIN-1-FILE-STREAM C:\users\nick\foo> > > CL-USER 42 > STREAM::OS-FILE-HANDLE-STREAM-FILE-HANDLE x > 1376 > > CL-USER 43 > STREAM::%L1FILE-STREAM-FILE-HANDLE x > 1376 > > CL-USER 44 > > > Is that what you were after? Thanks Nick (for the two colons ;-). But that does not always work. In particular, this function won't accept a SYSTEM::TERMINAL-STREAM which is what I get when using *STANDARD-OUTPUT* (with some bits of canonicalization). -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com
Unable to parse email body. Email id is 11576
Tim Bradshaw <tfb@cley.com> wrote: > I don't think all streams even have file descriptors. Yeah, that's true. It seems to me that TERMINAL-STREAMs should, though. As per Paul's suggestion, I introspected a bit and the only thing I could see so far is a slot named OUTPUT-HANDLE which sounds kinda nice, but its value for *terminal-io* is T, not an fd... :-/ > On the mac implementation there's a class > stream::os-file-handle-stream, and I guess those are the ones that > correspond to filehandles in the underlying system. Probably (hence Nick's suggestion). However, even in a standalone console application (delivered from Lispworks), a TERMINAL-STREAM such as *terminal-io* has no relation with an OS stream, and that currently escapes me... -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com
Unable to parse email body. Email id is 11579
Martin Simmons wrote: > TERMINAL-STREAM on Unix-like OSes always uses fd 1 Hmmm, so is this a singleton? > (but note that output to *TERMINAL-IO* will not be written there by > default in a GUI application). Is there a way to know where it will be printed ? > What will be the foreign code do with the fd? Perform an ioctl on it. > Is this code supposed to work on Windows? Err, not sure :-) In fact, I think it should under cygwin, but probably not otherwise. -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com
Unable to parse email body. Email id is 11582
Martin Simmons wrote: >> > What will be the foreign code do with the fd? >> >> Perform an ioctl on it. > > That could be risky on a file descriptor that you don't control (and could be > of an unknown type, e.g. pipe, tty). Which ioctl is it? Possibly LispWorks > should include an API for it? TIOCGWINSZ. It's for Clon. The idea is to figure out whether the stream is connected to a terminal and (when that's the case) get the terminal size at the same time. The most common situation is a standalone application doing 'app --help' or 'app --help > file' on a terminal (which involves *standard-output* in both cases). In case you're interested, I'm attaching the file doing this in the current version of Clon. It supports 7 implementations in various ways (CFFI or some implementation-specific version). The current code would probably break for esoteric streams (checking slime streams is on my TODO List) but it works for the intended usage at least.
I wrote: > In case you're interested, I'm attaching the file doing this in the > current version of Clon. It supports 7 implementations in various ways > (CFFI or some implementation-specific version). The current code would > probably break for esoteric streams (checking slime streams is on my > TODO List) but it works for the intended usage at least. FWIW, here's a new version with more robust support for non FILE-STREAMs and with support for Lispworks SYSTEM::TERMINAL-STREAMs as well...