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: Tue, 17 Nov 2015 14:33:11 +0100 Message-ID: <20151117133311.GC14674@tuxteam.de> References: <874mgxx1y3.fsf@elephant.savannah> <87fv0h1ic2.fsf@delenn.home.rotty.xx.vu> <87h9kpvqw1.fsf@netris.org> <09b3d3156d439ce3dd7bedc48d84fd5b@hypermove.net> <20151117095319.GA7958@tuxteam.de> <20151117125956.4b2fc363@bother.homenet> <20151117125221.GB13216@tuxteam.de> <20151117135517.42458d6a@bother.homenet> 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 1447769309 28430 80.91.229.3 (17 Nov 2015 14:08:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 Nov 2015 14:08:29 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Nov 17 15:08:19 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 1Zygvi-0002tc-6X for guile-devel@m.gmane.org; Tue, 17 Nov 2015 15:08:18 +0100 Original-Received: from localhost ([::1]:58687 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zygvh-0003Dz-Mu for guile-devel@m.gmane.org; Tue, 17 Nov 2015 09:08:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41888) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zygva-0003D6-4g for guile-devel@gnu.org; Tue, 17 Nov 2015 09:08:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZygvW-0004eC-1U for guile-devel@gnu.org; Tue, 17 Nov 2015 09:08:10 -0500 Original-Received: from mail.tuxteam.de ([5.199.139.25]:45415 helo=tomasium.tuxteam.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZygvV-0004dB-Rx for guile-devel@gnu.org; Tue, 17 Nov 2015 09:08:05 -0500 Original-Received: from tomas by tomasium.tuxteam.de with local (Exim 4.80) (envelope-from ) id 1ZygNj-0003sd-Mb for guile-devel@gnu.org; Tue, 17 Nov 2015 14:33:11 +0100 In-Reply-To: <20151117135517.42458d6a@bother.homenet> 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:18032 Archived-At: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Nov 17, 2015 at 01:55:17PM +0000, Chris Vine wrote: > On Tue, 17 Nov 2015 13:52:21 +0100 > wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On Tue, Nov 17, 2015 at 12:59:56PM +0000, Chris Vine wrote: > > > On Tue, 17 Nov 2015 10:53:19 +0100 > > > > [...] > > > > > guile's R6RS implementation has get-bytevector-some, which will do > > > that for you, with unix-read-like behaviour. > > > > Thank you a thousand. You made me happy :-) > > I suppose it is worth adding that it might not be optimally efficient > for all uses, as there is no get-bytevector-some! procedure which > modifies an existing bytevector and takes a maximum length value. I > guess it is a matter of 'suck it and see', efficiency-wise. > > If you are sending/receiving binary packets, it might be better to make > them of fixed size and use get-bytevector-n!. (Unfortunately, > get-bytevector-n! does block until n is fulfilled according to R6RS: > "The get-bytevector-n! procedure reads from binary-input-port, blocking > as necessary, until count bytes are available from binary-input-port or > until an end of file is reached".) :-( As I noted before, it's a while since I attempted that. I was looking for an equivalent of read(2) and write(2): simple, efficient, easy to understand semantics (if you discount the EOF problem for now). Perhaps the limitations you mention above steered me towards read-string!/partial and friends, then. Thanks & regards - -- tomás -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlZLLJcACgkQBcgs9XrR2kbS9gCeNM696u8KT9Fzq0fSifH8YKa3 VjEAn0KKx5Im4UNxUumiy0RroiKT3iDU =nAXY -----END PGP SIGNATURE-----