[04:51:47] <Krinkle>	 Today I learned ParserCache actually caches entire PHP ParserOutput objects, which means things I previously thought were in-process only (such as set/getExtensionData - not set/getProperty) are actually persisted as well to some extent
[04:51:53] <Krinkle>	 I thought it was HTML only.
[16:24:37] <bd808>	 blerg. It turns out I do have to dive into the rabbit hole of figuring out how to exclude CentralAuth from loading on my LdapAuth wiki :/
[20:21:56] <bd808>	 ori: I updated https://addons.mozilla.org/en-US/firefox/addon/wikimedia-debug-header/ to pass the profile and readonly options
[20:22:13] <bd808>	 pretty neat stuff you are making possible :)
[20:35:11] <ori>	 bd808: that's awesome! I see you added a screenshot to https://wikitech.wikimedia.org/wiki/X-Wikimedia-Debug :)
[20:38:44] <ori>	 bd808: btw, what do you think about https://gerrit.wikimedia.org/r/#/c/277585/ ? Is it OK to for that to be a free-floating utility function that is not using the actual proper logging subsystem?
[20:40:58] <bd808>	 ori: is the idea there that you would live hack `hackLog( "foo" )` calls on mw1017?
[20:41:34] <ori>	 yeah, exactly -- actual usage would be restricted to live-hacking
[20:45:32] <bd808>	 MWExceptionHandler::getRedactedTraceAsString() might end up being prettier than your array_map() trick
[20:46:06] * ori will check that out
[20:46:09] <bd808>	 or MWExceptionHandler::prettyPrintTrace()
[20:47:43] <bd808>	 I think prettyPrintTrace can be fed the output of debug_backtrace()
[20:49:49] <bd808>	 generally I don't have a problem with the concept of a nice way to do that sort of on the fly debugging. Wedging in a proper PSR3 handler would be more trouble than its worth
[20:50:30] <bd808>	 file_put_contents can have problems with huge files (2Gb?) but that shouldn't be an issue in short term debugging
[22:27:44] <Krinkle>	 bd808: Woah, very nice :)