wjakob

When rewinding to an earlier turn, what if that turn is more than 1hr old? Can this cause KV-cache misses compared to continuing the conversation?

I used to switch coated (teflon, ceramic, other fancy gadgets) pans every 1-2 years after eventually wearing them out. This seems so wasteful! I wish somebody had given me the following advice earlier: get 1-2 good uncoated steel pans. They build up a coating from cooking oils that works just as well. I've had mine for over 12 years now, and it's pristine and just a joy to use. I will probably never need another one.

Besides boringBar, the following are enabled: Claude, Dropbox, MacWhisper.

I am running the trial and it seems great except for two crucial deviations from Dock behavior. Clicking on a button ("chip") does not bring the associated window to the foreground. It does work when I hover over a chip and then click the preview of a specific window. But nothing happens when I directly click the button in the bar. The issue occurs regardless of whether an app has 1 or >1 windows open. In the latter case, I would prefer if clicking the button brings the most recently used window to the top.

Another observation: many macOS apps (e.g. pages, mail, keynote, etc.) like to stay open even without having any active windows. This is completely hidden by boringBar, which leads to tons of apps being open without the user being aware of it (-> memory waste). Furthermore, actually using such an app then requires me to awkwardly type the name of the app even though it's already open.

I think it would be better if such passive apps without windows still have chips, perhaps smaller ones without a window title.

Regarding the foreground issue, in case it's relevant: The app has all the permissions it requested. This is on a macOS 26.2 on a M4 MBP.

I am very worried by feature creep in libc++ and libstdc++ and the harm that this inflicts on the wider C++ ecosystem. Transitive inclusion of large parts of the STL, and entangling of STL with core language features are both extremely bad. This should IMO be topic #1 of the committee but is barely even noticed. The mantra "It's okay, modules will save us" is naive and will not work.

> Why would you recommend that? [..] It's a bunch of work for no benefit.

nanobind/pybind11 (co-)author here. The space of python bindings is extremely diverse and on the whole probably looks very different from your use case. nanobind/pybind11 target the 'really fancy' case you mention specifically for codebases that are "at home" in C++, but which want natural Pythonic bindings. There is near-zero overlap with Cython.

There is also IINA that somehow seems more snappy/better-integrated on macOS.

What's wrong with red-black trees? :) Since you mention C++: you do realize that std::map will typically be implemented with one?