Camelia, the Perl 6 bug

IRC log for #mojo, 2013-04-10

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

All times shown according to UTC.

Time Nick Message
00:05 marty no aether?  dang!  :)   String theory here I come...
00:10 jberger_ now you're talking!
00:12 jberger_ http://www.youtube.com/watch?v=FMSmJCKaaC0
00:22 marty geek humor rocks.  that was pretty cute.
00:31 j3nnn1 joined #mojo
00:31 j3nnn1 left #mojo
00:43 Akron joined #mojo
00:45 shmuel joined #mojo
01:09 d4rkie joined #mojo
01:14 jb360 joined #mojo
01:23 ka2u joined #mojo
01:31 jberger_ joined #mojo
01:33 jberger joined #mojo
01:34 zivester joined #mojo
01:51 bpmedley joined #mojo
01:56 Meiermann joined #mojo
01:58 tempire hmm
01:58 tempire there's a lot of topics to cover in a book.
01:58 tempire just brainstorming everything, the book could be huge.
01:58 * tempire wonders where the limit should be set
01:59 * tempire really doesn't like cover-everything-and-the-kitchen sink books
02:00 anewkirk it really depends on the position and perspective
02:00 anewkirk have you figured that out yet?
02:00 Akron Is the unicorn already taken for o'reilly covers?
02:01 anewkirk is the book more about history and evolution, best practices, tutorial-style, cookbook-style, ....
02:02 * sri would bet on "the definitive guide"
02:02 Akron ... "for dummies"
02:02 sri haha
02:03 sri tempire: the sinatra book might be a good starting point
02:03 tempire http://sinatra-book.gittr.com/ ?
02:04 sri i would start small, maybe 100 - 200 pages max
02:04 sri http://shop.oreilly.com/product/0636920019664.do
02:04 sri ah, they call that kind "Up and Running"
02:05 sri 122 pages and extremely popular
02:06 sri regarding topics, i also liked the tornado book for async stuff http://shop.oreilly.com/product/0636920021292.do
02:07 Akron The good thing with Mojolicious: No model, no headaches regarding how fine-grained you have to explain that.
02:08 tempire and up and running book would have to include some database connectivity
02:09 sri you don't have to cover those in depth though, could just show small examples for dbi, mongodb and redis for example
02:10 sri like the Databases chapter in the tornado book
02:10 Akron Why's that necessary?
02:10 Akron Is it "by definition" of the series?
02:10 sri well, you have to show how to use a model layer at least, doesn't matter what kind
02:10 sri it's not required i bet
02:11 sri could just have fun with redis and make a little pub/sub chat app with websockets :)
02:12 tempire the topics in the tornado book look more interesting than the sinatra book
02:12 sri well, you have to cover the basics though, the tornado book is not so good at that
02:13 sri but who am i telling that.... you made the mojocasts :D
02:13 sri just do the same in book form and you're fine
02:15 Akron Based on the feedback of the mojocasts, the topics were wisely chosen, yeah!
02:17 Akron (or is it "to the mojocasts"?)
02:17 sri yea, you can ignore all the hardcore topics and focus on getting people started, just have fun
02:18 sri in fact
02:18 sri tempire: this should be considered too :) http://shop.oreilly.com/product/9781565924192.do
02:19 sri or maybe not... damn does that cover a broad range of topics
02:19 tempire 472!
02:20 sri maybe the first few chapters ;p
02:24 egopro joined #mojo
02:40 zivester joined #mojo
02:49 preflex_ joined #mojo
03:12 preflex joined #mojo
03:15 good_news_everyone joined #mojo
03:15 good_news_everyone [mojo] kraih pushed 1 new commit to master: http://git.io/og7C0w
03:15 good_news_everyone mojo/master 3022055 Sebastian Riedel: mention that full applications have no need for group blocks
03:15 good_news_everyone left #mojo
03:30 jberger sri: just reread the new Growing doc and I really like it!
03:31 sri you were right :)
03:31 * sri didn't think it would be so simple to change
03:43 jberger :-)
03:56 btyler joined #mojo
04:25 perlite joined #mojo
04:29 good_news_everyone joined #mojo
04:29 good_news_everyone [mojo] kraih pushed 1 new commit to master: http://git.io/74_e-w
04:29 good_news_everyone mojo/master 9aa2b4c Sebastian Riedel: modernized some examples
04:29 good_news_everyone left #mojo
04:31 fhelmber_ joined #mojo
04:33 good_news_everyone joined #mojo
04:33 good_news_everyone [mojo] kraih pushed 1 new commit to master: http://git.io/Owq1UQ
04:33 good_news_everyone mojo/master 6e341ee Sebastian Riedel: recommend verbose testing
04:33 good_news_everyone left #mojo
05:08 ka2u joined #mojo
05:24 shmuel joined #mojo
05:27 ver joined #mojo
05:28 d4rkie joined #mojo
05:32 ver joined #mojo
05:43 basiliscos joined #mojo
05:46 fhelmber_ joined #mojo
06:02 davido joined #mojo
06:10 Mike-PerlRecruiter_ joined #mojo
06:18 dpetrov_ joined #mojo
06:27 Averna joined #mojo
06:41 duncanthrax joined #mojo
06:43 rihegher joined #mojo
06:44 arthas joined #mojo
06:46 arthas_ joined #mojo
06:52 egopro joined #mojo
06:54 powerman joined #mojo
06:55 powerman hi. when running mojo app under plackup (to use fastcgi) it looks like mojo's reactor::ev doesn't work
06:55 powerman and thus I can't use EV::timer etc. in mojo app
06:55 powerman any way around this?
06:59 dod joined #mojo
07:00 dod joined #mojo
07:04 Vandal joined #mojo
07:10 powerman nevermind, using plackup -s FCGI::EV instead of -s FCGI does the trick
07:15 rihegher left #mojo
07:19 dod joined #mojo
07:19 jpn joined #mojo
07:22 rem_lex|pivo joined #mojo
07:24 marcus sri: That's more of a reflection of the fact that I'm in parental leave atm
07:29 suy joined #mojo
07:30 dod joined #mojo
07:52 powerman I'm trying cookbook example with timer/delayed response. Works fine using mojo servers, but doesn't work using plackup.
07:54 powerman I've tried Twiggy. EV works, timers running ok, but looks like $c->render_later; doesn't work with plackup - twiggy doesn't wait until timer runs and render response, it's just immediately return 404 to browser.
07:54 powerman Same with FCGI::EV, so I suppose something broken between mojo<->plackup.
07:58 jzawodn joined #mojo
08:05 powerman looks like mojo return 404 to plackup… looks like bug in mojo
08:10 avkhozov joined #mojo
08:16 avkhozov Hi!
08:16 avkhozov Is it possible to share the template blocks (http://mojolicio.us/perldoc/Mojolicious/G​uides/Rendering#Reusable_template_blocks) between different templates?
08:24 powerman ok, it's not a bug - Mojo::Server::PSGI just doesn't support delayed responses :(
08:29 suy avkhozov: AFAIK, yes. Create them as helpers.
08:30 avkhozov suy: In this case I will need write html code in Perl module. It's not very good.
08:33 shmuel avkhozov: IIRC, mojolicious support layout. maybe that is what you are looking for?
08:33 suy avkhozov: then I think what you want is a reusable template. One template can use other template
08:34 shmuel suy: how do you do that?
08:35 Vandal include
08:37 avkhozov While using layout or include, template just rendering, not import any blocks
08:38 Vandal make block partial template
08:38 Vandal *make block as partial template
08:41 Vandal does any one know why $self->req->url->host always empty?
08:42 suy Vandal: how does it look the whole url?
08:43 Vandal suy, http://site1.com:3000/
08:43 Vandal $self->req->url->base is http://site1.com:3000
08:44 suy mmm, then I dunno :(
08:47 alnewkirk joined #mojo
08:49 Vandal I get it
08:49 Vandal it should be $self->req->url->base->host
08:49 avkhozov I want to write something like this (include doesn't work): https://gist.github.com/avkhozov/5352958
08:49 Vandal very originally
08:51 Vandal avkhozov, ho to change it?
08:52 Vandal *how
08:56 avkhozov I think, in no way.
08:58 Vandal ok
08:58 Vandal avkhozov, why not like this? http://paste.org.ru:2/?XNKDNO
09:01 avkhozov Yes, this work, thanks. But in this case I have to create many files for many little blocks.
09:02 avkhozov Oh no, sorry.
09:02 avkhozov This is what I need, very thanks.
09:02 Vandal you can use hash
09:02 Vandal and call them by keys
09:07 nicolaas joined #mojo
09:29 Lysbertus joined #mojo
09:30 Lysbertus Hi!
09:31 Lysbertus I'm writing a plugin but I can't seem to find a way to get the request_url my register method
09:32 Lysbertus I know you can do $self->req …. in mojolicous::controller
09:32 Lysbertus But what with Mojo::Plugin?
09:50 mrphilov joined #mojo
10:08 KindOne joined #mojo
10:17 avkhozov Lysbertus, in register method you can't access to any controllers
10:21 Lysbertus @avkhozov I am writing a plugin to email me log message
10:21 Lysbertus and I want to email the current request url as well
10:21 Lysbertus is there maybe a way to get the request url from Mojo::Exception?
10:39 Britzel joined #mojo
10:50 KindOne joined #mojo
10:51 bc547 joined #mojo
11:00 StylusEater left #mojo
11:28 d4rkie joined #mojo
11:42 mire joined #mojo
11:53 dod joined #mojo
11:55 dod joined #mojo
12:03 ryozi joined #mojo
12:06 Kripton joined #mojo
12:07 bowtie joined #mojo
12:09 btyler joined #mojo
12:11 fayland joined #mojo
12:11 fayland hi guys
12:11 fayland http://pastebin.com/yubYeJkT
12:12 fayland is there any reason why hypnotoad bin/www.pl
12:12 fayland didn't make a deamon or script running?
12:12 fayland hypnotoad -f bin/www.pl  makes the same output
12:15 fayland seems the same with the issue here: http://stackoverflow.com/questions/11327639​/mojolicious-cant-start-app-with-hypnotoad
12:23 Vandal joined #mojo
12:27 Zx3 joined #mojo
12:34 Lysbertus left #mojo
12:38 fayland sorry, leave it, actually it works
12:39 Adura joined #mojo
12:42 moltar joined #mojo
12:48 asarch joined #mojo
12:53 mire joined #mojo
13:10 bluescreen joined #mojo
13:25 btyler joined #mojo
13:28 sri \o\
13:28 sri /o/
13:33 suy o/
13:43 maxhq joined #mojo
14:02 ka2u joined #mojo
14:13 fayland left #mojo
14:14 inokenty joined #mojo
14:18 btyler doc question: just showed some non-perl coworkers mojo's home page, and their first reaction was "gah why doesn't the ua just use css selectors?" I know it'd be complicating the message to show Mojo::DOM in the same spot, but I wanted to share that impression
14:23 bluescreen_ joined #mojo
14:24 zivester joined #mojo
14:25 sh3 joined #mojo
14:28 gryphon joined #mojo
14:29 sri btyler: what?
14:31 btyler too terse, heh. was chatting frameworks with coworkers (php/node/python webdevs), and linked them to mojo. the thing that stuck out at them was the user agent 'scrape a title from another site' example, and the immediate reaction was "jeez, why doesn't that use css selectors"
14:32 sri to illustrate that there's more than just selectors
14:33 btyler yeah, I totally get it, and probably showing mojo::DOM in the same space would be too much. it was just an idle data point for how some of the front-page code struck some folks
14:34 sri umm, it *is* showing Mojo::DOM
14:34 sri tree walking is just another part of it
14:34 btyler oh heh, right. sorry, short circuiting in the morning
14:35 sri did your cow orkers just skipped the feature list?
14:35 sri s/ed//
14:37 btyler yeah I imagine they did. not saying this is cause for any sort of change, but I imagine a lot of people who encounter mojo are already into the idea of using perl for webdev. these guys weren't, so I figured I'd share that initial impression
14:38 Mikey the Perl community, or why I'd take a dozen devs that RTFM over a million devs who don't.
14:41 sri is $self->ua->get($url)->res->dom->at('title')->text a better example than $self->ua->get($url)->res->d​om->html->head->title->text
14:41 sri ?
14:48 tadamo joined #mojo
14:49 tadamo joined #mojo
14:49 btyler +1
14:49 btyler I think that shows more off\
14:51 dotan joined #mojo
14:52 good_news_everyone joined #mojo
14:52 good_news_everyone [mojo] kraih pushed 1 new commit to master: http://git.io/1kWx9A
14:52 good_news_everyone mojo/master 08b69fc Sebastian Riedel: use selector in example
14:52 good_news_everyone left #mojo
14:52 * sri shrugs
14:58 sri that used to be the old example before we added tree walking to Mojo::DOM
14:58 sri i thought the new one showed off more
15:05 powerman sri: any chance to see full compatibility with PSGI in near future?
15:06 powerman or DIY is only way to go? :)
15:15 suy powerman: what is incompatible now?
15:19 powerman suy: no support for delayed responses
15:20 powerman what's the fun using event-based framework if we can't use events while handling requests?
15:24 sh4 joined #mojo
15:26 mire joined #mojo
15:29 btyler joined #mojo
16:03 xaka joined #mojo
16:05 _xaka_ joined #mojo
16:08 Kripton joined #mojo
16:10 dpetrov_ joined #mojo
16:11 rihegher joined #mojo
16:11 denisboyun joined #mojo
16:13 sri powerman: once delayed responses are properly supported in the PSGI spec we'll support them
16:14 sri but many advanced features will always require the built-in server
16:16 basiliscos joined #mojo
16:17 powerman1 joined #mojo
16:18 powerman1 I've hear pidgin's sound of incoming message and my Xorg hang. So if anyone replied to me minute ago - please resend.
16:19 sri see topic for channel log
16:20 powerman1 sri: thanks. but what you mean as "properly supported in the PSGI spec"? isn't it already fine?
16:20 sri current version is just plain broken, there is no way to know if the client closed the connection
16:20 sri the solution is still being discussed
16:24 powerman1 exception or return error from $writer->write()?
16:24 sri if you don't care about such details, you're of course welcome to fork Mojo::Server::PSGI and add whatever features you like
16:25 powerman1 I care. Actually, it's a shame I missed that. :(
16:25 sri powerman1: i have no influence on the design of PSGI, so this is not the place to discuss it
16:25 powerman1 ok, thanks
16:26 sri that said, making the return value of $writer->write() special would be silly
16:26 sri in an event loop all ->write() should do is buffering the data, and then wait until the socket is writable asynchronously
16:27 sri there needs to be a separate callback
16:27 powerman1 sure. it can't return error on actual failed write in most cases, but it can return error on next write immediately
16:27 sri that's broken design
16:28 powerman1 yep. but that's how write(2) works in posix.
16:29 sri i don't see the relation
16:30 powerman1 it's just good enough and well known and intuitively expected behavior for most people
16:31 powerman1 psgi designed to work without event loops, so using async callback here won't look nice. in blocking code it become something like:
16:31 powerman1 my $err; $writer->write($data, sub { $err = shift });
16:31 sri i disagree, but neither is part of the spec anyway
16:31 sri delayed is already ugly in psgi
16:32 sri btw. last i looked the discussion was in favor of the callback solution
16:33 powerman1 it ugly everywhere when event loop and callbacks are in game. only way to do this right is use cheap threads like in OS Inferno/Plan9 or Go. :(
16:33 sri haha
16:34 sri completely agree there
16:34 sri but it's not gonna happen anytime soon
16:34 powerman1 yep :(
16:34 powerman1 actually I'm using Inferno in production. a lot of fun and clean code
16:36 powerman1 maybe I'll try to implement something like micro-mojo for inferno later
16:36 sri while i like goroutines, the way they map to real threads still seems a bit weird to me, think i'd rather have just real threads instead of that green/real hybrid
16:38 sri will be interesting to try threads with rakudo and moe on the jvm
16:46 sri powerman1: which psgi server were you planning to use?
16:46 powerman1 FCGI::EV
16:47 powerman1 I wanna run fastcgi daemon myself and use unix socket to connect to web server, not start some automatically by apache.
16:47 sri i see, if you control the server then a Mojo::Server::PSGI fork could be a good solution for you
16:49 sri (since you can just make up your own way to handle connection close)
16:49 sri might even be useful for us in the future once we want to officially support delayed and streaming
16:50 powerman1 yeah. maybe later, for now I just switch to nginx+hypnotoad, for current project it's acceptable.
16:53 sri https://github.com/plack/psgi-specs/issues/27 # this was part of the discussion, most happened in #plack though
16:53 sri powerman1: oh i just remembered another problem with return values
16:54 sri you have no indication for how many bytes have been written
16:54 cfedde joined #mojo
16:55 sri so if the server can't write for some time and you keep streaming shit the buffer will keep growing
16:55 sri huge async problem
16:55 * sri likes to use drain events for that
16:57 sri those are all solved problems in mojolicious, that's why supporting delayed/streaming in the PSGI binding would be so frustrating
16:59 powerman1 in IO::Stream I decide to let user just check output buffer when he write(append) to it and handle overflow in any way he likes
17:00 powerman1 because user usually will generate data to write anyway, that's rarely depend on how fast data is actually sent
17:00 sri disagree again :)
17:00 powerman1 so, to use drain callback he should keep generated data somewhere anyway, that's same output buffer just in another place
17:01 sri if you're streaming data from a backend service you might want to throttle throughput, stop reading from the backend until a drain event happens again
17:01 jhthorsen joined #mojo
17:01 * sri is very concerned about backend services streaming data through mojolicious apps
17:02 sri (real-time web stuff... comet, websockets)
17:02 powerman1 in all projects I've seen before data generation wasn't depend on user. we've event stream, events generated in other places, and only we can do is either send them to client or close connection to client is it read slower than we get new data for him
17:04 sri simple example would be a MongoDB gridfs backend, i can always read chunks slower if the server can't send websocket messages fast enough
17:05 cfedde how do I package up a file so that Mojo::UserAgent can post it properly?
17:05 powerman1 even if we keep all events in unlimited db, and can sent user as much events as he ready to read, when he read slower than new events added, he will get more and more old and non-actual data with every minute, which usual doesn't make any sense
17:07 sri my example is not a message bus, but a backend with a finite amount of data
17:08 * sri follows the node.js design there mostly
17:08 powerman1 in such cases I'm usually use "sent" event (output buffer empty after last syswrite) to fetch more data and sent to user. sort of drain cb without extra buffering
17:09 sri cfedde: http://mojolicio.us/perldoc/Mojolicio​us/Guides/Cookbook#Large_file_upload
17:10 cfedde sri: awesome!
17:11 powerman1 but, again, in most, if not all projects where I've seen data streaming it wasn't finite amount of data, it was stream of events. not sure is this specific to my experience or more general…
17:12 sri in my experience there are many cases where you can throttle the stream
17:13 sri it starts with simple cases, like the file upload example i linked to above
17:14 sri we could pump gigabytes blindly into the event loop, or wait for drain events and do it smoothly
17:15 sri if we do it blind, maybe it will blow up, maybe not, if we do it smoothly we always know what's going on
17:15 sh4 joined #mojo
17:19 powerman1 of course. streaming large files differs a lot from streaming endless events
17:19 sri that's my point, PSGI needs a way to do that
17:20 powerman1 sure
17:23 powerman1 btw, it may make sense for mojo to detect attempt to use delayed response in environment which doesn't support mojo's event loop (like some psgi configurations) and die with nice error message. should help beginners.
17:24 sh4 joined #mojo
17:25 sri same for the CGI backend
17:25 powerman1 why? you can start event loop in cgi mode and shutdown it after sending response
17:26 sri it works just the same as the PSGI backend now
17:27 powerman1 cgi may use non-blocking i/o to fetch few urls in parallel before sending response
17:28 sri we don't support that
17:29 sri i suppose making Mojo::Server::CGI use the event loop could be fun
17:29 sri but not sure i'm keen on writing all those unit tests ;p
17:29 powerman1 :)
17:31 powerman1 probably you can just reuse most of tests for non-cgi backends - all which doesn't make parallel requests should just work, and others should be removed because cgi won't support handling parallel requests anyway
17:35 jhthorsen_ left #mojo
17:43 sh3 joined #mojo
18:07 beyondcreed joined #mojo
18:11 Mike-PerlRecruiter_ joined #mojo
18:17 labrown joined #mojo
18:29 sh3 joined #mojo
18:30 psimanx1 joined #mojo
18:35 mire joined #mojo
19:02 powerman1 left #mojo
19:07 rihegher left #mojo
19:21 komodo joined #mojo
19:27 kthakore hallo
19:27 Akron joined #mojo
19:27 kthakore I am using the newest mojolicious. When I send large data to a websocket it does a get to '/' and dies. Data string is 681906
19:35 kthakore I am getting  431 Request Header Fields Too Large  how do I make this bigger?
19:35 kthakore or should I split the string up?
19:42 psimanx1 kthakore: http://mojolicio.us/perldoc/Mojo/Tran​saction/WebSocket#max_websocket_size
19:43 sri sounds more like the websocket is never established, maybe invalid handshake or so
19:43 kthakore THANKS!
19:44 kthakore sri yeah the error message SUCKED
19:44 kthakore where can I write a better error message for this in the codez?
19:44 kthakore I spent 6 hrs debugging this
19:45 sri so what was the error?
19:45 kthakore here?
19:45 kthakore https://github.com/kraih/mojo/blob/maste​r/lib/Mojo/Transaction/WebSocket.pm#L163
19:46 kthakore it just did this: http://paste.scsys.co.uk/240894
19:46 kthakore no errror message what so ever
19:47 sri i think you're misinterpreting something, because what you said makes no sense
19:47 kthakore sri: at line 163 may I put in a error warn or whatever '431 too large change your max_websocket_size' ?
19:48 sri no
19:48 kthakore ok
19:48 kthakore so ... what can I articulate so I make more sense?
19:48 kthakore I am lost too
19:48 kthakore on how to explain
19:49 kthakore debuggin this thing was hard because the debug output in the application log didn't indicate a 431 Request Header Fields too Large
19:49 sri to me it seems like you've not actually tracked down anything, you've mixed up errors from completely different parts of the framework
19:49 kthakore but rather just rerouted to '/
19:49 kthakore '
19:50 sri WebSocket.pm is for established WebSocket connections *after* the handshake... 431 is an HTTP error
19:51 sri it's not even the right protocol
19:52 asarch joined #mojo
19:52 kthakore oh shit ok
19:53 kthakore sorry then. Thanks for explaining that to me :)
19:53 kthakore what error would be viable for the length of the message being too long
19:54 kthakore sri: or perhaps a warning?
19:54 sri hmm, we've had a bit too many wild assumptions recently, i'm gonna insist on test cases again from now on
19:54 kthakore sorry I don't understand. Do you want a test case?
19:55 kthakore I can cobble a mojo lite in an issue report? But I still think I am missing something as to articulate the real problem
19:58 * sri has to run now, maybe someone else will be able to help you
20:01 kthakore sri: thansk for your time. Sorry about my inablity to understand what to do.
20:02 Mikey you should figure out what's going on, you're doing good work.  don't feel disheartened.
20:02 sri quick note for the next one, i still believe it's something silly, like wrong protocol version or so and no connection was ever established
20:13 kthakore I can't seem to figure out where the handshake is done in the code
20:32 kthakore derp
20:32 kthakore I mean
20:32 kthakore where the error codes are generated in the handshake
20:32 kthakore eeeeh I give up gotta get back to hacking the app
20:33 nelio joined #mojo
21:04 basiliscos1 joined #mojo
21:05 tempire dernit
21:09 sri kthakore: ok, if you have a test case i could take a look now
21:12 good_news_everyone joined #mojo
21:12 good_news_everyone [mojo] kraih pushed 2 new commits to master: http://git.io/myBY9A
21:12 good_news_everyone mojo/master c6011ce Sebastian Riedel: test tweaks
21:12 good_news_everyone mojo/master 98a9919 Sebastian Riedel: a few more 64bit WebSocket tests
21:12 good_news_everyone left #mojo
21:15 kthakore sri: okie making it
21:27 btyler joined #mojo
21:37 jpn joined #mojo
21:38 basiliscos joined #mojo
21:40 lukep joined #mojo
21:56 cfedde joined #mojo
22:03 buu Where can I find documentation on what req->body and req->body->json return?
22:04 kthakore sri:
22:04 kthakore ~
22:04 kthakore oops
22:04 kthakore sri:  http://paste.scsys.co.uk/240916
22:04 buu Oh
22:04 buu It's req->json
22:04 kthakore ok so the problem is some time it does [error] softrware caused abort
22:05 kthakore and send just a bit more it is 431
22:05 kthakore and other times it just doesn't say anything
22:05 kthakore but all three instances kill the websocket
22:12 ka2u joined #mojo
22:13 labrown joined #mojo
22:15 kthakore hope that helps sri or at least doesn't come off stupid
22:16 moltar joined #mojo
22:27 good_news_everyone joined #mojo
22:27 good_news_everyone [mojo] kraih pushed 1 new commit to master: http://git.io/4ktjXg
22:27 good_news_everyone mojo/master c5eb1a0 Sebastian Riedel: fixed a few small timing bugs in Mojo::Server::Daemon
22:27 good_news_everyone left #mojo
22:28 sri kthakore: i fixed the part that made it look weird
22:28 sri harmless though
22:29 cfedde joined #mojo
22:29 kthakore sri:  so I halped?
22:30 sri yes
22:30 kthakore \yay/
22:30 sri \o/
22:32 sri a websocket connection gets kept open by the event loop to write the close frame, the browser just keeps writing, we destroyed the transactions already though, so the daemon thought it was keep alive http requests that looks like garbage following the websocket connection
22:32 sri s/s//
22:32 kthakore ahhhh I get it NO!
22:32 kthakore now!
22:33 kthakore so because the timeout happens mid write?
22:33 sri no timeout, size limit
22:33 kthakore oh right
22:33 kthakore sorry
22:33 sri yes, and the daemon was not defensive enough
22:33 kthakore can I run my snippet against the git repo without isntall it?
22:33 kthakore gotcha
22:34 sri sure, i ran it with perl -Irepo/mojo/lib
22:34 kthakore kk
22:34 kthakore awesomeo
22:34 kthakore sans the cartman
22:37 sri at some point i would like to support close reasons for WebSockets, no clue how it should look though http://tools.ietf.org/html/rfc6455#section-7.4
22:37 sri until then, you'll only get a finish event
22:37 kthakore okie dokie
22:37 sri maybe a todo task for a volunteer
22:38 kthakore if you can make a dummy version of the issue I could give it a shot
22:38 kthakore I just ... donno rfc's and scary stuff like that
22:38 sri i have no idea for the design yet
22:38 sri so you would have to "design" the api
22:44 sri https://github.com/kraih/mojo/issues/476
22:44 kthakore oh ok
22:44 kthakore yeah that is out of my time/tuits/pool
22:49 freman joined #mojo
22:49 freman So, I've had a thought
22:50 freman I want to combine the Mojo IOLoop with curses::ui - which appears to have it's own loop
22:50 freman is that a simple task?
22:52 kthakore freman: how simple do you mean?
22:53 freman well, merging the two loops
22:53 freman I ultimately want mojo in control...
22:53 kthakore link to the curses::ui loop?
22:54 freman http://search.cpan.org/~mdxi/Curses-​UI-0.9609/lib/Curses/UI.pm#mainloop
22:55 freman C::UI mainloop seems simple enough... force focus, draw, update, do_one_event forever
22:55 kthakore doesn't seem like a big deal. Give it a shot and let us know! :)
22:56 sri marcus, jberger, tempire, crab: maybe something for one of you, in case you want to get more familiar with the WebSocket protocol :) https://github.com/kraih/mojo/issues/476
23:07 sri could be a pretty good summer of code task, it's rather simple if you know perl and websockets
23:17 hrupp_ joined #mojo
23:43 zivester joined #mojo
23:55 ka2u joined #mojo

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