[00:01:07] what do you think is the right thing to do here? I'm not a very visual person. the bulk of the benefit you saw w/NetSpeed=B is due to the suppression of srcset, not the lower compression setting on jpegs. [00:03:25] it probably makes sense to introduce a cookie value that only suppresses srcset [00:04:10] as for policy... [00:05:37] I see that we already have an option to suppress images [00:05:57] so an option to downscale or reduce quality could be added alongside that [00:06:00] yeah, though not a very well-designed one [00:06:01] maybe as a slider bar [00:06:12] yeah, that's a good idea [00:06:48] I still think we should omit srcset by default in most cases [00:07:04] in Opera Mini there's a setting "images" with options "Off, Low quality, Medium quality, High quality" [00:07:28] this takes 2/3 of the screen to display [00:08:09] it's a bit weird sending higher resolution images to lower-capability devices [00:08:37] well, they are not retrieved [00:14:30] who introduced srcset? [00:17:37] brion, I think [00:18:09] maybe he has an opinion on tuning it [00:20:23] maybe :) [00:20:30] did you know that WP policy strongly recommends that upright= be used in favour of fixed image widths? [00:20:41] https://en.wikipedia.org/wiki/Wikipedia:Image_use_policy#Displayed_image_size [00:23:21] yes, but how does that apply? [00:26:36] I'm just thinking about images that are larger than the viewport width [00:27:07] oh, I see [00:39:02] so, there remains the fact that mobile devices typically have higher DPI, and according to akamai have a similar connection speed in large parts of the world [00:39:26] as I said here yesterday [00:42:17] if it were not the case that mobile devices typically have higher DPI, sending the srcset attribute would not be an issue, because the images would not be fetched anyway [00:44:58] I might be missing something. What do the two facts you cite above tell us about whether or not to send srcset? [00:45:44] whether srcset is used depends on DPR, not DPI [00:46:13] the question we are asking is whether to respect the device's specified DPR [00:47:13] the reason for respecting it is presumed high DPI, thus users will see a better image quality [00:47:40] higher DPI means you need more pixels to fill in a given space [00:48:05] i.e. if you want an image to be two inches wide, you need to send more pixels to the mobile device than to a desktop to achieve that [00:49:18] the reason to not send srcset is because we suppose that the additional pixels take too long to download and the additional time does not justify the quality improvement [00:49:52] so to know whether that is valid, the actual amount of time it takes to download extra pixels is relevant [00:50:00] so is the argument you are considering this: that it is not reasonable to suppress srcset for mobile devices, since mobile devices are (a) more likely to benefit from higher-quality images, (b) are more likely to render lower-quality images in a manner that is harmful to user satisfaction, and (c) are no more bandwidth-restricted than their desktop counterparts in the relevant parts of the world [00:50:27] right? [00:51:04] more or less [00:51:21] you asked what to do by default [00:52:04] that implies we have to consider the whole world [00:52:54] I'm not promoting a particular solution here, I'm just mapping out the two sides of the argument [00:54:51] Yeah, this is useful. [00:55:02] * ori checks something in the NavTiming DB [00:56:39] JonR's experience in Indonesia over the last month was sort of interesting in light of the akamai discussion -- https://lists.wikimedia.org/pipermail/mobile-l/2015-December/009973.html [00:57:56] indonesia is one of the countries where Opera Mini is the most common mobile browser [00:58:10] that would make sense [01:03:46] so, according to our Navigation Timing data, 17% of desktop clients have high DPI, vs. 88% of mobile clients [01:05:34] so the fact that mobile connection speeds are equal to or better than desktop in the many parts of the world is not in itself an argument for not targeting mobile, because mobile clients have more to lose [01:09:01] what do you mean? [01:09:21] re "more to lose" [01:09:39] (I meant 'DPR' above) [01:10:32] don't desktops with DPR>1 have the same tradeoffs as mobiles? [01:11:09] no, because the connection is less likely to be metered [01:12:14] DPR>1 on desktop probably correlates with good connectivity more often than it does on mobile, too [01:13:14] yeah, data volume costs are an additional consideration [01:13:40] have you clicked through to the cost page on webpagetest.org? [01:13:48] yeah [01:22:21] I think it is also important to remember that the browser makes the decision to retrieve a particular image variant in ignorance of the semantic role of the image. Thumbnails play a supporting role on article pages. [01:23:05] The existence of a preference to disable images testifies to that; such a preference wouldn't make much sense on Instagram or Flickr. [01:25:37] Thumbnails on Wikipedia also provide a navigation path to a higher-resolution variant sized for the full display size [01:30:32] bd808: Hm.. I guess Monolog doesn't like it when I use a template key called 'message' [01:30:37] it blows away the actual message [01:30:49] https://github.com/wikimedia/mediawiki/blob/master/includes/cache/MessageBlobStore.php#L222-L225 [01:31:40] hmm.. probably has something to do with how it merges the context into the log event [01:32:26] it would be bad one direction or the other once it gets to logstash [01:32:48] because we flatten the context hash in to the event [01:33:55] Krinkle: "message_key" or "key" may be better in that particular case I guess [01:34:18] yeah [01:38:42] bd808: Do you know if there is a way to stop kibana from breaking up messages into individual word segments? [01:40:11] https://logstash.wikimedia.org/#/dashboard/elasticsearch/resourceloader [01:40:12] It seems there is some arbitrary cut off where if there are not enough unique values it starts breaking it up by space or hypen [01:40:12] which is really useless [01:40:12] I see it quite often in "trending" panels. The behaviour seems unpredictable. Changes from one to the other. [01:40:36] Krinkle: use the ".raw" variant of string keys for things like that [01:40:55] they aren't analyzed into tokens [01:41:12] Okay [01:41:18] normalized_message.raw for that one I think [01:41:58] Yeah [01:42:01] Perfect [01:42:02] thanks [01:42:09] I did the same to stacktrace on mediawiki-errors [01:42:15] pretty much any time you make a terms panel you probably want the .raw if it exists [01:42:17] that one was sometimes breaking it up by slash as well. [01:42:52] when a .raw doesn't exist that means I have already marked the string value as un-tokenized in the schema [02:19:57] Hello. I'm looking for an accessor method in the parser to give me all the parser functions and their params on a page after parsing is complete. Is there a way to do this or I'd have to cache the info every time it hits the function? [02:23:44] I think there's a parse tree thing somewhere [02:23:52] But I don't know if that's stored in ParserOutput [02:23:56] TimStarling: Thoughts? ---^^ [02:32:25] well, from the preprocessor parse tree you could get unexpanded parameters, but maybe Niharika wants everything to be expanded? [02:33:20] TimStarling: I am not sure I know the difference. :) Unexpanded would be? [02:37:40] well, if you have {{#if:{{{foo|}} | bar }} then do you want the first parameter to be literally "{{{foo|}}}" or the contents of the template argument called "foo"? [02:39:29] TimStarling: Contents only. Although I don't expect template parameters for the specific parser function I am looking to get parameters for. [02:40:05] {{#assessment: A | B | C}} <-- I want all instances of this from the page. [02:41:02] what site is this? [02:41:42] do you want to run a bot over all articles to extract this information? [02:43:08] TimStarling: Soon its going to be enwiki. Not all articles, I want to get this data on every page save from the article talk page. (This is for WIkiprojects) [02:43:25] It doesn't exist anywhere besides my local wiki yet. [02:44:28] Hmm, you want it on page save [02:44:33] Do you control the parser function's implementation? [02:44:42] RoanKattouw: Yes. [02:44:44] Because then maybe the code for {{#assessment:}} itself could store this [02:44:52] during parsing [02:45:09] RoanKattouw: But there can be multiple instances of the same function on the page. [02:45:22] Right, so you can't trivially use a page property or something like that [02:45:36] RoanKattouw: I can cache the information on every strike but I was hoping there was a way to get them all in one go. [02:45:58] Okay. Caching it is. [02:46:04] Maybe you could add a rogue field to the ParserOutput object and accumulate the information in there, then do something with all of them from a different code path that runs at the end [02:46:09] Yeah basically what you said [02:46:22] I don't know if ParserOutput has a nice facility for this, but I don't remember seeing one [02:47:13] I found no documentation at all. :( [02:47:17] keep in mind that not every parse operation results in the article being saved [02:47:19] Also, good job saying the same thing that I said, but faster and in six words instead of two lines :D [02:47:33] TimStarling: Oh, good point. [02:47:52] Haha. :) Thanks RoanKattouw, TimStarling. [02:47:54] Is there a hook that runs when a page is being saved, and gives you access to the ParserOutput object? [02:48:05] cause that would solve that problem [02:48:34] you can use ParserOutput::setExtensionData() to save the assessment data into the ParserOutput object [02:48:44] ooh nice [02:48:46] :Right now there's only a hook when the parser is initialized. [02:49:20] note that there is also ParserOutput::getExtensionData() so you can make an array or whatever [02:49:30] TimStarling: Oh, that's handy. Thanks. [02:50:15] hmmm [02:50:31] but maybe page_props is a good way to go with this if you don't have any storage system you need to plug into [02:51:36] if you use ParserOutput::setProperty(), then the data you set is automatically saved into the page_props table in mysql [02:51:49] TimStarling: What do you mean by "storage system you need to plug into"? [02:51:54] then you can efficiently get a list of pages which contain the property [02:51:57] I guess you would have to read, update and re-set the page prop on every pfunc call? [02:52:14] (can you even do that?) [02:52:14] yeah, I know, 4 lines of code [02:52:24] but nobody said programming was easy [02:52:41] yes there is ParserOutput::getProperty() [02:53:02] OK and that does in fact return props set by the current (half-finished) parse, rather than the previous one? [02:53:09] yes [02:53:17] (Without looking at it I could imagine either being the case) [02:53:18] OK cool [02:53:24] Yeah then that's probably the best way to go [02:53:26] so it will be something like [02:54:07] $assessments = $parser->getOutput()->getProperty('assessments'); [02:54:25] if ( $assessments === false ) $assessments = array(); [02:54:36] $assessments[] = $data; [02:56:20] $parser->getOutput()->setProperty('assessments', $assessments); [02:56:20] You can have page properties be arrays? :O [02:56:20] hmm, good question [02:56:21] I mean, without ending up with assessments=Array in the database :P [02:56:21] no [02:56:35] you are correct, you have to serialize it [02:57:19] So like $assessments .= ',' . $data; or something [02:57:47] yes [03:02:46] Okay, sorta makes sense. [03:09:26] oh, I see there is an ops list thread about this [03:10:02] and Krinkle already said "use page_props" [03:12:19] Ah, just saw. [16:14:45] [16:09:48] hhvm-help . hhvm still doesn't support 32bit? [16:14:45] lol [16:33:18] Reedy: And they still lack proper ms dos support [16:33:30] also gcc 5.1 :P [19:42:36] Krinkle: Guess I might aswell abandon https://gerrit.wikimedia.org/r/#/c/256756 now, right? [20:01:02] Reedy: indeed [20:56:47] err wtf git review just hangs [22:40:45] legoktm: CentralAuth not being able to find local user-- known issue, right? [22:40:52] Yup [22:40:56] Needs investigating [22:40:58] csteipp: which instance of it? [22:41:02] It seems to be getting "worse" [22:41:29] legoktm: I just saw it in the logs, and had vague memories of someone asking about it. Cool. [22:42:15] Each instance usually needs investigating, they're usually caused by something else going wrong [22:43:23] If there's a bug I should post it on, let me know. ERROR: [f3759a93]. [22:44:19] that's Lesabendio@cewiki [22:44:53] hmm, CentralAuthCreateLocalAccountJob is failing on meta