(Of course, it'll probably just work the first time now...)

The export process is already robust at a coarse level: the dump is retained on disk and the process can be retried at the "upload the whole file again" level, then picked up with bin/host export using the --database or --database-file flags (probably with --keep-file).

The (anonymized) error the process encountered occurred while transferring the dump to central storage was:

Per above, this was partially mooted by the house framing rotting and partially resolved by me being generally pretty satisfied with the "Stop or Prop".

These are still stuck in a manufacturing backlog.

About a year later, I still like PCB manufacturing in theory, but haven't actually manufactured any more PCBs.

A year or so later:

I redid the clogged sink according to the schema above and haven't had any issues with it so far. I think this is probably an approximately reasonable map for tackling plumbing problems that might arise in the future.

For the moment, the customer has pivoted to knitting.

The customer requirement for "NO MUSIC!!!" abated before I got around to pulling the vehicle apart, so I'm giving up on this one.

Well now, that is certainly a nice rock.

In D21862#279385, @epriestley wrote:

I'll see about getting it upstream.

See D21862.

Next issue: can't pull from secure.

Issue 3:

With bin/provision events working again:

Your suggested patch looks correct to me, insofar as I recall what a computer looks like. I'll see about getting it upstream.

Things I've figured out:

I haven't used heat-set inserts yet and I'm not sure if they're trustworthy or not.

Bobbin Case

One actual logical issue inline.

Fine as-is, but see inlines about Conduit error behavior.

This version looks correct to me in all non-pathological cases, thanks!

PhutilJSONParserException is sometimes handled specifically:

My preferred behavior is that the error is reported to the user, but not sent to the error log.

This is a big mess, but here's some general guidance (see also inline):

I think the JSON change is suspicious, everything else looks good.

The two phlog() commands introduced in error handling seem unrelated, can we strip those out of this change? Everything else looks good.

I didn't catch anything that looks suspicious or hazardous. Thanks!

(Haven't forgotten about this stuff, but the kids got sick and family is flying in soon.)

The relation between AuthProvider and AuthProviderConfig and AuthAdapter confused me a bit

I think the string typehint isn't supported until recent-ish PHP, so its availability will depend on your minimum supported version.

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.

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

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.

Aha! Looks good, then. Thanks!

I'm a little confused about how we ever hit the test for zip_open() (or whatever prompted the original change in D21860) if you don't have any custom compressed fonts and Phabricator doesn't ship with any custom compressed fonts? This change looks good to me, but how did we run into a problem in the first place?

(It would also probably be fine to just remove support for compressed figlet fonts, they're probably saving like 5KB?)

Thanks!

I also cherry-picked this to stable, since I don't have any specific plans around when I'm going to cut the next release right now.

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?

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

Thanks!

...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. >_> <_<

An easy optimization here is likely to avoid calling phutil_utf8v(...) on very long strings using a strategy like this:

• Slightly smaller diff.

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: