[02:05:56] <Krinkle>	 I've rebased 2 vendor updates (less.php, minify) that are ready for review at https://gerrit.wikimedia.org/r/c/mediawiki/vendor/+/901744/ and https://gerrit.wikimedia.org/r/c/mediawiki/core/+/901745
[14:26:22] <Reedy>	 jerkins says no
[17:39:44] <Krinkle>	 > 19:04:11 DEBUG:quibble.cmd:No quibble.yaml in /workspace/src
[17:40:08] <Krinkle>	 ah, red herring
[17:40:09] <Krinkle>	 Error: your composer.lock file is not up to date. Run "composer update --no-dev" to install newer dependenciesScript phpunit --colors=always --testsuite=core:unit,extensions:unit,skins:unit handling the phpunit:unit event returned with error code 1
[21:02:40] <Krinkle>	 Reedy: I don't get it...
[21:02:48] <Krinkle>	 I'm using the command in the README.
[21:02:54] <Krinkle>	 is this about a difference in composer versions or something?
[21:03:28] <Krinkle>	 https://gerrit.wikimedia.org/r/c/mediawiki/vendor/+/896656/6..7
[21:03:29] <Krinkle>	 no difference
[21:36:21] <Reedy>	 https://gerrit.wikimedia.org/r/c/mediawiki/core/+/572110/5/maintenance/checkComposerLockUpToDate.php#65
[21:36:26] <Reedy>	 bets its that
[21:36:29] <Reedy>	 line 65
[21:38:18] <Reedy>	 https://gerrit.wikimedia.org/r/902497
[21:39:37] <Reedy>	 if ( !( count( $requiredButOld ) || count( $requiredButMissing ) ) ) {
[21:42:34] <Krinkle>	 Reedy: hm. what's the hypothesis for this returning false yet both being empty?
[21:42:52] <Krinkle>	 like is the logic borked or am I looking for something that has a falsey count but is empty
[21:44:24] <Reedy>	 the error message it's getting? :P
[21:45:52] <Krinkle>	 my vendor updates are reaching the implicit 'else' down where the fatalError is
[21:45:57] <Krinkle>	 yet there are no warnings printed
[21:46:08] <Reedy>	 I don't think we have that string anywhere else in MW core...
[21:46:10] <Krinkle>	 suggesting that we're going down the path for non-empty with only empty arrays 
[21:46:26] <Krinkle>	 yeah, I think this code indeed
[21:46:44] <Krinkle>	 I believe you're expecting your patch to change it so that my patch passes CI instead of falsely failing?
[21:47:16] <Reedy>	 It's somewhat amusing that the patches in MW core depending on your vendor patches pass just fine
[21:51:39] <Reedy>	 But yeah...  I'm presuming it'd fix the weird false positive
[22:05:30] <Krinkle>	 https://3v4l.org/cOaj5
[22:05:34] * Krinkle is not seeing it
[22:45:51] <Reedy>	 var_dump(foo($a, $b), foo($a, $b));
[22:45:54] <Reedy>	 you're calling foo twice :P
[22:49:25] <TimStarling>	 Krinkle: did you test your WikimediaDebug changes?
[22:50:28] <Krinkle>	 I did.
[22:50:33] <Krinkle>	 (in Firefox)
[22:53:40] <TimStarling>	 maybe I can test it in Chromium
[22:58:47] <TimStarling>	 Uncaught (in promise) TypeError: entry.timestamp.toLocaleTimeString is not a function
[23:07:39] <TimStarling>	 after I fix that, the output area still does not appear in chromium
[23:07:51] <TimStarling>	 I had to load it into Firefox to make sure I wasn't just being stupid -- it works in firefox
[23:08:38] <TimStarling>	 I'll just leave a -1 comment for now
[23:13:14] <Krinkle>	 ok, thanks for testing.
[23:13:24] <Krinkle>	 thoughts on the ux approach of a link buffer like this?
[23:14:03] <TimStarling>	 looks good to me
[23:27:13] <Krinkle>	 interesting, so Chrome encodes the Date object as an ISO string between the two threads instead of following the Worker spec and its structuredClone logic for preserving/re-creating certain built in types like Date.
[23:30:27] <Krinkle>	 chrome also seems to default to reading the stylesheet as something other than UTF-8