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 error occcurs (V2) Date: Sat, 17 Mar 2012 10:26:40 +0800 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=14dae9cdbf6f3221bb04bb670e87 X-Trace: dough.gmane.org 1331951215 4259 80.91.229.3 (17 Mar 2012 02:26:55 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 17 Mar 2012 02:26:55 +0000 (UTC) Cc: guile-devel To: Tristan Colgate Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Mar 17 03:26:51 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 1S8jM1-0002HA-S9 for guile-devel@m.gmane.org; Sat, 17 Mar 2012 03:26:50 +0100 Original-Received: from localhost ([::1]:50531 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S8jM1-0002Id-78 for guile-devel@m.gmane.org; Fri, 16 Mar 2012 22:26:49 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:33861) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S8jLy-0002Hi-Ak for guile-devel@gnu.org; Fri, 16 Mar 2012 22:26:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S8jLv-0002x8-Or for guile-devel@gnu.org; Fri, 16 Mar 2012 22:26:45 -0400 Original-Received: from mail-vx0-f169.google.com ([209.85.220.169]:41156) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S8jLv-0002x3-HC for guile-devel@gnu.org; Fri, 16 Mar 2012 22:26:43 -0400 Original-Received: by vcbfk14 with SMTP id fk14so6211940vcb.0 for ; Fri, 16 Mar 2012 19:26:41 -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=FDsWILvB8QO4cjmKiiclVKing/7v3cXTZg4lBHFvPf8=; b=yXZJTGCPLxZ9EvFbXZLZL9Ab6U6puPEp8Q22xUSVk1/RI46YK/KbvZL5He5+srRfcc s/VkbubgPQ11/JbFTpwknoDJiDNZUQhayCvpNdE2JR9ukKaWXwXCOGq72AgMbVrSuwND UJb/Yhs20uYepxphFMSyslXCN2KObgXVVdZnTFyJNnfmO3xNgPddPM9lJ3Pn2HRVkCWN QZ2Tj2KHuHs9WoS7Slltc6kQ/GTbi4WxbCtG87ENh2mcc3YGmDLs4d9GmHiidKzlfFhE oNyPMIzWdy9yDukDf/4M1Gk+PL9O7dRd+jh8SMPYBrjvAkuJmnxALUhm7mXnAE8Z4G63 MebQ== Original-Received: by 10.220.231.136 with SMTP id jq8mr1384684vcb.74.1331951201034; Fri, 16 Mar 2012 19:26:41 -0700 (PDT) Original-Received: by 10.52.88.231 with HTTP; Fri, 16 Mar 2012 19:26:40 -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:14134 Archived-At: --14dae9cdbf6f3221bb04bb670e87 Content-Type: text/plain; charset=UTF-8 Wrong thread but interesting ;-) Could you resend it to the correct thread? Maybe helpful to people there. Regards. On Sat, Mar 17, 2012 at 12:27 AM, Tristan Colgate wrote: > I got this the other day with lalr.scm. My build got stuck (100% CPU > for quite a while). I ended up clearing out all old .go files and > trying again and it got past it (didn't even take that long, a few > seconds compared to a 15 minute wait). > > On 16 March 2012 08:47, Nala Ginrut wrote: > > Well, I saw your point. So read-response-body is defined to read the > whole > > body, and shouldn't return anything when it didn't get all the data. > > For this reason, one should use bytevector handler to get the data on > one's > > own rather than read-response-body. > > Well, I just thought read-response-body is the only API to get body, at > > least from the manual, I can only get this conclusion. But in fact, the > > worth of read-response-body is very limited. It just a simple procedure > to > > get a simple page or few data. > > If possible, I wish the manual can add few words to notice this. > > > > > > On Fri, Mar 16, 2012 at 3:32 PM, Daniel Hartwig > wrote: > >> > >> On 16 March 2012 13:54, Nala Ginrut wrote: > >> > This patch will return any data get-bytevector-n received and throw > >> > error > >> > when get . > >> > Actually, it's not the same feature in the old version thread > >> > http://lists.gnu.org/archive/html/guile-devel/2012-03/msg00116.html > >> > The old version is complicated because it catches *any* exception and > >> > return > >> > the received data within exception. > >> > But this new version is an easy one. > >> > >> Yes, it looks much nicer :-) > >> > >> > My point is, read-response-body is a low level procedure, so we > >> > shouldn't > >> > make it complex. But our current doesn't return received data when > >> > the received data is less than the content-length. I think it should > >> > return > >> > it, and let the user determine whether it's an error or continue > >> > reading. > >> > >> So r-r-b is a really a two-liner: > >> > >> - read response body from port; > >> - make sure the complete response has been read. > >> > >> This combination is the utility of the procedure: it guarentees that > >> the data it returns comprises the complete response body. > >> > >> With your proposed change, that guarentee no longer holds. The caller > >> now must perform their own checks on the response data size, making > >> your function effectively this: > >> > >> - read response body data from port. > >> > >> So what is the utility of calling a procedure to do that over, say, > >> reading from the port directly? [pointed out earlier in this thread] > > > > > > > > -- > Tristan Colgate-McFarlane > ---- > "You can get all your daily vitamins from 52 pints of guiness, and a > glass of milk" > > --14dae9cdbf6f3221bb04bb670e87 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Wrong thread but interesting ;-)
Could you resend it to the correct thre= ad? Maybe helpful to people there.

