<to...@tuxteam.de> writes: > On Fri, Nov 13, 2015 at 10:51:58AM -0500, Mark H Weaver wrote: >> Jan Synáček <jan.syna...@gmail.com> writes: >> >> > On Sun, Nov 8, 2015 at 12:49 AM, Andreas Rottmann <a.rottm...@gmx.at> >> > wrote: >> > >> > Also note that if there's no requirement to actually implement >> > this in >> > C, there's `fdes->inport' and `fdes->outport' on the Scheme level, >> > so >> > something like the following would be analogous to the C example >> > code >> > posted: >> > >> > (import (ice-9 binary-ports)) >> > >> > (define (process-fd fd) >> > (let ((port (fdes->inport fd))) >> > (display "read: ") >> > (display (get-bytevector-n port 100)) >> > (display "\n"))) >> > >> > (process-fd (acquire-valid-fd)) >> > >> > >> > This is something very similar that I ended up with. Just instead of >> > get-byte-vector, I used read-string!/partial. >> >> I would advise against using 'read-string!/partial' or any of the >> procedures in (ice-9 rw). This is a vestigial module from Guile 1.8 >> when strings were arrays of bytes, which they no longer are. We should >> probably mark them as deprecated. >> >> For one thing, when we switch to using UTF-8 as the internal string >> encoding, it will not be possible to keep 'read-string!/partial' >> efficient. It will necessarily have to do an encoding conversion. >> >> In Guile 2+, I would advise using byte vectors when working with binary >> data. Portions of these can be converted to strings with a given >> encoding if desired. I might be able to give better advice if I knew >> more about what you are doing here. > > Mark, > > what Jan is after (and what I'd like to have too) is something > akin to Unix read(2) with O_NONBLOCK: provide a buffer, request > (up to) N bytes from the file (descriptor) and get an answer > (with possibly less bytes). > > I tried that a while ago and was surprised that I had to resort > to (character) strings, with all the downsides you mention. Something > like that for byte vectors would be awesome. Either it exists (and > neither Jan nor me have succeeded in finding it) or it doesn't. > The procedure with the closest semantics is R6RS `get-bytevector-some`. While the R6RS says it will block if no data is available, a quick look at Guile source code seems to indicate that it probably works with non-blocking I/O -- I'd say it should return EOF if called on a non-readable, non-blocking port, and otherwise not block, and return the data available. This is all just from a quick inspection, without running any actual code.
Regards, Rotty -- Andreas Rottmann -- <http://rotty.xx.vu/>
