Perl 6 - the future is here, just unevenly distributed

IRC log for #metacpan, 2015-06-02

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

All times shown according to UTC.

Time Nick Message
00:25 vroom1 joined #metacpan
00:46 punter joined #metacpan
00:57 vroom1 joined #metacpan
01:00 vroom joined #metacpan
01:00 vroom left #metacpan
01:01 csson joined #metacpan
01:32 vroom joined #metacpan
01:37 klapperl joined #metacpan
01:55 vroom joined #metacpan
02:20 diego_k joined #metacpan
02:41 vroom joined #metacpan
03:12 bin_005 joined #metacpan
03:30 vroom joined #metacpan
03:33 vroom1 joined #metacpan
03:52 vroom joined #metacpan
04:33 * kentnl boggles
04:34 kentnl why does ->download_url from MetaCPAN::Client::Release randomly alternate between http and https?
04:34 kentnl specifically, http:/  ( yes, one slash ) and https:/ ( yes, one slash )
04:38 kentnl weird, must be something I've done somehow. :/
04:43 kentnl ok, that single slash shit was CPAN::DistnameInfo going awol.
04:54 kentnl https://github.com/CPAN-API/cpan-api/issues/415
04:59 haarg kentnl: the url is a stored value
05:00 haarg things indexed before https://github.com/CPAN-API/cpan-api/pull/330 will have http
05:10 kentnl Ah. So will it be resolved eventually? Or is that a relatively permenant thing?
05:10 kentnl its not important I guess. I just noticed it being anomalous when I was seeing output.
05:11 haarg it's relatively permanent
05:11 haarg there will likely be a full reindex eventually
05:12 haarg we could also do a rewrite of that specific value if it was important
05:46 ChoiKyuSang joined #metacpan
06:36 Valkyrie joined #metacpan
06:58 neilb joined #metacpan
07:10 mtj joined #metacpan
07:21 neilb joined #metacpan
07:59 castaway ranguard: mm, I figured something like that, no tweak to put shortest possible matc first? I swear it used to..
08:03 ranguard castaway: I know there is a ticket to improve the results, but need someone to work on it, and free time at the moment is going on upgrading to improve redundancy
08:03 ranguard s/and free/any free/
08:12 neilb joined #metacpan
09:00 * castaway steps back rapidly ;)
09:14 ranguard ether: I've change most link on perl.org to metacpan, and on www.cpan.org - email me any you spot that arn't converted
09:17 ksurent joined #metacpan
09:25 bin_005 joined #metacpan
11:28 vroom joined #metacpan
11:55 ksurent left #metacpan
12:03 vroom joined #metacpan
12:17 vroom joined #metacpan
12:58 oiami joined #metacpan
12:59 vroom joined #metacpan
13:35 oiami joined #metacpan
13:36 vroom1 joined #metacpan
14:05 neilb joined #metacpan
14:49 vroom joined #metacpan
15:19 neilb joined #metacpan
15:41 Tempesta joined #metacpan
16:15 vroom joined #metacpan
16:28 ether ranguard++ # \o/
16:29 ether how long does a full reindex take? I wonder if it's worth doing monthly via cron
16:30 ether and purely a wishlist item.. if there was a way to see what *changed* in that reindex, that could be really valuable to toolchainers to spot potential problems in the wild (or possibly with the tools themselves)
16:30 ether but I don't expect the output of that reindexing to be something that's easily diffable..
16:31 oalders i think that will be easier to do once we upgrade Es and have a proper cluster
16:31 oalders right now it can be done in less than a day if we devote a lot of resources to it, but that doesn't play well with a production machine
16:31 oalders so we'd have to either move the index or switch production to a different machine, copy over user data etc
16:32 ether wow, yeah, that's a lot of time.
16:32 ether I guess it could take as long as it takes, if it just happens in the background and doesn't interfere with normal operations.. *and* if infrastructure were free and plentiful :)
16:32 haarg also last time we did a full reindex, it broke a lot of things and we had to restore the old data
16:33 oalders that was a bit messy
16:33 ether are there enough systems available to do a reindex in an offline version that is maintained in parallel, but doesn't service requests?  then when it's done, it can be checked "somehow" and then swapped in place if found to be good
16:33 haarg it's not very easy to find the mistakes without having it live
16:49 oalders ether: luckily resources are not the problem
16:50 oalders at least hardware
16:50 oalders it's the human resources
17:01 neilb joined #metacpan
17:08 neilb joined #metacpan
17:43 ranguard re-indexing isn't the issue, it's that a reindex breaks stuff that's the problem
17:45 ranguard but as the upgrade (for ES) requires a re-index it would be part of that project
17:45 ranguard ether: we don't really have any regression tests for the actual data/indexes
17:57 oalders we could look into something that provides us content and layout diffs when things change
18:52 ranguard haarg: any news on that css/js branch, I'm going nuts with doing page refreshes in dev, takes 10->15 seconds for a refresh :(
19:04 ranguard oalders: do we have some magic xss protection turned on for TT pages?
19:15 Peter joined #metacpan
19:24 oalders ranguard: other than using HTML::Restrict?
19:26 ranguard oalders: that's only on the POD render isn't it?
19:27 oalders Right. I guess there are other points we don't cover.  Not sure how good we are about using HTML filters on the TT tags.
19:27 ranguard I'm building the JS in TT instead of trying to use the '.json' as I was getting ""foo&quot:bar
19:28 oalders that sounds crazy
19:28 ranguard yep, but JFDI, it's only for a stats page
19:30 oalders sure
19:36 * ranguard doesn't like UI it's too slow for developing, or maybe he is, one or the other
19:59 oalders ranguard: have you looked into http://gulpjs.com/ ?
20:11 Ptolemarch joined #metacpan
20:14 haarg ranguard: 10 to 15 seconds?  that sounds extremely slow.  what are you using for a browser?
20:14 ranguard haarg: chrome
20:14 haarg has it always been like that for you?
20:15 ranguard against the VM
20:15 haarg is the vm really slow at serving files or something?
20:15 ranguard yea, though got worse with the .less switch, seems to be all the loading of the dozens of .less  and .js files
20:18 ranguard oalders: umm, sort'a what I wrote in that pull request for merging?
20:26 oalders ranguard: you can use this to watch your assets and then recompile the changed files without restarting the app
20:26 oalders so, i think that's kind of what you had done
20:26 * ranguard nods
20:27 ranguard the VM serving file times are crap it seems...
20:27 * ranguard adds it to his list :(
20:28 haarg is the vm using nginx?
20:28 * ranguard nods
20:29 haarg seems odd that it would be so slow serving the static files then
20:30 ranguard nginx only proxies.. might be a basic config thing somewhere, even how many starman workers *shrug*
20:30 ranguard oh, look at that, dev defaults to 1 starman worker...
20:31 ranguard though really starman should be able to process a dozen requests in a second or two
20:33 ranguard well *I*(&^£@£(*@&@£ all this time I could have saved!
20:33 ranguard increasing starman improved it a lot
20:34 * ranguard is building a /about/stats page...
20:34 ranguard https://www.evernote.com/shard/s54/sh/503d8a08-761d-4193-bf17-1bbb4198487c/5e67ef52333a1a407f922a3014015356
20:35 haarg if nginx is already being used, it should really be configured to serve the static files
20:35 haarg it will be much faster at that that starman
20:35 ranguard haarg: non-issue, static files should be cached at fastly, and this way 'plackup' is EXACTLY the same as production
20:36 haarg for the vm i mean
20:36 ranguard headers for fastly are set in app.psgi and i want to test those on the VM
20:37 haarg not really much point to even using nginx then
20:39 ranguard not huge, but nice to have a reverse proxy to ensure starman processes arn't ties up with anything network related
20:40 haarg personally i'd rather have nginx handling the headers for the static files
21:01 Ptolemarch joined #metacpan
21:03 miniCruzer joined #metacpan
21:09 vroom joined #metacpan
21:27 Ptolemarch joined #metacpan

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