If I get some computer time, I’d like to finalize my attempt to make the nuenv script from nu_scripts (1) unload the .env.nu environnement when leaving its directory and (2) easily reload it when the .env.nu contents change.
See https://github.com/fuzzypixelz/nu_scripts/tree/nuenv-reload
score 1 · canonical
Yes there was pi-terminal-thème for instance, which I have been using until the system theme was added. I should have said that the built-in themes were only dark/light, and that the issue of “fitting the terminal colors” was initially only remedied by an automatic switching between the two, before the system theme was added. I was referring to the out-of-the-box experience, which is how I used Pi really. The only extension I ever had was pi-terminal-theme.
score 1 · canonical
For many months, Pi annoyingly insisted on a light/dark theme duo, with no option at all to disable the machinery that sets its own colors. Thankfully there was https://github.com/mavam/pi-terminal-theme.
But I can’t help but feel that this is needlessly complex. Typically a terminal application with a “native” palette maps its colors to terminal colors in a best effort manner. But I understand that it’s quite awkward to map a set of 60 elements to a set of 18 elements.
I believe that the contrast problem is better solved on the terminal emulator’s end. kitty has text_fg_override_threshold, Ghostty has minimum-contrast and iTerm2 has a minimum contrast setting as well. This detail is frustratingly missing from the discussion around Pi’s system theme design. I commend the enthusiasm of the survey but it’s important to be aware that some terminals will rewrite your colors anyway.
As a concrete example, the base16_transparent theme in Helix is horrendous with most kitty themes I’ve tried. But a sufficiently high minimum contrast setting made it good enough. Incidentally, here Helix demands 76 colors, which sits uncomfortably close to Pi’s stated number despite the fact that Helix has a much less trivial UI.
I don’t want every terminal application to be doing its own contrast calculations; I cannot rely on them doing so, thus I will set minimum contrast anyway so I don’t have to think about it.
Perhaps there should be a protocol that allows a terminal application to ask for contrast adjustments when it knows it’s using entirely too many colors and needs help.
score 1 · canonical
I can’t stay much about the noise around LLMs on Lobsters in particular. I’ve only joined recently after all.
I was speaking of my experience with the overall internet, e.g. on YouTube where “I’m done coding with AI” by Brett Codes hit 1M views in early Aug and was positively received in general.
Though I admit I was lurking HN more often in the past, and the general madness in the comments over there might’ve influenced my impression that things have gotten better since I opted to get my tech news from here instead.
score 1 · canonical
Fun discussion on why i0 existed but is removed in this release: https://github.com/ziglang/zig/issues/1593
score 1 · canonical
I believe that PLs are for people. As long some people write code for other people with intent and care, then PL design will matter for the original author, for the reviewer, for future maintainers, for hackers and for users (on account of enjoying a program whose behavior was grasped by a person).
For a PL researcher, I imagine the thought of my systems no longer being exclusively exclusively or even primarily used by people quite disheartening.
But the more research we put into empowering people to use PLs with ease (less cognitive load, friendlier tooling, simple semantics, etc) the more attractive and exciting it will be to write code by hand. I am really excited to learn Zig for example because I see many refreshing ideas in it coming from Rust. Of course it will never reach the same level of effortlessness as using LLMs, but it is something that many people care still care about.
I also think that it’s interesting to think about whether it’s possible to have a clean separation between human authored code and LLM-generated code inside a code base, whether we can have language features that help with restricting the effects of running slop (e.g. limited capabilities), etc.
It seems that recent online discourse is increasingly critical of LLMs and already thinking of hopeful ways forward. We’re moving away from the phase of astonishment and panic. That’s quite pleasant to see. Although maybe I shouldn’t have been so online in the first place :P
score 1 · canonical
Don’t mean to hijack the thread, just testing the waters; Paris meetup perhaps?
score 1 · canonical