Re: Some newbie questions: http-client, logging.
Carl Gay <[email protected]> Sun, 31 Aug 2014 20:25:59 -0400
| Newsgroups | gmane.comp.lang.dylan.gwydion.devel |
|---|---|
| Message-ID | <CALekcH2+zOirNaVnXukYYwLZ+qjWGnmP4d2sYQ4SzG5y7sEcsA@mail.gmail.com> |
--001a1134d26e1692400501f60cb5 Content-Type: multipart/alternative; boundary=001a1134d26e16923a0501f60cb3 --001a1134d26e16923a0501f60cb3 Content-Type: text/plain; charset=UTF-8 There are a bunch of things going on here... On Sun, Aug 31, 2014 at 6:02 PM, Piotr Klibert <[email protected]> wrote: > Thanks for your response. > > > > > If I recall correctly you can also get a header value with > > element(response, "Connection", default: #f) > > because the response is an instance of <message-headers-mixin>. > > > > I don't think so. This: > https://github.com/dylan-lang/http/blob/master/common/headers.dylan#L16 > and this: > https://github.com/dylan-lang/http/blob/master/common/headers.dylan#L104 > seems to suggest that I need to use get-header accessor. But I guess > implementing element for <message-headers-mixin> would be trivial in > Dylan :-) > > > > > That was intended for debugging the http code itself and so isn't > exported. > > (It should be removed.) > > > > The reason why I ask about *debug-reads?* is that I'm trying to debug > http-get function. It doesn't seem to work for me for some reason. It > refuses to take a string as an argument and makes me call parse-url on > the url, but I guess that's ok, the problem is that it just hangs and > then dies with 110 (timeout) socket error. > > The request I do is to my own site, which is behind CloudFlare at the > moment, which means it uses chunked Transfer-Encoding (but I tested it > with 'direct' subdomain which exposes my nginx directly and there is > Content-Length in headers). I tested it mainly with this site, which > means it may return some peculiar response, which confuses some part > of response handling code. > There are two problems: The $default-http-port (in http-common) was changed to 8000 recently. I did that only thinking about the server, but clearly the client should default to 80 for HTTP and 443 for HTTPS. I'll fix that. For now you can just put :80 in your URL. There were two more bugs I hit while getting your code to work: * some code is expecting a <url> rather than a <uri> and http-client was giving it a <uri>. boom. * some code wasn't passing read-request-body? = #t along so http-get didn't fetch the URL content. See attached patch, which I'll clean up and commit. > > You can (hopefully!) reproduce this behaviour with this simple > program: https://gist.github.com/piotrklibert/d1acddad89bcad944a0e - I > also attached program output there for quick inspection. > > Some other things: I discovered "keyed-by" extension to for syntax, > which can replace key-sequence. Nice. > > I'm working with Emacs mode and I found its indentation code breaks in > some situations. I didn't look into it yet, but as a heavy Emacs user > I probably will. > I look forward to that! It's been driving me crazy but I can never get up the energy to fix dylan-mode. > > It's a bit of a pain to have to look in two separate files for > definitions and their exported names. Dylan module system indeed is > similar to Racket's, but there the `provide` and `require` forms are > in the same file (more precisely, inside a module, as you can have > many modules in single file). I expect a decent IDE would make it a > non-issue and I'll see what I can do with Emacs mode to this end. > I agree completely. The IDE definitely helps here, but I'd love to have a way to make it better for the non-IDE case as well though. > > I need to look into XML library (I love the use of macros here: > > https://github.com/dylan-lang/xml-parser/blob/40bd659debb9cb3623ec971d3c2ce29c33bf33a7/latin1-entities.dylan > ), signal/error handling and cleanups, threads library (where > apparently dynamic-bind lives?) and I have still quite a bit of > language spec to read (collections and other built-ins, not to mention > the whole sealed/open thing), so I will be busy with all this for > quite a while, I think. > > But please tell me if you have no time to debug http-client thing I > encountered (if it indeed is a bug in the library), I'll try and do my > best here too :-) > > > Best regards, > Piotr Klibert > --001a1134d26e16923a0501f60cb3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">There are a bunch of things going on here...<div class=3D"= gmail_extra"><br><br><div class=3D"gmail_quote">On Sun, Aug 31, 2014 at 6:0= 2 PM, Piotr Klibert <span dir=3D"ltr"><<a href=3D"mailto:piotr.klibert@1= 0clouds.com" target=3D"_blank">[email protected]</a>></span> wr= ote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">Thanks for your response.<br> <div class=3D""><br> ><br> > If I recall correctly you can also get a header value with<br> >=C2=A0 element(response, "Connection", default: #f)<br> > because the response is an instance of <message-headers-mixin>.<= br> ><br> <br> </div>I don't think so. This:<br> <a href=3D"https://github.com/dylan-lang/http/blob/master/common/headers.dy= lan#L16" target=3D"_blank">https://github.com/dylan-lang/http/blob/master/c= ommon/headers.dylan#L16</a><br> and this: <a href=3D"https://github.com/dylan-lang/http/blob/master/common/= headers.dylan#L104" target=3D"_blank">https://github.com/dylan-lang/http/bl= ob/master/common/headers.dylan#L104</a><br> seems to suggest that I need to use get-header accessor. But I guess<br> implementing element for <message-headers-mixin> would be trivial in<= br> Dylan :-)<br> <div class=3D""><br> ><br> > That was intended for debugging the http code itself and so isn't = exported.<br> > (It should be removed.)<br> ><br> <br> </div>The reason why I ask about *debug-reads?* is that I'm trying to d= ebug<br> http-get function. It doesn't seem to work for me for some reason. It<b= r> refuses to take a string as an argument and makes me call parse-url on<br> the url, but I guess that's ok, the problem is that it just hangs and<b= r> then dies with 110 (timeout) socket error.<br> <br> The request I do is to my own site, which is behind CloudFlare at the<br> moment, which means it uses chunked Transfer-Encoding (but I tested it<br> with 'direct' subdomain which exposes my nginx directly and there i= s<br> Content-Length in headers). I tested it mainly with this site, which<br> means it may return some peculiar response, which confuses some part<br> of response handling code.<br></blockquote><div><br></div><div>There are tw= o problems:</div><div><br></div><div>The $default-http-port (in http-common= ) was changed to 8000 recently. =C2=A0I did that only thinking about the se= rver, but clearly the client should default to 80 for HTTP and 443 for HTTP= S. =C2=A0I'll fix that. =C2=A0 For now you can just put :80 in your URL= .</div> <div><br></div><div>There were two more bugs I hit while getting your code = to work:</div><div>* some code is expecting a <url> rather than a <= ;uri> and http-client was giving it a <uri>. =C2=A0boom.</div><div= > * some code wasn't passing read-request-body? =3D #t along so http-get = didn't fetch the URL content.</div><div>See attached patch, which I'= ;ll clean up and commit.</div><div>=C2=A0</div><blockquote class=3D"gmail_q= uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e= x"> <br> You can (hopefully!) reproduce this behaviour with this simple<br> program: <a href=3D"https://gist.github.com/piotrklibert/d1acddad89bcad944a= 0e" target=3D"_blank">https://gist.github.com/piotrklibert/d1acddad89bcad94= 4a0e</a> - I<br> also attached program output there for quick inspection.<br> <br> Some other things: I discovered "keyed-by" extension to for synta= x,<br> which can replace key-sequence. Nice.<br> <br> I'm working with Emacs mode and I found its indentation code breaks in<= br> some situations. I didn't look into it yet, but as a heavy Emacs user<b= r> I probably will.<br></blockquote><div><br></div><div>I look forward to that= ! =C2=A0It's been driving me crazy but I can never get up the energy to= fix dylan-mode.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" st= yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> It's a bit of a pain to have to look in two separate files for<br> definitions and their exported names. Dylan module system indeed is<br> similar to Racket's, but there the `provide` and `require` forms are<br= > in the same file (more precisely, inside a module, as you can have<br> many modules in single file). I expect a decent IDE would make it a<br> non-issue and I'll see what I can do with Emacs mode to this end.<br></= blockquote><div><br></div><div>I agree completely. =C2=A0The IDE definitely= helps here, but I'd love to have a way to make it better for the non-I= DE case as well though.</div> <div>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 = 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> I need to look into XML library (I love the use of macros here:<br> <a href=3D"https://github.com/dylan-lang/xml-parser/blob/40bd659debb9cb3623= ec971d3c2ce29c33bf33a7/latin1-entities.dylan" target=3D"_blank">https://git= hub.com/dylan-lang/xml-parser/blob/40bd659debb9cb3623ec971d3c2ce29c33bf33a7= /latin1-entities.dylan</a><br> ), signal/error handling and cleanups, threads library (where<br> apparently dynamic-bind lives?) and I have still quite a bit of<br> language spec to read (collections and other built-ins, not to mention<br> the whole sealed/open thing), so I will be busy with all this for<br> quite a while, I think.<br> <br> But please tell me if you have no time to debug http-client thing I<br> encountered (if it indeed is a bug in the library), I'll try and do my<= br> best here too :-)<br> <br> <br> Best regards,<br> Piotr Klibert<br> </blockquote></div><br></div></div> --001a1134d26e16923a0501f60cb3-- --001a1134d26e1692400501f60cb5 Content-Type: text/plain; charset=US-ASCII; name="http.diff" Content-Disposition: attachment; filename="http.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hzj24j770 ZGlmZiAtLWdpdCBhL2NsaWVudC9odHRwLWNsaWVudC5keWxhbiBiL2NsaWVudC9odHRwLWNsaWVu dC5keWxhbgppbmRleCA3Nzg2MWEzLi5mMTE3NjE1IDEwMDY0NAotLS0gYS9jbGllbnQvaHR0cC1j bGllbnQuZHlsYW4KKysrIGIvY2xpZW50L2h0dHAtY2xpZW50LmR5bGFuCkBAIC02NTQsNyArNjU0 LDExIEBAIGVuZCBtZXRob2QgcmVhZC1zdGF0dXMtbGluZTsKIGRlZmluZSBmdW5jdGlvbiBtYWtl LWh0dHAtY29ubmVjdGlvbgogICAgIChob3N0LW9yLXVybCwgI3Jlc3QgaW5pdGFyZ3MsICNrZXkg cG9ydCwgI2FsbC1rZXlzKQogICBsZXQgaG9zdCA9IGhvc3Qtb3ItdXJsOwotICBsZXQgcG9ydCA9 IHBvcnQgfCAkZGVmYXVsdC1odHRwLXBvcnQ7CisgIGxldCBwb3J0ID0gcG9ydCB8IDgwOworICAv LyBJdCdzIGNvbnZlbmllbnQgdG8gYmUgYWJsZSB0byB1c2UgYSBzdHJpbmcgZm9yIHRoZSBVUkwu CisgIGlmIChpbnN0YW5jZT8oaG9zdCwgPHN0cmluZz4pICYgbWVtYmVyPygnLycsIGhvc3QpKQor ICAgIGhvc3QgOj0gcGFyc2UtdXJsKGhvc3QpOworICBlbmQ7CiAgIGlmIChpbnN0YW5jZT8oaG9z dCwgPHVyaT4pKQogICAgIGxldCB1cmkgOjogPHVyaT4gPSBob3N0OwogICAgIGhvc3QgOj0gdXJp LWhvc3QodXJpKTsKQEAgLTczMyw3ICs3MzcsNiBAQCBkZWZpbmUgbWV0aG9kIHBlcmZvcm0tcmVx dWVzdAogICAgICAgICAgIHN0cmVhbSA6OiBmYWxzZS1vcig8c3RyZWFtPikpCiAgPT4gKHJlc3Bv bnNlIDo6IDxodHRwLXJlc3BvbnNlPikKICAgbGV0ICh1cmwsIHJlcXVlc3QtbWV0aG9kLCB2ZXJz aW9uLCBoZWFkZXJzLCBjb250ZW50KSA9IGV4cGxvZGUtcmVxdWVzdChyZXF1ZXN0KTsKLQogICB3 aXRoLWh0dHAtY29ubmVjdGlvbihjb25uID0gdXJsKQogICAgIGl0ZXJhdGUgbG9vcCAoZm9sbG93 ID0gZm9sbG93LXJlZGlyZWN0cywgdXJsID0gdXJsLCBzZWVuID0gIygpKQogICAgICAgc2VuZC1y ZXF1ZXN0KGNvbm4sIHJlcXVlc3QtbWV0aG9kLCB1cmwsIGhlYWRlcnM6IGhlYWRlcnMsIGNvbnRl bnQ6IGNvbnRlbnQpOwpAQCAtODIyLDEwICs4MjUsMTAgQEAgZGVmaW5lIG1ldGhvZCBodHRwLXJl cXVlc3QKICAgICAgICAgICBwYXJhbWV0ZXJzLAogICAgICAgICAgIGRhdGEsCiAgICAgICAgICAg Zm9sbG93LXJlZGlyZWN0cywKLSAgICAgICAgICByZWFkLXJlc3BvbnNlLWJvZHk/LAorICAgICAg ICAgIHJlYWQtcmVzcG9uc2UtYm9keT8gPSAjdCwKICAgICAgICAgICBzdHJlYW0pCiAgPT4gKHJl c3BvbnNlIDo6IDxodHRwLXJlc3BvbnNlPikKLSAgaHR0cC1yZXF1ZXN0KHBhcnNlLXVyaSh1cmwp LAorICBodHRwLXJlcXVlc3QocGFyc2UtdXJsKHVybCksCiAgICAgICAgICAgICAgICByZXF1ZXN0 LW1ldGhvZCwKICAgICAgICAgICAgICAgIGhlYWRlcnM6IGhlYWRlcnMsCiAgICAgICAgICAgICAg ICBwYXJhbWV0ZXJzOiBwYXJhbWV0ZXJzLAo= --001a1134d26e1692400501f60cb5 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ hackers mailing list [email protected] https://lists.opendylan.org/mailman/listinfo/hackers --001a1134d26e1692400501f60cb5--