Perl 6 - the future is here, just unevenly distributed

IRC log for #metacpan, 2017-02-20

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

All times shown according to UTC.

Time Nick Message
03:19 Guest69_ joined #metacpan
07:34 nakiro joined #metacpan
07:34 nakiro joined #metacpan
07:42 nakiro joined #metacpan
09:06 oiami joined #metacpan
09:08 Relequestual joined #metacpan
09:19 neilb joined #metacpan
11:37 edward joined #metacpan
15:01 ilmari loading https://metacpan.org/author/PERLANCAR gives me slow script warnings in firefox
15:01 ilmari pagination might be an idea?
15:05 ilmari the examples seem to have disappeared from https://explorer.metacpan.org/
17:26 haarg ilmari: it's the routine that adds the ellipses
17:56 neilb joined #metacpan
18:00 neilb_ joined #metacpan
20:02 dpetrov joined #metacpan
20:03 dpetrov joined #metacpan
21:00 jberger you know, if someone was interested, there has been a request from the peanut gallery on slack for a "why is metacpan better than sco" blog post
21:25 perigrin a) open source b) tons more features / metadata (I haven't looked at s.c.o in a while though) c) easily found people responsible for it's upkeep
21:26 preaction (a/c) aren't important to end-users. (b) could be, but some enumeration/explication would help (which i think is what they're asking for)
21:26 preaction (a/c) aren't important of themselves, but are for what they could achieve (which is b)
21:28 perigrin I disagree about a/c ... but more explanation could probably be made there
21:29 perigrin well I agree that they're not important of themselves, but I disagree that (b) is the only end goal there.
21:30 preaction not only, sure
21:30 preaction i mean, i changed all the links in cpantesters (i think) mostly for SEO purposes :p
21:31 preaction oh, also stability. ahhh remember the week s.c.o went down?
21:31 perigrin heh
21:31 perigrin stability is the reason I think a/c are important
21:31 preaction topic in #perl-help: "CPAN is not down - use https://metacpan.org"
21:32 perigrin if for some reason the responsible people from c are collectively hit by a bus, then a makes it possible for someone else to pick up the gauntlet
21:32 preaction eh, and i'm the maintainer now, but cpantesters was open source and is... well... let's say that stability is still very high on my list of active, open issues
21:33 perigrin sure, but it's more stable than had Barbie (?) not made the code opensource and disappeared without a handoff
21:33 preaction the foss community's problem isn't enough projects being open source, it's enough volunteers.
21:33 perigrin yes
21:34 perigrin I don't disagree
21:34 preaction and that's true that barbie could hand off the reins rather easily since it's all out in the open
21:34 perigrin but a good first step is making sure people *can* volunteer if they want.
21:35 perigrin which is rather harder to do if you have to introduce them to a private codebase
21:35 preaction and if barbie had not, in theory one could've eventually built a new box out of what's in the open (and the more i believe that...)
21:36 perigrin also entirely true
21:36 perigrin we wouldn't have metacpan if people hadn't built a new box out of what was out there
21:36 preaction the context of this is that someone was asked to link to metacpan.org over s.c.o on blog posts about cpan modules, so benefits from _that_ context would make a better answer
21:36 preaction metacpan got a copy of s.c.o? or kobesearch or something?
21:37 perigrin More I think they built it out of the toolchain bits that underly PAUSE and cpan
21:37 perigrin it fell out of oalders' attempt to build a docs app for iOS if I remember
21:37 mst s.c.o source was intentionally kept private because it was a giant pile of hacks and gbarr wanted us to make our own different mistakes, basically
21:38 perigrin nothing wrong with that
21:38 preaction and the same mistakes, too, but that's not really the answer to "what's compelling about metacpan?"
21:38 perigrin and nothing inherently wrong with closed source stuff, it's just less right than open source stuff in my opinion
21:39 preaction i also don't really need the answer, and since i'm not writing the requested article/blog, i have run out of any kind of valuable input
21:39 * perigrin makes a fine living writing closed source bits out of opensource bits all day long.
21:39 mst oh, sure, I just want to explain why (a) we've never seen a copy (b) that's not actually gbarr being a dick, as some like to pretend
21:40 preaction i agree: i know exactly what would happen if some of the crap i've written got released: i would spend the next dozen years explaining it and not writing a single line of code ever again :p
21:40 perigrin hehe
21:40 perigrin I tend to throw such crap up on github anyway
21:40 preaction which isn't useful to anybody at all
21:41 perigrin rather than make it something I push to CPAN
21:41 preaction i've... gotten quite draconian in my pursuit of best practices. which means i'm really slow at dev now :(
21:41 perigrin I've gotten ... lazy and bored with programming in and of itself. Which means I'm really slow at opensource now.
21:43 mst I still love programming, it's everything else that annoys me
21:45 preaction i still love doing it, there's just a lot more to it now than there used to be...
21:46 perigrin best practices aren't *best* if the stop the practice part.
21:46 preaction like, spending a week evaluating different user-space process watchers that will coordinate with the system-level init process :p
21:47 preaction then, once a candidate is selected, documenting everything so that the next person doesn't need to waste a week reading about all the different things to figure out why the one was picked
21:47 preaction engineering stuff...
21:52 mst preaction: I like s6 best but runit is more widely available
21:52 mst nosh is interesting for its ability to consume systemd unit files
21:52 mst (and this part is actually one of the fun parts for me ;)
21:52 preaction yeah, i went with runit for that reason but also runit had more docs on integrating with the system init for a normal user
21:53 preaction i tried figuring it out with s6 but it didn't seem like it liked that. none of the docs seemed to want to let me do it
21:53 preaction i think i avoided nosh because the author of those docs was... quite mad...
21:54 mst s6-svscan and runit's runsvdir are both basically identical
21:54 preaction no, nosh really wanted to be PID 1. s6's guy was a bit mad
21:54 mst well, people who write good bernstein chaining code usually are
21:55 preaction that's what i figured would be the case, but then "apt-get install runit" worked and runsvdir had docs on how to do the very narrow and specific thing i needed
21:55 mst right
21:55 preaction yeah, that too. people who can do shell like that are only like that because they're fundamentally broken in some way :p
21:56 mst s6 is actually more interesting to me for execline, the logger, and a few of the features
21:56 mst like, basically, is runit works, s6 would likely work basically identically and I don't care which you're using ;)
21:56 * preaction remembers all the arguments over how the shell works and you should really use shell redirection for things like a "--outputfile" switch
21:57 preaction yeah, setting up the runit log process was a few hours' frustration (the service itself doesn't really indicate anything is wrong with the log service), and it's still technically not at the point i want it: going to syslog, but that's for a bit later i think
21:58 preaction i've got a good 3-4 pages of notes i have to coalesce into a blog post of some kind, but ugh...
21:58 mst care and feeding of daemontools like things is a skill in itself
21:58 mst I've been doing it, fuck, over 15 years now
21:58 mst you'd be welcome to ping me to review said blog post and see if I have any thoughts
22:00 mst (I am fundamentally broken in many ways, as I'm sure you've noticed ;)
22:00 preaction sure, i really want to get some kind of info out on setting up per-user daemon watchers, since i couldn't find any and it makes it easier to deploy stuff (no giving out root just to run daemons)
22:00 preaction oh, me too, is why i can recognize it ;)
22:01 mst oh, I have runit doing that on my rpi
22:01 mst I could show you the config sometime
22:01 mst main runit just launches per-user runsvdirs
22:02 preaction yeah, i have systemd doing that (because debian... sigh...)
22:02 preaction which... systemd's docs are thorough, but dense and difficult to navigate unless you already fully grok its architecture...
22:02 mst ah, no, on my rpi, systemd starts the system runsvdir
22:03 mst which then starts the per-user runsvdirs
22:03 preaction ahh
22:03 mst systemd was threatening to mke me defenestrate my rpi, and I live in an upstairs apartment
22:05 neilb joined #metacpan
22:20 autarch1 joined #metacpan
22:20 autarch1 how can I look up a specific release version using the client module?
22:21 autarch1 MetaCPAN::Client->new->release("MooseX-Getopt-0.71") is not doing it
22:22 mst ->release({ all => [ { name => 'MooseX-Getopt' }, { version => '0.71' } ] })
22:22 mst or so
22:22 mst I think
22:22 autarch1 ok, that works
22:22 autarch1 I mean, that make sense
22:22 autarch1 I'll TIAS
22:22 mst that's a guess based on the search spec docs
22:22 mst I may have got the field names wrong or whatever
22:23 mst https://metacpan.org/pod/MetaCPAN::Client::Release suggests that might be ok
22:24 mst but code typed straight into IRC has even less warranty than usual ;)
22:24 autarch1 yeah, it didn't work :(
22:25 autarch1 perl -MMetaCPAN::Client -E 'say MetaCPAN::Client->new->release({all => [ { name => q{MooseX-Getopt} },  ] })->next'
22:25 autarch1 that doesn't even work
22:36 autarch1 s/name/distribution/
22:37 jberger joined #metacpan
22:37 jberger joined #metacpan

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