Camelia, the Perl 6 bug

IRC log for #mojo, 2010-07-25

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

All times shown according to UTC.

Time Nick Message
00:16 dotan left #mojo
01:41 Alias joined #mojo
02:44 vti joined #mojo
02:49 milki_ joined #mojo
02:54 janus joined #mojo
03:20 su-bzero_ joined #mojo
04:03 tl joined #mojo
04:59 doubi joined #mojo
07:36 dotan joined #mojo
07:37 dotan left #mojo
07:48 cognominal joined #mojo
08:06 zakame joined #mojo
08:12 yko joined #mojo
08:41 dotan joined #mojo
09:54 spleenjack joined #mojo
10:58 dotan joined #mojo
11:06 * sri yawns
11:12 dotan left #mojo
11:39 dotan joined #mojo
12:23 dotan left #mojo
12:43 GitHub164 joined #mojo
12:43 GitHub164 mojo: master Sebastian Riedel * 1c4f528 (2 files in 1 dirs): cleanup - http://bit.ly/c3Ob4M
12:43 GitHub164 left #mojo
13:06 sri guess it's a good sign people start asking about mojolicious performance, we could use a speed demon to profile and optimize a bit now
13:07 yko joined #mojo
14:42 * marcus just caught up with futurama episodes from vacation
14:42 marcus sri: mojo doesn't have anything like LWP::RobotUA?
15:01 dotan joined #mojo
15:10 memowe sri, marcus: I'm here. Ready to start hacking tomorrow :)
15:11 sri marcus: nope
15:12 marcus memowe: I've not been able to follow you up for the last week, due to having no internet
15:12 marcus memowe: did you do any work for that period?
15:12 sri we also don't do auto mirroring
15:12 marcus sri: ok :/ Have started work on the article I was talking on, so was looking into how to replicate Sean's examples.
15:13 sri :)
15:13 marcus can we use mozilla cookie jars? ;)
15:13 sri show how easy multipart forms and uploads are instead
15:13 marcus mm
15:13 sri no mozilla okkie jars ;p
15:14 sri *cookie
15:14 sri *munch*
15:14 marcus wookie jars!
15:14 sri i would buy one
15:16 marcus sri: we only support in memory wookie jars?
15:17 marcus I mean cookie jars
15:20 marcus also, seems the client is missing a way to do large downloads without gobbling up all the memory, unless I miss something
15:21 marcus I think streaming support would be the best way. LWP only supports dumping it to a file.
15:23 marcus In some of my iphone apps, I use a client that gives callbacks with chunks, then feed that to a streaming sax parser
15:23 marcus of course, the iphone apps are threaded..
15:41 sri marcus: only in memory yes
15:41 sri marcus: we do the chunk thing too :)
15:41 marcus sri: guess you still have some weak spots compared to lwp ;-)
15:41 marcus you do?
15:41 marcus I couldn't find it from the client docs
15:41 sri marcus: like?
15:42 sri i guess lwp could be a little faster with raw http parsing, considering it is spaghetti code and we have no optimization at all yet
15:43 marcus robot ua, mozilla cookies,  file downloads was the ones I noticed for now
15:43 sri those are not on my todo list
15:43 marcus but of course you have a lot of things lwp lack
15:43 sri file downloads?
15:43 marcus sri: if you can do chunked downloads, that is not needed
15:43 marcus sri: lwp supports  ':content_file' => $filespec,
15:44 sri i think we handle large downloads very elegantly
15:44 marcus for downloading big files without keeping them in memory
15:44 sri we do that automatically
15:44 marcus ah
15:44 sri based on file size the decision is automatic
15:44 marcus I remember now
15:44 marcus cool beans
15:44 marcus much better solution
15:45 sri i don't even consider it a feature it's such a basic thing :)
15:46 sri http://github.com/kraih/mojo/blob/​master/lib/Mojo/Command/Get.pm#L52 # streaming in action btw
15:46 garfield [ lib/Mojo/Command/Get.pm at master from kraih's mojo - GitHub ]
15:46 garfield http://xrl.us/bhudkc
15:46 sri $tx->res->body(sub {...}) and you are done
15:46 sri chunked transfer encoding is also handled transparently and just works
15:48 sri personally i have no interest in robotua and vendor specific persistent cookie support
15:48 sri but both could be implemented simply as MojoX modules
15:52 sri what i consider a big feature is native async support
15:55 sri server and client share the same core
15:58 vti mojo rocks!
15:58 vti wsconsole source code is damn simple btw
15:58 sri vti: it's amazing
15:59 sri didn't i say i wanted a ws console in the core few weeks ago? :)
15:59 sri vti: it has one problem though, IO::Poll for STDIN is not portable
16:00 vti i wrote it ages ago, but it didn't work right because of that bug, and i thought i was doing smth wrong and forgot about that
16:00 sri i'm not sure you could make STDIN/STDOUT non blocking on windows
16:01 sri maybe select works
16:01 sri but poll completely fails
16:01 vti hm
16:01 vti select could work here, not that much of a performance is needed :D
16:01 sri ;p
16:03 vti it's not usable yet, just a simple wrapper, but i could work on it to make it better, just have to find a case where i would use it heavily :D
16:04 sri vti: tell me once you have it finished, it should become Mojo::Command::Websocket :)
16:05 sri mojo websocket ws://127.0.0.1:3000/echo
16:06 sri or even ./myapp websocket /echo
16:06 sri :o
16:07 vti ye, would be cool
16:20 marcus sri: how come ::ByteStream doesn't have convenience methods to do json deserialization?
16:20 marcus oh doh, response has it
16:21 sri bytestream is for...well bytestreams ;p
16:21 sri json results in structures one way or the other
16:21 marcus yeah, but they start as bytestreams.
16:21 sri and yea, we have ->json just like ->dom
16:22 marcus right. in ::Message
16:22 yko joined #mojo
16:24 sri you can't really do much transformation on json bytestreams though
16:24 sri or none at all :)
16:26 sri the point of ::ByteStream is that transformation chains that so often come up get convenient ->decode('UTF-8')->url_unes​cape->encode('koi-8')->say
16:27 sri was one of the first things i missed coming from ruby
16:27 sri (not that they handle unicode well...)
16:39 marcus sri: btw, doesn't g follow redirects?
16:40 sri nope
16:40 sri ->max_redirects(0) is the default
16:40 sri i was unsure about that
16:40 marcus I think 1 would be a better default for ojo
16:40 marcus seeing as it's a convenience class
16:41 sri possible
16:41 sri i could also allow MOJO_MAX_REDIRECTS
16:41 marcus good defaults are better than options
16:42 sri in addition i meant
16:42 marcus yeah.
16:43 marcus btw, why isn't g("slashdot.org") parsed the same way as g("http://slashdot.org") ?
16:44 sri dunno
16:45 marcus seems slashdot.org gives a completely empty response object
16:45 sri likely
16:45 sri so far we only accept absolute or relative urls
16:45 sri no custom format
16:45 marcus ok
16:45 marcus I think most users would expect it to work like the location bar of a browser
16:46 sri didn't say it's a bad idea :)
16:46 marcus want a failing test? ;)
16:46 sri please
16:46 sri or not
16:47 sri i could copypasta something in client.t
16:47 marcus okies
16:47 sri less work than clicking a link first :D
16:47 marcus yeah, probably quicker
16:49 marcus sri: seems the default is to return an empty response if something fails?
16:50 sri ye
16:50 marcus for instance g("http://qerq5gshsthsth.net/")' does not mention that qerq5gshsthsth.net does not resolve
16:50 marcus memowe: this might be a good area for you to add more tests when you start tomorrow ;)
16:50 sri what should it do, die?
16:51 marcus or set an error in the response object
16:51 marcus that's what LWP does, I believe
16:51 sri isn't ->error set?
16:51 sri maybe it's just in the tx object, not sure
16:52 marcus I just dumped the response, it was completely empty
16:52 sri yea, that error is tx scope, makes sense
16:52 sri you normally check for errors on the tx object
16:53 sri res/req usually just get more specific
16:53 sri not sure what to do for the oneliner case :S
16:54 sri well, this is exactly what memowe was supposed to test and possibly fix :(
16:54 marcus guess he will start tomorrow.
16:54 * sri hands marcus the whip
16:57 * marcus feels like indiana jones
16:57 marcus sri: who's that twitter quote by?
16:58 sri bill gates :)
16:58 marcus it's a good quote.
16:58 sri yea
17:00 marcus sri: btw, shouldn't a 404 set $res->error ?
17:00 marcus (more testing meat for you, memowe)
17:00 sri marcus: it's not strictly an error
17:00 marcus sri: it's not really success either tho
17:00 sri depends how you look at it
17:01 marcus lwp::simple returns undef for a 404
17:01 sri from a REST api point of view...
17:01 marcus well, from almost all use cases I can think of
17:01 sri well, lwp is from another time
17:02 marcus you want to know if you get a 404 instead of a 200 tho
17:02 sri i'm not sure about it, memowe should explore possibilities ;p
17:02 marcus of course, it should not die from a 404.
17:04 sri i'm open to inclusing ->is_status_class(400/500) in the ->success logic
17:04 sri *including
17:04 sri but i think someone should think it through
17:04 sri also the implications for Test::Mojo
17:05 sri which is often used to specifically test errors
17:05 marcus yeah, it needs to be designed well.
17:12 GitHub139 joined #mojo
17:12 GitHub139 mojo: master Sebastian Riedel * a3efb32 (4 files in 4 dirs): allow schemeless urls similar to browsers - http://bit.ly/bvhhvS
17:12 GitHub139 left #mojo
17:13 marcus yaay
17:13 marcus I like it when you implement my suggestions ;)
17:14 sri i like it when your sugegstions are good ;p
17:14 marcus sri++
17:14 sri GROUPHUG!
17:20 GitHub137 joined #mojo
17:20 GitHub137 mojo: master Sebastian Riedel * 5f198ab (2 files in 2 dirs): pod update - http://bit.ly/c3SDjQ
17:20 GitHub137 left #mojo
17:22 sri i love it when a plan comes together!
17:30 sri marcus: so if we include 400/500 in the ->success logic, should we set ->error to the response message?
17:31 sri ->error can already be an array, we usually suggest response codes for internal errors
17:31 sri ->error('lalala', 404)
17:31 marcus yeah, I think that's a good plan
17:32 sri ->error('Maximum message size exceeded.', 413)
17:32 sri thats one of the internal ones
17:33 marcus just use the message from the rfc. 'Not Found'
17:33 marcus 'Internal Server Errror'
17:34 sri sounds like a plan
17:34 vti sounds like music
17:34 sri also makes it easy to differentiate between internal and external errors
17:35 marcus you mean like solar flares? ;)
17:35 sri ;p
17:36 sri the parser could blow up receiving the reponse
17:36 ask joined #mojo
17:36 marcus never. Your code is perfect.
17:36 marcus <;)
17:37 dotan left #mojo
17:42 sri this is an error that can happen locally, while parsing a 200 response ->error('Maximum message size exceeded.', 413) vs a real error response like ->error('Request Entity Too Large', 413)
17:42 sri this could be a problem
17:43 sri you don't know at first sight if it is local or remote
17:45 sri (at second sight you can just check ->res->code for the real response code)
17:45 sri marcus: this is another case i'm unsure about
17:46 marcus hmm
17:46 marcus not sure the local error should set a http error code...
17:46 sri it doesn't
17:46 sri the code is a suggestion from the protocol layer
17:47 marcus not sure I understand the implications of that.
17:47 sri server and client use the same parser
17:47 sri both get the same sugegstions for error codes from it
17:47 sri in the ->error attribute
17:49 marcus I see.
17:50 sri a possible solution would be for the client to just sync the error code with the actual response code
17:50 sri ->error('Maximum message size exceeded.', 200)
17:50 sri thats would be a possible result ;p
17:50 sri *-s
17:50 marcus not sure I like that.
17:50 marcus I have to put Eva to bed now, will ponder meanwhile
17:50 sri or it could remove codes completely
17:51 marcus if there's no request, I think that makes more sense
17:51 sri it's a long standing problem, not seen a good solution in any implementation yet i think
17:52 sri client side plain error messages might be best
17:53 sri then again if you are building a crawler, and want to catch parser errors like 413, you are screwed in that case
18:04 sri maybe the right strategy is to leave all protocol and connection errors without a code (or remove if neccessary) and only add codes for 400/500 responses.
19:24 ask joined #mojo
19:38 GitHub165 joined #mojo
19:38 GitHub165 mojo: master Sebastian Riedel * 650659d (4 files in 3 dirs): cleanup - http://bit.ly/dnKTvG
19:38 GitHub165 left #mojo
19:50 GitHub160 joined #mojo
19:50 GitHub160 mojo: master Sebastian Riedel * 418944b (1 files in 1 dirs): cleanup - http://bit.ly/cVp1jA
19:50 GitHub160 left #mojo
19:52 sri i've changed error handling a bit, lets how it turns out
19:52 sri *see
19:57 marcus deceptive commit message ;)
19:58 marcus but it looks pretty good to me
19:59 sri i'm still unsure
19:59 sri and i've noticed a few more things that make me rather unhappy
19:59 marcus like what?
19:59 sri pipelining was a bad idea really
20:00 sri since client side you can just opt out and everything is fine
20:00 sri i might just remove it
20:01 marcus perl -Mojo -le'print g("iuasdfassethis.com/json/google​chrome")->json->{app}->{version}'
20:01 marcus gives me Can't use an undefined value as a HASH reference at -e line 1.
20:01 marcus it might actually be better to die in that case?
20:01 marcus I'm a bit unsure.
20:01 sri unsure
20:02 marcus I guess that's because it gets a empty response, and then the json method returns undef?
20:02 sri ye
20:02 sri empty or error
20:03 sri actually your example is not very good
20:03 sri normally you would check the structure
20:04 sri borked json would be undef
20:04 marcus no json would be undef too
20:04 sri ye
20:15 marcus I see there's been more discussion about chunked responses on the list ;-)
20:16 sri not much interesting recently on the list
20:17 marcus hmm, I see varnish is serving osx.iusethis.com with chunked encoding
20:17 marcus guess that's because of ESI
21:08 yko joined #mojo
22:03 ltriant joined #mojo
22:57 Alias joined #mojo
23:01 GitHub171 joined #mojo
23:01 GitHub171 mojo: master Sebastian Riedel * 99e645d (11 files in 6 dirs): cleanup - http://bit.ly/bTFHef
23:01 GitHub171 left #mojo
23:11 GitHub154 joined #mojo
23:11 GitHub154 mojo: master Sebastian Riedel * 911158b (4 files in 1 dirs): cleanup - http://bit.ly/ajEmqS
23:11 GitHub154 left #mojo
23:28 GitHub86 joined #mojo
23:28 GitHub86 mojo: master Sebastian Riedel * 1e02455 (3 files in 3 dirs): cleanup - http://bit.ly/doI5MC
23:28 GitHub86 left #mojo

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