| 21 Apr 2026 |
 zoë (@blokyk) | with regards to #1175, does saving each typed line ourselves (e.g. in an std::list or std::vector?) and then appending it to the file sound good? if so i can try to make a CL for it, but i want to get a vibe-check for it first | 12:26:04 |
| zoë (@blokyk) | * with regards to #1175, does saving each typed line ourselves (e.g. in an std::list or std::vector?) and then appending it to the file sound good? if so i can try to make a CL for it, but i'd like to get a vibe-check for it first | 12:38:30 |
| zoë (@blokyk) | * with regards to #1175, does saving each typed line ourselves (e.g. in an std::list or std::vector?) and then appending it to the file sound good? if so i can try to make a CL for it, but i'd like to get a vibe-check about it first | 12:38:35 |
 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 |
| 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 | expanding it is cool | 17:24:23 |
| raitobezarius | writing new tests for builtins which are not tested | 17:24:30 |
| raitobezarius | new test behaviors, etc. | 17:24:32 |
| Qyriad | we have three flavors of test:
gtest (offer only available in libexpr and libutil) bash script virtual machine
the vast, vast majority of testing is in the "bash script" flavor and it is a mess | 17:25:01 |
| samrose | I was just going to ask on the "functional" tests: do we still like using bash there? | 17:25:56 |
| samrose | the last time that I worked on a major nix related cli project that used bash, or bats for testing, over time it became rather kind of hard to maintain | 17:26:42 |
| samrose | I am not usually a big python fan, but in that project we heard from some in the Rust community that they actually use Python to test CLI and seem to have success there. | 17:27:59 |
| Qyriad | no gods please kill bash testing. the problem is that it's kind of really difficult to migrate an entire test suite and be sure that you actually migrated the test suite correctly and won't lose coverage accidentally in the process, which makes any kind of migration a bit nerve wracking | 17:28:36 |
