shabbyrobe
The rationale for MCP and codemode I can swallow, Armin's writing on that makes a lot of sense, and meeting models where they are seems critical to me based on my own experience.
But for me, fullscreen mode is a huge turn-off. I already have a backbuffer that I strongly prefer to use, it's called my terminal, and it's important to me. If the backbuffer-based version disappears, I'll be forced to migrate to something else (seems there are a few options here) or make my own tool, but that involves abandoning or porting my extensions, which turned out to be a huge superpower with Pi. Perhaps Pi Durable helps with that and lets me keep my extensions, but I'd rather this was not necessary in the first place.
If switching to full-blown TUI has anything to do with how slow the "expand thinking" and "expand tool output" features get as the session gets longer, could that be mitigated by only expanding the n most recent behind the default shortcut, and the slower "nah, I really do want you to expand them all thanks" can be a different shortcut?
If it's to add more fancy features that require fullscreen rendering and a dyed-in-the-wool terminal user like me might reasonably tolerate as a dismissable modal, make those bits TUI, but keep the backbuffer in the terminal (for e.g. the session tree or the settings, those don't need to be in the terminal's scrollback).
And if it's for any other, richer interactions... can we just... not, instead, and let the terminal be the terminal rather than a single page web app?
This at least seems to improve the situation of marshalling to/from an interface directly slightly by providing the ability to pass custom Unmarshalers for a specific type (via json.WithUnmarshalers and json.UnmarshalFunc) to the Unmarshal functions, but it appears to still have the inefficient double-decode problem. Or I just haven't found a decent way around it yet.
Looks like they're intentionally punting on a first class solution until (if) the language gets some sort of sum type, but I still think the second-class solution could do a bit more to make this extremely common use-case more convenient. Pretty much every serious production Go app I've worked on in the last 10 years or so has had some horrible coping strategy for the "map a field-discriminated object to/from implementations of an interface" gap.
Quote from the proposal [1]:
> First-class support for union types: It is common for the type of a particular JSON value to be dynamically changed based on context. This is difficult to support in Go as the equivalent of a dynamic value is a Go interface. When unmarshaling, there is no way in Go reflection to enumerate the set of possible Go types that can be stored in a Go interface in order to choose the right type to automatically unmarshal a dynamic JSON value. Support for such use cases is deferred until better Go language support exists.
[1]: https://pkg.go.dev/github.com/go-json-experiment/json
[2]: https://github.com/golang/go/issues/71497
[3]: https://github.com/golang/go/discussions/63397Heads up about the modernc library, it has been stuck on an old version of sqlite for several months [1]. It seems like maintainer time is the limiting factor [2]. There has been a call to arms on that issue page, the maintainer is looking for help, but it looks like not much has arrived. It seems like it might trace back to blockers in the C-to-Go compiler.
It's a major undertaking and a very impressive piece of work, but I'm not surprised it's a struggle when big roadblocks get hit. I hope they find a way to progress, but I'm very relieved to be seeing some CGo-free alternatives like ncruces/go-sqlite3 emerging. I'm going to give it a try for sure and see if I can live with the compromises.
Squinn-go looks very compelling too, but I don't like that it requires the squinn binary to already be installed on a user's machine, I think that gives with one hand and takes with the other: sure, I get to avoid CGo, but I also lose the turnkey, single-command install, static build benefits Go brings out of the box.
Seconding the point about nitty gritty, I'd read it for sure too!
[1]: https://gitlab.com/cznic/sqlite/-/issues/154
[2]: https://gitlab.com/cznic/sqlite/-/issues/164 [1]: https://www.python.org/dev/peps/pep-0591/I'd love to see this one addressed but it's not looking too hopeful at this stage.
But I think this is less about specific phrases one might need to be careful not to say, and more about the kinds of default attitudes that can turn into ongoing impediments to the free flow of ideas. It's definitely possible ask "what problem does this solve" without becoming the "What Problem Does This Solve Person", and the same goes for the other phrases too.
I wonder if they started out as "That Won't Work" people, but evolved better defenses?
> Git on Windows client corrupts files > 4Gb
It's apparently an upstream issue with Git on Windows, but if you depend on something, you inherit its issues.
There are tons of proprietary escape codes, not least of all the incredibly useful one for "fireworks"! [1]
^[]1337;RequestAttention=fireworks^G
I tried to use the profiling flags to get some data to file reports, but ran out of yak-shaving time when I realised was trying to flush out a bug in the tool command helpers in golang/go where it would write empty profiles if the process was shut down the exact way vim was shutting it down. That may have been fixed since, I haven't had a chance to look back into it.
No, complaining about JS Fatigue is just like complaining that we should actually try to launch a spaceship instead of tearing the last one we started into pieces just so we can put some shiny new thing in the middle of it, and that we should try to actually finish an airplane and send an email while we're at ooh React Hooks! Hang on, I really need to start my post again and do it perfect this time now that it's possible. Bear with me a sec, trust me I'll be finished soon, hopefully you still have enough money to pay me.
"Falsehood flies, and truth comes limping after it, so that when men come to be undeceived, it is too late; the jest is over, and the tale hath had its effect: like a man, who hath thought of a good repartee when the discourse is changed, or the company parted; or like a physician, who hath found out an infallible medicine, after the patient is dead."
[1]: or merging your branch, if you're solo.
func Pants() (rerr error) {
defer func() {
if err := doStuff(); err != nil && rerr == nil {
rerr = err
}
}()
// ...
return nil
}
func DeferClose(err *error, closer io.Closer) {
cerr := closer.Close()
if *err == nil && cerr != nil {
*err = cerr
}
}
func Pants() (rerr error) {
f, _ := os.Open(...)
defer errtools.DeferClose(&rerr, f)
// ...
return nil
}Oh well, it was worth a shot, sidebar tabs are just so good when they're working well, but it's not worth the battery drain.
Your userChrome.css tweaks worked great!
The last time I tried TST, it was fairly hostile to my battery on macOS; is that still a problem?
Sidebar tabs are a massive workflow upgrade, it surprises me that it's not a core browser feature, especially now with the ridiculous proliferation of those loathsome vertical-space hostile sticky elements that have spread through the web like a plague.