From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: mark@markwitmer.com Newsgroups: gmane.lisp.guile.user Subject: Re: asynchronous socket library Date: Wed, 17 Jul 2013 09:49:07 -0700 Message-ID: <87a9ll9loc.fsf@markwitmer.com> References: <8761w9n2i6.fsf@mark-desktop.PK5001Z> <8738rd1wwy.fsf@tines.lan> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1374084315 16010 80.91.229.3 (17 Jul 2013 18:05:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 17 Jul 2013 18:05:15 +0000 (UTC) To: guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Wed Jul 17 20:05:15 2013 Return-path: Envelope-to: guile-user@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 1UzW6D-0002qg-NC for guile-user@m.gmane.org; Wed, 17 Jul 2013 20:05:13 +0200 Original-Received: from localhost ([::1]:37412 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UzW6C-0001ko-Vq for guile-user@m.gmane.org; Wed, 17 Jul 2013 14:05:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53600) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UzVMg-0004qZ-F0 for guile-user@gnu.org; Wed, 17 Jul 2013 13:18:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UzVMe-00087R-Rt for guile-user@gnu.org; Wed, 17 Jul 2013 13:18:10 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:47042) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UzUtx-0006D0-FU for guile-user@gnu.org; Wed, 17 Jul 2013 12:48:29 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1UzUtr-0004nw-A3 for guile-user@gnu.org; Wed, 17 Jul 2013 18:48:23 +0200 Original-Received: from 174-21-131-23.tukw.qwest.net ([174.21.131.23]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 17 Jul 2013 18:48:23 +0200 Original-Received: from mark by 174-21-131-23.tukw.qwest.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 17 Jul 2013 18:48:23 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 41 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 174-21-131-23.tukw.qwest.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:2gGPC2ESDP/q8HMehUGeY5blni4= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:10554 Archived-At: Mark H Weaver writes: > mark@markwitmer.com writes: >> Reading and writing to a socket seems to lend itself well to custom >> binary ports, > > Why do you say that? For most purposes, Guile's native file ports are > superior, and they seem the natural choice for sockets. > I over-generalized. In my application, I'm using the X protocol, which is a binary one. I've been so involved with that I forgot that much of the time you want to read/write character data from a socket. > 'get-bytevector-some' from (rnrs io ports) might do what you need. If > there's at least one byte available it will not block, but in practice > it reads much more than that (for buffered ports). Guile 2.0.9 has a > nice fast implementation. Prior to 2.0.9, it was less so. > > In more detail: as of 2.0.9, 'get-bytevector-some' will simply copy the > input buffer managed by Guile into a bytevector and return it. If > Guile's input buffer is empty, it will try to refill the buffer using > the port type's 'fill_input' method. For file ports this is > fports.c:fport_fill_input, and for custom binary ports it's > r6rs-ports.c:cbip_fill_input. In order to know if the port has at least one byte ready, you need to be able to call 'char-ready?', don't you? And as you mentioned, that doesn't work on custom binary ports. I'm still exploring this part of Guile so I might not have the details right. > > So again I ask, why use custom binary ports for sockets? > Thanks for the detailed explanation; I think I'll move away from them. Were they added just to meet the r6rs spec? Are there any good uses for custom binary ports that you're aware of? -- Mark Witmer