With PHP 7.4, it seems OpenSSL (and various other libraries) have moved to pkg-config, which is a tool that uses the PKG_CONFIG_PATH environmental variable to locate packages. This impacts OpenSSL and libxml2.

"FutureGraph" is dead. Long live "HardpointEngine".

Generators can't "return" until PHP 7:

In T11968#251717, @epriestley wrote:

XHPAST currently can't build an AST for $result = yield ..., even though this is a valid construct. This is probably a straightforward fix.

In T13492#251814, @epriestley wrote:

XHPAST currently can not parse $x = yield $y;.

This is entangled with T9753.

XHPAST currently can not parse $x = yield $y;. I suspect this was added to the PHP grammar after XHPAST diverged. I'm hopeful the fix is straightforward.

One long-standing warning in a unit test cropped up (D21055) but if this does have far-reaching implications, they don't seem terribly obvious/common.

XHPAST currently can't build an AST for $result = yield ..., even though this is a valid construct. This is probably a straightforward fix.

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.

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.

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

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:

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.

I'm changing the minimum required version to PHP 5.5; see T13492 for 5.5-specific followup.

Probably require PHP 5.4 regardless.

A problem in moving forward here is that we ultimately do very little complex data access in Phabricator, and what complex data access we do perform can often be faked. We likely have more use cases in Arcanist and provisioning code: API calls are slower, workflows are more parallel/interactive, and we can't just fake it all with AJAX.

The issue in PHI1605 resolved itself without apparent intervention, presumably as a result of changes on the CircleCI side. I can't find any release notes to shed any light on things, but this is no longer time-sensitive.

(Since a full implementation here will imply that removing a custom field from configuration may "unmention" an arbitrarily large number of relationships, and we can't easily do that inline or at display time, the ultimately implementation would likely include a more robust version of this script.)

In PHI1602, I proposed a script to "reset" mentions on an object. The use case this serves is:

I deployed the --sshd-key %k stuff to secure and it looks like that shaved ~1,000-2000ms off the total cost. The ssh-auth cost has dropped to about 200ms:

I saw things hang during deploy and the OpenSSH bug should have been fixed years ago.

I configured ControlMaster on secure.

For LDAP, brew install openldap + --with-ldap=/usr/local/opt/openldap/.

Vaguely adjacent:

Now that we are on RDS I can confirm that MySQL also has ONLY_FULL_GROUP_BY enabled by default.

Our behavior appears to be correct when the load balancer is an AWS ELB.

That actually using MySQL official Docker image.

There are only 23 occurrences of the string "GROUP BY" in the codebase, and, from inspection, many obviously do not conflict with ONLY_FULL_GROUP_BY.