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

IRC log for #mojo, 2015-01-30

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

All times shown according to UTC.

Time Nick Message
00:11 gyan joined #mojo
00:30 asarch joined #mojo
00:35 gyan joined #mojo
00:36 muraiki_ joined #mojo
00:40 onelander joined #mojo
00:45 onelander i have a route that contains a while loop that gathers RSS feeds and updates a sqlite database.  i would like to update a <div> in my html when the feeds are processed.  how do i update the <div> inside the route?
00:48 onelander if it is renderer can someone point me to some working code?
00:49 Grinnz_ <div> inside the route?
00:49 Grinnz_ do you mean the response that route generates?
00:49 Grinnz_ you'd do that by passing updated data to the template via the stash
00:52 Grinnz_ if you mean an existing page, well, you're gonna need some javascript
00:55 onelander i do mean an existing page.  if i use javascript then how do i call the javascript function?  i apologize if these are simple questions but i am confused as to updating dynamically.
00:57 gyan joined #mojo
01:02 onelander if it helps.  here is the code i am talking about.  i want to update the html around line 523 - https://github.com/mikeplem/rss/blob/master/rss_sqlite.pl
01:02 muraiki_ so you want your page to retrieve some data and then update what's on it?
01:03 muraiki_ have you used ajax before?
01:05 Averna joined #mojo
01:08 onelander i have used ajax and some of that is used in the code i posted but i am not quite certain how to update without stopping the work going on in the while loop.
01:18 gyan joined #mojo
01:19 onelander after looking over more of the documentation i think i may need to use eventsource.  i will play with that and see if that is what i need.
01:21 mst onelander: seems like you'd be better off having a JSON endpoint that duplicates that data
01:21 mst onelander: and then polling that every so often from javascript
01:22 onelander mst: i will look into that.  thanks
01:25 jb360 joined #mojo
01:26 muraiki_ it also looks like you are doing a series of blocking actions that can take a long time. you have a timeout, but if you used mojo's agent in a nonblocking way, you could pull feeds essentially simultaneously
01:26 mst I was thinking keep it simple since he's new to everything
01:27 mst and that's essentially an optimisation
01:27 mst but absolutely true
01:27 muraiki_ ah, sorry :)
01:27 mst yeah, I just wanted to make clear "you don't have to understand that part -yet-"
01:28 onelander yeah, i want to get to a more simultaneous process but i am not there yet and i do not want to saturate sqlite either with a whole lot of row updates.
01:30 pink_mist mayhaps you should look into switching to something more capable in the future? say postgresql
01:31 onelander i was using it when i started but since i am the only user of the script it was overkill so i went to sqlite.
01:31 muraiki_ oh I see
01:31 muraiki_ yeah if it's just you it's not a huge deal then :)
01:32 onelander i am not trying to make something that will be used by 10s, 100s, or even 1000s of people.  i wanted a replacement for google news so i wrote my own and now i am trying to fix the little things.
01:32 muraiki_ I see. I was thinking you were going to launch this somewhere
01:32 muraiki_ rip google reader :(
01:32 onelander rip indeed
01:35 onelander you guys have been a big help.  thanks all
01:40 gyan joined #mojo
01:42 Grinnz if you do feel like getting into that nonblocking stuff, look at https://metacpan.org/pod/Mojolicious::Guides::Cookbook#Synchronizing-events and https://metacpan.org/pod/Mojolicious::Plugin::DefaultHelpers#delay
01:42 Grinnz with Mojo::UserAgent requests, it's very simple
01:42 pink_mist (and https://metacpan.org/pod/Mojo::Pg too :P)
01:43 pink_mist why have everything else nonblocking if your db isn't nonblocking too? :P)
01:43 pink_mist -)
01:45 onelander good point
01:45 purl nice and sharp
01:45 onelander adding those URLs to my code comments for future use.  :-)
01:47 pink_mist oh wait, sorry, it seems I was mistaken -- that one isn't actually nonblocking
01:48 mst er, Mojo::Pg *is*
01:48 pink_mist "While all I/O operations are performed blocking"
01:48 pink_mist 0_o
01:48 pink_mist it claims not to be
01:49 mst did you even read the rest of that sentence?
01:49 mst "While all I/O operations are performed blocking, you can wait for long running queries asynchronously, allowing the Mojo::IOLoop event loop to perform other tasks in the meantime."
01:49 pink_mist no I got stuck on the word "blocking" :P
01:49 Grinnz lol
01:49 mst my superpower: reading past the first comma before making shit up
01:50 onelander lol
01:50 Grinnz in other words: talking to the DB is blocking, waiting for the DB is not
01:50 pink_mist right :P
01:51 pink_mist Grinnz++ #that's a much better way of wording it than what's written in the docs :P
01:52 dabudabu joined #mojo
01:53 onelander pull request?
01:53 purl somebody said pull request was just a message
02:01 gyan joined #mojo
02:09 inokenty-w joined #mojo
02:10 Vertig0 joined #mojo
02:14 klapperl_ joined #mojo
02:23 asarch joined #mojo
02:25 gyan joined #mojo
02:48 gyan joined #mojo
03:12 gyan joined #mojo
03:13 Averna joined #mojo
03:31 cpan_mojo Mojolicious-Plugin-AutoRoute 0.17 by Yuki Kimoto - http://metacpan.org/release/KIMOTO/Mojolicious-Plugin-AutoRoute-0.17
03:32 gyan joined #mojo
03:49 noganex_ joined #mojo
03:52 gyan joined #mojo
04:05 hshong joined #mojo
04:10 Eke- joined #mojo
04:10 jberger don't anyone show sri the coffee for that module
04:11 jberger :-P
04:11 jberger coffee?
04:11 purl YOU CAN SLEEP WHEN YOU'RE DEAD. or the sacred nectar of life or bulk88's gauge is at E and I need a fillup of Everclear
04:11 jberger s/coffee/code/
04:14 Grinnz sounds like you need some code
04:14 jberger I also need to re read before I post when I'm on my phone
04:15 Snelius jberger: iphone
04:15 Grinnz thats why i switched keyboards when i found out my new one is autocorrecting
04:15 Grinnz i aint havin that
04:15 Snelius i'm just put in off autocorrection
04:16 jberger I'm on android, swipe is good, but I need to double check
04:16 Grinnz i used swype a while ago but it didnt seem that great
04:16 Grinnz but i'm gonna try it again
04:16 s1037989 joined #mojo
04:17 jberger it is very fast
04:17 Snelius hmm swype is hard for my blackberry bold :)
04:18 gyan joined #mojo
04:19 jberger on my laptop I now have a branch on my laptop where you can mount a minion monitor in your running app or start it as a separate command which subclasses from daemon
04:20 jberger and my co-worker has been looking at backbone for the front end
04:20 jberger so who knows, it might be coming along
04:20 jberger but it is something we might really need for work
04:21 preaction nice!
04:21 jberger and it's a fun data binding learning project
04:21 Snelius screenshit ?
04:21 jberger hahaha
04:21 Snelius (8
04:21 jberger my github repo works
04:22 jberger no screenshots yet
04:22 jberger https://github.com/jberger/Minion-Command-minion-monitor
04:23 Grinnz backbone is something the frontend guys at my work use
04:23 jberger and something called lodash
04:24 Grinnz that sounds familiar too
04:24 preaction lodash is nice
04:24 jberger I don't know anything about front end stuff :)
04:24 Grinnz sometimes i wish i got to work with JS, and then i remember i'm really glad i don't
04:24 jberger Grinnz: same
04:24 preaction lodash is like mojo::collection, honestly
04:24 Snelius jberger: waiting for screenshots
04:24 jberger not coming
04:25 Snelius may be tomorrow ?
04:25 Snelius )
04:25 jberger check out the repo
04:25 Snelius ok
04:25 jberger give it a whirl
04:25 jberger a bundle a very simple app which declares the job "sleep"
04:26 Grinnz as long as it looks better than this i think you'll be good https://home.grinnz.com/pokemon
04:26 Grinnz thats the most complicated JS i've written :P
04:26 jberger Snelius: I'm on my phone atm
04:27 jberger and I wouldn't go add far as screenshots until the front-end is solidified
04:27 jberger as far
04:27 Snelius ok ok
04:28 jnbek joined #mojo
04:39 gyan joined #mojo
04:41 hahainternet wasn't there a nice way to run mojo ua from the terminal?
04:41 hahainternet in a succinct manner?
04:41 preaction mojo get 'http://example.com'
04:42 hahainternet i need to do a bit of dom work too
04:43 preaction mojo get 'http://example.com' h1
04:43 preaction read the fine manual on mojo get
04:43 hahainternet when it finishes building on this new install i will
04:44 preaction there's a website that also has the docs
04:45 jberger hahainternet: http://jberger.github.io/MojoliciousIntroduction/#/20
04:47 hahainternet jberger: very nice
04:48 hahainternet one annoyance is that this website uses lots and lots of tables
04:48 hahainternet so the easiest way is just to parse for the link text, not sure i can do that easily from the cli, but no bother
04:48 jberger should be very possible with the correct selector
04:50 hahainternet oh? can you select against a link text? i thought only attributes, not plain text contents
04:50 hahainternet i hate html and everything to do with it :D
04:50 Snelius hahainternet: why? html is briliant!
04:50 jberger not against link text, but presumably you have some structure?
04:51 hahainternet sarcasm tags not included clearly
04:51 Snelius hahainternet: you will go to heaven after that
04:51 hahainternet jberger: the structure is ugly, it's fine i'll write it as a one liner with real perl
04:51 jberger your call
04:51 hahainternet a friend just asked in another channel and i wondered exactly how succinctly it could be done
04:51 hahainternet and the selector would have to be god knows how many tables in a line
04:52 jberger paste a sample somewhere
05:01 gyan joined #mojo
05:03 rem_lex joined #mojo
05:06 jberger aha, all your wifi are belong to us
05:11 hahainternet jberger: oh sorry i was playing about, i think it's a torrent link from http://libgen.in/ not sure how legitimate the site is really
05:16 jberger hahainternet: so if you search "game of thrones" what are you trying to exract?
05:19 jberger titles (link text)
05:19 jberger mojo get http://libgen.in/search.php?req=game+of+thrones 'table.c tr td:nth-child(3) a' text
05:20 gyan joined #mojo
05:33 jberger sri: I really would love a master class on the router
05:33 hahainternet jberger: that's pretty cool, i've no idea exactly what he has in mind so i'll just link him what i have
05:34 jberger its really the only dark continent on my mojo map
05:34 jberger hahainternet: selectors are really nice :-)
05:35 jberger sri: I would love to know why this works: https://github.com/jberger/Minion-Command-minion-monitor/blob/master/lib/Mojolicious/Plugin/Minion/Monitor.pm#L13
05:35 jberger basically copied from the Mount plugin
05:35 jberger (obviously)
05:36 hahainternet jberger: well the problem is that i need to match the link text and then convert it to an abs url
05:36 hahainternet but you'll never guess who i found answering on SO that answered a question i had about it
05:36 jberger yeah, then you need a script
05:36 * jberger guesses bdfoy
05:36 hahainternet guesses wrong
05:44 gyan joined #mojo
06:05 gyan joined #mojo
06:05 jberger for those not in the pm chat, apparently it was me :-P
06:06 jberger nn
06:26 gyan joined #mojo
06:34 dod joined #mojo
06:39 dod joined #mojo
06:46 basiliscos joined #mojo
06:47 gyan joined #mojo
06:51 mtths joined #mojo
06:57 ovnimancer joined #mojo
06:58 Eke- joined #mojo
07:10 dod joined #mojo
07:10 gyan joined #mojo
07:15 noganex joined #mojo
07:31 gyan joined #mojo
07:54 gyan joined #mojo
07:57 reneeb joined #mojo
08:11 sri jberger: http://mojolicio.us/perldoc/Mojolicious/Guides/Routing#Embedding-applications
08:14 eseyman joined #mojo
08:16 gyan joined #mojo
08:16 sri Grinnz: i've been thinking about supporting log rotation on SIGUSR1, but it seems a bit meh when you have SIGUSR2 for single downtime software upgrades
08:16 janus joined #mojo
08:17 Vandal joined #mojo
08:18 stephan48 to me it makes sense to have a seperate log rotation task signal, f.e. with the SIGUSR2 theres always a chance that someone accidentially updated the codebase and a upgrade might break the site... this would suck for an automatism
08:18 stephan48 with a seperate log rotation signal it would be guranteed that only the logs will be rotated and no upgrades or so on are performed, atleast for me it would make it a bit safer for automatism/cronjobs
08:19 stephan48 maybe even fire an event on logrotate to be able to do additonal cleanup by the app when the signal is given
08:20 sri you'd have to restart all workers anyway
08:21 stephan48 okey, i thought logrotate would be something like, move the old logfile away, reopen the handle
08:21 sri workers may run as a different user and not have the permission to reopen the file
08:21 stephan48 ah, so the handle is passed on fork/exec?
08:22 sri on fork
08:22 stephan48 nvm then, i still don't grasp the whole schematics behind hypnotoad at times :)
08:24 trone joined #mojo
08:24 sri Grinnz: if you have a good plan let me know, if the whole thing has tests i might even be ok with a sub reopen { delete shift->{handle} } in Mojo::Log
08:25 stephan48 if theres a restart anyway and theres no guarantee that the old codebased is still used it makes no sense. if the use of the old codebase could be guranteed it would be okey
08:26 sri no, it can't
08:26 stephan48 good then scrap my input :)
08:27 sri even in a running app it can't actually
08:27 sri only the last 100 templates are cached by default
08:27 dotandimet joined #mojo
08:27 sri and controllers the worker has not used are not loaded either
08:28 stephan48 ah okey
08:28 stephan48 makes sense
08:37 gyan joined #mojo
08:47 fhelmber_ joined #mojo
08:58 gyan joined #mojo
08:59 cpan_mojo Mojolicious-Plugin-CGI 0.18 by Jan Henning Thorsen - http://metacpan.org/release/JHTHORSEN/Mojolicious-Plugin-CGI-0.18
09:03 marcusr mst: When are you coming to brussels?
09:04 marcusr any mojo peeps coming besides me and batman?
09:14 odc i'll be there too!
09:17 sri Grinnz: actually forget about it... i don't think it's possible to have a solution that also works for embedded apps... since apps are responsible for logging, and not the server
09:17 marcusr odc: cool!
09:19 gyan joined #mojo
09:19 sri marcusr: tell odc to prepare a new Mango release
09:19 odc i know! i feel so ashamed
09:20 odc though in the end it turned out ok since MongoDB is changing its API again, just before the new release
09:20 marcusr odc: release the flying mangos!
09:21 marcusr odc: you will be able to use that excuse forever :)
09:21 odc lol
09:21 reneeb joined #mojo
09:21 odc (i'm not sure why i'm laughing)
09:22 marcusr odc: sometimes it's better than crying.
09:24 reneeb_ joined #mojo
09:40 gyan joined #mojo
09:41 Insane joined #mojo
09:42 Insane hi all, please, correct me if I'm wrong, but... does Mojo store all session data inside user's cookies?
09:43 Insane I mean, if I want to store big structure in users' session - Mojo will encrypt entire structure and push to client as a cookie?
09:44 sri they are not encrypted
09:46 Insane sri, if cookie is not encrypted, so ehat is secrets() purpose?
09:47 Insane I'm confused witgh now, because I want to store some big hash in session, but it looks like cookie size is getting bigger if hash size is growing
09:47 odc Insane, to sign the cookie (to make sure it's not a fake)
09:48 odc Insane, yes, session == cookie, so you'll have to store you session data in a database
09:49 Insane can Mojo store session data into .tmp files as PHP do?
09:49 Insane I don't want to hande a database only for session data...
09:50 odc err, not that I know of. Although you could use something like DBM::Deep if you don't want to setup something like Redis
09:50 hernan604 read abount hash hmac
09:51 hernan604 or use CHI
09:52 odc oh yes, CHI would be easier
09:53 Insane I don't want to have any storage... my application is some kind of proxy between external API and browsers on mobile phones
09:53 hernan604 you can encrypt the data yourself
09:53 hernan604 and set the cookie
09:54 hernan604 or use html5 local storage
09:54 tomboh I'd only store session data in a cache if my users wouldn't mind arbitrarily having to log in again
09:55 tomboh CHI might be easier for development, but it might also harm your UX
09:59 dotandimet joined #mojo
10:01 good_news_everyon joined #mojo
10:01 good_news_everyon [mojo] kraih pushed 1 new commit to master: http://git.io/FXwK
10:01 good_news_everyon mojo/master 6c240b8 Sebastian Riedel: better descriptions for sessions
10:01 good_news_everyon left #mojo
10:04 gyan joined #mojo
10:07 good_news_everyon joined #mojo
10:07 good_news_everyon [mojo] kraih pushed 1 new commit to master: http://git.io/FXot
10:07 good_news_everyon mojo/master 3318c59 Sebastian Riedel: the tutorial description does not need to be as detailed
10:07 good_news_everyon left #mojo
10:26 hernan604 see you all next week
10:26 gyan joined #mojo
10:34 punter joined #mojo
10:36 chansen_ joined #mojo
10:38 phillipadsmith joined #mojo
10:50 gyan joined #mojo
10:51 Insane wow... how could I change maximum cookie size for Mojo?
10:51 Insane getting this error: [error] Cookie "mojolicious" is bigger than 4096 bytes.
10:52 Insane omg
10:53 Insane sri, why maximum cookie size is hardcoded?
10:58 jkramer Insane: They're browser-side cookies. The maximum for that is 4096
10:58 odc proof: http://browsercookielimits.squawky.net/
11:00 Snelius Guessing Max Cookie Size Per Cookie: 4097 bytes
11:00 Snelius !!!!
11:00 Snelius where is my one byte over ??!
11:00 jkramer It's for the = or : between key/value :)
11:00 Snelius (8
11:00 jkramer Not sure which character it was
11:01 michael Is there a way of determining if another plugin has been loaded, other than $app->can on a helper in this plugin's register()?
11:04 preaction check %INC for the module's package?
11:06 tomboh the %INC approach deals with files rather than classes, so I'd check that %Class::Name:: isn't empty for a more robust approach
11:07 michael INC is still a bit fragile, if class gets renamed. trying to check for functionality, like Moose::Role "requires"
11:07 michael not sure I need it now anyway. but I think the method name "register" for plugins is a bit of a misnomer, since they aren't registered anywhere
11:08 jkramer Or do this :D sub is_plugin_loaded { my $plugin = shift; app->plugin($plugin); return 1 }
11:09 jkramer I think it's called register because that's where you register your helpers and stuff
11:09 cpan_mojo Mojolicious-Plugin-AssetPack 0.36 by Jan Henning Thorsen - http://metacpan.org/release/JHTHORSEN/Mojolicious-Plugin-AssetPack-0.36
11:09 gyan joined #mojo
11:11 jkramer Why do you need to know anyway? If you need a certain plugin to be loaded, just load it
11:11 michael jkramer: yes but Mojolicious::Plugins->register_plugin implies it's registered somewhere (until you read code)
11:12 michael jkramer: this is a framework on top of Mojolicious, multiple apps written using the framework. provides nice error messages for devs writing those apps
11:12 michael i.e. you can't use this plugin without this other pre-req plugin
11:12 jkramer Ah
11:12 jkramer Well you can load plugins within the other plugin I guess if it's a pre-req
11:13 preaction but if it's a prereq, why not just load it? then if that fails, die with an error
11:13 michael but then can't pass arguments to it
11:13 michael the apps have their own options etc
11:13 jkramer Use a config?
11:13 preaction if they want to pass options to the underlying plugin, they can load it first
11:14 preaction or, yeah, dependency injection
11:16 michael config split over file (for stuff people might want to change) and stuff that won't change, but is set per-app, so passing that it at register time
11:18 michael not sure i need it now anyway at the moment, but thanks.
11:22 sri Insane: OMG
11:27 marcusr Insane: if you have more than 4k of session state, you are doing it wrong.
11:29 * sri wonders if we should just allow app->log->reopen and leave all further log management to app developers
11:32 marcusr sri: as opposed to reopening on a signal?
11:32 sri yes, we can't do that
11:33 andrew joined #mojo
11:33 marcusr if we can't do that, I am partial to your plan
11:33 sri problem is embedded apps
11:34 sri servers do have access to the main app, and use its logger, but not to embedded apps
11:34 sri and loggers are local to each app
11:35 gyan joined #mojo
11:36 sri of course handling it yourself in a prefork server sucks too
11:36 sri i don't see a good solution here
11:37 sri just zero downtime restart
11:39 marcusr just never use embedded apps :)
11:39 marcusr or embedded apps should use the main app's logger
11:39 marcusr t
11:39 marcusr guess that's a big change tho
11:40 sri you can't really enforce that
11:40 AndrewIsh Hey guys, I've got a hopefully simple (and probably embarrassingly n00b) non-blocking question. I have an API route that itself makes a request to an external API. I want the requests to the external API to be non-blocking. I have the following code: http://pastebin.com/DsJaFJ20 The problem is that $xml ends up empty. When I manually request $req_url, it returns a result. My previous non-blocking version of this also populated $xml. Any idea what I might
11:40 AndrewIsh be doing wrong?
11:40 sri AndrewIsh: it's non-blocking
11:41 sri http://mojolicio.us/perldoc/Mojolicious/Guides/FAQ#What-is-the-difference-between-blocking-and-non-blocking-operations
11:42 AndrewIsh So my callback will populate $xml once $ua gets a response?
11:43 AndrewIsh Sorry, I'm really new to non-blocking stuff with Mojo...
11:50 AndrewIsh Aha, so the "say $xml" needs to go inside the callback! Of course!
11:51 sri :)
11:53 AndrewIsh Thanks, jeez that took a while to sink in...
11:58 gyan joined #mojo
12:12 human39 joined #mojo
12:15 good_news_everyon joined #mojo
12:15 good_news_everyon [mojo] kraih pushed 1 new commit to master: http://git.io/F1s6
12:15 good_news_everyon mojo/master 37304c2 Sebastian Riedel: better Windows error messages
12:15 good_news_everyon left #mojo
12:20 gyan joined #mojo
12:21 AndrewIsh OK, more problems, hopefully someone will be able to help. This is the supposedly non-blocking portion of my code: http://pastebin.com/j6TzgU9w Loading in a browser renders a blank page, i.e. $xml is not being populated. Manually requesting $req_url returns a result, so I know that bit is working. Does anyone have any idea what I'm doing wrong? Thanks :)
12:26 jkramer Use $self->ua-> instead of a new UA
12:28 AndrewIsh Yep, that's got it, thanks :) Is that because starting IOLoop creates a UA that I need to use instead of creating my own?
12:40 gyan joined #mojo
12:53 kaare joined #mojo
12:54 neilhwatson joined #mojo
13:04 gyan joined #mojo
13:08 asarch joined #mojo
13:09 jberger sri: omg I totally forgot about that guide section
13:09 jberger guess that means it's time to re-read the whole thing again
13:10 jberger I wonder what else I forgot
13:10 jberger sidenote, embedding apps is really fun
13:11 jberger I'm glad that that is supported
13:11 reneeb joined #mojo
13:27 gyan joined #mojo
13:38 tencendur joined #mojo
13:49 gyan joined #mojo
13:52 marty joined #mojo
13:59 sri AndrewIsh: no, $ua goes out of scope and is garbage collected by perl
14:01 AndrewIsh sri: Ah, ok, makes sense, thanks :)
14:12 gyan joined #mojo
14:29 amon joined #mojo
14:34 gyan joined #mojo
14:44 good_news_everyon joined #mojo
14:44 good_news_everyon [mojo] kraih pushed 1 new commit to master: http://git.io/FMsg
14:44 good_news_everyon mojo/master 774c03e Sebastian Riedel: show the calling subroutine too
14:44 good_news_everyon left #mojo
14:48 sri not sure if ... or do_something_with_the_result($result) make for better examples in cases like this
14:54 ryozi joined #mojo
14:57 gyan joined #mojo
14:59 daniel_ joined #mojo
14:59 daniel_ Hi everybody!
14:59 purl Hi, Dr. Nick!
14:59 daniel_ lol
15:00 daniel_ i just started using mojolicious, and its pretty nice, i am trying to make an json api, however i have a problem when the object returning is empty i get an error page
15:01 daniel_ how do i fix that so it just displays nothing instead of an error page
15:02 mst 'object returning is empty' ?
15:02 mst if there's nothing there surely you wanted to return a 404
15:03 jberger daniel_: or do you mean no content?
15:03 daniel_ yes, no content in the object
15:03 jberger define object?
15:03 jberger {}
15:03 jberger ?
15:04 jberger or an empty response body?
15:04 mst daniel_: that's not valid for json
15:04 jberger $c->rendered(204) might be what you mean for literally no content
15:04 mst daniel_: and makes no sense
15:04 mst daniel_: what do you actually -mean- by 'no content'
15:04 mst daniel_: be specific
15:06 mst marcusr: I AM IN BRUSSELS
15:07 ignacio_ joined #mojo
15:10 * sri wonders if Mojo::Server::Prefork should support SIGHUP, for restarting all workers at once
15:11 sri makes is easier to support some other signal in the manager process that changes state
15:12 sri $SIG{USR1} = sub { app->log->reopen; kill 'HUP', $$ };
15:18 sri not sure if it's worth 2 lines of code https://gist.github.com/anonymous/e47a78ff4398a5b4fd64
15:21 Ptolemarch joined #mojo
15:23 gyan joined #mojo
15:26 sh4 joined #mojo
15:30 fhelmber_ joined #mojo
15:31 dotandimet joined #mojo
15:37 jberger seems like a sane feature
15:41 hahainternet o/ jberger
15:41 jberger \o
15:42 Grinnz sri, how does hot deployment work now?
15:43 hahainternet so is there any reason that Mojo::DOM couldn't translate <a href> attrs into Mojo::URIs?
15:43 Grinnz sri, and btw i like the log->reopen idea, it would also make it easier to change path of an existing log object
15:43 jberger hahainternet: I worked on that for a while, it just isn't pleasent
15:43 hahainternet jberger: oh?
15:43 gyan joined #mojo
15:43 hahainternet did you manage to golf what i pasted you? no pressure either way
15:44 jberger I tickered for a few minutes, but I didn't have a good page to query
15:44 jberger could you send me an example link?
15:44 jberger and g() is difficult in your case because it doesn't give you the $tx
15:46 Grinnz sri, the HUP signal makes sense also
15:47 hahainternet jberger: one moment, and yeah that's exactly why i think the DOM should parse the URI
15:47 hahainternet it makes sense to me at least
15:54 gryphon joined #mojo
15:59 * sri is very -1 on Mojo::DOM automatically generating Mojo::URL objects
15:59 hahainternet sri: how so?
15:59 hahainternet or restated: why?
16:00 mst it would be ugly, fragile, and make it impossible to use Mojo::DOM for some valid purposes
16:00 hahainternet the first two surely depend on implementation, the latter though i'm intrigued
16:00 hahainternet what would it make impossible?
16:00 sri everything in Mojo::DOM is neutral atm., works the same for HTML and XML
16:01 mst the value in href at parse time can easily not be a valid URI
16:01 sri the last time we tried adding an HTML specific feature (Mojo::DOM::val) it turned out terrible
16:01 Grinnz sri, restarting the workers will restart the app right? whats the difference between hot deployment and the HUP worker restarts you propose
16:01 hahainternet sri: my primary concern is having to keep $tx around or do slightly ugly chains in order to keep the base url around
16:01 mst <a href="{{protocol}}://{{host}}">
16:01 sri Grinnz: HUP only restarts the workers, manager stays the same
16:01 hahainternet that strikes me as a little in-elegant
16:02 Grinnz what does the manager hold?
16:02 mst hahainternet: even if Mojo::DOM provided URLs you'd still be responsible for keeping the base URL around
16:02 mst a DOM doesn't intrinsically have a URL
16:02 mst it could've come from a string
16:02 hahainternet yes but this sort of separation while fine in theory, leads to difficulties
16:02 mst so your primary concern can never be solved by Mojo::DOM
16:02 hahainternet not that i want to criticise DOM
16:02 mst forget fine in theory
16:02 purl mst, I didn't have anything matching fine in theory
16:02 sri Grinnz: USR2 does a fork/exec of the manager, starting a completely new server
16:02 mst it's how stuff actually works
16:02 hahainternet but i think it's not infeasible to assume a DOM will commonly have an url
16:03 mst it's making your trivial case slightly harder
16:03 sri Grinnz: the manager holds the original app instance
16:03 mst your minor inconvenience doesn't justify ruling out lots of other valid uses
16:03 hahainternet i'm not really complaining about difficulty, or complaining in general
16:03 hahainternet mst: nobody is trying to rule out other valid uses, please stop accusing me of that
16:03 Grinnz sri, i see
16:03 mst hahainternet: stop proposing ideas that do then
16:03 hahainternet mst: it doesn't, i haven't, stop it
16:04 hahainternet i'm literally asking questions and trying to learn, no need for the hostility
16:04 sri mst: everybody here is welcome to propose as many silly ideas as they like
16:04 hahainternet one of my annoyances with other frameworks is the idea that as soon as you get to a DOM object you throw away any possible other references
16:05 mst sri: of course
16:05 mst sri: and I can call them silly
16:05 mst sri: and if they ask me to stop calling their ideas silly, I'm going to suggest not proposing silly ideas if they want that to happen :)
16:05 hahainternet mst: calling it a silly idea is fine, straw manning me and telling me to stop talking about stuff, that's a bit too far
16:05 mst hahainternet: I mirrored your words telling me to stop saying things that you didn't like
16:05 mst if you don't want those words used on you, don't use them on me first
16:05 hahainternet that's not what i said either, please stop making up things and then claiming i said it
16:06 mst anyway, it's clear you don't want to actually understand this
16:06 mst so I'll leave you to it
16:06 mst sri: sorry for the noise
16:06 hahainternet that's also nonsense, i am actually very interested in understanding it
16:06 hahainternet but i still fail to understand how a url helper, or the facility to remember a base url would rule out other use cases
16:06 hahainternet sri's point about HTML specificity seems valid but i wasn't around for ::val so i have no idea what problems occurred
16:07 kaare joined #mojo
16:07 jberger hahainternet: the basic problem is that it goes beyond scope
16:07 mst sri: if you were interested you'd've asked questions instead of attacking me and then trying to blame me for it
16:08 mst bah
16:08 mst hahainternet: ^^
16:08 mst stuff this, I'm just going to get trolled here; kill file time
16:08 hahainternet mst: i did ask questions, i never attacked you, you made up things from me like saying "telling me to stop saying things that you didn't like"
16:08 jberger ok, ok, we've had our little spat, calm down
16:08 hahainternet this never happened
16:08 hahainternet and if i wanted to troll i'd certainly do it somewhere i don't care about as much
16:08 hahainternet it's something that would have come in useful for some fun golf, that's it
16:09 sri mst: i don't care about the feature, but i am interested in keeping it civil here
16:09 hahainternet so if it turns out that it is out of scope then fine, i just think that a DOM holding its own URI could potentially make sense
16:09 jberger hahainternet: I would encourage you to attempt a full proposal if you are interested, I think you will see as you go that the scope creep become more than you would expect
16:09 hahainternet jberger: yeah quite possibly, there's nothign wrong in principle with separation like this, but it can be taken too far
16:09 mst sri: and that's why I've killfiled him, since all he seems to be able to do is yell 'attack!' when I try and explain the situation
16:10 * hahainternet shrugs
16:10 sri can we all calm down now?
16:10 hahainternet sri: i still don't understand why it would rule out xml use or similar :(
16:10 genio Is this a good time for me to run around screaming like a maniac?
16:10 sri the SIGHUP feature actually interests me
16:10 jberger for the record, the precedent for $dom having a base would be that $url has a base attribute. the difference is that since $dom does not have a mechanism to extract a relative url from an element, it doesn't make sense to keep on there (until it did)
16:10 jnbek joined #mojo
16:10 hahainternet i guess i'll go read the code, that's usually the easiest way to get these questions answered
16:11 mst and, also, a DOM meant for templating could easily have an href or src attribute that isn't a valid URL
16:11 hahainternet sri: i will shut up for now or help out in a SIGHUP discussion
16:11 mst so trying to force it into that mode would be a problem
16:12 sri hahainternet: jberger proposed this before, i'm specifically referring to his proposal
16:12 sri hahainternet: which conincidetally had a lot in common with ::val
16:12 hahainternet sri: well i don't even have a proposal at all, i am just interested in why it failed so i can understand it better
16:12 hahainternet sri: i just found that having to keep $tx around just for a base url was a little frustrating, and ojo's g() returns the res, not the tx
16:13 sri hahainternet: sorry, i'm not interested in discussing it again... last time was not so pleasant for me... :/
16:13 hahainternet so there's just a couple of places i could see that from my initial look, could be smoothed over
16:13 hahainternet sri: haha no problems
16:13 sri hahainternet: you could look it up in the channel logs i guess
16:13 hahainternet yeah i'll bug jberger at some point and read the code
16:13 hahainternet it's no big deal, every time i come back to mojo though there's 5 new modules and 50 awesome changes for me to read up on
16:13 hahainternet so i never get a chance :D
16:13 mst I made many of the same points last time as well, without getting interrupted by somebody calling disagreement attack that time
16:13 mst so those are probably more coherent than I'd manage now too
16:14 dotandimet joined #mojo
16:14 hahainternet sri: so back to SIGHUP? :D
16:14 jberger mst: he has relented, lets move on
16:14 hahainternet don't let me distract the channel
16:15 mst jberger: I'm mostly saying "if you find those logs, you'll find the point I was trying to make too"
16:15 hahainternet and mst fwiw my problem was just that you seemed to immediately start criticising the implications of a question, i wasn't trying to demand people write my code or anything, but you were acting as if i had insisted it was 100% the right way to go and other use cases be damned
16:15 hahainternet but no more distraction, SIGHUP HO!
16:18 sri Grinnz: problem with log reopening is that you can't cover embedded apps
16:18 sri dotandimet: made progress with highlight.js? :)
16:19 dotandimet :(
16:19 sri ?
16:21 disputin joined #mojo
16:23 jberger -o/
16:23 jberger \o-
16:23 gyan joined #mojo
16:23 sri /o\
16:24 genio IRC brought to you by Jane Fonda?
16:26 hahainternet o7
16:26 hahainternet slight annoyance
16:26 hahainternet no british salute possible in base ascii
16:26 hahainternet have to salute the bloody yank way
16:35 sri does anyone actually care about the HUP signal patch?
16:36 hahainternet honestly i thought it was already supported
16:36 hahainternet HUP is a bit of an ugly signal in general, but it seems based on lastlog that it's an intelligent choice
16:37 sri could it be confusing that HUP only restarts workers, but does not reload the app?
16:37 hahainternet it certainly could be
16:37 sri that's a solid reason against it i suppose
16:37 hahainternet but i guess the question is above my pay grade
16:37 hahainternet as long as it's well documented that you must hot deploy to update the app itself, and HUP simply restarts the workers
16:38 hahainternet it looks like the original concern was something like logrotate where a filehandle needed reopening but no deployment was required?
16:38 hahainternet periodic restarts and things like that do occur in some environments, so it's feasible it would be a useful feature
16:39 sri of course, if workers have to go down, why not just use a zero downtime restart?
16:40 hahainternet can you trigger it by a simple pkill in a logrotate script? if so then no argument from me
16:40 sri kill -s USR2
16:41 hahainternet job done then
16:41 hahainternet probably a better choice too as you won't get that confused with ^D
16:42 Grinnz_ sri: i want the ->reopen method more than HUP tbh :)
16:43 sri on it's own i'm -1 on that
16:43 Grinnz_ well it's either that or i keep using "delete $log->{handle}"
16:43 Grinnz_ there is no public API way to do this atm
16:44 hahainternet Grinnz_: what's provoking this requirement?
16:44 good_news_everyon joined #mojo
16:44 good_news_everyon [mojo] kraih pushed 1 new commit to master: http://git.io/FDcV
16:44 good_news_everyon mojo/master bb00095 Sebastian Riedel: fix typo in prefork test
16:44 good_news_everyon left #mojo
16:44 hahainternet still one of my favourite things that the bot is called good_news_everyone
16:44 hahainternet can't help but hear that in my head
16:44 Grinnz_ hahainternet: the ability to change the path for an existing Mojo::Log object, and to reopen a Mojo::Log handle after logrotate
16:45 sri Grinnz_: how would reopen after logrotate work?
16:45 hahainternet haha guessed it would be logrotate, yeah that's a fairly important feature
16:45 Grinnz_ sri: that's up to my application
16:45 hahainternet but given sri says you can restart the workers with a SIGUSR2
16:45 hahainternet i don't see the problem with that
16:45 Grinnz_ sri: i'm not just talking about the application log
16:45 sri Grinnz_: i'm not convinced it's possible
16:45 hahainternet changing the path dynamically seems a little ugly too, wouldn't you prepare a new object and swap them out? idk
16:46 sri Grinnz_: note that i'm considering the prefork case here
16:46 RenatoCRON lala
16:46 Grinnz_ sri: for the application i can do a hot deployment if necessary, thats not a problem
16:47 Grinnz_ sri: i think having a HUP for reopening the application log would be a good idea but i don't know the best way to do that
16:47 sri Grinnz_: i don't think that's possible
16:48 hahainternet although my input here isn't that helpful, i have to say that being able to poke a process to reopen its logfiles is EXTREMELY useful at times
16:48 hahainternet so +1 for the ability to do that if it is feasible
16:48 sri hahainternet: not the point at all
16:48 Grinnz_ sri: to make sure i'm understanding this right; what you proposed before is essentially the workers would stop the same way they do after handling X requests, and be restarted by the watcher?
16:48 sri i said earlier i would accept the feature, but nobody made a good proposal
16:49 hahainternet sri: well i am ignorant of the internals of the log and just wanted to put my views forward, i haven't even had chance to read Mojo::DOM yet so i have nothing to say about the internals
16:49 sri Grinnz_: i have made no complete proposal
16:50 Grinnz_ sri: i meant proposed in the colloquial sense
16:50 sri i have suggested a HUP signal to restart all workers, and an app->log->reopen method as primitives for log rotation
16:50 sri $SIG{USR1} = sub { app->log->reopen; kill 'HUP', $$ };
16:50 sri that was the idea
16:51 DaniBunn1 joined #mojo
16:51 sri but it's a silly idea
16:51 sri since if you stop all workers anyway, you might as well use SIGUSR2
16:51 Grinnz_ but SIGUSR2 will reload the app, is the difference, right?
16:51 sri yes
16:52 Grinnz_ that could be a big difference for some
16:52 sri how so?
16:52 Grinnz_ more chance for failure
16:52 sri if the app fails the old manager keeps running
16:52 Grinnz_ right, but you don't get the log reopened
16:52 sri if your app fails you've got bigger problems
16:53 Grinnz_ true, its just an additional moving part is all im saying
16:53 sri and HUP is another feature withtout tests
16:53 sri that raises the bar substantially
16:55 Grinnz_ my question would be why have two different signals? why not just have HUP reopen the log and restart the workers?
16:55 sri which reminds me, if anyone is looking for something to hack on, TTIN/TTOU signals could use some tests in t/mojo/prefork.t
16:55 Grinnz_ (i think HUP is usually what's expected to be passed from logrotate)
16:55 sri Grinnz_: because the server has only access to the main application log, not embedded apps
16:56 sri Grinnz_: you're wrong, SIGUSR1 is usually for logrotate
16:56 Grinnz_ oh, right
16:56 sri SIGHUP is for reload config and restart workers
16:56 Grinnz_ fair enough then
16:57 Grinnz_ regarding embedded app: i don't think there's going to be a catch all solution, but i think giving the tools to do it is better than nothing
16:57 sri i don't think so actually, giving the tools without a clear way to use them will cause confusion
16:58 sri as we've seen earlier today already
17:00 sri i do not believe you could use app->log->reopen for logrotate
17:00 Grinnz_ well in my situation, without these tools my strategy will continue to be delete $log->{handle} on startup, and running a hot deployment after logrotate
17:00 dod joined #mojo
17:00 sri if you show me a way, i will consider it
17:00 Grinnz_ on path change*
17:01 sri right now it's all just handwawing... "IF YOU PROVIDE THE TOOLS THEY WILL COME!"
17:01 Grinnz_ why do you not think it could be used for logrotate?
17:02 sri SHOW ME! :)
17:02 sri sub reopen { delete shift->{handle} }
17:02 sri use that to show me a logrotate scenario
17:03 Grinnz_ it would be as you said, it would send SIGUSR1, reopen and restart the workers
17:03 Grinnz_ that would be sufficient for my case
17:03 sri for which USR2 is better
17:04 Grinnz_ i don't agree with that
17:05 Grinnz_ less intrusion from logrotate seems better
17:05 gyan joined #mojo
17:06 Grinnz_ but as i said, in my case either would work
17:06 sri agreed, and USR2 is less intrusive, since the server never stops serving requests
17:06 Grinnz_ it would with USR1?
17:06 sri server1 only stops once server2 is ready to take over
17:07 sri yes, on HUP all workers stop accepting connections
17:07 Grinnz_ hmm
17:07 sri and then there's a graceful shutdown time when no connections are being accepted
17:08 sri which may be minutes
17:08 Grinnz_ that would be a problem
17:08 sri with USR2 the first server keeps working normally until the second is ready to accept connections, and only then shuts down gracefully
17:09 sri it's very elegant since 5.75
17:09 sri the first server actually waits until all workers of the second have already sent a heartbeat signal
17:10 Grinnz_ yes i like that update
17:11 sri re: delete $log->{handle}
17:11 Grinnz_ so the only way HUP would be usable for logrotate is if it didn't prevent accepting connections
17:11 Grinnz_ which probably cannot be done in a simple way
17:11 sri it seems to be a common problem that resetting an attribute is hard
17:12 sri why not solve it once and for all?
17:12 sri perhaps a Mojo::Base method
17:12 Grinnz_ standard attribute clearing mechanism?
17:12 Grinnz_ seems simple enough
17:13 sri ->reset_to_default('foo') or whatever
17:13 sri the trick will be to find something elegant
17:14 jberger simple sure, but is it necessary? data isn't private in your own class, it is private externally
17:14 jberger I think it makes sense to add a reopen method in Log
17:14 sri use case?
17:16 sri (no, logrotate does not count)
17:16 Grinnz_ why not?
17:16 jberger I'm not fighting for reopen, I'm saying that I think I'm against an attribute clearer
17:16 * sri is starting to get a little upset
17:16 sri we've established that ->reopen cannot be used for logrotate
17:17 jberger sorry, I retract all previous example with reopen, I meant that in relation to clearer only
17:18 sri Grinnz_: in fact, i'm leaving the discussion now
17:18 Grinnz_ alright...
17:18 jberger I think it makes sense for a class to declare a clearer if it wants one, I don't especially want a generic clearer as a new method in all my Mojo::Base classes
17:19 sri jberger: it's more a "reset to default value"
17:19 jberger that's Moose' clearer
17:19 sri since you can assign undef, but not nothing
17:20 jberger in Moo(se)? you have to declare that an attribute has a clearer, it doesn't get one by default
17:20 sri ye
17:20 dotandimet joined #mojo
17:21 sri perhaps
17:21 purl then again, perhaps not
17:21 sri perhaps "delete $object->{foo}" is ok too... since Mojo::Base specifically mentions that it is a hash based object
17:21 * sri shrugs
17:21 jberger that's how I would see it
17:21 jberger it is used all over the mojo codebase
17:21 jberger especially with regard to weakening attributes
17:22 sri we have the same with weaken $object->{foo}
17:22 jberger now if we wanted to do something cool, a weak attribute would be really cool
17:22 sri ye :)
17:22 sri we had weak attributes, they were terrible ;p
17:22 jberger hmmmm, must have been before me
17:22 * sri nods
17:23 jberger the setter was too confusing?
17:24 jberger I guess there is some ambiguity sometimes too, an attribute which might only be weakened sometimes
17:24 sri personally, i think the idea of a weak attribute is silly, since the caller is usually the one that needs to decide if a value needs to be weakened
17:24 sri right
17:25 jberger but that necessarily requires a semantically named hashref based object
17:25 jberger so that's what we assume then
17:25 jberger OR
17:25 sri we do assume that with Mojo::Base
17:26 sri it's documented
17:26 dotandimet sri: still struggling to get perl highlighting triggered - the xml syntax devours all when it's at the top level. I notice PHP is embedded in the xml syntax as a sub-language, which is not a good sign.
17:26 jberger sub Mojo::Base::weaken { weaken shift->{shift} }
17:26 sri dotandimet: :(
17:26 Grinnz_ maybe Mojo::Base can document the intended way to clear attributes?
17:26 dotandimet sri: that's what I said.
17:27 jberger Grinnz_: I'd be interested to see that doc patch
17:27 Grinnz_ yeah i'm not sure how yet
17:28 sri Mojo::Collection and Mojo::ByteStream specifically mention that stuff in their docs
17:28 sri @$collection and $$stream
17:28 jberger https://github.com/kraih/mojo/blob/master/lib/Mojo/Base.pm#L193
17:28 jberger hashref based object
17:29 sri of course it's a fine line... you don't want to suggest that poking into private attributes is a good idea
17:29 Grinnz_ exactly
17:29 sri if it's exposed with a public accessor it's fair game imo., but that's it
17:29 hahainternet i have a pathological hatred of private attributes
17:29 jberger so an additional sentance might be added that clearers can be implemented by deleting the attribute causing the default behavior to be available again
17:29 hahainternet is it just me?
17:30 jberger sri: I don't see it as a fine line, if you are declaring the class, you can dip into the hashref, if you are outside, you cannot
17:31 jberger a nice, thick, brightly painted line
17:31 sri we are talking about delete $app->log->{handle} though
17:31 jberger right, log would have to implement that
17:31 jberger in my view
17:32 jberger which is why I think Mojo::Base::weaken might be nice, to prevent callers from having to dip into the hashref
17:32 jberger though they get to control the strength
17:34 sri lol
17:34 sri you can make the same argument for Mojo::Base::reset_to_default
17:36 rem_lex joined #mojo
17:37 sri $object->weaken('foo'); $object->clear('foo')
17:38 Grinnz_ seems ok to me but it could be a concern introducing new methods to everything using Mojo::Base
17:38 sri haha, or generate methods... $object->weaken_foo; $object->clear_foo
17:39 Grinnz_ then you are doing it the moose way :P
17:39 Grinnz_ well, not for weaken, hah
17:39 gyan joined #mojo
17:40 asarch joined #mojo
17:40 sri of course weaken_foo and clear_foo would be a bad idea... security risk for controllers
17:40 Grinnz_ security risk?
17:41 jberger yea, not sure what to do about that
17:41 jberger :/
17:41 sri i guess Mojo::Base::weaken/clear would work well though
17:42 sri no, adding a method to Mojo::Base is no problem, as you can see from Mojo::Base::tap
17:47 jberger throwing stuff at the wall, perhaps a {} argument to has
17:48 jberger { weaken => 'weaken_foo', clear => 'clear_foo' }
17:48 sri now weaken is on the wrong side again
17:48 jberger no, that just provides access to the outside
17:49 basiliscos joined #mojo
17:49 jberger so you would do $target->foo($value)->weaken_foo
17:49 sri and if the clearer is opt-in, each will need a use case again
17:49 dotandimet joined #mojo
17:50 sri guess this is going nowhere
17:50 jberger yeah, its kinda feeling forced
17:51 sri not like we have to make a decision
17:51 sri if there's no good option we stick to what we have
17:51 Grinnz_ perhaps, see if any better use cases come up
17:51 jberger somewhow I don't hate "weaken $target->{foo}" but I do hate "delete $target->{foo}"
17:51 jberger that seems odd
17:51 Grinnz_ the delete is a more direct modification
17:51 Grinnz_ perhaps
17:52 jberger yeah, delete is going to cause behavior to change
17:52 jberger but not in an unknowable way
17:52 sri weaken is actually more dangerous
17:52 Grinnz_ it could be, but also, weaken cannot trigger the default
17:53 pink_mist if you know you need to weaken something, it feels like you already know too much about the inner workings of it
17:53 Grinnz_ the danger of either is really dependent on how the attribute is used
17:54 sri pink_mist: i soo wish we didn't have to know about weaken at all
17:54 pink_mist I guess my point was that "since you _already_ know, just use the knowledge" :>
17:55 pink_mist but yeah, I really wish it was unneeded too
17:55 Grinnz_ it still breaks the encapsulation when you have to access its hash attributes
17:55 Grinnz_ but, thats how its done already
17:56 jberger I guess that's where my view is, I kinda don't see weakening as breaking encapsulation
17:56 jberger I wish it didn't look like it though
17:56 Grinnz_ i guess the way i see it is, if an attribute foo was internally stored at $obj->{bar} everything thats properly encapsulated should still work
17:56 jberger If I could pass in a pre-weakened variable, that wouldn't be breaking encapsulation
17:56 Grinnz_ but Mojo::Base has assumptions already that the name is the same
17:57 jberger perl just doesnt have that feature
17:57 Grinnz_ so its not a big deal
18:05 gyan joined #mojo
18:09 rem_lex joined #mojo
18:11 sri hmmm
18:12 sri i wonder if hypnotoad should start a new worker before the old one has been stopped
18:13 Grinnz_ the concern with that would be extra ram usage
18:13 sri (while it's stopping gracefully)
18:14 Grinnz_ but, that happens during a hot deployment anyway
18:15 Grinnz_ if the old one does not accept new connections i think its reasonable to start the new worker right away
18:26 disputin joined #mojo
18:27 gyan joined #mojo
18:33 tencendur joined #mojo
18:54 dotandimet joined #mojo
19:08 punter joined #mojo
19:12 hahainternet sri: oh i assumed that's how it worked already
19:12 hahainternet the safest way seems to be to bring up a new worker, check it actually starts, then gracefully kill the old
19:12 hahainternet idk again i'm ignorant of internals and lots more besides
19:23 Eke- joined #mojo
19:29 sri it would be a simple change now, but there is indeed the problem of memory use
19:29 sri if you have a few workers stopping gracefully that can add up
19:30 reneeb joined #mojo
19:30 sri worst case, twice as many active workers
19:33 Grinnz one thing to note: apache from sig USR1 restarts workers only once they've exited
19:33 Grinnz i'm not sure if that means the workers continue accepting connections
19:33 Grinnz but that wouldnt make sense
19:34 sri "What doesn't work? Cookie parsing."... wtf? http://www.slideshare.net/cstrep/mojolicious-what-works-and-what-doesnt
19:34 Grinnz ?
19:35 sri oh, 2011...
19:35 Grinnz yeah i have a question, elaborate more than "cookie parsing"
19:35 Grinnz lol
19:35 sri that just popped up on my twitter... guess it's just a spam site
19:37 Grinnz on nginx it just tells its workers to reopen log files
19:37 Grinnz so that doesnt help, heh
19:38 dotandimet joined #mojo
19:39 Grinnz the nginx method is certainly more immediate though
19:40 hahainternet sri: hmm well that shouldn't be that significant should it?
19:40 hahainternet what portion of a worker's memory is unique?
19:40 hahainternet it's all preforked isn't it? so surely a significant fraction is cow
19:41 hahainternet RAM is relatively cheap but that's no excuse if the overhead is quite high i guess
19:41 Grinnz if you're using hypnotoad i would think you should have enough RAM for hot deployment to function
19:41 Grinnz but, i dunno
19:41 sri that is a good point
19:42 hahainternet i don't have anything big running on mojo i can look at the stats on
19:43 hahainternet and frankly as mojo is just a little framework around what could be monstrosities in the user's code, i don't think you can really do anything about it sri
19:43 hahainternet for all you know the next 5 bytes are the last 5
19:55 good_news_everyon joined #mojo
19:55 good_news_everyon [mojo] kraih pushed 1 new commit to master: http://git.io/FSJH
19:55 good_news_everyon mojo/master b58d7ad Sebastian Riedel: improve Mojo::Server::Prefork to start a new worker as soon as an old one signals that it is shutting down gracefully
19:55 good_news_everyon left #mojo
19:58 sri not entirely sure about that yet
19:59 basiliscos joined #mojo
20:04 sri yea, i guess it's too dangerous
20:05 sri especially with the possibility of two graceful shutdowns overlapping
20:05 Eke- joined #mojo
20:06 good_news_everyon joined #mojo
20:06 good_news_everyon [mojo] kraih pushed 1 new commit to master: http://git.io/FStu
20:06 good_news_everyon mojo/master 92f9903 Sebastian Riedel: starting new workers early is too dangerous
20:06 good_news_everyon left #mojo
20:08 Grinnz_ is the graceful shutdown of a worker used outside of manual graceful shutdowns?
20:08 Grinnz_ maybe prevent graceful restarts if a worker is already flagged for that
20:08 sri it is used for pretty much everything
20:08 Grinnz_ ah ok
20:09 sri workers that have reached their accept limit also signal the parent that they are shutting down gracefully
20:09 sri which then applies the graceful timeout
20:10 Grinnz_ have to consider interactions with that as well, then
20:10 sri making those restarts faster was the whole point
20:11 Grinnz_ i'm pretty sure apache actually spawns new workers immediately on graceful restart, even though the docs are ambiguous
20:12 sri workers have an accept limit, 1000 connections by default, after that they stop accepting new connections, tell the parent they are done, and gracefully stop, once that is done the parent starts a new worker as a replacement
20:12 sri we are an app server, so we have much heavier memory requirement
20:12 sri s
20:12 Grinnz_ apache likes to think it's an app server sometimes :P
20:13 sri apache is mostly legacy
20:13 Grinnz_ indeed
20:13 sri lots of shitty design decisions by todays standards
20:13 sri nginx is much better
20:13 Grinnz_ what about the case where all of the workers reach the limit at the same time? then the server would also not be able to accept connections?
20:14 sri hypnotoad is mostly based on the nginx design
20:14 sri correct
20:14 sri *but*
20:15 sri up to 50% of the accept limit is subtracted randomly
20:15 sri so odds of all workers stopping at the same time are very low
20:18 Grinnz_ i'm interested how nginx solves this, but the documentation isnt much help
20:19 sri nginx does not restart workers regularly
20:19 Grinnz_ ah
20:19 Grinnz_ hypnotoad does because of perl memory leaks, right?
20:19 sri it's not an app server, no leaks
20:19 Grinnz_ nginx also has an integrated perl interpreter, lol
20:20 Grinnz_ but i am very glad i don't have to use it
20:20 sri i hope nobody does
20:20 Grinnz_ it's like mod_perl 1 in functionality
20:20 Grinnz_ *shudder*
20:21 marmez joined #mojo
20:21 Grinnz_ ok, well on HUP, nginx starts new worker processes immediately, and the old ones gracefully stop
20:21 Grinnz_ that's the closest analogue i guess then
20:22 Grinnz_ i see it has similar USR2 functionality
20:24 Grinnz_ maybe there should be a flag for graceful restart so it doesn't overlap (regardless of this issue)
20:35 dotandimet alllllrightie!
20:38 dotandimet This was giving me problems with highlight.js: <%{1,2}={,2}
20:38 dotandimet Apparently, it wants <%{1,2}={0,2}
20:39 sri \o/
20:39 * jberger hands dotandimet a beer
20:39 * jberger assumes he needs it
20:41 Lee joined #mojo
20:45 dotandimet jberger: thanks
20:46 dotandimet https://github.com/dotandimet/highlight.js/blob/mojo/src/languages/mojo-ep.js
20:47 dotandimet Now lets see about templates in the __DATA__ section (perl in xml in perl, how very yo dawg)
20:49 sri dotandimet++
20:52 jberger dotandimet: does that handler for %= have to start at the beginning of a line?
20:52 jberger I see a ^ in your pattern
20:52 sri there seems to be a \s* missing
20:56 good_news_everyon joined #mojo
20:56 good_news_everyon [mojo] kraih pushed 1 new commit to master: http://git.io/FSwn
20:56 good_news_everyon mojo/master 9d08386 Sebastian Riedel: fix bug in Mojo::IOLoop where the accept limit was applied too broadly
20:56 good_news_everyon left #mojo
20:59 good_news_everyon joined #mojo
20:59 good_news_everyon [mojo] kraih pushed 1 new commit to master: http://git.io/FSoK
20:59 good_news_everyon mojo/master 134bc00 Sebastian Riedel: fix typo in Changes
20:59 good_news_everyon left #mojo
20:59 dotandimet joined #mojo
21:00 Eke- joined #mojo
21:01 sri dotandimet: http://irclog.perlgeek.de/mojo/2015-01-30#i_10034302
21:01 sri in case you missed it
21:06 dotandimet updated the test case and added the optional indent.
21:07 dotandimet (reload the previous link to see it)
21:07 dotandimet The test is here: https://github.com/dotandimet/highlight.js/blob/mojo/test/detect/mojo-ep/default.txt
21:08 sri yay
21:13 sri there's whitespace missing in front of those two "true" values :)
21:14 sri and the indentation is off ;p
21:15 dotandimet no perltidy for javascript :(
21:20 reneeb joined #mojo
21:21 Grinnz_ jslint
21:37 gyan joined #mojo
21:40 Eke- joined #mojo
21:42 marty joined #mojo
21:42 jrhunt joined #mojo
21:45 Grinnz_ joined #mojo
21:45 berov joined #mojo
21:53 punter joined #mojo
21:56 dotandimet I fiddled with the whitespace by hand. I think I'm done.
21:56 sri \o/
21:57 dotandimet Sent highlight.js a pull request. I probably should have squashed all my commits first ..
21:57 gyan joined #mojo
21:58 sri https://github.com/isagalaev/highlight.js/pull/722#issuecomment-72277473
21:58 sri everybody +1 :)
21:59 dotandimet :)
21:59 sri dotandimet: are you going to hack it into mojolicious too?
21:59 sri it's mostly in the PODRenderer plugin and https://github.com/kraih/mojo/blob/master/lib/Mojolicious/templates/perldoc.html.ep
22:00 sri i can adapt the themes, but the basics would be cool
22:03 dotandimet I could do it, but probably tomorrow
22:03 dotandimet What languages do you want in the custom highlight.js version?
22:04 sri good question, perl, html, xml, css and javascript for sure
22:05 sri i guess what they consider common here + mojo https://highlightjs.org/download/
22:05 Eke- joined #mojo
22:12 dotandimet The build script doesn't take categories. I made a file with mojolicious http nginx apache bash zsh javascript css. Let's see how this goes (mojolicious includes perl and xml/html)
22:13 sri markdown, json, sql and diff seem rather useful too
22:18 dotandimet Full highlight.packed.js is 289K; The mojo prettify directory is 196K.
22:20 dotandimet Just the languages we listed is 23K
22:21 sri nice
22:21 gyan joined #mojo
22:23 sri put it into lib/Mojolicious/public/mojo/highlight.js/highlight.min.js
22:24 sri maybe with a light default theme in the same directory
22:25 sri there's two places where we need it, the podrenderer and the exception template
22:25 dotandimet Do you use the dark theme anywhere?
22:26 sri yea, the exception template
22:26 sri let me make you a one-liner for testing
22:26 Eke- joined #mojo
22:27 sri perl -Ilib -Mojo -E 'plugin "PODRenderer"; a({inline => "test\n% die;\n123"})->start' daemon
22:28 sri http://127.0.0.1:3000 for the exception
22:28 sri http://127.0.0.1:3000/perldoc/Mojo/DOM for the POD
22:29 sri most of it should be in development.html.ep and perldoc.html.ep https://github.com/kraih/mojo/tree/master/lib/Mojolicious/templates
22:30 sri the plugin just adds some classes https://github.com/kraih/mojo/blob/master/lib/Mojolicious/Plugin/PODRenderer.pm#L47
22:30 sri dunno if you need that
22:31 sri i've used it to ignore blocks that don't look like perl (contain no sigils...$@%)
22:33 sri i think POD is easier to start with
22:38 sri the exception page is a bit odd, because every line is a <pre> block
22:39 gyan joined #mojo
22:39 disputin joined #mojo
22:42 alnewkirk joined #mojo
22:56 dotandimet hmm. I'm looking at the tutorial (with highlight.js and autodetection) and I notice some blocks are marked Mojolicious, but some are marked Perl, even if they have templates in their __DATA__ section. I guess because those templates don't look like html.
23:00 sri maybe just flag all code blocks as mojolicious in the plugin
23:01 gyan joined #mojo
23:14 rem_lex|pivo joined #mojo
23:22 gyan joined #mojo
23:23 punter joined #mojo
23:25 dotandimet In the development exception page - highlight.js looks for <code> blocks, you're using a <pre>. When I nest a <code> block inside, there's some inline styling for <code> in the page that messes things up.
23:26 dotandimet I'll continue tomorrow, maybe I should use jQuery to do syntax highlighting instead of it being automatic (at least in the exception page).
23:37 jrhunt left #mojo
23:42 gyan joined #mojo
23:52 cpan_mojo Mojolicious-Plugin-DateSimple 0.01 by Stefan Adams - http://metacpan.org/release/SADAMS/Mojolicious-Plugin-DateSimple-0.01

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