Perl 6 - the future is here, just unevenly distributed

IRC log for #metacpan, 2016-08-03

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

All times shown according to UTC.

Time Nick Message
00:05 y1mmm joined #metacpan
00:36 y1mmm joined #metacpan
01:02 y1mmm joined #metacpan
01:35 y1mmm joined #metacpan
01:55 y1mmm joined #metacpan
06:24 oiami joined #metacpan
07:35 [Tux] joined #metacpan
07:35 [Tux] [SSL] ** [https://fastapi.metacpan.org:443]-[599] SSL connection failed for fastapi.metacpan.org: SSL connect attempt failed, called from sub Search::Elasticsearch::Role::Client::Direct::Main::scroll_helper at /pro/lib/perl5/site_perl/5.22.0/MetaCPAN/Client/Request.pm line 108. With vars: {'request' => {'method' => 'POST','serialize' => 'std','path' => '/v1/rating/_search','mime_type' => 'application/json','ignore' => [],'qs' => {'search_type' =>
07:35 [Tux] 'scan','size' => 1000,'scroll' => '5m'},'body' => {'query' => {'term' => {'distribution' => 'VCS-SCCS'}}}},'status_code' => 599}
07:45 nicomen joined #metacpan
07:45 dg joined #metacpan
07:45 mickey joined #metacpan
07:45 oalders joined #metacpan
07:45 arc joined #metacpan
07:45 Grinnz joined #metacpan
07:45 Mithaldu joined #metacpan
07:45 fuzzix joined #metacpan
07:45 grantm joined #metacpan
07:45 castaway joined #metacpan
07:45 castaway_ joined #metacpan
07:45 jibsheet joined #metacpan
07:45 ohoushyar joined #metacpan
07:45 GumbyNET7 joined #metacpan
07:45 GumbyNET5 joined #metacpan
07:45 haarg joined #metacpan
07:45 sivoais joined #metacpan
07:45 genehack joined #metacpan
07:45 ingy joined #metacpan
07:45 charsbar joined #metacpan
07:45 jdv79 joined #metacpan
07:45 michael joined #metacpan
07:45 cjm joined #metacpan
07:45 bpmedley joined #metacpan
07:45 Grinnz_ joined #metacpan
07:45 rafl joined #metacpan
07:45 zostay joined #metacpan
07:45 diegok joined #metacpan
07:45 jberger joined #metacpan
07:45 Tux joined #metacpan
07:45 kentnl joined #metacpan
07:45 [Tux] joined #metacpan
07:45 dustinm joined #metacpan
07:45 oiami joined #metacpan
07:45 y1mmm joined #metacpan
07:45 alh joined #metacpan
07:45 Tempesta joined #metacpan
07:45 ribasushi joined #metacpan
07:45 ilmari joined #metacpan
07:45 Khisanth joined #metacpan
07:45 karjala joined #metacpan
07:45 vanstyn joined #metacpan
07:45 garu_ joined #metacpan
07:45 ether joined #metacpan
07:45 BinGOs joined #metacpan
07:45 Ralesk joined #metacpan
07:45 TBSliver joined #metacpan
07:45 ranguard joined #metacpan
07:45 klapperl joined #metacpan
07:45 rsrchboy joined #metacpan
07:45 bjakubski joined #metacpan
07:45 csson joined #metacpan
07:45 chansen joined #metacpan
07:47 neilb joined #metacpan
07:55 punytan_ joined #metacpan
08:02 Relequestual joined #metacpan
08:06 neilb joined #metacpan
11:43 AirDisa joined #metacpan
12:36 metacpan joined #metacpan
12:36 metacpan [metacpan-api] mickeyn created mickey/GH446 (+1 new commit): https://git.io/v6kFA
12:36 metacpan metacpan-api/mickey/GH446 bd79747 Mickey Nasriachi: removing timestamp references (not supported in ES2.x)
12:36 metacpan left #metacpan
12:45 edward joined #metacpan
13:33 oiami joined #metacpan
16:53 y1mmm joined #metacpan
17:31 y1mmm joined #metacpan
17:35 kentnl "Fix result values in v1 - single valued arrayref in ES result will be turned to a scalar (Mickey)"  # what inspired this?
17:36 kentnl I haven't looked too deply, but I had code that was iterating via for ( @{ $x->module } ) { , and now it needs extra special casing.
17:39 mst yeah, that sounds like an error to me.
17:39 mst reminds me of TT, and not in a good way
17:43 Grinnz_ you mean XML::Simple :P
17:46 mickey kentnl: since the ES upgrade we have a lot of single-value results coming back from ES wrapped in an array-ref (in the JSON). in the MetaCPAN-Web code we already have that fix to deal with them, but in the MetaCPAN::Client we didn't have it so some fields (like 'name', 'pauseid', etc.) where you would normally expect a scalar came back as an array-ref with one value inside - that's what the fix is for
17:47 kentnl Yeah, I see now, I tried downgrading MetaCPAN::Client and got worse results, so I'll file a bug with code that /used/ to work before the ES tweak but no longer does
17:47 mickey having said that, I realize that for some fields like 'module' the fix is a bit too eager and should be applied as you may get multiple values in some cases
17:48 mst unwrapping arrayrefs when there's only ever one result is sane
17:48 mst unwrapping arrayrefs that might have >1 entries is going to suck
17:52 mickey yeah, i found that out when oalders mentioned the issue with OrePAN2
17:53 mickey I'll map the fields that can potentially be lists like 'module' and skip the unwrapping for them
17:54 kentnl https://github.com/metacpan/metacpan-client/issues/43 # small example code for repro
17:54 mst mickey: I would suggest instead whitelisting things to unwrap
17:54 mst the failure modes will be less upsetting
17:55 Grinnz_ yes, if you're going to do that it should be 100% of the time it unwraps elements X Y and Z
17:56 mickey i'm not sure, i'm guessing most failures will be with 'module' specifically and most fields are single-value
17:56 Grinnz_ what if you add more arrays in the future?
17:56 mickey that's changing our ES mappings... that doesn't happen very frequently
17:57 mickey (as it mostly require full reindex)
18:02 mickey anyway, i'll try to fix it soonish
18:02 kentnl <3
18:13 mickey Grinnz_: besides, the list of served attributes in the client is hardcoded anyway... so adding fields in ES is not automatically reflected :)
18:14 Grinnz_ mickey: it's a matter of what is most likely to prevent future issues; if you have ever used XML::Simple this is a painful possibility
18:15 mickey both white&black listing can cause breakage in this case... if we don't whitelist a new field you will get arrayref when expecting a scalar
18:17 Grinnz_ true
18:17 mickey but since the list of attributes is fixed in the client - I don't think that's a problem... I'm thinking of just turning it into a hash where the value indicates that so it will be an even more accurate handling
18:19 Grinnz_ so, every field would specifically say whether it should be treated as a scalar or arrayref?
18:20 mickey yes
18:21 mickey well, not for the user. internally in the client
18:21 Grinnz_ right, that sounds good to me
18:21 mickey for the user I can document it
18:21 mickey but at least this will force me to check it for every new field :)
18:53 neilb joined #metacpan
21:14 neilb joined #metacpan
22:11 metacpan joined #metacpan
22:11 metacpan [metacpan-client] mickeyn pushed 2 new commits to master: https://git.io/v6L0w
22:11 metacpan metacpan-client/master 7d6e0d6 Mickey Nasriachi: ES fields: accurate type check (pre-defined types)
22:11 metacpan metacpan-client/master 7a0b226 Mickey Nasriachi: Release: 1.022000
22:11 metacpan left #metacpan
22:12 mickey https://v1.metacpan.org/release/MICKEY/MetaCPAN-Client-1.022000-TRIAL
22:13 mickey kentnl: ^^
22:14 mickey i will be travelling tomorrow, so i'll wait for some input and properly release during the weekend
22:54 neilb_ joined #metacpan
23:45 y1mmm joined #metacpan

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