I was ready to suggest that after further investigation was made, recalling the "recent" refactor work of the mercurial command-with-extensions changes we looked at 😄

For https://we.phorge.it/T15281, consider modifying DiffusionGitCommandEngine->newFormattedCommand() to pass explicit configuration to Git (as we do in Mercurial) rather than requiring administrators correctly configure Git via .gitconfig via $HOME.

Gotcha. I'm going to take a swing at updating past 8.0 and see what crops up. Also thanks for the tip with PHPAST. I haven't looked too much into it other than trying to get it working on Windows a year or so back

With the caveat that I mostly dig holes in the dirt now and no longer remember how computers work:

Would this be reasonable to address with a new server-side setup check, similar to the checks for post_max_size and op_cache values?

I favor dealing with them on a case-by-case basis since they don't seem especially pervasive and I think in most of the cases where I've fixed the issue, the fix I chose wasn't just to swap the call. I think these strlen() errors are often a correct/useful symptom of undesirable slop in type handling.

In T13588#256584, @epriestley wrote:

PHP 8.1 disallows strlen(null).
...
Broadly, Phabricator likely will not pass the empty string as a constraint in these cases...
...
D21762 introduces phutil_nonempty_string(), which is like this test but slightly stricter (it raises an exception for wonky values) and easier to revisit later (i.e., use of this function is a hint that the code can be made more strict about value types).
...
Upshot:

• if (strlen($maybe_null)) may be replaced in all cases with if (phutil_nonempty_string($maybe_null)) to work in PHP 8.1 and not break any code which wasn't already extremely suspicious (...stringlike() may be required if the value may be an object, usually a URI object).
• This is usually not the most desirable replacement, but probably 95% of these aren't realistically worth being surgical about.
• In new code, prefer increasing type strictness over these more-flexible tests.

If the small pipe needs to drain into the big one, how about taking a large pvc end-cap, drilling a 1/4" hold and forcing the smaller pipe in it?

If the small pipe needs to drain into the big one, how about taking a large pvc end-cap, drilling a 1/4" hold and forcing the smaller pipe in it? Maybe seal the whole thing with some silicone.

I've been using Fusion 360, which I'd say is "not bad". (See also T13697, perhaps.)

I'm curious what 3d modeling software you use, I've had success making simple boxes and things like that with sketchup but I've been a little intimidated by more advanced modeling software.

...I suspect that's a difficult geometry for FDM in PLA.

These sewing machine shaft collars are kind of tricky: thread unspools around them, so the inward face must have a completely smooth edge that can't catch or snag. This rules out a simple clamping-style shaft collar with a slit in it.

Spool Cap (Small)

ADPClientService is a (currently) non-essential background service that collects juicy user data to send to Autodesk, since there's no way they could be expected to make ends meet on just $545/year licenses alone. You can find lots of threads about how to disable it in various Autodesk products, but none of these instructions appear to work in the current version of Fusion 360.

It stopped doing it as soon as I started watching it. But just wait, I'll catch it in the act. >_> <_<

They sell "broken" Ender 3 printers on eBay for like $75 shipped. I ordered two. One had a bad board (a $40 part); one had a bad Y limit switch (a $3 part) -- so the actual cost per printer seems to be around ~$100 if you're familiar with how they work and can identify which parts aren't working.

I traced the alarms back to Breaker #8 in Panel #2 (the detector tool actually worked okay this time). I disconnected the breaker and verified that killed the circuit. I swapped the alarms and updated the map of known breakers with this new information:

No great surprise, but the blue boards seem about the same as the red boards and have the same problems:

The genuine article is not a JST-VH 4-pin connector -- the connecting clip is a little different, and there's no hole in the housing for (unused) pin #2. However, the pin size and spacing is right, so you can cut the connecting clip off a JST-VH and melt one of the pins out and the connector will fit well enough.

I bought an oscilloscope and tested the speed signal of one of the new red boards once it arrived. The scope showed the perfectly sensible signal I expected, and the signal came off the board fine once I hooked it up. So maybe the first couple boards were legitimately bad?

