That said, after the squash merge of A and git fetch origin, you want something like git rebase --update-refs --onto origin/main A C (or whatever the tip of the chain of branches is)

The --update-refs will make sure pr B is in the right spot. Of course, you need to (force) push the updated branches. AFAICT the gh command line tool makes this a bit smoother.

Which seems to be function composition and some extra rules about if there's 1 or 2 arguments, so the 2 arguments go to G and F is applied as a single argument function. Anyway if you click on a few of these an look at the red text in the upper right it's fairly clear what it's doing.

> look, I'm sorry, but the rule is simple: if you made something 2x faster, you might have done something smart if you made something 100x faster, you definitely just stopped doing something stupid

https://x.com/rygorous/status/1271296834439282690

I've no idea myself, I just thought it was interesting for comparison.

Some bitcoin advocates will talk about how useful it is as a currency, and I wonder how much bitcoin is actually used for purposes other then to hope you can sell it to someone else for more than you paid.

Ideally we could just increase the tax credits so it's large enough to cover the childcare expenses (and other necessities), and let the families decide what is best. And yes, some people are going to do a bad job taking care of their kids and spend the money on something else. But my understanding is that it generally works well to just give people money, rather than pay for specific things.

Actually, now that I think about it, choosing z = c * t is kind of both influencing how the path is parameterized as well as the path carved out on the sphere.

As an example: Say the user clicks a button to submit a form, clicking the button updates the local state to include something like `status: 'SUBMIT_REQUESTED'` then you make the request conditionally, and update the state to `status: 'IN_PROGRESS'`.

It might become a mess, but the point is to do no side effects based on any events, all effects happen conditionally based on the state. My hope is the forces you to actually track everything you should be tracking in your state object.

  - No Hooks.
  - Don't try to sync any state. E.g. keep a dom element as the source of truth but provide access to it globally, let's call this external state.
  - Keep all other state in one (root) immutable global object.
  - Make a tree of derived state coming from the root state and other globally available state. (These are like selectors and those computations should memoized similar to re-select)
  - Now imagine at any point in time you have another tree; the dom tree. If you try to make the state tree match to dom tree you get prop drilling. 
  - Instead, flip the dom tree upside down and the leaves get their data out of the memoized global state. 
  - Parent components never pass props to children, the rendered children are passed as props to the parent. 

One note, is that the tree is lazy as well as memoized, there's potentially many computations that don't actually need to be computed at all at any given time.

You need something like Rx to make an observable of the root state, some other tools to know when the external state changes. Some memoization library, and the react is left with just the dom diffing, but at that point you should swap out to a simpler alternative.

They had a 6 x 6 grid with 26 letters, then the digits 1-9, then an extra X to fill in the space left over. :facepalm: