rictic

I just want to say kudos for the design of the protocol. Seems inspired by https://langserver.org/ in all the right ways. Reading through it is a delight, there's so many tasteful little decisions.

One bit of constructive feedback: the TypeScript API isn't using the TypeScript type system to its fullest. For example, for tool providers, you could infer the type of a tool request handler's params from the json schema of the corresponding tool's input schema.

I guess that would be assuming that the model is doing constrained sampling correctly, such that it would never generate JSON that does not match the schema, which you might not want to bake into the reference server impl. It'd mean changes to the API too, since you'd need to connect the tool declaration and the request handler for that tool in order to connect their types.

I'm putting increasing probability on the idea that there's something in our modern environment that's disrupting the GLP-1 metabolism (or a related system), these drugs are counteracting that effect.

When it was just appetite suppression, that made sense, we're not adapted to a modern degree of plenty. Not sure that explains the other positive effects, if these results reproduce.

It is way easier to get someone to click a link than to get them to download and run your app.

I'm optimistic that improved proof search using modern AI can make working with dependent type systems much more productive and practical.

A future programmer may be spending more time formally describing the invariants of the system.

It's true that there are valid programs which don't type check in the same way that for any mathematical system there are truths which can't be proven.

In practice though, almost any program you'd want to write can be type checked, in the same way that few proofs get tied into Gödelian knots.

I've never worked with a group that tested each of their rebased commits, and the rebase workflow definitely doesn't make that the default. It's possible, the options are there in the flow, but they're inconvenient and out of the way, and as a result, people don't use them in my experience.

> Not to imply I accept the "corrupt database" opinion, but I think it's worth saying that aside from the collaborative element of VCS, commits exist for the purpose of exploring past code changes. A practice which improves that seems sound to me.

I dispute that rebasing improves exploring history. It makes the history linear at the cost of making intermediate commits untrustworthy.

Both techniques require some manual discipline, and I'd feel differently if in practice people generally would lint and test each commit every time they rebased. If you do, then I've got no quarrel with ya.

Memory errors can be exploited by a clever adversary to control your process in a variety of unpleasant ways, see: https://en.wikipedia.org/wiki/Memory_safety#Types_of_memory_...

Sure it looks nice, but it's a fake history. After a rebase you have commits where no one's ever run the tests, no author ever intended to get the repo into that state. Hell, most likely no one knows if the code even compiles.

It's assuming that that merge conflicts will never be too difficult, and people won't make mistakes in resolving them. If so, too bad, the original commits are lost by the rebase process. (They might or might not be kept in any given clone. No guarantees, good luck trawling through the reflog.)

It's corrupting your database because it makes the UI for exploring it nicer.

This is the opposite of what we should be doing! If the truth is messy we should build better UIs for exploring it. Add additional information on top of the true history, allow people to group and describe commits. Add more information to get the UI that you want, rather than destroying information because it makes things look cluttered.

Related work: Functional Enumeration of Algebraic Data Types - https://mengwangoxf.github.io/Papers/Haskell12.pdf

It's quite efficient, able to generate the 10^100th element in ~a second on 2013 hardware. It also groups the generated values by size, so you can e.g. randomly sample among ASTs with N nodes.

Yeah, some of the bigger models won't work, but there are a bunch that will.

Thanks for making this app! I've been using it for the past week or so. I've played around with some open source stuff but for some reason it's been enough hassle that I haven't stuck with it.

The "this conversation is completely private" messages are also oddly reassuring.

Worth being aware that deeply nested trees are quite inefficient on modern hardware, where CPUs can execute many instructions in the time it takes for a single cache miss. There are techniques to ameliorate this somewhat, e.g. B-trees, but from a quick skim of pygtree it looks like it doesn't use them. You may get a spaghetti of nodes and pointers spread unpredictably over the heap.

It's easy to end up writing code that's got good algorithmic time complexity, but where the CPU spends its time sitting cold and waiting on RAM.

I don't miss all the variants of DVI. DVI-D, DVI-I, DVI-A, single-link, dual-link. But people would just see the cable and think, "ah, I know this, it's a DVI cable"

"I didn't delete your files, I moved them from the bucket where they aren't deleted to the bucket where they are deleted, and then according to my own policies, I deleted them. This change is mandatory."

It's a policy change that impacts storage and has the practical effect that PWAs on iOS in the EU have had the persistent storage feature removed with no replacement.

