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

IRC log for #mojo, 2017-03-13

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

All times shown according to UTC.

Time Nick Message
00:19 Janos joined #mojo
01:08 jberger Thanks preaction, good luck zach
03:08 stryx` joined #mojo
03:30 asarch joined #mojo
03:40 noganex_ joined #mojo
04:47 hafizh joined #mojo
04:50 inokenty-w joined #mojo
05:04 dboehmer_ joined #mojo
06:07 avkhozov joined #mojo
06:13 avkhozov joined #mojo
06:28 eseyman joined #mojo
06:53 dod joined #mojo
06:55 polettix joined #mojo
07:06 VVelox joined #mojo
07:40 batman joined #mojo
07:44 janl joined #mojo
07:54 polettix joined #mojo
07:56 rshadow joined #mojo
08:16 trone joined #mojo
08:23 AndrewIsh joined #mojo
09:10 sri are there actually frame/message size limits in mod_proxy_wstunnel?
09:13 coolo joined #mojo
09:25 rshadow joined #mojo
09:40 rshadow joined #mojo
10:09 * sri just learned something cool from coolo, you can start your mojolicious app with an unprivileged user and add a port forward to the systemd .service file
10:09 sri ExecStartPre=iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3000
10:36 irqq joined #mojo
11:32 marty joined #mojo
11:36 tyldis That's quite handy, assume a teardown would be good practise as well
12:43 vicash sri: you can also use a reverse SSH tunnel if you're traversing NATs...
12:48 itaipu joined #mojo
12:54 Janos joined #mojo
12:57 gryphon joined #mojo
12:59 Sebbe sri: I'm told that setting "CapabilityBoundingSet=CAP_NET_BIND_SERVICE" would allow Mojo to bind to port 80 directly while otherwise unprivileged.
13:02 sri Sebbe: oh, that's cool
13:16 gizmomathboy joined #mojo
13:24 Pyritic joined #mojo
13:25 rshadow joined #mojo
13:31 Xyem joined #mojo
13:36 aborazmeh joined #mojo
13:39 itaipu joined #mojo
13:41 dantti_laptop joined #mojo
13:42 coolo joined #mojo
13:45 marty_ joined #mojo
13:46 Xyem Good day. I'm setting up a Mojolicious site on shared hosting with perlbrew, which has required me set up a dispatch script with mod_rewrite, but this leaves REQUEST_URI being prefixed with the dispatch script. Any advice on where to handle removing that, so it doesn't show up in url_for?
13:47 marty_ joined #mojo
13:47 genio Xyem: does this host only allow you to run cgi scripts? It doesn't allow you to alter Apache in any way to serve as a reverse proxy?
13:48 Xyem genio: Only CGI scripts as far as I can tell. I did attempt at using FastCGI but had no success there.
13:51 genio Xyem: http://mojolicious.org/perldoc/Mojolicious/Guides/Cookbook#Apache-CGI   have you looked at that?
13:52 Xyem I did, but I couldn't see how ScriptAlias would be useful in this configuration.
13:53 Xyem I'm having to redirect through a dispatch.sh so it can set up perlbrew. Perhaps I can set up the perlbrew environment manually in .htaccess?
13:54 Xyem Then the CGI server can execute app.pl directly.
13:55 genio oh, wait. yea. I'm sorry I completely missed one of the problems.  The system-perl Apache is using probably doesn't have Mojo available to you.
13:55 zivester joined #mojo
13:56 Janos joined #mojo
13:56 genio This is going to be slower than slow.
13:57 genio can you even have a long-running daemon on this machine?
13:58 coolo sri: there was an unexpected fallout of the iptables solution: localhost:80 wasn't reachable
13:58 pink_mist if the system perl isn't too ancient, you could probably just do a local::lib for it instead of perlbrew
13:58 Xyem Once the site is running, I'll get into discussions with the host about improving it. FastCGI is listed on their website as supported.
13:59 Xyem pink_mist: The server has perl 5.10.1
13:59 pink_mist that's sufficient for Mojolicious - but maybe you have other requirements that need higher
13:59 genio That's... at least new enough to run Mojo.
14:03 Xyem Ah, I thought Mojo needed 5.14. I'll see about using local::lib instead. Thank you.
14:03 Xyem Would be a little unfortunate as the host went out of their way to allow me to use perlbrew :)
14:04 pink_mist heh =)
14:04 pink_mist well, using newer perl might be faster for you anyway - lots of speed improvements since 5.10.1 =)
14:10 Xyem As someone said this site would be "clunky" due to being in Perl, I would like to prove that claim wrong..
14:10 dod joined #mojo
14:10 genio Perl, within those constraints, might indeed be clunky.
14:11 pink_mist CGI is always clunky
14:11 Xyem I can host a mirror of the site on my own VPS to show it running at "unhindered" speed.
14:12 Xyem Which I believe having FastCGI on the shared hosting would also achieve?
14:12 pink_mist I've never used FCGI myself, but it should certainly be faster than CGI, yeah
14:13 pink_mist I don't even know if Mojo can FCGI natively?
14:13 Xyem Not from what I have read, but it is possible.
14:13 pink_mist I think you need something like starman for it
14:14 genio Usually when I'm stuck in CGI-only scary land, I just give in and use Web::Simple. Still slow, but at least easier to look at later when converting to Mojo and less fiddling with shoehorning things in
14:14 Xyem I believe I just need to install Mojo::Server::FastCGI.
14:14 pink_mist ah, didn't realise that one existed, Xyem ... yeah, that sound like a good solution too =)
14:17 Xyem Aha, perhaps this article would be useful: http://blogs.perl.org/users/robhammond/2013/01/mojolicious-on-cpanel.html
14:19 Xyem It may be the that current deployment just needs the $ENV{SCRIPTNAME} setting for correct url_for output!
14:20 Xyem I'll mention my findings back here, for reference.
14:26 dod joined #mojo
14:28 itaipu joined #mojo
14:35 jberger pink_mist: that was spun out of the mojo core
14:39 jberger genio: why don't you still use Mojo in CGI deployments?
14:39 jberger it works fine there
14:39 jberger (well, no websockets but you don't get them in Web::Simple either)
14:41 genio jberger: Probably something stupid the first time I tried that I didn't understand and had to get it done quickly, so I just Web::Simple'd it. I haven't had the time to revisit it since I do _very_ little of anything using CGI anymore (thankfully).
14:41 genio short answer, genio is a dummy dumb dumb
14:42 jberger I'd never say you should only use Mojo of course (though you should :-P) but I just wondered why you'd prefer something else because of deployment
14:42 jberger but that makes sense
14:43 jberger it is kinda amazing that it works on CGI, you might not expect that at first
14:43 genio basically everything I do now that's new is either Mojo or systems work or Node.js.
14:44 genio The old stuff I have to maintain is all over the place.
14:44 genio I only _really_ cry when it's mod_perl or PHP
14:46 jberger oh, don't be so hard on mod_perl and PHP, they are just trying ... hahahahah ok yeah, I couldn't keep a straight face
14:46 jberger actually I just deployed a PHP site for the first time in ages
14:46 jberger I decided I wasn't going to get my personal image-host site done any time soon so I punted and installed nextcloud
14:48 genio some of the more modern PHP doesn't feel quite so icky anymore.  However, all the PHP I have to deal with is really old and deserves every ounce of ire you can muster
14:48 jberger last night I finally got around to doing the last few tweaks to the CarPark code, now it needs tests and doc
14:48 jberger and it can FINALLY go to CPAN
14:50 genio I don't really do any personal projects anymore. :/
14:54 genio the majority of my CPAN contributions are trying to help update really old modules.
14:55 jberger I'm trying to get back into personal projects honestly
14:56 jberger I'm starting to get a little obsessed with personal data/harware-access ownership
14:56 jberger hardware
14:56 purl hardware is, like, old fashioned
14:56 jberger shut it, purl
14:56 purl Phuque Oph!
14:57 jberger I wrote CarPark because I couldn't find a way to open/close/check my garage door via a service that I could deploy
14:57 jberger and I don't want to trust that hardware manufacturers are going to support cloud access to hardware indefinitely
14:57 jberger (see https://www.wired.com/2016/04/nests-hub-shutdown-proves-youre-crazy-buy-internet-things/)
14:58 genio My only side project at home is working with the IP cameras we bought to provide a service to monitor them since I don't trust the security shipped in their own software.
14:59 jberger nice
15:00 genio the software baked into these things is just scary terrible. It requires IE and a terrible plugin in order to config them.  So, once I had one configured, I had to figure out their weird web services to manage the configuration of any of them with my own web service.
15:01 jberger and you got it figured out?
15:01 genio the hardest part at this point is the live-stream (converting RTSP to RTMP) and keeping the individual cameras isolated from the web
15:03 jberger sure
15:03 jberger my next project will likely be to write a ownTracks service, my family uses Life360 and I'd rather have our GPS data in my hands than in some 3rd party
15:03 genio yea.  I have them configured to send videos of any motion detection to a server with a service running that watches for changes there, uses AWS's transcoding service to sanitize the crappy encoding they use, grab the completed versions of the videos and notify me via email with a few stills of the event and a URL to the video
15:04 jberger (and yes I know google is going to have our GPS data too, but in this day-and-age I'm not sure there's anything you can do about that :( )
15:04 genio which is locked down with proper auth.  I can then use the web app to archive the videos or remove them if they were  just the dog moving around, etc.
15:05 genio So, the live video stream part is the only remaining piece but I haven't worked on it in a while
15:06 genio That sounds kind of fun.
15:07 genio I don't have anything to remotely trigger my garage door, but one of the cameras is positioned to where I can see it (if I ever get the live stream part functioning properly).
15:08 jberger Why use aws for transcode?
15:09 jberger I thought opensource transcoding was pretty advanced?
15:09 vicash genio: have you tried using Zoneminder ? it does all this for you
15:09 genio because the videos the cameras take are all oddly broken in their own individual ways.  I ended up spending more time dealing with FFMPEG folks to work through problematic videos than it was worth to me
15:09 jberger Ah
15:09 genio vicash: oh, gods. That thing is quite possibly the worst thing ever to setup. it also doesn't seem to like my cameras
15:11 genio since I can send them to an S3 bucket, create a job for the transcoding service, and grab the results from another S3 bucket, that generally turns out to be faster than trying to do that on my local server anyway
15:11 vicash genio: last year i tried doing this with a set of chinese cameras and they also had some weird backdoor in their flash plugin. so i connected all of the stuff but left it disconnected from the internet. frankly it did not matter to view stuff live in my case.. but if you're concerned, i would put a simple router/raspberry pi in front of the off-the-shelf device that you're using and block all access except from your system via iptab
15:12 genio vicash: Yea, don't get me wrong, there are services out there that are already built for this stuff. What I'm doing mostly is playing for the fun of learning when I have free time.
15:13 vicash genio: yes Zoneminder prefers you use their list of supported hardware .. this space is ripe for proper secure camera + DVR product that doesn't have backdoors but is quite expensive to implement even as a hobby
15:18 jberger Funny, as I read their front page they are pretty clear about "any camera"
15:19 genio read that as, "any camera except any of the ones that genio owns"
15:19 genio I've been through every tutorial I could find and all of them are "look, it's so easy. just do this!" and that never works
15:27 Pyritic joined #mojo
15:27 vicash genio: maybe you should ask on their IRC or mailing list. they're pretty helpful and would love to add support for your camera if it doesn't exist yet.. they have volunteers making open source iphone/android apps for viewing too.. i know it's extra work though
15:29 sh14 joined #mojo
15:32 stryx` joined #mojo
15:55 PryMar56 joined #mojo
16:16 disputin joined #mojo
16:31 Janos joined #mojo
16:34 lluad joined #mojo
16:54 kes joined #mojo
16:56 Pyritic joined #mojo
16:57 unspecified_perl joined #mojo
16:58 unspecified_perl Hello
16:58 purl bonjour, unspecified_perl.
17:19 unspecified_perl purl, are you a bot?
17:19 purl a bot? yeah right.
17:19 unspecified_perl Mighty quick responses.
17:19 janl the quickest perl slinger around
17:19 Grinnz maybe we're all bots
17:20 unspecified_perl How do I know if I'm a bot?
17:20 pink_mist take the voight-kampff test
17:21 unspecified_perl Anyway, I've found some funky behaviour with Mojo::UserAgent and I'm pretty sure it's undesirable
17:22 genio let's see
17:22 unspecified_perl When it goes out of scope, its DESTROY method runs callbacks early.
17:23 genio unspecified_perl: Perl 5.10?
17:23 purl Perl 5.10 is RIGHT NOW !!! or Perl5 X or http://www.slideshare.net/rjbs/perl-510-for-people-who-arent-totally-insane/
17:23 disputin joined #mojo
17:23 * genio pushes purl down the stairs
17:23 purl Hey! *thump* ow! *bang* argh! *bam* son of a *thump* *crunch* whimper...
17:24 unspecified_perl 5.16.3
17:24 pink_mist (you just specified which perl version you were using!!!! :P)
17:25 genio heh
17:25 rshadow joined #mojo
17:25 genio unspecified_perl: Can you provide a simplified gist of what you're doing and the errors thrown?
17:25 unspecified_perl Sure
17:26 jberger unspecified_perl: the user agent must run its finish handlers when going out of scope
17:26 jberger I don't think that could possibly be a bug
17:27 jberger see also: http://mojolicious.org/perldoc/Mojolicious/Guides/FAQ#What-does-Premature-connection-close-mean
17:27 jberger "the user agent got destroyed, which forces all connections to be closed immediately"
17:27 unspecified_perl "user agent got destroyed, which forces all connections to be closed immediately"
17:28 unspecified_perl Yeah. I'd call that an error in judgment then
17:28 jberger what do you mean?
17:28 genio unspecified_perl: not really.  Let's see what you've got. There may be something glaring in there we can point out
17:28 unspecified_perl http://pastebin.com/PN6hUzBK
17:29 jberger unspecified_perl: Perl's memory management is reference counting
17:30 jberger and since async with Perl is likely to cause people to write lots of closures Mojolicious is aggressive in making sure that memory leaks don't happen accientally
17:30 jberger *accidentally
17:30 unspecified_perl Yes but am I expected to keep a reference to $agent when my callback is given $ua as an argument?
17:30 jberger yes
17:31 Grinnz the invocant is passed there so that you don't have to close over it (well, probably not the entire reason, but it's commonly helpful that way)
17:34 unspecified_perl Doesn't seem very async to me to have to keep that $agent reference. It's not used for anything.
17:34 jberger the agent is the thing that manages the connections
17:35 unspecified_perl and I'd expect the fact there's an action with a pending callback would keep that agent in memory
17:35 jberger it opens sockets and watches for traffic
17:35 Grinnz unspecified_perl: that easily leads to circular references, and thus memory leaks
17:35 jberger it is reasonable to think that, for reasons of memory leak safety it is not that way
17:36 Grinnz unspecified_perl: however, you can do that yourself, by putting "undef $agent;" at the end of your callback, similar to how the delay helper holds onto the transaction
17:36 jberger the rule is simply, when using a user agent be sure to keep a strong reference to it, when writing a server be sure to keep a strong reference to the transaction
17:37 Grinnz that will "keep a reference" by closing over it
17:37 jberger heh, Grinnz and I are on the same wavelength here :-P
17:38 unspecified_perl Feels much like an exception to the rule
17:39 pink_mist unspecified_perl: if you were in an actual mojo app, I'd recommend using the app's ->ua instead of making a ->new one, then it'll be referenced elsewhere anyway: https://metacpan.org/pod/Mojo#ua
17:39 jberger to which rule
17:39 jberger ?
17:39 unspecified_perl To callbacks in generally
17:39 jberger I'm not sure what you mean by that?
17:40 Grinnz intentionally so, to make it easier to avoid memory leaks
17:40 unspecified_perl Well I've not to my memory come across an instance where I needed to keep a reference to something when applying a callback or an event listener
17:41 unspecified_perl Especially when the variable itself is passed to that callback/listener
17:41 jberger unspecified_perl: and we've stipulated that it is reasonable that you expected that, but we've made this choice
17:41 jberger we see users make much more memory safe apps this way
17:42 unspecified_perl I'm happy with that, just wanted to hear why
17:43 jberger think of it slightly differently, the user agent object is like a filehandle object, it closes connections when it goes out of scope
17:45 unspecified_perl Not really because the only file read/write I've done asynchronously, I had no regard for the filehandle once the callback was in place
17:46 Grinnz your callback likely closed over the filehandle
17:46 unspecified_perl I hate to bring this up but it's the only example I can think of off the top of my head, but for NodeJS I don't think the fielhandle needs to be maintained after a callback is set
17:46 jberger ok well if that mental model doesn't work for you then don't think of it that way :-P
17:46 jberger that mental model works for me
17:47 unspecified_perl Is there another example of this? That would do it for me
17:48 jberger as I said, when you write a mojolicious web application the transaction object behaves the same way
17:48 jberger you have to keep a strong reference to it
17:48 jberger imagine you have a class which has a useragent attribute
17:48 jberger and using that attribute you make a request
17:49 jberger and in the callback you do something else with the original object
17:50 jberger if there was a strong reference to the useragent you've now made a circular reference
17:50 jberger and nothing gets cleaned up
17:50 jberger and that's an obvious way to do things
17:51 jberger you'd have to use Scalar::Util::weaken all over the place to make sure that memory got reclaimed
17:51 jberger in our experience users don't do that
17:52 jberger oh and Node.js isn't a good parallel because (IIRC) javascript is mark-and-sweep
17:52 preaction yes, the JS interpreters i know of all do formal GC
17:53 orev joined #mojo
17:58 marty joined #mojo
17:59 unspecified_perl Wouldn't you want a circular reference in that instance?
18:00 unspecified_perl i.e. a closure?
18:01 pink_mist unspecified_perl: circular references directly lead to memory leaks
18:01 Grinnz unless manually cleaned up
18:01 unspecified_perl Until that callback is called at which point the coderef with the closure is destroyed and so is the closure
18:02 Grinnz not if the closure is referencing itself
18:02 Grinnz directly or otherwise
18:03 unspecified_perl I'm not sure what you mean by closure in that case
18:03 unspecified_perl The callback coderef or the reference to the ua/class?
18:04 preaction the coderef
18:04 purl hmmm... the coderef is a reference to a block of code?
18:04 preaction ... that bot is incredibly useless...
18:04 genio she's an old, senile bot.
18:06 unspecified_perl Anyway, gotta run. Thanks for explaining it all to me. I think it's my experience in JS that have skewed my expectatinos.
18:14 itaipu joined #mojo
18:23 jberger purl forget the coderef
18:23 purl jberger: I forgot coderef
18:53 disputin joined #mojo
19:00 stryx` joined #mojo
19:07 rshadow joined #mojo
19:31 dantti_laptop joined #mojo
19:44 irqq joined #mojo
19:49 bif joined #mojo
19:52 ashimema joined #mojo
20:48 irqq_ joined #mojo
20:58 Xyem I can confirm that setting $ENV{SCRIPT_NAME} = '/'; resolves the issue with the dispatch script being in URLs generated by url_for. I decided to set it in the dispatch script itself, to keep the Mojolicious application agnostic about its deployment though.
20:59 Xyem Thanks for the help.
21:00 batman bif: you need to define the routes first, and then load the plugin
21:02 batman bif: like here: https://github.com/jhthorsen/mojolicious-plugin-openapi/blob/master/t/empty-string.t#L15
21:19 bif @batman: thank you; that's what was working practically. But looking here: https://metacpan.org/pod/distribution/Mojolicious-Plugin-OpenAPI/lib/Mojolicious/Plugin/OpenAPI/Guides/Tutorial.pod#Application I read "The first thing in your code that you need to do is to load this plugin and the "Specification"." which was throwing me off track.
21:19 bif @batman: thanks very much, btw, for all the work on Swagger and OpenAPI. It's saved us a ton of time with our APIs!
21:21 itaipu joined #mojo
21:31 stryx` joined #mojo
21:39 janl left #mojo
22:03 rshadow joined #mojo
22:05 disputin joined #mojo
22:09 marty joined #mojo
22:16 howitdo joined #mojo
22:19 batman bif: glad it works for you :)
22:19 batman you can join #swagger if you have any other questions
23:00 marty joined #mojo
23:05 Janos joined #mojo
23:37 Xyem After some tests, changing the shebang and setting the lib in Mojolicious (rather than 'perlbrew use' in dispatch.sh) reduced response time from 0.64 seconds to 0.53 (saving 100ms).

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