screcth

From the comment I replied to:

> Generally grid backfeed capability for these systems is predicated on the presence of a stable voltage and frequency already on the grid.

You are using the reference clock to know precisely how misaligned the grid is and you use the reference to make small corrections to the generator power or inverter phase to restore phase alignment.

If you have an external stable reference clock (GPS) you know what the grid *phase* should be and it should be easier for network of multiple small inverters to keep the grid stable and to bring it up by themselves if there's a large blackout.

If you use GPS-based synchronization you have a reference of when zero crossings should occur. This does not mean that you have to output exactly that waveform.

Once you have a reference you can use a control algorithm. like a PID, to adjust the phase of the grid that you are generating locally.

If you sense that the grid is running out of phase from what your GPS clock says is the true reference you can increase/decrease your power output a bit to increase/decrease its frequency and catch up with the phase error.

It would be analogous to a type 2 PLL. The 1 Hz GPS clock would be the reference clock, the 60 Hz grid would be the "PLL output" and the VCO would be the power turbine, or AC inverter.

I wonder why it is that real world systems don't use a GPS receiver to obtain a 1 Hz signal that's synchronized to the GPS clock and then generate a local 50/60 Hz clock for grid synchronization.

I'm just an EE with no experience in real power systems, so this may be absurd to someone who knows how this stuff works.

You could also use SIMD to compute N independent Kahan sums in parallel and reduce them at the end.

If you have a compacting GC you are going to move the nodes anyway, so why not reallocate them sequentially?

That would only cover the simplest feed-forward designs: combinational circuits and versions with extra registers added for timing reasons.

As soon as you introduce any kind of feedback in your RTL design it's possible to do any kind of computation that SW can do and therefore proving correctness is difficult.

Formal hardware verification has been much more successful in industry. Are there fundamental differences in the types of problems that they solve? EDA companies have been able to create tools that don't require a PhD in Math to be used effectively.

I think that the explanation for such different levels of success is that economic incentives are different. The cost of a hardware bug is much much higher than the cost of the average software bug; this means that hardware companies are willing to spend a lot of money in getting designs right the first time, versus software companies that know they can always make bug fixes in new versions of their products. Additionally, hardware companies are used to paying millions of dollars in software licenses, which is not common in the software world.

Isn't it possible to restrict what memory regions a device may have access to?

TRAMP is unusable if you have a high-latency connection. The UI thread blocks for a few seconds after every operation, which are really frequent if you use a complex configuration. The remote SSH plugin makes high-latency connections bearable, it's not perfect, but IO operations run in the background and so the UI thread does not block.

I expect rewriting Emacs to use async IO to be a massive effort. It's difficult to write async code in Elisp.

I completely agree, that's why in that case you could download the missing code from the server and load it using dynamic linking.

The server would then mark it as reachable so it's delivered as part of the main bundle next time.

I would expect the bundle to converge quickly to the set of functions that are actually reachable.

Aditionally, it's very likely that the sets of reachable code of two versions of the same app have significant overlap, so the information collected for version N could be used as a starting point for N+1, and so on.

Could it be possible to do "profile guided tree-shaking" to build a small module with all the code that's necessary for the application and pull-in less used functionality on-demand using dynamic linking?

If tree-shaking was done based on production information it may be possible to prune a lot of dead/almost-dead code without having to implement sophisticated static analysis algorithms.

Why don't sources try to measure the frequency response of the driver + cable + headphone circuit and apply a digital prefiltering step to compensate these distortions?

Analysis becomes much simpler when frequencies are low enough. Wavelength is large compared to the dimensions of the circuit so you can ignore the effects of wave propagation.

What's stopping AMD from implementing CUDA?

Just like Wine implemented Windows APIs

Does this mean that someone could decrypt a old dump of traffic between a client and GitHub? If so, this means that every repo on GitHub must be assumed to have been leaked?