Seems fair to gloss that as "Removing persistent storage."

Have you benchmarked the overhead of awaiting? I believe that in doing so you yield to the microtask queue and then your function has to be scheduled and run again. You could compare

        await yieldOrContinue('user-visible');
        doSomeWork();

against

        if (isTimeToYield('user-visible')) {
            await yieldControl('user-visible');
        }
        doSomeWork();

A few years back when I measured it on a fast laptop the cost was ~1µs to do `await 0;`

You've got me curious, how did the developer's misunderstanding of forms cost millions? Was it submitting duplicate orders? Blocking submission of valid orders causing lost business?

I think it's an error to bring that up here though, where we're talking about someone patching a closed source app for their personal use. Is it worth the cost/benefit of decompiling and studying the app's code sufficiently long to be highly confident of the fix?

Sloppiness and "good enough" has its place. So does full effort correctness.

Epistemic status: just some guy, override this if you get specialist info.

Lenders are going to take this into account. I imagine that commercial real estate lenders are realists though, and expect their debtors to exercise their right to walk away from deals that go south. So lenders may consider it primarily a reflection of the state of commercial real estate, and secondarily a reflection of those companies' ability to operate in a bad market, and a fairly minor update on how the debtor will behave in future deals (because they already expect this behavior).

Home mortgage borrowers defaulting is more unusual and may say more about the person, given that a high proportion of the population will hold onto their home even if the value of the home drops and the mortgage gets underwater. This expectation gets priced into the terms of the home loan. So an individual who's shown that they're willing to exercise the default option if the market turns has a different risk profile.

A random sampling of things GPT-4 has helped me with lately:

Where are the dates in whole foods? (A: with nuts, not fruits and veggies)

How can I steam bao without a steamer basket? (A: saucepan, 1" water, balled up aluminum foil, plate, baos, lid)

Any guess as to when this photo was taken? It looks like anywhere from the 70s to the 90s. (A: the photo paper has a logo that postdates a 2003 company merger)

If you're asking "Could another company make a much better version of their products?" then the answer is a fairly clear yes, it could happen to OpenAI. They have an unknown number of proprietary advancements that give their products the edge (IMO), but it's an incredibly fast moving space with more and more competitors, from fast moving startups and deep-pocketed megacorps.

The impression I get is that if they rested on their laurels for a fairly short time they would be eclipsed.

Yeah, Jevons Paradox suggests that 10xing efficiency of training and inference would increase demand for GPUs.

Carmack doesn't seem to believe that ASI will be dangerous, while it's currently looking like Ilya is breaking with Sam over this.

Are there stats on what proportion of Deck use is piracy? I have a Deck, half my friends have Decks, none of them have mentioned piracy as a use case that I can recall.

A 40 year old with a twenty year back catalog of Steam titles gives me plenty of things to play.

Turning an airline receipt pdf into a well structured function call is very nice.

Yeah, tools can add support for them, but they're fundamentally a whole-program-optimization in a build chain that's 99.9% file-by-file.

Supporting const enums will, by necessity, greatly reduce the maximum performance that toolchain can achieve, because you have to evaluate the entire project to tell whether `Foo.BAR` should be left alone or replaced with a constant defined elsewhere. And in the worst case of an ambient declaration, "elsewhere" could be any file in the project.

This is definitely the dream of the Lit team, that Lit itself gets smaller and smaller as the platform gets more capable. For example, the DOM Parts proposed spec would let us drop a lot of the most complicated code in lit-html.

Lit was originally written by a group of engineers at Google, and most of the main team is still at Google working on Lit either full time or part time, though there's increasing contributions and governance from outside Google.

This is, uh, a pretty confused set of things to say. Shadow DOM is implemented in every browser. Now that we've dropped IE11, Lit doesn't need any polyfills in any of our supported browsers.

Lit is javascript, and would greatly benefit from Google's internal stack having better support for NodeJS.

There are thousands of Lit elements in google's internal repo, and new products are launching with Lit regularly. One of the recent ones I really like is Google Maps' API built on Lit and web components. Makes it super easy to drop a map into a page: https://developers.google.com/maps/documentation/javascript/...

How would the API do that without more overhead than the check that GP is suggesting?

Ascii convention to emphasize text, similar to doing the same thing with asterisks. Markdown later used this syntax for italics and bold, which popularized it further.