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

IRC log for #mojo, 2017-06-28

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

All times shown according to UTC.

Time Nick Message
00:00 tchaves joined #mojo
00:57 tchaves joined #mojo
01:16 bit_shifter joined #mojo
02:16 noganex joined #mojo
02:26 tchaves joined #mojo
02:41 anparker joined #mojo
03:40 bit_shifter Using Slack's events API to receive events in a morbo-powered mojolicious server app.  Their docs say they require an HTTP 200 within 3 seconds or they re-send the event.  This is for a web service, so I in turn send requests off to other web APIs (non-blocking), but in my "post '/'" sub, I have '$c->render(text => 'ok', status => 200);' as my 2nd line (after shifting $c off @_).  I'm frequently getting
03:40 bit_shifter duplicated events.  Could this be my fault still?
03:41 bit_shifter If so, what is the best way to send them an HTTP 200 immediately, then process the request at my leisure?
03:52 Grinnz add a Mojo::IOLoop->next_tick(sub { ... }) to do the rest of the processing so you can return from the action
03:56 bit_shifter I'm not sure I completely understand.  Inside that sub, I use the UA to do the rest of my API calls, etc?  And I do that after my $c->render() call?
03:57 Grinnz that sub will be run by the event loop on the "next tick" so the HTTP request/response will be completely finished first
03:58 Grinnz so it doesn't matter where in the action you do it
03:58 Grinnz it won't be called until after
03:58 Grinnz you can use any variables from the action's scope that you need (known as closing over variables)
04:09 bit_shifter So far so good, thank you!  Why is it that the req/res portion doesn't finish otherwise?  I'd like to understand the problem a little better.
04:13 Grinnz the content is not actually written until the action returns. this is because hooks later in the process might need to alter what's rendered
04:14 Grinnz however you can write content directly, see https://metacpan.org/pod/Mojolicious::Guides::Rendering#Streaming
04:14 Grinnz but i think you dont really need that
04:16 bit_shifter Ah, that makes sense.  Thanks for your help.  I still have a lot to learn...
04:33 zivester joined #mojo
07:03 inokenty-w joined #mojo
07:06 prg joined #mojo
07:11 vinnix_ joined #mojo
07:20 dod joined #mojo
07:23 karjala_ joined #mojo
07:25 trone joined #mojo
08:30 rshadow joined #mojo
10:28 absolut_todd joined #mojo
10:31 FROGGS joined #mojo
10:56 sivoais joined #mojo
11:29 dod joined #mojo
11:30 tchaves joined #mojo
12:15 gizmomathboy joined #mojo
12:15 anon joined #mojo
12:52 dantti_laptop joined #mojo
13:10 zivester joined #mojo
13:11 itaipu joined #mojo
13:29 Pyritic joined #mojo
13:40 PryMar56 joined #mojo
13:40 gregf_ joined #mojo
14:00 cosimo joined #mojo
14:03 Pyritic joined #mojo
14:03 gryphon joined #mojo
14:06 mcsnolte joined #mojo
14:08 cosimo joined #mojo
14:25 itaipu joined #mojo
14:26 bwf joined #mojo
14:38 disputin joined #mojo
14:43 mr_pants joined #mojo
14:45 FROGGS joined #mojo
14:51 ribasushi sri: hey a while ago you did signature benchmarks
14:52 ribasushi 5.26 supposedly had the experimental stuff merged finally, you should re-do that when time permits
14:52 sri ribasushi: i don't even remember doing that
14:55 ribasushi sri: it was a while ago yes, trying to recall what the context was
14:58 ribasushi sri: https://irclog.perlgeek.de/mojo/2015-10-08#i_11341576
14:58 ribasushi is what I was referring to
15:02 sri not a clue what i was benchmarking with
15:16 zivester joined #mojo
15:17 new_student joined #mojo
15:24 schelcj joined #mojo
15:48 schelcj joined #mojo
16:25 sh14 joined #mojo
16:31 kes joined #mojo
16:57 rshadow joined #mojo
17:01 tchaves joined #mojo
17:08 kes joined #mojo
17:47 Pyritic joined #mojo
17:48 itaipu joined #mojo
18:18 FROGGS joined #mojo
18:25 jacobydave joined #mojo
19:39 jabberwok Mojo::DOM::next_node seems to be incredibly slow, at least when I have a 5MB HTML file in the DOM.  Hmm.
19:49 zivester joined #mojo
19:59 dantti_laptop joined #mojo
20:19 tchaves joined #mojo
20:24 sri jabberwok: you're welcome to optimize
20:24 jabberwok $dom->find('a[href$=".tar.gz"]')->each(sub{handle(shift->attr('href'))} takes 1.3 seconds, but ...handle(shift->attr('href')->next_node) takes 20 minutes. Looks like the internal __maybe and _siblings build and destroy multiple trees each time thru the loop
20:25 sri that would surprise me
20:26 jabberwok i shall make a short test, 1 moment
20:27 tchaves joined #mojo
20:27 Grinnz uh, ->attr('href') returns a string
20:28 jabberwok retyped instead of copy/paste.  example coming up
20:32 jabberwok http://www.pastebeest.com/10E
20:33 jabberwok called as » time perl next_node_test.pl « → 5 seconds.  called as » time perl next_node_test.pl 1 « → (still waiting)
20:33 tchaves joined #mojo
20:35 Grinnz any reason you're parsing that instead of 02packages?
20:35 Grinnz https://cpan.metacpan.org/modules/02packages.details.txt
20:36 Grinnz 01modules is missing a lot
20:37 jabberwok cheers Grinnz  that's going to be far simpler
20:37 jabberwok so often one becomes fixated on a problem that one ceases looking for alternatives
20:38 pink_mist to be fair, it would still be interesting to see why his example behaves like it does
20:40 jabberwok pink_mist: with a dom of that size, each call to next_node seems to take about 0.1 sec on a nearly 3GHz machine.  (how long is that in TRS-80 years?)
20:43 Grinnz i see similar performance on my box in 5.26
20:53 stryx` joined #mojo
21:37 good_news_everyon joined #mojo
21:37 good_news_everyon [mojo] kraih pushed 1 new commit to master: https://git.io/vQWo5
21:37 good_news_everyon mojo/master 6e52bd4 Sebastian Riedel: use more references
21:37 good_news_everyon left #mojo
21:39 jabberwok sri++
21:39 sri it doesn't fix the problem
22:22 sri Mojo::DOM::_siblings is pretty slow
22:24 sri think a more efficient way to implement that would be to make an array with all the parent nodes
22:24 sri then look for the index of the current node
22:24 sri and split up the array into two parts, before the current node, and after the current node, with array slices
22:25 disputin joined #mojo
22:25 sri all the appending to arrays with @before/@after is pretty expensive
22:25 sri if anyone wants to give it a try, since i don't have time
22:26 sri think there is a lot of potential to make ->next*/->previous* much faster
22:26 pink_mist wish I had time for it
22:27 sri test coverage is very very good, so it's a perl puzzle anyone could try to solve
22:28 sri prove -l t/mojo/dom.t
22:28 sri if something breaks you did it wrong :)
22:29 pink_mist :P

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