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

IRC log for #mojo, 2016-03-14

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

All times shown according to UTC.

Time Nick Message
01:58 cpan_mojo Mojo-Weixin-1.0.6 by SJDY https://metacpan.org/release/SJDY/Mojo-Weixin-1.0.6
02:04 cpan_mojo Mojo-Webqq-1.7.4 by SJDY https://metacpan.org/release/SJDY/Mojo-Webqq-1.7.4
02:31 punter joined #mojo
02:38 punter Is it possible to somehow make render(json => ...) faster, by replacing Mojo::JSON with Cpanel::JSON::XS ?
02:39 punter or will the speed increase be miniscule?
02:39 Grinnz https://metacpan.org/pod/Mojo::JSON::MaybeXS
02:40 punter Thanks
02:40 punter Grinnz: That module does what I want?
02:40 punter ok!
02:55 mcsnolte joined #mojo
02:59 punter Grinnz: I can't make 'render' to work with Mojo::JSON::MaybeXS (see below)
02:59 punter http://paste.scsys.co.uk/507712?hl=on&submit=Format+it!
02:59 Grinnz looks fine to me?
02:59 punter ok I'll check again (sorry)
03:00 punter yes, it's fine
03:03 punter i'm slightly confused though because of this in Cpanel::JSON::XS's documentation:
03:03 punter native boolean mapping of yes and no to true and false, as in YAML::XS. In perl !0 is yes, !1 is no. The JSON value true maps to 1, false maps to 0. [#39]
03:04 punter https://metacpan.org/pod/Cpanel::JSON::XS
03:04 punter that's under the Changes to JSON::XS section
03:04 punter Doesn't that mean that !0 should encode to true?
03:04 Grinnz not sure what reini was trying to say there. no, it doesn't.
03:05 Grinnz if you want true, use Mojo::JSON::true or \1
03:05 punter ok! thanks
03:09 meredith hm, so the difference i see there is when i do things like {foo => !0} or {foo => (1==1)} the output is q[{"foo":1}], whereas JSON::XS makes that value a string "1"
03:09 meredith true/false don't do anything i'm not expecting from all the other libraries, so i'm not sure about that bit
03:10 Grinnz because JSON::XS doesn't have the intelligent numeric detection that Cpanel::JSON::XS added
03:14 asarch joined #mojo
03:39 noganex joined #mojo
04:55 zivester joined #mojo
05:09 irqq joined #mojo
05:13 inokenty-w joined #mojo
06:51 Grinnz_ joined #mojo
07:03 Grinnz joined #mojo
07:15 batman but... why be correct, if you can be fast..?
07:15 batman ;)
07:18 haarg it's not really a case of being correct or not
07:18 haarg just "most useful"
07:19 dod joined #mojo
07:24 dod joined #mojo
07:27 batman i would argue that it's very important to have the types correct in a typed "language"
07:28 batman there's a lot of languages where "42" != 42
07:28 haarg except perl is not typed that way
07:29 haarg "1" is just as accurate of a representation as 1
07:39 McA joined #mojo
07:44 osfabibisi joined #mojo
07:45 kes joined #mojo
08:07 Vandal joined #mojo
08:11 salva joined #mojo
08:17 batman sri, jberger: sorry for deleting the comment on github! it had a big bug which made it invalid :(
08:17 batman here is the comment if anyone would like to see: https://ssl.thorsen.pm/paste/152fc5156656
08:18 batman the "bug" is that the first "-d" check use "_", but i don't think the wanted method can rely on "_" being the actual file
08:18 batman don't think == it would just be too fragile i think
08:19 batman chdir() is very slow, but i'm most surprised about how slow basename() is...
08:34 AndrewIsh joined #mojo
09:03 arthas joined #mojo
09:30 salva joined #mojo
09:35 ichi joined #mojo
10:21 trone joined #mojo
10:22 irqq joined #mojo
10:57 melo joined #mojo
10:59 jkramer left #mojo
11:55 kaare_ joined #mojo
12:11 sri batman: you're making the same mistake again, you're not thinking it through ;p
12:11 batman sri: if i was, i would've just made the commit in master
12:11 sri are dotfiles really so common you need to perform that check first? no!
12:11 sri in fact, dotfiles are super uncommon, so it will always be faster if you perform that check last
12:12 batman sri: so what you're saying is that /^\./ is _slower_ than stat() ?
12:12 batman ah. now i get it.
12:13 sri how was the saying? the fastest code is the one you don't run
12:14 batman :)
12:14 sri if you have 5000 files you'd dotfile check 5000 files and then stat() maybe 4999, it's much cheaper to stat() 5000 files and dotfile check that one that changed
12:14 batman yeah, that's why i said "now i get it" :)
12:15 sri having Morbo not use Mojo::Util::files would be a bit of a bummer though
12:15 sri that function exists because of it
12:15 sri just so the functionality can be shared by Morbo and Mojo::Home
12:17 batman i'm not sure if it's worth sharing the code... i wonder if find() should be wrapped inside eval {} or do {} and and make it die when it finds a file that is changed
12:17 batman i don't see why morbo has to find _all_ the changed files
12:18 sri batman: you've really not been paying attention -.-
12:19 sri it used to stop once it found a changed file, but then you're in big trouble if many files change at once, because your morbo will restart again and again
12:20 batman oh. that's true... that's what the PR was all about :/
12:20 sri we definitely need to keep checking all, an optimization i could imagine would be the use of inotify and friends
12:21 sri although, i imagine most users develop on windows and os x
12:23 sri hehe, i bet this looked a lot easier when you started
12:23 batman https://metacpan.org/pod/Mac::FSEvents ?
12:24 batman well... when i started i only had one goal: get back the change in the commit i've pointed to
12:24 batman never knew there was a grand plan behind it all.
12:24 sri there's always a grand plan
12:24 batman :D
12:25 sri i think your original patch with the dotfile check moved down might be the best option
12:26 sri your File::Find version also seems dangerous
12:27 sri i remember countless bug reports when Mojo::Home didn't use no_chdir => 1
12:28 sri and i don't think you should overestimate the cost of stat()
12:28 sri most file systems cache metadata pretty aggressively
12:28 denny joined #mojo
12:30 sri i think there is value in sharing this stuff though Mojo::Util::files
12:31 sri much more opportunity to find edge cases
12:31 sri like the no_chdir stuff
12:32 batman sri: https://ssl.thorsen.pm/paste/76f72063bc72
12:33 nic My dream is a specialised morbo driven by inotify, which when it completes its restart then triggers a browser refresh
12:33 sri wasn't there a plugin for browser refresh? it's so easy to do
12:33 nic oh, that's sounds _very_ interesting
12:34 nic Is this hooking into browser development mode?
12:34 sri i remember talking about how to do it, and like 30 mins later batman made it :)
12:34 nic awesome
12:34 nic batman, where have you hidden the treasure?
12:34 batman nic: planning a browser refresh extension for AssetPack. i kicked it out because it was such an ugly hack :(
12:35 sri sounds like it should be a separate plugin
12:35 nic some people make careers out of ugly hacks :)
12:35 batman nic: https://github.com/jhthorsen/mojolicious-plugin-assetpack/commit/77ef8c53ba8f1ad45af8d1f4a9372727ebe9c795
12:35 sri just standalone Mojolicious::Plugin::BrowserRefresh or so
12:36 batman sri: the idea with the next version for AssetPack is that it shouldn't require morbo to restart when an asset is changed. just reload the asset.
12:36 nic batman, sri: I love you even more than I did yesterday!
12:36 batman haha
12:37 sri then i think there should be two versions ;p
12:37 sri one standalone and one asset pack specific
12:37 batman sri: indeed
12:37 sri plugin 'BrowserRefresh';
12:37 sri %= browser_refresh
12:37 batman sri: the patch above is 1.33274 vs 1.821 for me. n=50 and 5134 files
12:39 sri batman: i think that needs a vote, and if it passes Mojo::Util::files should be deprecated
12:39 sri since the code can just be moved to Mojo::Home again
12:40 sri if Morbo does its own thing there is no need for Mojo::Util::files to exist
12:40 batman sri: but... if a directory matches /^\./, should all the files in that directory be skipped?
12:41 batman sri: not too eager for a vote yet. i would be very surprised if i don't mess up again :(
12:41 sri dunno, that's up for debate
12:41 sri also, nobody has yet proposed to add the dotfile skipping stuff to Mojo::Util::files
12:42 sri perhaps with a boolean flag
12:42 sri Mojo::Util::files('/home/sri', $skip_dotfiles)
12:42 batman sri: i would very much like if Mojo::Home->list_files would return /every/ file
12:42 sri doesn't mean you can't have a flag
12:43 batman i tried to make a patch with $skip_dotfiles, but then i started thinking about /what if.../ and i then i didn't want it anymore
12:43 batman i would much rather have a flexible filter
12:44 sri jberger: looks like there's too many options, you might have to dictate a solution ;p
12:44 batman results in a mess if we suddenly want to skip more files in morbo, or add a --skip-files "#|swp" option
12:45 * batman adds https://ssl.thorsen.pm/paste/76f72063bc72 to the github issue
12:50 jberger I think having a files utility is good for the toolkit
12:50 jberger and if batman's patch results in a deprecation, I'd rather see if a flag would be possible
12:50 batman jberger: so you disagree with my arguments for why morbo code != mojo-home code?
12:51 jberger "doesn't mean you can't have a flag"
12:51 jberger that also doesn't prevent a more flexible filter
12:52 jberger a future api could take a code reference for a flexible filter or a true value for the default "no dotfiles filter"
12:52 jberger not saying that would need to be in the first implementation, but the api isn't blocked
12:53 batman i think it gets messy. what would the code receive? $File::Find::name? is that often the case you want to filter on?
12:53 ramortegui joined #mojo
12:53 * jberger is getting ready to go to work
12:53 batman so... i've written the patch and threw it away. that's why i'm against it :)
12:54 batman when that is said... there might be a perfectly fine way to implement it (of course)
12:57 batman https://metacpan.org/pod/Filesys::Notify::Simple
12:57 batman ^^so what good does files() do if we decide to use _something_ like that?
12:57 sri batman: to be fair, that would change the whole Morbo api ;p
12:58 sri no more ->modified_files i imagine
12:58 sri since it's push instead of pull
12:58 batman indeed. just trying to make an argument for why i think morbo is one thing and mojo-home is something else
12:59 sri not yet though
13:00 batman it does get to remove files() as time pass along
13:01 batman oops. left some parts out :/
13:01 batman it gets /harder/ to remove files() as time pass along
13:02 neilhwatson joined #mojo
13:04 asarch joined #mojo
13:09 sri that is true i guess
13:10 sri we should all think about where we want to take Morbo in the next few years
13:11 sri if fsevents/inotify is on the roadmap
13:11 sri jberger: your first strategic decision to dictate :)
13:11 pink_mist a Mojolicious::Plugin:: for that might be awesome
13:12 batman pink_mist: the issue is that a plugin can't change the server
13:12 batman it can only change the app
13:12 pink_mist ah
13:12 sri it would have to be a morbo fork
13:12 sri which is not actually that radical... morbo is like 50 lines of code
13:13 batman i don't think files() is a good fit for Mojo::Util. I think it's too similar to find(), so in most cases i need some sort of filter method.
13:13 batman like i think morbo needs
13:15 sri filtering for dotfiles ie meh though
13:16 batman "ie meh" ?
13:16 sri it's not expensive at all if done after stat()
13:16 pink_mist s/e/s/, batman
13:16 batman inside files() or in morbo?
13:16 sri ok, what i'm trying to say is that you have two proposals here
13:17 sri one is to just filter out dotfiles, which is super easy and cheap to add in Morbo.pm
13:17 batman pink_mist: i was curious if it meant "not a problem" or "not something i like" :)
13:17 sri the second to make Morbo.pm a little faster by not using Mojo::Util::files
13:18 pink_mist imo that should be a separate issue
13:18 sri agreed
13:21 nic Just to throw a bonkers idea on the table... How about morbo-plugins?  Is there a practical way to have morbo extensible via site-chosen plugins?
13:22 CandyAngel nic: That would actually be really useful, if it allowed you to, say, throttle restarts
13:24 sri and that's a third issue :)
13:25 jberger I think a Filesys::Notify::Simple fork of morbo would be really cool
13:25 jberger But it wouldn't be in mojo core
13:25 ashimema +1 for a Notify fork :)
13:26 jberger I really have to leave for work soon but I'll be back on in an hour
13:27 sri on my laptop cpu usage of morbo is about 0.9% when watching 200 files, i'm kinda ok with that
13:29 jberger My current thinking would be to accept batman's patch and deprecate the utils function
13:29 sri at 4000 files it gets a little uncomfortable with 15%
13:29 jberger The argument that File::Find is probably usually a better choice is sticking in my head
13:30 jberger Actually i usually use File::Next
13:30 jberger And plenty of people use Path::Tiny which i believe has a file iterator
13:32 sri batman: your patch is a bit sloppy btw. re formatting and alphabetical ordering
13:32 sri and "no warnings;" without category
13:34 sri also not importing find()
13:35 sri what "Can't stat" warnings anyway?
13:36 sri there's no new tests, what changed?
13:38 batman sri: the tests are in the patch above. just made it shorter since it's in a comment
13:38 batman "can't stat" is when you're watching something that doesn't exist
13:39 batman but... it would be very easy if we just do grep { -e } @{$self->watch};
13:55 mcsnolte joined #mojo
14:00 aborazmeh joined #mojo
14:24 jberger I had had a thought: https://metacpan.org/pod/EV#STAT-WATCHERS---did-the-file-attributes-just-change
14:25 jberger but then it even says: "This watcher type is not meant for massive numbers of stat watchers, as even with OS-supported change notifications, this can be resource-intensive."
14:32 jberger just reading the doc for https://metacpan.org/pod/Filesys::Notify::Simple now
14:32 jberger it only has a blocking interface
14:32 jberger sigh
14:48 batman btw: i'm not saying we should use Filesys::Notify::Simple. just throwing it out there so we can maybe get som ideas
14:48 batman :)
14:49 jberger yeah, I know, I was actually kinda excited about the prospect of a fork of Morbo that uses it, but I don't think that will be possible with that API
14:58 romel hey guys. is there any proper mojo ways to continuously poll some remote url with mojo::useragent or defining a recrusive function and call it inside ua's callback is a proper solution?
15:02 batman romel: do you want to start polling at once or with a delay?
15:03 batman there's no such built in function, but it shouldn't be too hard to make
15:03 nic beware recursive functions in perl
15:04 batman nic: i think a non-blocking function that calls it self would still be considered recursion..?
15:04 batman i'm not a programmer, so i really don't know these things :/
15:05 romel batman: in fact it should be an analogy of while (1) { some_blocking_sub(timeout => 30); } ua requests api url with a "long polling" and then restarts once data arrives the current connection closes
15:07 nic 'conceptually' recursive is fine, for example a method that adds itself to a queue
15:08 jberger we just had this discussion not so long ago
15:08 * jberger searches
15:09 jberger http://irclog.perlgeek.de/mojo/2016-02-12#i_12033047
15:10 romel i just wondered if i could solve it using mojo::ioloop capabilities as much as possible. "watch" for ua execution somehow and restart it when needed
15:10 jberger and sri had the right term, trampolining
15:10 jberger anyway, in that chat you can see my example from Mojo::FriendFeed
15:10 jberger its almost exactly what you want in this case
15:11 romel yea, i'm reading already. thank you very much
15:11 jberger np
15:12 batman jberger++
15:31 romel jberger: is it ok to just use sub poll { $self->poll; } instead of __SUB__ or it turns on tail recursion?
15:32 jberger romel: I'd say you'd want to try to avoid any pattern that has infinite recursion
15:32 jberger the idea of trampolining is that the stack doesn't grow
15:33 jberger now, if poll were nonblocking then its ok, though of course the way you have shown it would just setup an infinite number of polls in the ioloop
15:34 jberger it has to wait until the callback to call itself
15:34 jberger see for example https://github.com/jberger/Mojo-ACME/blob/master/lib/Mojo/ACME.pm#L44-L60
15:35 jberger note that the trampoline is in the third step, but the third step doesn't execute if the second step returns early
15:35 jberger that's a "poll until this condition" pattern
15:35 romel that's what working mockup looks like http://paste.scsys.co.uk/507750
15:36 jberger are you trying to end the recursion when you call the callback or is it infinite?
15:36 romel yes, it's infinite
15:36 jberger I guess infinite now that I read it
15:36 jberger yeah, that's fine
15:36 jberger well no
15:37 jberger you have to pass the callback to the second call of poll
15:38 batman https://ssl.thorsen.pm/paste/301c12f3f607 <-- here is my idea
15:39 jacoby joined #mojo
15:40 batman romel, jberger ^^
15:40 jberger batman: when I first wrote that Mojo::ACME code I did it by modifying "remaining"
15:40 jberger it got ugly quickly
15:40 jberger let me see if I can find the change
15:42 romel batman: looks nice to me. thanks
15:43 jberger https://github.com/jberger/Mojo-ACME/commit/a0afea2c8db94e6f10c9d2c6e90e1428c648fdec
15:43 jberger it was kinda hard to find because it moved files
15:58 perlpilot joined #mojo
16:01 lluad joined #mojo
17:00 bradjm joined #mojo
17:22 cpan_mojo Clustericious-1.17 by PLICEASE https://metacpan.org/release/PLICEASE/Clustericious-1.17
17:31 sri jberger: yea, support for inotify and friends does seem unlikely with the available apis
17:33 preaction i had a plan to make a Mojo::FileWatch or something. the low-level modules seem to all support async APIs, the high level modules just don't care to expose them
17:34 preaction Statocles uses Mac::FSEvents async, for example
17:44 bradjm joined #mojo
17:54 batman jberger: i think it depends, but i don't disagree :)
17:56 cpan_mojo Mojolicious-Plugin-Tables-0.03 by FRANKC https://metacpan.org/release/FRANKC/Mojolicious-Plugin-Tables-0.03
18:07 trone joined #mojo
18:21 dod joined #mojo
18:53 cpan_mojo Test-Mojo-More-0.061 by COOLMEN https://metacpan.org/release/COOLMEN/Test-Mojo-More-0.061
18:53 PryMar56 joined #mojo
18:58 irqq joined #mojo
19:24 cpan_mojo Test-Clustericious-Cluster-0.30 by PLICEASE https://metacpan.org/release/PLICEASE/Test-Clustericious-Cluster-0.30
19:39 cpan_mojo Mojolicious-Plugin-Tables-0.04 by FRANKC https://metacpan.org/release/FRANKC/Mojolicious-Plugin-Tables-0.04
19:49 marty_ joined #mojo
20:08 batman joined #mojo
20:46 lsm joined #mojo
20:55 batman joined #mojo
22:19 pink_mist anybody going to do anything nice for Mojoday?
22:29 disputin joined #mojo
23:07 lluad When is that? Saturday?
23:09 pink_mist should be, yes
23:11 lluad I have no plans. Which ... seems appropriate. Spontaneity is good.
23:25 sri curious #934 is moving so slowly, i guess everyone might just have reconfigured their vim ;p

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