Much of this is supported now; T13492 has some general followup.

No current plans to pursue this.

No plans to pursue this.

No longer clear what this accomplishes.

I don't currently plan to pursue this.

This is very old and we have no outstanding customer requests for ARM support.

Also, just so I don't completely forget about it:

Changes in D17802, D17803, D17816 and D17817 all seem generally fine to me from cursory inspection. If D17819 seems sane for fixing the "huge blobs of unstable JSON" problem, let's stick them all on that, I'll take a closer look at the nodes, and we can get everything in? Good luck racing each other on minor version numbers.

The first page I found on the internet claims the iPhone 7 will be 1920x1080, so my strategy looks like it's paying off!

That seems fine to me.

I'm about to start implement full dereferencing support. Cases that are missing now:

($expr)[0];
SomeClass::BRILLIANT_CONSTANT[5];

@ofbeaton, if you care also about starting a translation, you can do it for src/applications like this :
./bin/i18n extract src/applications and ./bin/i18n extract src/view and merge the results.

I didn't purge the cache here, but here's an updated version of the original diff without the rendering error:

I wouldn't have expected the issue to be in xhpast at all. Thanks for the quick resolution!

In my case when attempting to generate symbols (per https://secure.phabricator.com/book/phabricator/article/diffusion_symbols/ ), this error was fixed by running make install in /usr/local/phabricator/libphutil/support/xhpast

In T10257#156493, @epriestley wrote:

Broadly:

• You only need to run arc liberate when developing Phabricator itself (e.g., writing Phabricator extensions or otherwise modifying Phabricator).
• The one ARM system (the Raspberry Pi) we have other direct evidence of users attempting to do installs on is explicitly not supported as a Phabricator host platform -- see Installation Guide. You can try, but you're on your own.
• If you're using an ARM system that could, in theory, broadly qualify as a "normal computer" to host and/or develop Phabricator this is something we might eventually look at supporting, but we don't currently have any evidence that anyone else is trying to do this. We are vanishingly unlikely to dedicate resources to ARM support for the benefit of only one user (if you are developing on ARM hardware) or one install (if you are hosting on ARM hardware).
• If you did read the "Installation Guide" and believed ARM hardware to reasonably qualify as "a normal computer", we can add additional language to make it clear that ARM is not included in what we consider "a normal computer".

Oh sorry... I am dumb.

(Assuming you meant XHPAST rather than XHProf)

Probably not, but it seems vaguely nice that i18n extract doesn't need to know anything about the directory structure, and that we can put pht() in externals/ as a local patch if we need to clarify some error or something.

Is there any real news to extract translations from externals/?

This is because externals/stripe-php/lib/Stripe/ApiRequestor.php has this on line 357:

See T9175

Ran into this today and had to try again for it to work (and upgrade). The error is scary and probably should be addressed.

hit this too.

https://secure.phabricator.com/D14031

Also unable to build XHPAST, but for a different reason.

We could make make not actually depend on the timestamps on those files, conceivably (only on whether they exist).

I think that the issue was that the timestamp on parser.yacc.hpp was older than the timestamp on parser.y. I'm not really sure how git handles timestamps but likely they aren't preserved.

What was getting cached that created an issue?

I guess git doesn't preserve timestamps... I just worked around this by running rm support/xhpast/* && git reset --hard HEAD && ./scripts/build_xhpast.php.