From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nala Ginrut Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH] read-response-body should return received data when any break happens Date: Fri, 16 Mar 2012 10:23:53 +0800 Message-ID: References: <877gylu2wf.fsf@Kagami.home> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=20cf307abf5d59214d04bb52e606 X-Trace: dough.gmane.org 1331864663 2271 80.91.229.3 (16 Mar 2012 02:24:23 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 16 Mar 2012 02:24:23 +0000 (UTC) Cc: Ian Price , guile-devel To: Daniel Hartwig Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Mar 16 03:24:22 2012 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 1S8Mq5-0007au-Ls for guile-devel@m.gmane.org; Fri, 16 Mar 2012 03:24:21 +0100 Original-Received: from localhost ([::1]:58340 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S8Mq4-0004HW-Pr for guile-devel@m.gmane.org; Thu, 15 Mar 2012 22:24:20 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:54349) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S8Mq1-0004GS-1L for guile-devel@gnu.org; Thu, 15 Mar 2012 22:24:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S8Mpg-0001ES-72 for guile-devel@gnu.org; Thu, 15 Mar 2012 22:24:16 -0400 Original-Received: from mail-vx0-f169.google.com ([209.85.220.169]:57508) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S8Mpf-0001Di-Sb for guile-devel@gnu.org; Thu, 15 Mar 2012 22:23:56 -0400 Original-Received: by vcbfk14 with SMTP id fk14so4865795vcb.0 for ; Thu, 15 Mar 2012 19:23:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oKaFCmyjH/sUoHP0SwOBqGn8o1VSu5w3Cm2N7jLLh14=; b=k0CGPPrTJK5vFto1zZ0oqtlAZaqZLtyER92ny4KS1JFtz9qT+X0zvCMFVjsc4RfQ5G BwJ8alC3UGj9zXgTIbrdoDdIoEI1m2qSl/2nDVkdFqozk4oRHL95vLgIwWzLBuA7MyPy UREYIzUJm6CEYfUc7OPGA38Ezy7NuGca9gD8ABSQouVzqhDJe4+mFDAfEoXMWTYSe8DR ZMR4I8P27Pe/Nnr/cEpp+s6eNFxqiB6nTMZM036xsVe79nvCVo+O4s0fI7+nrax52ZgI +N/vxIR8y5Myeqezr3Bn/ypkHpPxM7B3c0ZIthKOpeYTMD+0PraKZOsptO2MwKjD5yzu X3HA== Original-Received: by 10.52.98.200 with SMTP id ek8mr644894vdb.36.1331864633155; Thu, 15 Mar 2012 19:23:53 -0700 (PDT) Original-Received: by 10.52.88.231 with HTTP; Thu, 15 Mar 2012 19:23:53 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.220.169 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:14112 Archived-At: --20cf307abf5d59214d04bb52e606 Content-Type: text/plain; charset=UTF-8 Thanks for reply! @ijp: Yes, I think return received data within exception is ugly. But I have to do it because my consideration is to return received data when *any* exception happens. So if it's not a common connection error, I have to catch it to return the received data, then re-throw the same exception(and cut the received data). Because other program may expect this exception. But I don't claim that this is the best design. Anyway, just a proposal. @Daniel: I realized that seems make "get-bytevector-n" return the received data rather than read-response-body is better. But I'm afraid that it'll conflict with the definition "get-bytevector-n". Say, we ask for n bytes, but it returned m bytes less than n. So the user maybe get confused with the name "get-bytevector-n". On Fri, Mar 16, 2012 at 2:48 AM, Daniel Hartwig wrote: > On 16 March 2012 02:37, Ian Price wrote: > > Daniel Hartwig writes: > >> For example, reusing the same bytevector and looping over > >> read-response-body! saving the results to disk each time. This limits > >> the memory use to the size of the bytevector *and* removes the copy > >> operation from your implementation (bonus!). > > If you wanted to do it that way, it'd be better to pass in the port > > directly and cut out the middle man. > > > > Indeed. The procedure shown is similar to one from one of my own > projects which features the write-to-disk internally. > > I guess it pays to keep in mind that it is trivial to rearrange > procedures such as this to suit any particular situation. The OP > appeared--to me--to be very over worked for the task. > > Perhaps such error-tolerance/streaming capabilities can be tied in at > a level closer to get-bytevector-n... > > > Regards > --20cf307abf5d59214d04bb52e606 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for reply!
@ijp: Yes, I think return received data within excepti= on is ugly. But I have to do it because my consideration is to return recei= ved data when *any* exception happens. So if it's not a common connecti= on error, I have to catch it to return the received data, then re-throw the= same exception(and cut the received data). Because other program may expec= t this exception. But I don't claim that this is the best design. Anywa= y, just a proposal.
@Daniel: I realized that seems make "get-bytevector-n" return the= received data rather than read-response-body is better. But I'm afraid= that it'll conflict with the definition "get-bytevector-n". = Say, we ask for n bytes, but it returned m bytes less than n. So the user m= aybe get confused with the name "get-bytevector-n".

On Fri, Mar 16, 2012 at 2:48 AM, Daniel Hart= wig <mandyke@gmai= l.com> wrote:
On 16 March 2012 02:37, Ian Price <ianprice90@googlemail.com> wrote:
> Daniel Hartwig <mandyke@gmail.com> writes:
>> For example, reusing the same bytevector and looping over
>> read-response-body! saving the results to disk each time. =C2=A0Th= is limits
>> the memory use to the size of the bytevector *and* removes the cop= y
>> operation from your implementation (bonus!).
> If you wanted to do it that way, it'd be better to pass in the por= t
> directly and cut out the middle man.
>

Indeed. =C2=A0The procedure shown is similar to one from one of my ow= n
projects which features the write-to-disk internally.

I guess it pays to keep in mind that it is trivial to rearrange
procedures such as this to suit any particular situation. =C2=A0The OP
appeared--to me--to be very over worked for the task.

Perhaps such error-tolerance/streaming capabilities can be tied in at
a level closer to get-bytevector-n...


Regards

--20cf307abf5d59214d04bb52e606--