Re: Some newbie questions: http-client, logging.

--===============0093048391==
Content-Type: multipart/alternative; boundary=001a11c372bcd54c800502708b8b

--001a11c372bcd54c800502708b8b
Content-Type: text/plain; charset=UTF-8

The http changes I mentioned have now been merged into master.


On Sun, Aug 31, 2014 at 8:25 PM, Carl Gay <[email protected]> wrote:

> 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
>>
>
>

--001a11c372bcd54c800502708b8b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">The http changes I mentioned have now been merged into mas=
ter.<br><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Su=
n, Aug 31, 2014 at 8:25 PM, Carl Gay <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:[email protected]" target=3D"_blank">[email protected]</a>&gt;</span> wro=
te:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">There are a bunch of=
 things going on here...<div class=3D"gmail_extra"><br><br><div class=3D"gm=
ail_quote"><span class=3D"">On Sun, Aug 31, 2014 at 6:02 PM, Piotr Klibert =
<span dir=3D"ltr">&lt;<a href=3D"mailto:[email protected]" target=
=3D"_blank">[email protected]</a>&gt;</span> wrote:<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><br>
&gt;<br>
&gt; If I recall correctly you can also get a header value with<br>
&gt;=C2=A0 element(response, &quot;Connection&quot;, default: #f)<br>
&gt; because the response is an instance of &lt;message-headers-mixin&gt;.<=
br>
&gt;<br>
<br>
</div>I don&#39;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 &lt;message-headers-mixin&gt; would be trivial in<=
br>
Dylan :-)<br>
<div><br>
&gt;<br>
&gt; That was intended for debugging the http code itself and so isn&#39;t =
exported.<br>
&gt; (It should be removed.)<br>
&gt;<br>
<br>
</div>The reason why I ask about *debug-reads?* is that I&#39;m trying to d=
ebug<br>
http-get function. It doesn&#39;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&#39;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 &#39;direct&#39; 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></span><div>There=
 are two 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 server, but clearly the client should default to 80 for HTTP and 443 f=
or HTTPS. =C2=A0I&#39;ll fix that. =C2=A0 For now you can just put :80 in y=
our 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 &lt;url&gt; rather than a &lt=
;uri&gt; and http-client was giving it a &lt;uri&gt;. =C2=A0boom.</div><div=
>
* some code wasn&#39;t passing read-request-body? =3D #t along so http-get =
didn&#39;t fetch the URL content.</div><div>See attached patch, which I&#39=
;ll clean up and commit.</div><span class=3D""><div>=C2=A0</div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">

<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 &quot;keyed-by&quot; extension to for synta=
x,<br>
which can replace key-sequence. Nice.<br>
<br>
I&#39;m working with Emacs mode and I found its indentation code breaks in<=
br>
some situations. I didn&#39;t look into it yet, but as a heavy Emacs user<b=
r>
I probably will.<br></blockquote><div><br></div></span><div>I look forward =
to that! =C2=A0It&#39;s been driving me crazy but I can never get up the en=
ergy to fix dylan-mode.</div><span class=3D""><div>=C2=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex">

<br>
It&#39;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&#39;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&#39;ll see what I can do with Emacs mode to this end.<br></=
blockquote><div><br></div></span><div>I agree completely. =C2=A0The IDE def=
initely helps here, but I&#39;d love to have a way to make it better for th=
e non-IDE case as well though.</div><span class=3D"">
<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&#39;ll try and do my<=
br>
best here too :-)<br>
<br>
<br>
Best regards,<br>
Piotr Klibert<br>
</blockquote></span></div><br></div></div>
</blockquote></div><br></div></div>

--001a11c372bcd54c800502708b8b--

--===============0093048391==
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

--===============0093048391==--