Regards.

On Sat, Mar 17, 2012 at 12:27 AM, Tristan Colgate <tcolgate@gmail.com> wrote:
I got this the other day with lalr.scm. My b= uild got stuck (100% CPU
for quite a while). I ended up clearing out all old .go files and
trying again and it got past it (didn't even take that long, a few
seconds compared to a 15 minute wait).

On 16 March 2012 08:47, Nala Ginrut <nalaginrut@gmail.com> wrote:
> Well, I saw your point. So read-response-body is defined to read the w= hole
> body, and shouldn't return anything when it didn't get all the= data.
> For this reason, one should use bytevector handler to get the data on = one's
> own rather than read-response-body.
> Well, I just thought read-response-body is the only API to get body, a= t
> least from the manual, I can only get this conclusion. But in fact, th= e
> worth of read-response-body is very limited. It just a simple procedur= e to
> get a simple page or few data.
> If possible, I wish the manual can add few words to notice this.
>
>
> On Fri, Mar 16, 2012 at 3:32 PM, Daniel Hartwig <mandyke@gmail.com> wrote:
>>
>> On 16 March 2012 13:54, Nala Ginrut <nalaginrut@gmail.com> wrote:
>> > This patch will return any data get-bytevector-n received and= throw
>> > error
>> > when get <eof>.
>> > Actually, it's not the same feature in the old version th= read
>> > http://lists.gnu.org/archive/html/guil= e-devel/2012-03/msg00116.html
>> > The old version is complicated because it catches *any* excep= tion and
>> > return
>> > the received data within exception.
>> > But this new version is an easy one.
>>
>> Yes, it looks much nicer :-)
>>
>> > My point is, read-response-body is a low level procedure, so = we
>> > shouldn't
>> > make it complex. But our current doesn't return received = data when
>> > the received data is less than the content-length. I think it= should
>> > return
>> > it, and let the user =C2=A0determine whether it's an erro= r or continue
>> > reading.
>>
>> So r-r-b is a really a two-liner:
>>
>> - read response body from port;
>> - make sure the complete response has been read.
>>
>> This combination is the utility of the procedure: it guarentees th= at
>> the data it returns comprises the complete response body.
>>
>> With your proposed change, that guarentee no longer holds. =C2=A0T= he caller
>> now must perform their own checks on the response data size, makin= g
>> your function effectively this:
>>
>> - read response body data from port.
>>
>> So what is the utility of calling a procedure to do that over, say= ,
>> reading from the port directly? [pointed out earlier in this threa= d]
>
>



--
Tristan Colgate-McFarlane
----
=C2=A0 "You can get all your daily vitamins from 52 pints of guiness, = and a
glass of milk"


--14dae9cdbf6f3221bb04bb670e87--