From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Newsgroups: gmane.lisp.guile.devel Subject: Re: Reading data from a file descriptor Date: Mon, 16 Nov 2015 14:02:49 +0100 Message-ID: <20151116130249.GA4154@tuxteam.de> References: <87a8qpx2kg.fsf@elephant.savannah> <874mgxx1y3.fsf@elephant.savannah> <87fv0h1ic2.fsf@delenn.home.rotty.xx.vu> <87h9kpvqw1.fsf@netris.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; x-action=pgp-signed Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1447707133 26153 80.91.229.3 (16 Nov 2015 20:52:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 16 Nov 2015 20:52:13 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Nov 16 21:52:08 2015 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZyQkx-0004G2-J9 for guile-devel@m.gmane.org; Mon, 16 Nov 2015 21:52:07 +0100 Original-Received: from localhost ([::1]:49261 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZyQkx-0007Na-3Z for guile-devel@m.gmane.org; Mon, 16 Nov 2015 15:52:07 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52093) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZyJzf-00010F-Jh for guile-devel@gnu.org; Mon, 16 Nov 2015 08:38:52 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZyJza-0003LS-QW for guile-devel@gnu.org; Mon, 16 Nov 2015 08:38:51 -0500 Original-Received: from mail.tuxteam.de ([5.199.139.25]:42442 helo=tomasium.tuxteam.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZyJza-0003Ab-Jg for guile-devel@gnu.org; Mon, 16 Nov 2015 08:38:46 -0500 Original-Received: from tomas by tomasium.tuxteam.de with local (Exim 4.80) (envelope-from ) id 1ZyJQn-00019S-9m for guile-devel@gnu.org; Mon, 16 Nov 2015 14:02:49 +0100 In-Reply-To: <87h9kpvqw1.fsf@netris.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 5.199.139.25 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:18024 Archived-At: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, Nov 13, 2015 at 10:51:58AM -0500, Mark H Weaver wrote: > Jan Synáček writes: > > > On Sun, Nov 8, 2015 at 12:49 AM, Andreas Rottmann > > 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. I'll go have a look later to see whether my recollection is accurate. Regards - -- tomás -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlZJ0/kACgkQBcgs9XrR2kb93QCdF1K/IT/Ma+CkOFAqQgul9px/ tDMAnRoki8ODfD3tqwZSyL1GArAfDnpn =AuBJ -----END PGP SIGNATURE-----