This connector has a 4mm pin pitch, but I had a great deal of difficulty finding a likely-seeming bare connector with a 4mm pitch. After resigning myself to a Digikey quest for a connector that will fit a board on T13692, which also has a "4mm" pitch I realize the pitch is probably not 4mm but 3.96mm -- a wonderful pitch for which many connectors are readily available.

Here's the updated lightbar:

Here's my nice safe smoke detector power adapter:

There doesn't seem to be anything mechanically wrong with the toy, although the motor and gearbox don't seem to be accessible without breaking something.

The capacitors on both boards arrived pretty banged up.

String Shelf

Turny Thing

Motor Drivers

Couple of years ago the furnace wasn't working so well. Light comes on, three reds. Pressure switch stuck open. I take off a panel, pull the pressure switches. The contacts close properly. No clue what's wrong. Call an HVAC guy. He's pretty busy. No problem, we got plenty of sweaters. Ha. He makes it out early the next week.

all my drains are belong to PVC

... condensate drain ...

...there's enough absorbent material underneath the sink...

(You don't actually need a leak detector, I think there's enough absorbent material underneath the sink to last a long while before it damages the floor)

Here is my bathroom sink. The right-most pipe coming out of the wall is the condensate drain from HVAC. The tailpiece is most definitely 1 1/4 and the rest of the piping is 1 1/2, at least to the naked eye.

I can't see a way to make the trap be any less garbage than it is because the 4" flanged tailpipe (the shortest flanged 1-1/4" tailpipe I could find) plus an additional 8" of tailpipe underneath it (the only 1-1/4" branch tailpipe I could find, which is only available with a slip fitting) means that the bottom of the lower tailpipe is super low. It looks like I left an extra 6" of flexible pipe on the drain side for fun, but that's just the rigid bottom of the tailpipe plus the minimum bend radius without making the flexible pipe start to crimp -- the bottom of the tailpipe is like 1-1/2" below the black plastic retainer clip.

A few more thoughts:

Since there's no fresh water supply to the dehumidifier I don't think there's much benefit to an air gap, as there's no way backflow could ever contaminate a supply line. A clogged sink drain could possibly drain sink water out through the dehumidifier bucket, but the top of the drain line is only ~1"-2" below the top of the sink so it would overflow the basin onto the floor before very long anyway.

My terminology might be wrong throughout this but a couple thoughts:

Other options I explored and rejected:

• Inline Comments: See PHI2217. See PHI2206. Inline comments don't currently attach images.
• Destroying Edges: See PHI2201. See PHI2217. Destroying files that have old edge types may raise warnings. The destruction still works, although it doesn't hit the edges.
• Destroying Files: See PHI2217. Destroying an object doesn't destroy corresponding FileAttachment objects, so you can end up with ghosts in the UI.

There are some remaining non-security bugs with this that I'll follow up on in T13682. I believe the security side of this is now resolved.

The details of this attack will be disclosed at a later date, once installs have had some sort of plausible chance to upgrade.

An earlier patch here (rCORE6d6170f76463) swapped binlogs to MIXED and set a 24-hour retention policy. This issue has not reoccurred in the cluster since that patch went out, but the root causes remain unresolved.

I filed T13687 as a followup for preventing this particular sort of error (where a Phobject is incorrectly serialized directly).

I patched and partially deployed this in early August. Another unattended MySQL upgrade went out on Monday night, also didn't restart MySQL on affected hosts, and caused some downtime on hosts that didn't have the patch (to "disable unattended upgrades"). I've now deployed this everywhere, and am presuming this is fixed until evidence arises to the contrary.

See also PHI2219, PHI2220.

That's very likely the same problem, and I think it should be fixed by updating to the current stable (rPf2a7db1 or newer).

I believe we may be hitting either the problem one of the above commit fixes, or suffering from a similar caused as side-effect from it.

...ideally this sort of thing should fail loudly at serialization time...

• The drydock_resource table could use a (status, ...) key to satisfy common/default queries.

After recent changes, only DifferentialRevision and ManiphestTask still have onboard mail keys.