Perl 6 - the future is here, just unevenly distributed

IRC log for #metacpan, 2016-08-26

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

All times shown according to UTC.

Time Nick Message
00:59 jberger ooooh I will
04:05 oalders mickey++
06:01 oiami joined #metacpan
07:03 batman joined #metacpan
09:55 Exodist joined #metacpan
10:18 karjala Bug: this page doesn't mention XML::MyXML as one of KARJALA's modules: https://v1.metacpan.org/author/KARJALA
10:18 karjala this page does however: https://metacpan.org/author/KARJALA
10:43 osfabibisi joined #metacpan
11:09 mickey karjala: fixed
12:05 jberger mickey++
12:06 jberger Just watched your talk, very well done!
12:08 mickey jberger: thanks :)
14:03 vanstyn_ joined #metacpan
14:56 dustinm joined #metacpan
19:59 Khisanth joined #metacpan
20:04 ranguard mickey: good talk
20:06 ranguard made me think, should we have MC::Client have a version of 'latest' which checks *handwave* somewhere what the production version is?
20:07 ranguard so we don't have to get everyone to change their code to add 'version => v1' ?
20:07 * ranguard might be talking crap (e.g. in compatabilities).. but?
20:09 oalders might be a good option to have, even if it sounds dangerous :)
20:11 * ranguard could create clientversion.mc.org that just returns some json with the number in
20:12 oalders or we could just bump the version in the client
20:12 ranguard oalders: yea, but then everyone needs to go and download the new client
20:12 oalders true
20:13 ranguard that was my thinking, though I guess it's not likely we're going to switch again anytime soon to a v2 :)
20:13 ranguard just trying to be future proof :)
20:13 jberger oalders: watched your talk to, very nice!
20:13 jberger too even
20:14 oalders ranguard: well, we upgrade once  every 6 or 7 years
20:14 oalders jberger: was it because of my bait and switch with mickey's talk url?
20:14 jberger haha, no I had already watched mickey's
20:15 jberger I only had one question
20:15 jberger when you mention using minion in a non-mojo context, why are you still talking about morbo?
20:15 jberger or did I miss a context switch?
20:15 oalders i think i was talking about starting the app at the command line
20:15 jberger you shouldn't need to start a web server at all
20:16 jberger so yeah, I just missed a context switch
20:16 oalders so, for MetaCPAN, we've got the Minion plugin in the skeleton app
20:17 jberger bin/queue.pl
20:17 jberger so all you need to do to start a worker is perl bin/queue.pl worker
20:18 oalders ah, i'm starting it via carton exec -- morbo bin/queue.pl
20:18 jberger and that works ?!
20:18 oalders indeed
20:18 jberger ...
20:18 jberger that starts a webserver, not the workers
20:19 oalders maybe my docs are bad
20:19 oalders ./bin/run bin/queue.pl minion job -s
20:19 oalders that's what we really do
20:19 jberger thats to see current stats
20:19 jberger something somewhere must be calling the worker command
20:20 oalders either that or we've really only run this code in production and under the test harness
20:20 jberger https://github.com/metacpan/metacpan-puppet/blob/6995110c82218dc7f2c4f6eb0642176934172c45/modules/minion_queue/templates/init.pl.erb#L45-L49
20:21 ranguard jberger: heh, beat me to it
20:22 jberger oalders: so forget for a second that morbo and hypnotoad exist
20:22 oalders i've got some slides to correct!
20:22 jberger the way you start a webserver is ./script daemon or ./script prefork
20:22 jberger depending on if you want one or many web server processes
20:23 oalders right
20:23 jberger and you can add other commands, minion is one of them
20:23 jberger it has two subcommands, worker and job
20:24 jberger morbo really just takes your script name and uses it to bootstrap a filesystem watcher and restart a daemon on each change
20:24 jberger and hypnotoad is basically the same thing for prefork only it isn't triggered by the filesystem it is triggered by a command to zero downtime restart
20:25 jberger if morbo could start workers it would mean something was really screwed up :-P
20:25 oalders :)
20:25 jberger no worries though
20:25 oalders so that was helpful explanation
20:26 jberger the reason morbo and hypnotoad are external "binaries" is because they have to live outside of the app to do what they do
20:26 jberger everything else is using the mojo commands system
20:26 jberger which is a ton of fun when you start using it
20:27 jberger like galileo bundles an entire webapp in its "setup" command (galileo setup) which has a web configuration page
20:27 jberger and i usually have a deploy command that I add to $work things to run the db deploy etc
20:28 jberger anyway </rant>
20:28 jberger it was a very enjoyable
20:28 jberger talk
20:28 jberger and I have been thinking about what I want to chart :D
20:28 oalders :)
20:28 oalders thanks for the feedback. you'll have noticed that i wasn't under any time pressure
20:45 mst App::opan is also a good example of abusing the command system
20:45 mst jberger: why does hypnotoad have to live outside when prefork doesn't?
20:46 jberger the prefork manager is an instance of the app, as are the worker forks
20:47 jberger but for hypnotoad that manager has to also be able to spawn a new manager and kill itself off but leave things as they were
20:49 jberger the architecture of it isn't my strong suit
20:49 jberger the code is here though if you want to see it
20:49 jberger https://github.com/kraih/mojo/blob/master/lib/Mojo/Server/Hypnotoad.pm
20:49 Grinnz_ morbo and hypnotoad live outside because of their requirements to restart themselves, essentially
20:50 Grinnz_ restart themselves loading any updates to the app's modules
21:11 genehack joined #metacpan
21:14 mst I've seen the code
21:14 mst I still don't see why that requires that.
21:14 mst it does an exec(), no?
21:18 Grinnz_ no, fork
21:18 Grinnz_ oh, hypnotoad
21:49 chansen joined #metacpan
23:42 genehack joined #metacpan
23:45 harleypig_ joined #metacpan

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