The web in a box - a next generation web framework for the Perl programming language

IRC log for #mojo, 2016-12-22

| Channels | #mojo index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:04 stryx` joined #mojo
00:34 kaare joined #mojo
00:59 jontaylor joined #mojo
01:07 aborazmeh joined #mojo
02:09 howitdo joined #mojo
02:15 disputin joined #mojo
03:58 noganex joined #mojo
05:04 dboehmer joined #mojo
05:24 inokenty-w joined #mojo
05:30 disputin joined #mojo
05:35 howitdo joined #mojo
06:20 tardisx joined #mojo
06:21 tardisx joined #mojo
06:55 Vandal15263 joined #mojo
07:07 mbudde joined #mojo
07:09 dod joined #mojo
07:15 dod joined #mojo
07:30 polettix joined #mojo
07:59 rshadow joined #mojo
08:24 AndrewIsh joined #mojo
08:34 trone joined #mojo
09:24 osfabibisi joined #mojo
09:29 marcus sri: "many wonderful attributes and methods" - maybe 'useful' would be better than wonderful?
09:29 * sri changes wonderful to fabulous
09:45 Jonis magical, just to poke jberger ;)
09:59 polettix joined #mojo
10:11 howitdo joined #mojo
10:33 stryx` joined #mojo
11:06 Adurah joined #mojo
11:06 osfabibi_ joined #mojo
11:19 dod joined #mojo
11:32 sri the folks at razer are definitely messing with me
11:33 sri sent me a wrong keycap again
11:42 sri last time it was a keycap with the right size, but wrong key and language... this time it's the right key but the wrong size
12:28 osfabibisi joined #mojo
12:30 mishanti1 sri: Perhaps one of them is a lurker in #mojo?
12:30 mishanti1 "Let's see how fired up we can make sri"
12:48 rshadow joined #mojo
12:52 polettix joined #mojo
13:14 rshadow joined #mojo
13:45 parv joined #mojo
13:50 jberger sri you seem to have really terrible luck when it comes to service
13:50 jberger Jonis++
14:09 Jonis jberger: nice blog post btw :)
14:11 gryphon joined #mojo
14:17 rshadow joined #mojo
14:40 rshadow joined #mojo
14:52 marty joined #mojo
15:02 polettix joined #mojo
15:08 ashimema joined #mojo
15:11 tholen joined #mojo
15:11 tl joined #mojo
15:16 jberger Thanks
15:17 marty joined #mojo
15:21 sh14 joined #mojo
15:27 asarch joined #mojo
15:43 cfedde joined #mojo
15:54 cfedde joined #mojo
16:06 cfedde joined #mojo
16:07 cfedde joined #mojo
16:11 dikim joined #mojo
16:14 cfedde joined #mojo
16:28 dboehmer regarding issue https://github.com/kraih/mojo/issues/1023
16:28 dboehmer I've further reduced it to this example:
16:28 dboehmer say Mojo::URL->new("foo?%2520#%2520")
16:29 dboehmer this is 1 call for 1 URL and it returns 2 different approaches of encoding. that can't possibly be correct, can it?
16:29 pink_mist the query string there is malformed
16:30 dboehmer pink_mist: the query string always needs to have key-value pairs, right?
16:30 pink_mist yes
16:30 tinita no
16:30 pink_mist no?
16:30 dboehmer don't mind. works the same way: say Mojo::URL->new("foo?bar=%2520#%2520")
16:30 pink_mist dboehmer: and what does that give?
16:31 dboehmer pink_mist: returns for me foo?%bar=2520#%20
16:31 dboehmer sorry, typo
16:31 tinita pink_mist: http://example.com/foo?bar is a perfectly valid url, no?
16:32 dboehmer say Mojo::URL->new("foo?%bar=%2520#%2520") => foo?%bar=%2520#%20
16:32 sri pink_mist: a simple string is a valid query too
16:32 dboehmer sorry for pasting so much code. it's supposed to be a one-liner;-)
16:32 pink_mist dboehmer: please correct yourself properly
16:32 pink_mist tinita, sri: right
16:33 sri dboehmer: the test case doesn't matter though
16:33 sri we already know what happens
16:34 sri we've just decided that it would be too expensive to handle the case differently
16:34 sri and a breaking change
16:35 dboehmer sri: I tried to understand your comments in the issue. There's more homework for me. but that behaviour of Mojo::URL seems just wrong. how's that acceptable?
16:35 sri $url->fragment would need to be an object like $url->query
16:35 sri dboehmer: i would only agree that it is "wrong" if you can quote parts of the spec that disagree with the implementation
16:36 dboehmer what do you consider spec regarding this case? HTTP RFCs + Mojo* POD?
16:37 sri the specs are listed in the module description
16:38 pink_mist dboehmer: why don't you simply set the fragment using the ->fragment accessor though?
16:39 dboehmer the URL is compiled somewhere else and only sent out by the Mojolicious app
16:42 sri dboehmer: anyway, if you want to propose a braking change to Mojo::URL, it can only be done if it is a bug according to the specs
16:43 sri *breaking
16:43 dboehmer https://metacpan.org/pod/Mojolicious::Controller#redirect_to and the linked url_for() are described to accept strings with complete URLs. my expectation was that any valid URL would be sent to the client. there is no restriction on which URLs will work
16:43 sri dboehmer: your url is relative though
16:44 sri so it has to be mangled no matter what
16:44 dboehmer sri: I posted relative URLs for short examples but there's no difference with complete URLs
16:45 sri i guess that's true, but even more so for relative ones
16:46 sri a Mojo::URL::Fragment object would be a pretty massive breaking change
16:46 sri honestly, i hope you don't find anything in the specs, because changes would be a nightmare
16:47 dboehmer from my point of view redirect_to fails it specs but I get your point
16:47 dboehmer i didn't understand yet why you'd need a new module
16:48 jberger to prevent double encoding, I believe
16:48 jberger sri: could it just use Mojo::Bytestream
16:48 dboehmer how are query and fragment handled differently? fragment is decoded once and then only appended to the URL?
16:49 * dboehmer is looking into URL.pm
16:49 jberger dboehmer: how do you indicate that a fragment has already been percent encoded once
16:50 jberger when a query is parsed, it is put into an object, later when the object is seen we know what the state of encoding is
16:50 dboehmer jberger: that's a good question but whatever your answer is, please stick to that while handling 1 string;-)
16:50 jberger ?
16:51 sri curious thing, only one test breaks when you change Mojo::URL::parse not to decode fragments https://github.com/kraih/mojo/blob/master/t/mojo/request.t#L2101
16:52 sri whatever, until there is confirmed spec breakage there is no point discussing further
16:53 dboehmer sri: I'm trying to adjust my thinking to Mojo::URL's structure. could a $url object keep information about whether $url->fragment is encoded or not? doesn't need to be an object.
16:54 jberger this SO post seems to break down the RFC: http://stackoverflow.com/a/26119120/468327
16:54 jberger looks like it should be percent encoded
16:55 dboehmer jberger: right
16:55 sri it's the "the" RFC
16:55 sri *not
16:55 sri there are multiple specs that apply http://mojolicious.org/perldoc/Mojo/URL#DESCRIPTION
16:58 jberger from my perspective, when I pass a url string to Mojo::URL::parse it does the correct thing
16:58 dboehmer reading ... ok, it's perfectly clear the a percent sign should encoded itself. but if you get one you don't know if it's to be encoded or is part of an encoding (given a hex number follows)
16:59 jberger if I pass a url which has an already encoded fragment to parse, it is going to have double encoding/(or double decoding) issues, just like any string encoding problem
17:00 dboehmer jberger: did you see my example above? you think it's correct to pass an URL and receive a different URL that doesn't match regardless how often de- or encoded?
17:05 jberger is it possible this is just a case of asymmetry of encoded characters passed to url_escape in Mojo::URL::to_string vs url_decode in Mojo::URL::parse
17:05 jberger errr, url_unescape
17:06 dboehmer jberger: sounds reasonable to me. problem is query is an object of known state while fragment could be anything
17:07 dboehmer I'm still thinking about this idea: parse() should decode the fragement and fragement should always be stored as plaintext. to_string() should encode. don't about fragment() though. maybe something like ifragment()?
17:08 dboehmer similar to ihost
17:09 sri dboehmer: you're describing how it works now
17:10 dboehmer sri: I think not, because my %2520 is decoded to plaintext %20 and then appended as is
17:10 howitdo joined #mojo
17:10 pink_mist exactly like you said
17:11 dboehmer but I wrote " to_string() should encode."
17:11 dboehmer so %20 should be encoded by to_string() to %2520 again
17:12 sri you want the % removed here? https://github.com/kraih/mojo/blob/master/lib/Mojo/URL.pm#L169
17:12 disputin joined #mojo
17:12 PryMar56 joined #mojo
17:13 dboehmer I'm looking into this to understand what the char list means
17:13 sri well, that should be easy to back up with spec references
17:14 sri *BUT*
17:14 sri the % is in the car list in Mojo::Parameters too
17:14 sri *char
17:14 jberger so things seem to work as dboehmer expects if I remove % from the character list here https://github.com/kraih/mojo/blob/e0ad165bfbec7d8e9d9ae96f89281f229e788a61/lib/Mojo/URL.pm#L169
17:14 sri so, you'll have to adjust that as well, or find good reasons for inconsistency
17:15 jberger heh, I just came to the same conclusion
17:15 jberger sorry, I should have caught up before posting
17:15 sri the change also breaks many tests, so needs to be backed up by spec references
17:16 sri either way, we can conclude that #1013 is not well enough researched yet
17:17 dboehmer sri: I am not into the guts of Mojo 100%. but yes, I think '%' is an unsafe char that should be encoded
17:17 dboehmer sri: I can supply more real-world-like test code. I just tried to map it down to the most minimal example
17:17 sri dboehmer: tests don't matter
17:18 sri if you're right, the specs will support your argument
17:19 sri to sum it up, nothing is going to happen until we have cold hard spec references telling us what to do
17:20 sri but once we have that, i would expect quick change
17:26 dboehmer sri: I really don't understand what you expect some spec to say. it's pretty clear how a valid URL should look like. of course there's no RFC or thelike which describes Mojo::URL->new(). there some sort of POD and if I may say a sane user will expect the URL might be de/encoded but not changed. sorry for repeating that. but really, what kind of spec statement do you expect?
17:27 dboehmer *there's
17:31 sri we don't just follow the rfcs...
17:32 sri the url spec is meant to deal with the same problems we deal with
17:32 sri i'm not saying it's going to be easy, you'll have to understand what's exactly going on
17:33 dboehmer I see. the scope of url.spec.whatwg.org is larger than I got before. reading even more ...
18:29 kes joined #mojo
18:31 kes Is there any interface in Mojolicious for error localization?
18:31 kes maybe link to discussion about it?
18:32 kes s/it/that/
19:27 xdg joined #mojo
19:31 marty_ joined #mojo
19:35 dikim Hi, I am very new to mojolicious and I tried to follow a simple instruction to play with useragent in mojocast. But I can not seem to make it work. have I done something stupid? http://pastebin.com/XvcHyw6B
19:40 jberger dikim: you don't need ->html
19:40 jberger oh wait
19:41 dikim jberger: I am just following the instruction in mojocast.
19:41 jberger I don't think that whole interface exist anymore
19:41 jberger you need selectors
19:41 jberger :(
19:41 jberger man those are getting old
19:42 jberger say $ua->get('http://www.crest.iu.edu')->res->dom('html head title')
19:42 dikim I see.
19:42 jberger I'll make a note on the wiki
19:42 jberger or actually!
19:42 jberger dikim, why don't YOU make a note on the wiki
19:42 jberger since you are watching along you know exactly what the example was
19:43 jberger that would be a big help for us
19:43 dikim jberger: yes, I do. Yes, I will.
19:43 jberger in that same errata section
19:43 jberger dikim++
19:44 dikim But your example returns the array address but not the contents of title or just title tag.
19:44 jberger oh right
19:44 jberger sorry, let me actually try it :-P
19:44 jberger I don't remember what the old interface did :-P
19:45 dikim Just FYI, http://pastebin.com/cTiGZYL1
19:46 jberger perl -Mojo -E 'say app->ua->get("http://www.crest.iu.edu")->res->dom->at("html head title")->text'
19:46 jberger yeah, dom (and its related method find) return a collection
19:46 jberger so you see I instead did dom->at(...)
19:47 dikim jberger: gotcha. Thanks.
19:47 jberger which is the same thing as dom(...)->first or dom->find(...)->first
19:47 dikim BTW, do you want to me to just leave a comment in the corresponding the mojocast /section ?
19:48 jberger do what you think will be most helpful for the next person who watches along
19:48 jberger the wiki is community edited, its up to you how you do it (assuming you don't wreck the thing :-P)
19:49 jberger tempire: my kingdom for updated mojocasts!
19:49 jberger (yeah, I know, you don't have the source material anymore)
19:49 jberger (but I can still wish)
19:49 dikim The most helpful would be just fix the web cast but if it can not be done quickly, I think leaving the comment under thd webcast does not seem to be very helpful.
19:50 dikim I see. I can try to do my best not to mess up something.
19:51 jberger I'm sure you'll do fine
19:51 jberger I just have to say that for completeness
19:51 jberger ;D
19:52 stryx` joined #mojo
19:57 disputin joined #mojo
20:22 polettix joined #mojo
20:41 polettix joined #mojo
20:42 disputin joined #mojo
21:10 howitdo joined #mojo
22:00 polettix joined #mojo
22:52 marty joined #mojo
23:13 marty_ joined #mojo

| Channels | #mojo index | Today | | Search | Google Search | Plain-Text | summary