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 <tcolg...@gmail.com>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 <nalagin...@gmail.com> 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 <mand...@gmail.com> > wrote: > >> > >> On 16 March 2012 13:54, Nala Ginrut <nalagin...@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 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" > >
