surrealize

I gave a standing directive to my coordinator to process subagent transcripts (with a simple Claude-written script that reads the transcript .jsonl) and save the result. I also follow along on the issue tracker; that really helps me understand WTH they're talking about, and the subagents are also directed to post their shipped notes there.

Haha, thanks!

In the context of the union query, I think it makes sense. The query takes two different columns (with two different names) from the same table, and combines them together into one column. The TS error happened because the column names didn't match between the two union inputs. But they would never match without the "as".

Cool! I'm surrealize though, sureglymop wrote a sibling comment! I should have just made a PR, lol.

Totally random, but I had a guess about the ts error. I hadn't seen kysely before, very cool!

  diff --git a/packages/lix-sdk/src/query-utilities/is-in-simulated-branch.ts b/packages/lix-sdk/src/query-utilities/is-in-simulated-branch.ts
  index 7d677477e..39502f245 100644
  --- a/packages/lix-sdk/src/query-utilities/is-in-simulated-branch.ts
  +++ b/packages/lix-sdk/src/query-utilities/is-in-simulated-branch.ts
  @@ -21,10 +21,9 @@ export function isInSimulatedCurrentBranch(
                // change is  not in a conflict
                eb("change.id", "not in", (subquery) =>
                        subquery.selectFrom("conflict").select("conflict.change_id").unionAll(
  -                             // @ts-expect-error - no idea why
                                subquery
                                        .selectFrom("conflict")
  -                                     .select("conflict.conflicting_change_id"),
  +                                     .select("conflict.conflicting_change_id as change_id"),
                        ),
                ),
                // change is in a conflict that has not been resolved

from https://www.youtube.com/watch?v=fjWCEFioT_Y

Conclusions:

* Standard Starship is probably good enough for HLS

* Simple coatings and/or a specific orientation makes things a lot better

If you fire one board member (Altman) and remove another from the board (Brockman) it's not exactly friendly either

This definition is an abuse of the word "open"

My favorite legal Harvey is Harvey Richards, lawyer for children. He'll argue the finer points of "no backsies" etc.

https://www.gocomics.com/tomthedancingbug/2015/03/12

Well, is scraping Twitter an improper use? Anyone can see tweets and who follows who - that's public. Twitter might consider a nascent competitor trying to scrape a significant fraction of the whole thing unfriendly though.

If you're making a twitter clone (as Substack is) then scraping the twitter follower graph seems useful. And that's public, obviously.

I worked at a company that was about 150 people when I joined. It's not primarily a software company but the early team had a bunch of ex-google folks, and they chose Bazel. I encountered it for the first time there. We did use React, yes.

I really liked the cross-language aspect of Bazel. Having one command that could compile everything and produce a deployable container in a highly reproducible way is great. It really cut down on "what's your compiler/tool version etc."-type back-and-forth during debugging with other engineers.

The bazel JS/TS rules were tough to work with when we first started using it for JS (2018 I think), especially since we were using create-react-app at the time, and that didn't mesh well with the way bazel wants to work. It's gotten a lot better though.

If I was making the choice from scratch in a new company/codebase, I think it'd really depend on the team. You kind of need broad-based buy-in to get the full benefits IMO.

> having to stop for hours while waiting for your car to charge is much, much worse

Have you done this? I picture burning some kid-energy during those breaks. I'm genuinely curious about how that ends up impacting the trip experience.

> fluctuating energy costs impact TCO

compared to gas?

There's an original, canonical version of the audio, and the hash of that version goes on chain. That establishes who posted it originally, when, and the exact version. Then any subsequent (potentially doctored) version can be compared with the canonical original. The on-chain timestamp and hash can't be changed after the fact, in the same way that past bitcoin blocks can't be changed (without creating a fork).

It could at least address some kinds of misleading editing. In the political use case, maybe the candidate posts all their event audio and records the hashes on chain. Then they can't change the content of any of it without getting caught. And if someone else posts an edited version, the edit will have a later timestamp, and the candidate can point to their original earlier version and prove that it's the original. That lets everyone else determine which version is the original and which version is the edit.

This is one of those things where Balaji is ahead of the curve - the way to guarantee metadata (e.g. who the speaker is) is to do it cryptographically on-chain.

https://twitter.com/balajis/status/1583495595737481217

Why should we believe that affluent parents clinician-shop and get a diagnosis from a friendly clinician? Because of the reporting that says so, linked upthread:

https://www.hollywoodreporter.com/lifestyle/lifestyle-news/h...

It's not a "wild conjecture".

They can, just not in real time.

"Tweets that share someone else’s historical (not same-day) location information are also not prohibited by this policy."

Thanks so much for the link! I tried the original and bounced off the style. It seemed like something that might be fun and useful if I invested enough effort in reading it, but I just bounced off.

But with the translation, I just devoured and appreciated it.

I haven't had a chance to try it at scale yet, but I've been looking at josh (Just One Single History): https://github.com/josh-project/josh

which goes at more-or-less the same problem from the other direction. Josh helps with treating a monorepo as separate repos, as opposed to git x-modules' approach of treating separate repos as one repo. Either way, the idea is to try and get the benefits of both monorepo and multi-repo styles, while avoiding/mitigating the disadvantages.

HN talked about it 11 months ago: https://news.ycombinator.com/item?id=27844363

Anyone have experience/updates to share since then, or a comparison with git x-modules?

> From what I gather I was basically at fault for daring to somewhat disagree with burntsushi.

Not so much for disagreeing. More for engaging a lower-effort way (than the person you were talking to) and appearing to assume that burntsushi was coming from a place of ignorance.

> The whole "general-purpose regex engine" thing was moving the goalposts in the first place and not very relevant to this whole discussion anyway. EDIT: I'm not saying that these distinctions don't matter at all, rather what I want to say is that it doesn't make sense to implicitly call upon a subjective and arbitrary standard.

"general-purpose regex engine" is a direct response to "most regexp libraries are stuck in the 80s/90s". It's about why the regex libraries most people use (the general-purpose ones) haven't adopted the ideas that you're advocating. Seems on-point to me; on HN most readers will be mainly familiar with the general-purpose libraries, so they'll be thinking in terms of those.

I downvoted it because you were talking to burntsushi, who has implemented an excellent general-purpose regex engine and is very thorough, thoughtful, and knowledgeable about it. When he said "Can you show me the research", that was him being exceedingly generous to your point of view. And when you said "Sorry, don't have time for that right now, but look into regular expression derivatives and similar stuff", that was you being the opposite of generous.

I'd bet that the stack size you refer to doesn't include callees (i.e., the stack used by procedures called by the method in question).

Separate in the "CGo is not Go" sense.

Poland and the US are both NATO. Somehow sending them from Poland is better? And we’re going to let concerns about how Russia would perceive the transfer dictate what we do?

We’ve already sent a bunch of weapons into Ukraine. These jets are just another entry in that long list.

We need to get this transfer done.

Some interesting context from one of the resigning mod team members: https://www.reddit.com/r/rust/comments/qzme1z/moderation_tea...

Demand growth is what we want. Our economy has been largely demand-limited for a while. Demand growth boosts GDP growth.

Corporations are sitting on huge piles of cash, so they're not investment-limited. Any labor market tightness raises wages, which have been mostly stagnant for a long time (until very recently). Wage growth is also good.

If wage growth squeezes profits, then that's also good from a wealth inequality point of view.

Now I have to re-read Diaspora. Thanks!

The performance comparisons start here https://youtu.be/eYxp8yJHpik?t=1421

Looks like the bandwidth went from 3.8 GB/s to 22 GB/s, with the client being the bottleneck.