| 21 Apr 2026 |
 piegames | Hm, would simply saving the history after each command also work around the issue? | 12:46:25 |
| piegames | (Not sure if that's a good idea either) | 12:46:41 |
 zoë (@blokyk) | no unfortunately, unless we also reload the history before each prompt, because otherwise we'll still be writing the "outdated" history to the file | 12:48:12 |
| zoë (@blokyk) | for most people it shouldn't be an enormous burden, but idk it feels dirty and pretty fragile | 12:50:44 |
| piegames | In reply to @blokyk:matrix.org
no unfortunately, unless we also reload the history before each prompt, because otherwise we'll still be writing the "outdated" history to the file That's what I meant yes | 12:55:12 |
| zoë (@blokyk) | * for most people it shouldn't be an enormous burden, but idk it feels dirty and pretty fragile (we'd be at the mercy of disk I/O timings) | 12:56:10 |
| zoë (@blokyk) | * for most people it shouldn't be an enormous burden, but idk it feels dirty and pretty fragile (+we'd be at the mercy of disk I/O timings) | 12:56:21 |
| zoë (@blokyk) | personally i don't feel like that's a better solution :/
in part because of the aforementioned fragility+timing, but also because it'd then have the side effect of sharing the history between every repl session, which is an antifeature imo (i often have two repl sessions side-by-side to trying out different things, or i open a quick repl to check something for a bigger expr or something; if both sessions are shared i have to wade through the other repl's history while trying to navigate the current session's history because they're now all confusingly interleaved... there's a reason i generally disable zsh's SHARE_HISTORY option @_@) | 13:04:06 |
| piegames | I see | 13:11:14 |
 goldstein | offtopic, but thank you for teaching me I can just disable SHARE_HISTORY, this was annoying me immensely | 14:46:20 |
| zoë (@blokyk) | there's actually multiple mutually-exclusive settings that control zsh, each one making you go "wait, the other one didn't do that?!" :D
| 14:51:54 |
| 23 Apr 2026 |
 antifuchs | also can I just say log-format = multiline-with-logs is so nice! first time I'm customizing that log format and it is far easier to see what's going on during nix build | 17:29:53 |
| antifuchs | (the explanation in the manual is a little less clear re. the differences to bar-with-logs though. is the diff that multiline-with-logs shows the currently active tasks below the bar?) | 17:31:09 |
 kloenk | yeah essentially. sorry I'm bad with describing some things :) | 17:33:59 |
| antifuchs | On a re-read that’s what it says! Just hard to form a mental picture without seeing it in action tbh | 19:56:35 |
| 25 Apr 2026 |
|  hsjobeki joined the room. | 11:19:23 |
| hsjobeki | I'm planning to migrate the nixpkgs module system eval tests from bash to nix-unit. There is also lix-unit. Question in the room: any plans to add this to nixpkgs? I would then wire up the test suite against that. Or do people have there own module system tests in lix? | 11:21:53 |
 emily | does nix-unit support all the supported versions of the Nix C++ API? otherwise we lose the ability to test on those versions, no? | 11:29:27 |
| emily | and https://github.com/adisbladis/lix-unit is archived for years unless it was moved | 11:30:20 |
 Sergei Zimmerman (xokdvium) | In reply to @hsjobeki:matrix.org
I'm planning to migrate the nixpkgs module system eval tests from bash to nix-unit. There is also lix-unit. Question in the room: any plans to add this to nixpkgs? I would then wire up the test suite against that. Or do people have there own module system tests in lix? I’m not sure it’s a great idea. The tests are used for both cppnix/lix CI I think, and it would be quite intractable. Maybe if it could be polyfilled somehow then it would be nice yes | 11:36:44 |
| 16 May 2024 |
|  zrsk joined the room. | 13:54:49 |
 samrose | In reply to @lunaphied:lunaphied.me
I think there were a few CLs on the Gerrit but nothing being actively worked The other thing that I could do if it helps is test things and try to find bugs. I did do some C++ work in the past, but may lack the time to do it justice here at least for about 30 days or so | 15:55:29 |
 Qyriad | we are not in any rush 🙂 | 17:20:53 |
| samrose | Would it help to also test out the existing Lix code and try to find issues/bugs etc? | 17:23:21 |
| Qyriad | absolutely | 17:23:41 |
| samrose |
- how do people feel about the existing test suite that comes along with nix source code or Lix?
| 17:23:48 |
| Qyriad | it's pitiful | 17:24:10 |
| samrose | heh | 17:24:16 |
 raitobezarius (DECT: 7248) | expanding it is cool | 17:24:23 |
| raitobezarius (DECT: 7248) | writing new tests for builtins which are not tested | 17:24:30 |
