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

IRC log for #mojo, 2015-08-19

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

All times shown according to UTC.

Time Nick Message
00:00 jontaylor joined #mojo
00:03 dave that's why I like California :)
00:03 dave we have it all, you name it
00:03 Grinnz water? :P
00:03 sri lol
00:03 dave off the coast ;)
00:04 dave supposed to be an el nino this year so we got water coming
00:06 jzawodn joined #mojo
00:10 jberger Grinnz++
00:11 dave hey that was a cheap shot, but...I understand. :) no east coast person likes my state
00:13 jberger I like California, I was born there actually
00:14 dave a fellow native then
00:15 jberger I suppose so
00:15 jberger I don't remember living there
00:15 jberger Left before I was one
00:18 dave eh, it's a state of mind .. aren't you looked on as the mellowest guy in the channel? :)
00:18 KCL_ joined #mojo
00:51 jberger I'm not sure I can speak to that
00:51 bpmedley Only when he's drinking.. ;)
00:52 * jberger tips bottle
02:03 Guest6 joined #mojo
02:11 jberger sigh, there is so much still missing from p6
02:11 jberger I want to be excited about the aync and yet (unless I'm missing something) there isn't even an async ua available
02:28 noganex_ joined #mojo
02:29 cpan_mojo Mojo-Webqq-1.4.1 by SJDY https://metacpan.org/release/SJDY/Mojo-Webqq-1.4.1
02:29 esh joined #mojo
02:34 genio worst API ever?  https://www.grandstream.com/products/surveillance/general/documents/grandstream_http_api.pdf
02:35 bpmedley genio: Are they security cameras?
02:36 genio yea
02:36 bpmedley What type of stuff needs an API?
02:36 genio setup.  Their built-in web site for config only works on IE 8-9 and then only if you have a crappy plugin
02:37 genio so, setting up motion detection zones, FTP servers, streaming users, etc. is all impossible without a shady plugin on a shady browser
02:38 genio well, unless you use this API
02:38 bpmedley I see.  That's cool.  Woah, state of the art has really improved.
02:39 bpmedley I remember when our APIs were just integers.  And we were proud.
02:41 genio it returns plaintext no matter what you ask for.  this is what I get from the motiondetect call https://gist.github.com/genio/72b9f8d9002c0e72ed5d
02:42 bpmedley Wowzers.  Thank god for perl.
02:43 genio and I'm thinking, ok, I can parse that... kind of.  There's a  "foo.index" key for arrays of hash refs.  then you notice at the end they throw in an extra "md.regn.index=0" for no apparent reason
02:43 genio and on systeminfo, some values are multi-line
03:02 kaare joined #mojo
03:04 asarch joined #mojo
03:05 asarch $self->res->headers->content_type('application/xhtml+xml'); $self->render(format => 'xhtml');   <- How can I make them "permanent" for my app?
03:06 sri http://mojolicio.us/perldoc/Mojolicious/Guides/Rendering#Content-type
03:07 asarch Thank you
03:08 asarch Thank you very much :-)
03:09 * sri wonders if the examples using "sub startup {...}" should just be replaced with lite apps
03:11 mrallen1 joined #mojo
03:11 sri hmm, for the routing examples it would be hard
03:12 jberger I think I should make a blog post called "don't fear the lite app" explaining how alike the two are
03:12 sri that's that the growing guide is for ;p
03:15 sri i guess for routing it makes more sense to use full examples
03:15 sri but rendering not so much, especially silly stuff like adding mime types
03:19 gabiruh joined #mojo
03:19 jberger I know it is, but I need something more to the point to link to
03:20 firnsy joined #mojo
03:21 good_news_everyon joined #mojo
03:21 good_news_everyon [mojo] kraih pushed 1 new commit to master: http://git.io/vstgM
03:21 good_news_everyon mojo/master 6cebde0 Sebastian Riedel: use more neutral examples in the rendering guide
03:21 good_news_everyon left #mojo
03:22 sri since we have the $app/$c convention, this works too :)
03:28 firnsy joined #mojo
03:48 Guest6 joined #mojo
03:57 hshong joined #mojo
04:04 melo joined #mojo
04:14 inokenty-w joined #mojo
04:15 gabiruh joined #mojo
05:15 sri Grinnz: this is your daily reminder that you still owe us a proposal for new documentation conventions ;p
05:52 sopanshewale joined #mojo
06:17 arpadszasz joined #mojo
06:20 marcusr sri: I've been thinking about  a shortcut ($c->log => $c->app->log)
06:20 marcusr mostly because I do $c->log so often already then cry myself to sleep.
06:39 dod joined #mojo
06:44 dod joined #mojo
07:24 AndrewIsh joined #mojo
07:25 Vandal joined #mojo
07:32 berov1 joined #mojo
07:59 eseyman joined #mojo
08:12 berov joined #mojo
08:17 jontaylor joined #mojo
08:37 sopanshewale joined #mojo
08:38 McA joined #mojo
08:39 berov joined #mojo
09:10 esh joined #mojo
09:13 meshl joined #mojo
09:54 melo joined #mojo
09:57 diegok marcusr: +1
10:16 esh joined #mojo
10:24 jontaylor joined #mojo
10:36 meshl joined #mojo
10:48 dimuls marcusr, how about global log? use Mojo::Log qw/ log_warn log_error log_die ... /
10:49 depesz left #mojo
11:00 henq joined #mojo
11:11 neilhwatson joined #mojo
11:28 eitz joined #mojo
11:43 pink_mist helper log => sub { shift->app->log(@_) };?
11:58 sh4 joined #mojo
12:09 CromeDome joined #mojo
12:18 marcusr pink_mist: I know how to do it, I just think it should be there by default.
12:21 DadaIsCrazy joined #mojo
12:21 esh joined #mojo
12:27 stephan hi all. i'm just curious what would be a good way to use SSL with mojo and apache. is there any recommendation?
12:33 marcusr stephan: http://mojolicio.us/perldoc/Mojolicious/Guides/Cookbook#Apache-mod_proxy
12:33 marcusr just like that, only with a https virtualhost
13:01 mrallen1 joined #mojo
13:01 stephan marcusr: okay works.
13:02 stephan marcusr: thx
13:19 meshl joined #mojo
13:21 mrallen1 joined #mojo
13:38 mst dimuls: Log::Contextual already provides that sort of global logging
13:47 jberger Or you can just close over the logger and export the functions
13:49 mst if you want your code to be fragile and slow, sure you can do it the wrong way
13:50 batman mst: not very constructive feedback
13:51 batman dimuls: why do you want global logging?
13:51 mst batman: I'm not sure how much more feedback suggesting a nasty hack instead of an already-existing cpan module can be given?
13:52 batman mst: "if you want your code to be fragile and slow" ...
13:52 mst well, yes, because that's what jberger's approach would achieve compared to using the module
13:52 batman oh. bad timing... dinner is served
13:52 mst hence why I recommended the module
13:56 jberger Mojo actually gives you a third option
13:56 jberger http://mojolicio.us/perldoc/Mojolicious/Guides/Cookbook#Application-embedding
13:59 mst a third option for what?
13:59 jberger Global logging
13:59 mst I don't really understand how that's supposed to relate
14:00 jberger Load the application and use its logger
14:00 mst I don't understand how that's 'a third option', all of the approaches we're discussing use the application's logger
14:01 mst just only one of them is already written, battle tested, and designed for performance
14:01 jberger Rather than using some other module or closing over an app instance
14:01 jberger So is this
14:01 mst where's the code that handles only generating expensive information when required?
14:01 mst I don't see any in that link
14:02 jberger Who is asking about that? "marcusr, how about global log? use Mojo::Log qw/ log_warn log_error log_die ..."
14:03 mst I'm now wondering if you've actually looked at Log::Contextual
14:04 jberger Do you really think that mojo is going to provide hooks to Log::Contextual so that marcus doesn't have to remember one method invocation?
14:05 mst I'm unsure what hooks you think mojo would need to provide
14:05 jberger Anything at all
14:05 jberger nm, I'm not interested
14:06 mst I'm unsure why you think mojo would need to provide something
14:06 Grinnz I think you guys are talking about different things, marcusr wanted a default shortcut for app->log, dimuls asked about global logging
14:06 jberger It can magically guess what log file your application is using?
14:07 jberger Or how to integrate it with your log level?
14:07 mst huh? you'd tell it to use app->log
14:07 Grinnz if it was available by default then it would have to be integrated, is what he's saying
14:08 jberger dimuls was suggesting a global logger style interface to the current application's logger, not asking about how to generally builds a global logger
14:08 mst and I'm saying "you can already do that in a couple lines with Log::Contextual, so I'm not sure why you'd want to change mojo"
14:10 jberger mst: you are fond of reminding people that they have misunderstood the original question
14:10 jberger you have misunderstood the original question
14:10 jberger certainly marcus could use any logger he would like to
14:11 jberger but what he wants is to stop forgetting to us the ->app in $c->app->log
14:11 jberger s/us/use/
14:11 mst I was commenting on a way to get dimuls' idea from already-existing code
14:12 jberger completely correct and yet far from the point
14:12 Grinnz moving on...
14:12 jberger indeed
14:12 mst plus for free you then get 'log_debug { expensive_debugging_info() }' only calling the expensive thing when is_debug is true
14:13 mst which I find really handy sometimes
14:13 mst which is what I meant about performance
14:13 * mst shrugs
14:14 jberger mst: this is a very interesting topic and I would love to learn about the performance implications of logging patterns, but the question is using the mojo logger in a slightly more convenient way
14:15 jberger convenience is often purchased at the cost of performance
14:15 mst right, ok, so, if I wanted that convenience, I'd experiment with it using an Import::Into/Import::Base thing that exported M::Lite plus then grabbed the app it created and handed its logger to L::C
14:15 mst if it turned out to make enough of a difference, maybe at that point it might be worth having a discussion about whether it's worth adding a version thereof to core
14:15 jberger is it likely that Mojolicious core is going to provide that in the way that marcus suggested?
14:16 mst I've no idea, because without running the experiment you can't really know whether it's useful enough to make a case for that
14:18 jberger I would think it unlikely, but it would make for a very interesting cpan module
14:20 mst same, but I think the module might have value anyway
14:20 mst it's a fairly common pattern in Catalyst code so that you can have application global logging without needing your model-ish stuff to know about the web app
14:22 batman marcusr: you could use https://metacpan.org/pod/Mojolicious::Plugin::Logf
14:22 batman it's an extra dep, but it does some very convenient things for you imo
14:23 mst aha, and flatten gives the equivalent of Dlog_debug etc.
14:23 * batman will add support for a code ref as the last argument
14:25 sopanshewale joined #mojo
14:25 PryMar56 joined #mojo
14:25 mst it's a lot easier to get right than having to remember 'if ($log->is_debug) {' IME
14:26 hernanGOA joined #mojo
14:26 batman mst: yeah, M::P::Logf does't call flatten unless $log->is_whatever at least
14:30 jberger dimuls: back to your original suggestion, that can't be directly done since you might have multiple apps in the process and they might have different loggers
14:30 mst batman: right, probably adding the 'take coderef that returns string' option would give you effective parity
14:30 jberger you would need some disamiguation (as Log::Contextual has) in order to work out which one was in play
14:30 mst there's some other stuff in L::C but it's not nearly as important
14:30 batman jberger, dimuls: Toadfarm will automatically share loggers between the apps
14:31 mst (and at the point where you need that other stuff, your requirements are probably sufficient to say 'stuff it' and just use L::C)
14:31 PopeFelix joined #mojo
14:31 batman mst: i still think i want to do flatten() on the list returned from the code ref
14:31 mst sure
14:33 PopeF joined #mojo
14:34 arthas joined #mojo
14:39 gryphon joined #mojo
14:47 esh joined #mojo
14:51 njlg joined #mojo
14:57 absolut_todd joined #mojo
15:00 lluad joined #mojo
15:08 Kogurr joined #mojo
15:09 esh joined #mojo
15:10 sopanshewale joined #mojo
15:14 meshl joined #mojo
15:21 cpan_mojo Mojolicious-Plugin-Logf-0.05 by JHTHORSEN https://metacpan.org/release/JHTHORSEN/Mojolicious-Plugin-Logf-0.05
15:22 Grinnz_ batman: cool stuff
15:22 sri jberger: no, global logging wouldn't work
15:23 sri as usual it all comes down to non-blocking operations, which don't have an app specific context
15:24 sri marcusr: feel free to put a log shortcut up for a vote, but please include new documentation examples
15:25 sri because right now we are using $c->app->log->... a lot as an example specifically for the $c->app->... interaction
15:28 sri (as in search for all cases of "app->log->" and propose replacements if necessary
15:32 batman Grinnz_: thanks
15:41 marcusr sri: sounds like a good plan for after kids go to bed.
15:42 sri or you could try the new hearthstone brawl ;p
16:10 PopeFelix I often create a "log" helper so I can just do $c->log->whatever
16:11 PopeFelix Speaking of Mojo...
16:11 PopeFelix There's no reason you couldn't use Mojo::UserAgent in a Moo* class if you wanted, right?
16:13 mst course not
16:13 PopeFelix didn't think so.
16:13 mst it's perl all the way down :)
16:13 PopeFelix oh boy. ;)
16:18 cpan_mojo Mojolicious-Plugin-Logf-0.06 by JHTHORSEN https://metacpan.org/release/JHTHORSEN/Mojolicious-Plugin-Logf-0.06
16:19 Grinnz_ PopeFelix: has 'ua' => (is => 'ro', lazy => 1, default => sub { Mojo::UserAgent->new }, init_arg => undef); # very common in my code
16:27 PopeFelix Grinnz_, cool.
17:26 dod joined #mojo
17:28 njlg joined #mojo
17:31 sopanshewale joined #mojo
17:38 disputin joined #mojo
17:38 rwp joined #mojo
17:47 njlg joined #mojo
18:02 berov1 joined #mojo
18:07 * sri wonders what performance implications a log helper would have
18:07 sri $c->helpers->log->debug() for good performance would be kind of hilarious
18:08 mst 'state $log = $c->log;' # optimized
18:10 sri test case
18:10 sri perl -Mojo -E 'app->helper(log => sub { shift->app->log }); my $c = app->build_controller; n { $c->app->log->debug("test") } 100000; n { $c->log->debug("test") } 100000'
18:11 sri 0.45s vs 1.34s
18:13 sri for the record... "app->helper(log => sub { state $log = shift->app->log });" does pretty much nothing
18:13 sri 1.28s
18:19 mst well, yes, (a) I was suggesting you'd do that in each method that used it (b) I was joking anyway
18:22 henq joined #mojo
18:25 mrallen1 joined #mojo
18:28 njlg joined #mojo
18:49 njlg joined #mojo
18:49 meshl joined #mojo
19:02 dave For perl modules, I can do a quick syntax check by doing "perl -wc Module.pm"
19:02 dave Is there an equivalent for Mojo ".ep" documents?
19:04 batman dave: not really a command for that, but why would you need it?
19:05 njlg joined #mojo
19:05 batman a unit test of the route rendering the template would do it for you...
19:05 mst dave: available 'my' variables are determined by the stash
19:05 mst so without a route, I don't think they'll compile
19:06 dave right
19:06 batman mst: i don't think that is right "compile" and "render" a template is not the same thing.
19:06 dave the emacs support for in-editor syntax checking doesn't seem to understand <% %> in javascript comments
19:06 batman depends on what dave really wants.
19:07 dave so I have a fairly involved app interaction I'm debugging and I get to a point and "oops there's a semicolon missing" or something
19:07 batman dave: sounds like you don't have any unit tests :/
19:07 dave I have tests for the models... not for the controllers
19:08 batman exactly. have you looked at Test::Mojo ?
19:08 dave I have
19:08 dave but I may be missing the element you are wanting me to grok
19:08 batman i want you to use that module to test your controller and templates
19:10 dave well ok, I have .ep templates that build data from models, so I have to mock up populating the models and then insert to the stash exactly how I do in the controller...?
19:11 batman no. just do $t->get_ok("/some/resource"); and test that the template is rendered as expected
19:11 batman that will test the controller, fetching data from the backend and rendering the template.
19:12 batman you probably need to mock the database (or whatever) somehow, but i guess you already know how to do that if you have tests for the models
19:12 dave that's the easy part
19:13 batman so what's the trouble testing you mojo application?
19:14 batman please tell us where you got stuck, so we can help you on forward...
19:14 batman sorry for my english. i hope you understand what i try to say
19:14 dave I can test it fine, but I have to test it by using it. I'm just trying to speed development by testing all my .ep files.
19:14 dave I see what you are saying, I'm going to try it :)
19:15 batman that's exactly what Test::Mojo does for you
19:16 dave ahh I see why I didn't try this
19:16 dave I have to log in first :/
19:17 Grinnz_ Test::Mojo makes it simple because it runs the app itself, to run requests against it
19:18 sri the growing guide literally shows you how to test an app with authentication
19:18 dave not the way *I* did authentication
19:18 sri and why does that matter?
19:18 batman dave: so the $t (Test::Mojo) object has a Mojo::UserAgent which again has a cookie jar... this means that if you test the login process first, then you can test whatever you need afterwards, since you are logged in
19:19 dave heh
19:19 batman you == the Mojo::UserAgent
19:19 batman so everything you can do in your browser, you can do with Mojo::UserAgent.
19:19 Grinnz_ i wrote a function which logs in with the Test::Mojo object's ua, to put at the beginning of my test files that need to authenticate
19:19 dave I rewrite the password field with javascript
19:19 Grinnz_ wat
19:19 bowtie joined #mojo
19:19 dave go ahead, bring it :)
19:19 batman dave: you're doing it wrong.
19:20 Grinnz_ heh
19:20 * batman gives up.
19:20 dave I'll stop asking questions now :)
19:20 sri it doesn't even matter, it's still just a form
19:20 batman dave: i really think you shouldn't, since you might learn something.
19:21 mst dave: your app can't tell whether the javascript generated something or your perl test code did
19:21 batman and for whatever reasons you think makes sense... it doesn't. and even if it does, you can still test it.
19:21 mst "don't trust the client" actually sorta works in your favour here
19:21 batman ...for the reason mst just said
19:22 Grinnz_ you might have to rewrite your javascript's logic in your test code, but...
19:23 dave I think that's the hurdle. I have to write my javascript logic in perl, so my thinking goes "well that really isn't testing..."
19:23 njlg joined #mojo
19:24 dave so I never delved into Test::Mojo because of that
19:24 mst yes it is, you're just mocking the browser, effectively
19:24 mst which is what testing is all about anyway
19:25 Grinnz_ you're testing your perl, not the javascript, so rewriting the javascript logic is fine
19:25 Grinnz_ if you want to test the javascript, then you can do that too, but that's different
19:26 dave fair enough ... I'll give it a go
19:26 dave I'd really like test suites for every link, so it's worth it
19:29 jwang joined #mojo
19:40 henq joined #mojo
19:45 ZoffixWork joined #mojo
19:47 ZoffixWork dave, there's also PhantomJS; browserless JS engine exactly for stuff like that. Haven't used it myself (yet) but I see there are a few PhantomJS modules on CPAN. If your JS logic is more complex than rewriting the password field, check PhantomJS out
19:47 Grinnz_ Mojo::Phantom ;)
19:47 ZoffixWork \o/
19:47 ZoffixWork jberger++
19:47 Grinnz_ and direct all complaints to jberger!
19:48 lluad Also, zombie.js if you're mostly testing the browser end of things.
19:48 lluad (Javascripty rather than perly, but if you're testing javascript that's probably OK)
19:49 mst yes. everything is jberger's fault, forever.
19:49 mrallen1 works for me
19:49 mst (there needs to be at least one channel I'm in where it isn't me)
19:49 ZoffixWork :)
19:55 jberger aaaaaaaaahhhhhh
19:56 jberger I also tend to agree with the others
19:56 jberger even if you are rewriting the password field in you form with javascript, in the end you are still submitting a form right?
19:56 jberger or making some kind of request?
19:57 jberger just make the same kind of request via the Test::Mojo instance to become authenicated
19:59 mrallen1 lol
20:02 absolut_todd joined #mojo
20:30 mrallen1 joined #mojo
20:36 HtbaaPi joined #mojo
21:10 PryMar56 joined #mojo
21:12 flamey joined #mojo
21:39 test123 joined #mojo
21:43 disputin joined #mojo
21:48 njlg joined #mojo
22:01 njlg joined #mojo
22:12 * sri pokes marcusr
22:12 sri guess he opted for hearthstone after all :o
22:13 sri ok, i'll give the whole log helper thing a -1
22:14 sri too slow, ruins many good examples...
22:14 sri and this is absolutely not worth another method in Mojolicious::Controller
22:17 dave just curious, not a commentary on what you should do at all...you don't find $c->app->log-><logmethod> cumbersome at all?
22:18 sri what would that change?
22:19 dave "that" = ?
22:19 sri if i said yes
22:20 cstamas joined #mojo
22:20 dave I'm not entirely sure :)
22:21 sri my points above still stand, and outweigh the gain
22:21 dave I am not disputing that
22:21 sri so it doesn't change a thing
22:21 dave I wind up doing my $log = $c->app->log at the top of most controllers
22:22 dave well it doesn't change a thing, but the desire -to- change might change
22:22 dave and hence some 3rd solution might appear
22:23 dave maybe $c->log might work not as a helper? I dunno
22:23 dave $Mojolicious::Controller::Log-> ...
22:25 y1mmm joined #mojo
22:25 dave just not sure how you are measuring worth of a method
22:28 sri methods are not added to Mojolicious::Controller as little conveniences
22:28 sri they have to be essentials
22:29 sri in fact, those that existsed in the past, like $c->ua, have been moved into helpers
22:31 njlg joined #mojo
22:33 dave and $c->helpers->log is actually longer to type than $c->app->log
22:34 sri yes, and $c->log is slow
22:34 dave ever since you said helpers are autoloaded unless you use ->helpers, I've been using ->helpers
22:34 sri that doesn't seem like a good idea either
22:35 sri if your helper isn't called over and over it prolly doesn't matter
22:35 sri there's lots and lots of convenience stuff you're using that could be replaced with something faster
22:35 dave I have been (ab-)using helpers
22:35 dave why isn't that a good idea? :)
22:35 absolut__ joined #mojo
22:35 sri always benchmark
22:36 dave ahh
22:36 dave I haven't gotten this deep with Mojo yet
22:37 sri if you do "$c->foo for 1 .. 10000", then yes, you prolly should optimize
22:37 dave $c->helpers->foo ;)
22:38 sri if it's a single call to a helper that's slow anyway (model?), then it just doesn't matter and you're sacrificing developer time for no reason
22:40 njlg joined #mojo
22:42 sri take this app for example
22:42 sri perl -Mojo -E 'helper foo => sub { "foo" }; get "/fast" => sub { $_->render(text => $_->helpers->foo) }; get "/slow" => sub { $_->render(text => $_->foo) }; app->start' daemon -m production -l http://*:8080
22:42 sri do you think the difference is actually measurable with wrk?
22:44 sri both give me 1065 rps
22:44 sri it just doesn't matter
22:45 sri this is for future reference
22:45 sri since someone is bound to bring it up again
22:45 sri always benchmark first!
22:48 njlg joined #mojo
22:56 jberger sri: if there is no measurable difference, isn't that an argument for $c->log?
22:56 jberger (not that I care one way or the other tbh(
22:56 jberger )) # ocd
22:58 sri i'd expect $c->log to be called a lot more
22:58 sri but hey, if you insist on adding the helper, i won't say no
22:58 sri not like they cost us much
22:59 sri some benchmarks to prove it's useful would be nice though
23:00 sri guess the biggest cost would be the reworking of doc examples
23:00 sri but i don't have to do it... soo... ;p
23:01 Grinnz as always, it depends on someone caring enough to do it :P
23:02 sri yea, and marcus doesn't exactly have the best track record there :)
23:15 howitdo joined #mojo
23:20 howitdo joined #mojo
23:34 bpmedley joined #mojo
23:45 dotan1 joined #mojo
23:46 lluad joined #mojo
23:47 berov2 joined #mojo
23:48 dotan joined #mojo

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