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: [PATCH] read-response-body should return received data when any break happens Date: Sun, 11 Mar 2012 23:35:56 +0800 Message-ID: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=bcaec50166edc391d804baf96152 X-Trace: dough.gmane.org 1331480168 28837 80.91.229.3 (11 Mar 2012 15:36:08 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 11 Mar 2012 15:36:08 +0000 (UTC) To: guile-devel Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Mar 11 16:36:07 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 1S6koZ-0003LH-3J for guile-devel@m.gmane.org; Sun, 11 Mar 2012 16:36:07 +0100 Original-Received: from localhost ([::1]:41357 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S6koY-0006C4-Bi for guile-devel@m.gmane.org; Sun, 11 Mar 2012 11:36:06 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:32807) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S6koU-0006BW-37 for guile-devel@gnu.org; Sun, 11 Mar 2012 11:36:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S6koR-0002SJ-Lv for guile-devel@gnu.org; Sun, 11 Mar 2012 11:36:01 -0400 Original-Received: from mail-vx0-f169.google.com ([209.85.220.169]:44120) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S6koR-0002S9-Di for guile-devel@gnu.org; Sun, 11 Mar 2012 11:35:59 -0400 Original-Received: by vcbfk14 with SMTP id fk14so3823388vcb.0 for ; Sun, 11 Mar 2012 08:35:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=+xesGcMj11o/rqr0eWcIoNFkqF2K+G4ButQYtfUfChg=; b=ZqOTkdtCwk0ihXXig3F8puCyp3GQWSuSN+remWCQVhI64u7ezD9rHzo1xrMMGTkjLZ +FXivTYs8cilqqEldTPPvNdYTYaE6Ga8AKcRvbGlTRNGLZ1sLh3E5mzMJNSAqvlnWoaF jJcnR2//TR6SUspbyiESF4g1VaScR12Rda5uVV9bionXk2b40b3SGGK09ufGYiOjI5jW JFWVbCxhutYVQmf/6ObDsvHPkfm8OBQ/dwhleMaJHNxUehI5ptFfbS59zzK4H1FOV+hs X9B2HFDrBX2X2vB/UXDZ8TVQRlKW73ogwwgcTWR4Mx25IERzlgtFQ1PJcGHFa3/iNf3K CHJQ== Original-Received: by 10.52.92.18 with SMTP id ci18mr12723734vdb.73.1331480156672; Sun, 11 Mar 2012 08:35:56 -0700 (PDT) Original-Received: by 10.52.88.231 with HTTP; Sun, 11 Mar 2012 08:35:56 -0700 (PDT) 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:14082 Archived-At: --bcaec50166edc391d804baf96152 Content-Type: multipart/alternative; boundary=bcaec50166edc391d504baf96150 --bcaec50166edc391d504baf96150 Content-Type: text/plain; charset=UTF-8 I've been troubled with a weird problem in read-response-body for a long time. I think read-response-body never return the received data when any break happens. No matter the break caused by connection problem or user interruption. The only possible read-response-body returns data is connection never down and all the data have been received even if I want to download a 2G file. Or there's no chance to write any data to the disk. When break occurs, all the received data will evaporate. Considering my terrible network, I decide not to pray for good luck when I establish connection with our web module. So here's a patch to fix it. The new read-response-body will add the received data to the exceptional information which used by "throw", if read-response-body can't continue to work anymore, the received data will return with throw. And there's a useful helper function to write this data to the disk ==> (output-received-response-body e port) However, add received data to the exceptions will cause troubles when tracing or REPL throw exceptional information, because received data(as a bytevector) is usually huge. So there's another helper function to get rid of the received data after you handle the received data in your way. It will re-throw the original information in case other program need to catch it. ==> (throw-from-response-body-break e) It's easy to use them, but you must catch anything when your code contains read-response-body: ----------------------------cut------------------------- (catch #t (lambda () .....do some work with read-response-body...) (lambda e (output-received-response-body e port) ;; write received-data to the disk or you may decide to store it to other place. ... ... (throw-from-response-body-break e))) ;; re-throw the original information in the last step. ---------------------------end--------------------------- Anyway, one may use it in his/her own way if he/she checkout their implementation. The helper functions are not always necessary. But I do think read-response-body should return the received data when it breaks. Any comments? Regards. --bcaec50166edc391d504baf96150 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I've been troubled with a weird problem in read-response-body for a lon= g time.
I think read-response-body never return the received data when = any break happens. No matter the break caused by connection problem or user= interruption.
The only possible read-response-body returns data is connection never down = and all the data have been received even if I want to download a 2G file. O= r there's no
chance to write any data to the disk. When break occurs= , all the received data will evaporate.
Considering my terrible network, I decide not to pray for good luck when I = establish connection with our web module.
So here's a patch to fix i= t.

The new read-response-body will add the received data to the exce= ptional information which used by "throw", if read-response-body = can't continue to work anymore, the received data will return with thro= w.
And there's a useful helper function to write this data to the disk =3D= =3D> (output-received-response-body e port)

However, add received= data to the exceptions will cause troubles when tracing or REPL throw exce= ptional information, because received data(as a bytevector) is usually huge= . So there's another helper function to get rid of the received data af= ter you handle the received data in your way. It will re-throw the original= information in case other program need to catch it. =3D=3D> (throw-from= -response-body-break e)

It's easy to use them, but you must catch anything when your code c= ontains read-response-body:
----------------------------cut-------------= ------------
(catch #t
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 (lambda ()
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 .....do some work with read-response-body...)
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (lambda e
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 (output-received-response-body e port) ;; write received-da= ta to the disk or you may decide to store it to other place.
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 ...
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ...
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (= throw-from-response-body-break e))) ;; re-throw the original information in= the last step.
---------------------------end---------------------------

Anyway, on= e may use it in his/her own way if he/she checkout their implementation. Th= e helper functions are not always necessary.
But I do think read-respon= se-body should return the received data when it breaks.

Any comments?

Regards.
--bcaec50166edc391d504baf96150-- --bcaec50166edc391d804baf96152 Content-Type: text/x-diff; charset=US-ASCII; name="0001-read-response-body-should-return-received-data-in-an.patch" Content-Disposition: attachment; filename="0001-read-response-body-should-return-received-data-in-an.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gzo8upc40 RnJvbSA2YjZhZWYyMTkyNzY5Y2UxMmEyOTYyYjAyZDEwM2EwMTlmNGJjOWM2IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBOYWxhR2lucnV0IDxOYWxhR2lucnV0QGdtYWlsLmNvbT4KRGF0 ZTogU3VuLCAxMSBNYXIgMjAxMiAyMzowMjowNyArMDgwMApTdWJqZWN0OiBbUEFUQ0hdIHJlYWQt cmVzcG9uc2UtYm9keSBzaG91bGQgcmV0dXJuIHJlY2VpdmVkIGRhdGEgaW4gYW55IGJyZWFrCgot LS0KIG1vZHVsZS93ZWIvcmVzcG9uc2Uuc2NtIHwgICA1MiArKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKystLS0tLS0tCiAxIGZpbGVzIGNoYW5nZWQsIDQ0IGluc2VydGlvbnMo KyksIDggZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvbW9kdWxlL3dlYi9yZXNwb25zZS5zY20g Yi9tb2R1bGUvd2ViL3Jlc3BvbnNlLnNjbQppbmRleCAwN2UxMjQ1Li5lM2VhMGE2IDEwMDY0NAot LS0gYS9tb2R1bGUvd2ViL3Jlc3BvbnNlLnNjbQorKysgYi9tb2R1bGUvd2ViL3Jlc3BvbnNlLnNj bQpAQCAtMjEsNiArMjEsNyBAQAogCiAoZGVmaW5lLW1vZHVsZSAod2ViIHJlc3BvbnNlKQogICAj OnVzZS1tb2R1bGUgKHJucnMgYnl0ZXZlY3RvcnMpCisgICM6YXV0b2xvYWQgKHJucnMpIChjYWxs LXdpdGgtcG9ydCkKICAgIzp1c2UtbW9kdWxlIChpY2UtOSBiaW5hcnktcG9ydHMpCiAgICM6dXNl LW1vZHVsZSAoaWNlLTkgcmRlbGltKQogICAjOnVzZS1tb2R1bGUgKHNyZmkgc3JmaS05KQpAQCAt MzgsNiArMzksOCBAQAogCiAgICAgICAgICAgICByZXNwb25zZS1tdXN0LW5vdC1pbmNsdWRlLWJv ZHk/CiAgICAgICAgICAgICByZWFkLXJlc3BvbnNlLWJvZHkKKyAgICAgICAgICAgIG91dHB1dC1y ZWNlaXZlZC1yZXNwb25zZS1ib2R5CisgICAgICAgICAgICB0aHJvdy1mcm9tLXJlc3BvbnNlLWJv ZHktYnJlYWsKICAgICAgICAgICAgIHdyaXRlLXJlc3BvbnNlLWJvZHkKIAogICAgICAgICAgICAg OzsgR2VuZXJhbCBoZWFkZXJzCkBAIC0yMjQsMTYgKzIyNyw0OSBAQCBUaGlzIGlzIHRydWUgZm9y IHNvbWUgcmVzcG9uc2UgdHlwZXMsIGxpa2UgdGhvc2Ugd2l0aCBjb2RlIDMwNC4iCiAgICAgICAo PSAocmVzcG9uc2UtY29kZSByKSAyMDQpCiAgICAgICAoPSAocmVzcG9uc2UtY29kZSByKSAzMDQp KSkKIAotKGRlZmluZSAocmVhZC1yZXNwb25zZS1ib2R5IHIpCisoZGVmaW5lKiAocmVhZC1yZXNw b25zZS1ib2R5IHIgIzprZXkgKGJsb2NrIDQwOTYpKQogICAiUmVhZHMgdGhlIHJlc3BvbnNlIGJv ZHkgZnJvbSBAdmFye3J9LCBhcyBhIGJ5dGV2ZWN0b3IuICBSZXR1cm5zCiBAY29kZXsjZn0gaWYg dGhlcmUgd2FzIG5vIHJlc3BvbnNlIGJvZHkuIgotICAobGV0ICgobmJ5dGVzIChyZXNwb25zZS1j b250ZW50LWxlbmd0aCByKSkpCi0gICAgKGFuZCBuYnl0ZXMKLSAgICAgICAgIChsZXQgKChidiAo Z2V0LWJ5dGV2ZWN0b3ItbiAocmVzcG9uc2UtcG9ydCByKSBuYnl0ZXMpKSkKLSAgICAgICAgICAg KGlmICg9IChieXRldmVjdG9yLWxlbmd0aCBidikgbmJ5dGVzKQotICAgICAgICAgICAgICAgYnYK LSAgICAgICAgICAgICAgIChiYWQtcmVzcG9uc2UgIkVPRiB3aGlsZSByZWFkaW5nIHJlc3BvbnNl IGJvZHk6IH5hIGJ5dGVzIG9mIH5hIgotICAgICAgICAgICAgICAgICAgICAgICAgICAgIChieXRl dmVjdG9yLWxlbmd0aCBidikgbmJ5dGVzKSkpKSkpCisgIChsZXQqICgobmJ5dGVzIChyZXNwb25z ZS1jb250ZW50LWxlbmd0aCByKSkKKyAgICAgICAgIChidiAoYW5kIG5ieXRlcyAobWFrZS1ieXRl dmVjdG9yIG5ieXRlcykpKQorICAgICAgICAgKHN0YXJ0IDApKQorICAgIChjYXRjaCAjdAorICAg ICAgICAgICAobGFtYmRhICgpCisgICAgICAgICAgICAgKGxldCBscCgoYnVmIChnZXQtYnl0ZXZl Y3Rvci1uIChyZXNwb25zZS1wb3J0IHIpIGJsb2NrKSkpCisgICAgICAgICAgICAgICAgIChpZiAo ZW9mLW9iamVjdD8gYnVmKQorICAgICAgICAgICAgICAgICAgICAgYnYKKyAgICAgICAgICAgICAg ICAgICAgIChsZXQgKChsZW4gKGJ5dGV2ZWN0b3ItbGVuZ3RoIGJ1ZikpKQorICAgICAgICAgICAg ICAgICAgICAgICAoY29uZAorICAgICAgICAgICAgICAgICAgICAgICAgKCg8PSBsZW4gYmxvY2sp CisgICAgICAgICAgICAgICAgICAgICAgICAgKGJ5dGV2ZWN0b3ItY29weSEgYnVmIDAgYnYgc3Rh cnQgbGVuKQorICAgICAgICAgICAgICAgICAgICAgICAgIChzZXQhIHN0YXJ0ICgrIHN0YXJ0IGxl bikpCisgICAgICAgICAgICAgICAgICAgICAgICAgKGxwIChnZXQtYnl0ZXZlY3Rvci1uIChyZXNw b25zZS1wb3J0IHIpIGJsb2NrKSkpCisgICAgICAgICAgICAgICAgICAgICAgICAoZWxzZQorICAg ICAgICAgICAgICAgICAgICAgICAgIChiYWQtcmVzcG9uc2UgIkVPRiB3aGlsZSByZWFkaW5nIHJl c3BvbnNlIGJvZHk6IH5hIGJ5dGVzIG9mIH5hIgorICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgc3RhcnQgbmJ5dGVzKSkpKSkpKQorICAgICAgICAgICAgIChsYW1iZGEgKGsg LiBlKQorICAgICAgICAgICAgICAgKGxldCAoKHJlY2VpdmVkIChjYWxsLXdpdGgtcG9ydCAKKyAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKG9wZW4tYnl0ZXZlY3Rvci1pbnB1dC1wb3J0 IGJ2KSAKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKGxhbWJkYSAocG9ydCkKKyAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoZ2V0LWJ5dGV2ZWN0b3ItbiBwb3J0IHN0 YXJ0KSkpKSkKKyAgICAgICAgICAgICAgICAgKHRocm93IGsgYCgsQGUgKGJvZHkgLEByZWNlaXZl ZCkpKSA7OyByZXR1cm4gdGhlIHJlY2VpdmVkIGRhdGEKKyAgICAgICAgICAgICAgICAgKSkpKSkK KworOzsgb3V0cHV0IHRoZSByZWNlaXZlZCBkYXRhIGlmIHRoZXJlIGlzLCBvciBkbyBub3RoaW5n CisoZGVmaW5lIChvdXRwdXQtcmVjZWl2ZWQtcmVzcG9uc2UtYm9keSBlIHBvcnQpCisgIChsZXQg KChyZWNlaXZlZCAoYXNzb2MtcmVmIChjYWRyIGUpICdib2R5KSkpCisgICAgKGlmIHJlY2VpdmVk CisgICAgICAgIChiZWdpbgorICAgICAgICAgIChwdXQtYnl0ZXZlY3RvciBwb3J0IHJlY2VpdmVk KSAKKyAgICAgICAgICAoZm9yY2Utb3V0cHV0IHBvcnQpKSkpKQorICAgCis7OyBFeGNlcHRpb25h bCBpbmZvcm1hdGlvbiBjb250YWlucyB0aGUgcmVjZWl2ZWQgYnl0ZXZlY3RvciBhZGRlZCBmcm9t IHRoZQorOzsgcmVhZC1yZXNwb25zZS1ib2R5IGlmIGFueSBleGNlcHRpb24gaGFkIGJlZW4gY2F1 Z2h0LgorOzsgSWYgcmVjZWl2ZWQgZGF0YSB3YXJlIGh1Z2UoaXQgYWx3YXlzIGRvZXMpLCBpdCdk IGJlIGEgdHJvdWJsZSBkdXJpbmcgdGhlIHRyYWNpbmcuCis7OyBUaGlzIGhlbHBlciBmdW5jdGlv biBjb3VsZCBnZXQgcmlkIG9mIHRoZSByZWNlaXZlZCBkYXRhIGZyb20gZXhjZXB0aW9uYWwgaW5m bywKKzs7IGFuZCByZS10aHJvdyBpdC4KKyhkZWZpbmUgKHRocm93LWZyb20tcmVzcG9uc2UtYm9k eS1icmVhayBlKQorICAodGhyb3cgKGNhciBlKSAobGlzdC1oZWFkIChjZHIgZSkgKDEtIChsZW5n dGggKGNkciBlKSkpKSkpCiAKIChkZWZpbmUgKHdyaXRlLXJlc3BvbnNlLWJvZHkgciBidikKICAg IldyaXRlIEB2YXJ7YnZ9LCBhIGJ5dGV2ZWN0b3IsIHRvIHRoZSBwb3J0IGNvcnJlc3BvbmRpbmcg dG8gdGhlIEhUVFAKLS0gCjEuNy4wLjQKCg== --bcaec50166edc391d804baf96152--