These aren't universally deployed yet, but are substantially complete and are deployed in multiple applications. See T7858 for some followups. These will deploy everywhere over time, although they may not come to some lesser-used applications for a bit.

to meemees is two many meemees

As much as I hate features, this is relatively easy to build from a JS/eng point of view, fixes T7132 more easily than giving it a real target, and might let us just not pursue T7843.

In Git, we get fairly good control over error messages, although less so in Subversion/Mercurial. We emit this particular message ourselves:

Does your remote also have an enormous number of branches?

This is possibly tricky because the user can enter some unparsable time format in their preferences, but we can assume that users mostly enter reasonable time formats until we have evidence to the contrary.

When you enter "23:00", what does it do? What did you expect it to do?

Couple things offhand:

Here's an updated profile

Here's an updated profile, this time from linting rP:

And, if your desired value is larger, would making it easier to activate highlighting be a reasonable alternative approach? Currently you can highlight with:

If it was configurable, what value would you set it to?

I think php_compat_info.json is the biggest easy win.

Those regexps can also be memoized.

This can probably build a single huge regexp and drop time to nearly zero:

The profile likely overstates the cost of functions like idx() and mpull(), but occasionally they're worth reducing to isset() or similar if they're really getting hit tens of thousands of times.

I don't see any huuuuge wins, but:

It looks like the most significant function is AASTNode::getTokens.

Here is a better profile (F379444), see https://secure.phabricator.com/xhprof/profile/PHID-FILE-k7tcfv6t7e7o3itxfwns/.

Let me know if that fixes it when you have a chance? Still not totally sure I've nailed this down but it shouldn't be possible for it to recurse now.

I think workboard permissions are a little iffy until T6502.

D12511 is a possible fix, although I was only sort of able to reproduce something sort-of similar to the issue you hit.

Doesn't repro for me at HEAD and I'm pretty sure I remember fixing this. I presume you can't reproduce on this install?

I suspect I'm just not hitting the right edge case, but this stuff did churn a lot recently so I just wanted to double check that it's definitely not me testing different code.

Just to confirm, you're ahead of rP8efdc4aa? I'll keep digging, but I can't immediately reproduce this at HEAD.

Ah, okay. Yeah, looks similar. I'll take a look, thanks!

Set debug.time-limit to a value like 15 and hit it again? That should give you a trace.

You can change the chunk size constant to 1 to see the effect -- I expect it will lower memory usage (but not provide a huge reduction in peak, which I think is approximately a function of the largest file in the repository at these chunk sizes) but be much slower overall.

I feel that the memory usage could be further improved if we linted by path, because we would only need to store a single XHPAST tree in memory. This means that we wouldn't need chunking.

Can you remind me why we lint by linter instead of by path? As in, we lint all paths for a given linter before moving to the next linter.

I've marked D12509 as fixing this, although it really just obsoletes it. Specifically: it removes this behavior (we no longer default to the first query) and makes scope selection explicit instead (if you want to default to a specific query, just select it from the dropdown).

I'm going to merge this into T4103, although D12509 partially obsoletes it. Hopefully, the explicit control surfaced in D12509 resolves the confusion here on its own.

he he he

I think we should probably just document our way out of that; it's admittedly unclear that we're dumping the input into a font: attribute and we don't provide any examples.

Ah, I'll fix the double-escaping.

I also can't reproduce this. An example string which works for me is:

After T7849 (in review), there's a sort of kludgey workaround for this that has some caveats but should get you 90% of the way there:

I think the root cause for this is a bit complicated to explain, but basically we try to match this as a move:

This has magically fixed itself.

We don't require MySQL 5.5. The install guide says this:

you sir, are awesome.

Estimate = review/test that ^^^

It looks like you already have a conflicting package installed already ("MySQL-server-5.6.13-1.el6.x86_64").

T7884 has the similar case of changing a real file to a symlink.

Yeah, but I'd have to take another look at the code to give you an estimate since I don't remember exactly how much stuff is standing in our way. I'm headed to bed pretty soon but can take a gander tomorrow morning.

Would this task be available for paid prioritization?

~~ psychic powers ~~

Restart apache or php-fpm and let me know if that fixes it?