[01:27:44] nostalgic bugs https://phabricator.wikimedia.org/T220563 [02:09:30] TimStarling: that is some impressively long-tailed code [02:09:59] TimStarling: on another topic, your thoughts on https://gerrit.wikimedia.org/r/c/mediawiki/core/+/500755 would be welcome. No giant urgency. [02:13:03] ok [02:14:27] it's a challenge to make sense of DateFormatter.php, even though I wrote it [02:14:57] I thought I was very smart to write such a thing, but with experience comes the ability to express yourself in a way that other people can understand [02:15:20] I mean, I felt smart at the time [02:16:59] It is probably a good thing for my self esteem that none of the first PHP I wrote is still part of my life. [02:18:49] bpirkle: are you sure? What if it still hides in your closet? [02:19:30] code can last for a surprisingly long time [02:20:28] in Vernor Vinge's "A Deepness in the Sky" there is a spacefaring civilisation in which a highly respected profession is "programmer archaeologist" [02:21:11] Indeed, it probably hides on a dusty backup drive in the upstairs closet, but we won't talk about that. :) It is, however, most certainly out of service, as the place I was working for at the time shut down that project long ago. MMO tools tend to have a brutally short lifetime. [02:21:13] he imagines space ships 1000 years in the future literally running UNIX-based operating systems [02:21:48] inside countless layers of virtualisation of course [02:23:39] I would not be surprised that someone will be running it because THEY HAVE THEIR IRC CONFIGURED EXACTLY HOW THEY WANT IT, DAMMIT! [02:23:53] lol [02:24:22] I want my IRC configured to /dev/null [03:38:24] there's a comment in this code "@todo preferences, OutputPage" [03:39:04] I actually did those two things 38 minutes after the original commit [03:40:05] the original commit was at 2003-11-21 00:12:41, the followup was at 2003-11-21 00:40:30 [03:40:36] but I forgot to remove the todo comment, so 15 years later it is still there [04:01:16] TimStarling: I consider half of our work on MediaWiki to be programming archæology, albeit not quite in the Vernor Vinge depths. :-) [04:39:33] <_joe_> TimStarling: I'm ready to bet that's not science-fiction (in X years, spaceships still running some flavour of unix [04:40:56] <_joe_> (also, that bug has the age of my stepdaughter, more or less) [19:57:39] _joe_: regarding INI settings, to what extent have you compared the effective settings? [19:57:51] I'm doing a comparison now to look for things we may want to double-check. [20:16:11] <_joe_> Krinkle: I looked at what was defined explicitly in the ini file for HHVM, plus some default settings [20:16:45] <_joe_> I didn't go father than that. Sadly, the only way to know what the setting defaults are in hhvm and what they actually mean is looking at the code [20:20:00] _joe_: I'm dumping get_all_ini and diffing [20:20:13] will paste on task with questions, and you can take further? [20:20:19] <_joe_> uh, sure [20:20:28] <_joe_> I completely forgot about get_all_ini [20:20:54] <_joe_> ini_get_all, btw [20:21:07] there's also phpinfo() but its toggle between plain text and messy HTML is bound to CLI vs CGI which means I can't get decent output on web. [20:21:46] <_joe_> phpinfo on hhvm has very sparse info [20:21:55] <_joe_> that's what I tried to use in the first place [21:50:29] is there a way to do \MWNamespace::getCanonicalNamespaces() on a different wiki in the cluster? [21:52:54] errr.. if I’m on meta and I want to get the namespaces of English Wikipedia. [21:55:49] Krinkle: do you get "Auto-creation of a local account failed: You have not specified a valid username." when trying to login with sqlite? [21:56:33] davidwbarratt: No, that requires initialisation of extensions. The way to get this information right now is through the Siteinfo API. [21:56:54] Titles are usually passed as-is without parsing though. [21:58:54] Krinkle hmm, ok, that's not a terrible idea... I'm working on CentralAuth extension, and I have an id for a namespace, to reference, but I was looking to get the name of the namespace, I suppose it wouldn't be crazy to call the siteinfo api for that info (it would only call it for sites the user has namespace partial blocks on) [21:59:08] errr... call the siteinfo api in JavaScript [21:59:38] davidwbarratt: what's the use case? [21:59:50] Krinkle https://phabricator.wikimedia.org/T200938#5094768 [21:59:53] namespace info doesn't seem, at glance, something that is meant to be useful across wikis. [22:00:57] davidwbarratt: I'd recommend validating core namespaces only with a localised label and expanding the rest to "… and 4 local extension namespace(s)" [22:01:34] oooo, that's not a bad idea, how do I know if it's a "core" namespace [22:01:37] assuming this is for Special:CentralAuth, those queries aren't going to scale to 900 potential targets. [22:02:52] davidwbarratt: eh... that's both very easy and very hard. [22:02:56] https://www.mediawiki.org/wiki/Extension_default_namespaces#MediaWiki_Core [22:02:59] I would say < 90 is core. [22:03:29] WikiLexicalData isn't used and they made a mistake. [22:03:41] it was meant to be < 100 but then LiquidThreads came along [22:04:27] so < 90 and MWNamespace::exists() [22:04:56] Krinkle oh ok, perfect, thanks [22:05:14] davidwbarratt: after initial thing, a follow-up could be to propose adding an isCore() method to NamespaceInfo service, but that may take an RFC to agree formerly that we reject WikiLexicalData and other undocumented cases. [22:05:31] so for now hardcoding in CentralAuth seems fine. [22:05:41] Krinkle okie dokie, thank you so much for your help! [22:05:47] yw [22:07:35] 14:55:49 Krinkle: do you get "Auto-creation of a local account failed: You have not specified a valid username." when trying to login with sqlite? [22:07:48] AaronSchulz: Yes I got this, and couldn't figure out why it happened. After updating a lot of stuff it eventually went away [22:08:00] Like, all extensions, running update.php, etc. Not sure which of my steps fixed it [22:08:09] update.php didn't work [22:08:11] * Krinkle hasn't seen it, but also doesn't sqlite usually. [22:08:14] I also ran vagrant provision and got partway through vagrant git-update [22:08:21] I feel like every few weeks I have to nuke my sqlite tables [22:08:44] So I really just threw the kitchen sink at it and eventually I was able to log in [22:11:06] Krinkle though... I guess, tbf, if we really wanted to, we'd only have to make the API request if the user was blocked from a non-core namespace, so that's not really that bad (if we wanted to go that route). I'll give the PO options. :) [22:12:55] davidwbarratt: if wanting localised labels for foreign namespaces, I would oppose in-process cross-apache requests. in favour of something pre-compiled, e.g. dump the namespaces statically from a maintenance script during deployment or periodically. e.g. like we do with localisation and interwiki. [22:14:31] Krinkle hmm, ok, good to know! [22:14:54] I mentioned API before I realised it was in-process on the server side. [22:15:19] Krinkle I mean I would do it from the client in JavaScript [22:16:11] Krinkle unless there is some huge downside to doing that? [22:17:17] seems like a workaround to fetch data meant to be rendered on the page client-side. What would it render initially, and reflows/delays. Seems like a rather big perf impact for UX. [22:17:47] esp. inside tables, adding text later can shuffle things around quite a bit. [22:19:38] Krinkle hmm, I guess a potential solution could be to add "... and 4 local namespaces" and make that a clickable link that would load the list [22:20:07] davidwbarratt: Right, or url to a local page with the block info/id. [22:20:17] which could be the nojs fallback and might suffice in general [22:20:27] Krinkle right, ok, great! thanks! [23:04:06] davidwbarratt: what's the point of localizing? [23:04:25] that page is mainly used by stewards and other cross-wiki people [23:04:51] if I were a steward I'd probably not appreciate zhwiki partial block namespaces shown in chinese [23:04:56] tgr I'm not worried about the localization, it's just that the database will return a namespace id of a namespace that is blocked, but not the name of the namespace itself [23:05:23] so no custom or extension namespace names? [23:06:01] tgr right that's what we were discussing above, I think the simpliest solution is to call the siteinfo endpoint and get the name [23:07:04] tgr it would only need to be requested if the user is blocked from a non-core namespace on that wiki [23:07:08] that makes sense, although I wonder if people would be happy with just a blocked / not blocked / partially blocked flag [23:07:20] tgr yeah I'm going to add that to the ticket [23:07:26] errr... ask the PO to. :) [23:20:07] tgr interestingly enough, it looks like siteinfo doesn't give the namespaces in the user's language. :/ [23:20:21] errr... it seems to ignore uselang [23:22:07] davidwbarratt: if you use user language, it will be pretty hard to cache [23:22:45] if you don't cache somehow you might end up with dozens of requests to render the page which is not great [23:23:10] tgr I mean I could pass it to the request, but it looks like the api ignors any value in uselang [23:23:29] *ignores [23:24:09] i.e. https://ja.wikipedia.org/w/api.php?action=query&format=json&uselang=en&meta=siteinfo&formatversion=2&siprop=namespaces [23:24:56] there isn't really such a thing as a namespace in the user's language [23:25:25] it won't actually work as a namespace, only the canonical version and the one in the wiki's content language are understood by the parser [23:27:13] for English you can use the canonical field [23:27:39] when there's no canonical field, it's a custom namespace and translations don't exist [23:45:43] _joe_: pfew, okay, done :) [23:50:54] tgr interesting