I made some effort to find an approach here, but I think it needs to wait until Toolsets define our config/caching better. In particular, guaranteeing this naively in arc requires running a subprocess (to execute locale -a, to enumerate available locales on the system) and possibly functionally-testing hundreds of locales (or, in the general case, an arbitrarily enormous number of locales). The functional test for UTF8 behavior requires running another subprocess, to echo 🐑.

Thanks!

If that doesn't immediately work, yell at me and I can grab this and figure out what's up.

(Actual change makes perfect sense.)

Try something like this:

D21044 may resolve this alone, but I suspect there will be at least a little bit of followup work so I'm going to leave this open for the moment.

(Also, hello after all this time! Hope you're all doing well over at phacility.)

• For completeness, explicitly handle "Undefined offset" (raised for undefined numeric offsets) in addition to "Undefined index" (raised for undefined string indexes).

For my own internal reference, PHI1234 has related discussion.

Thanks! I added you to Blessed Committers, so you should be able to land this. See that project description for help if you run into issues, or you can likely use "Land Revision" from the web UI here, or I can land it for you if all of that is more trouble than it's worth.

Hmm, I can't immediately find any upstream version of arc that has ever not had --no-verify: D13020 in 2015 had it, and it was version-checked but retained in D14033 (also in 2015) and seems untouched since then. If you're working with a fork, maybe blame/log to figure out why it was removed?

Instead of GIT_LFS_SKIP_SMUDGE=1, try git push --no-verify -- <remote-uri> ...? That just skips the pre-push hook, which seems to work locally:

As much as possible I'd like arc to have the property that interrupting/killing/aborting/striking-it-with-lightning at any point during execution leaves you in the least-surprising state we can leave you in, and "arc uninstalled LFS as a side effect" seems highly-surprising, so I'm hesitant to go down that path. Let me take a quick look and see if I can find some other way to trick LFS here -- maybe there's a clever --config flag or something like that.

That is, the sequence would look something like this, if the description above was muddy:

Part of this change -- pushing to a branch rather than a tag -- breaks a million things and can't come upstream without significant changes elsewhere.

It's true that it has been 12 years, but I'm sure fwrite() will start returning an error code when it encounters a permanent, fatal EPIPE error condition soon.

We also have two separate pieces of ngram extraction code:

For now, I'm going to change the ngram slicing to be character-oriented. This should never be worse than the current behavior, and moves us closer to effective normalization.

This appears to be the unicode normalization chart:

If you're affected by this and arc upgrade doesn't work, the easiest fix is to run git pull in arcanist/.

Does using --max-pack-size to reduce the maximum packfile size really let Git "checkpoint" after each packfile, so the process is effectively resumable?

PHI1655 identifies a specific case where enormous packfiles may create problems:

I have some code which runs and looks plausible (i.e., not covered in piles of callback garbage), at least:

See https://discourse.phabricator-community.org/t/data-truncated-when-pushing-into-repository/3586/ for what is likely to be a related issue.

The real root cause of this issue may have been a locale setting which uses comma as a decimal separator, see T7339.

Here's an actual example of loadHardpoints($objects, $hardpoint):

In the specific case of the Hardpoints, we currently often have code which loads objects but doesn't do anything with them. For example, most Query classes use didFilterResults() to fill things-that-sure-look-like-hardpoints, but few do anything with the results.

I'm going to mark this as resolved, since:

• Fix a unit test issue where a future was explicitly started before being added to an Iterator.

• Also remove uncalled "checkException()" method.

The core idea in D5104 + D5105 is that $future->resolve() and id(new FutureIterator(array($future)))->next() (like, roughly) execute meaningfully different code paths.

Somewhere in experimental or wilds, I introduced ArcanistConduitEngine. This has some weird fake future stuff going on, so this is probably now ripe.