| 28 Apr 2026 |
 zoë (@blokyk) | maybe i'm just blind, but is there any instruction for building lix with debug symbols? i tried to debug it with lldb and i just get nothing ^^; | 16:29:12 |
| zoë (@blokyk) | * maybe i'm just blind, but is there any instruction for building lix with debug info? i tried to debug it with lldb and i just don't get any source ^^; | 16:35:41 |
| zoë (@blokyk) | hmm actually it's just that every source path is pointing to /build/lix instead of /lix | 16:42:55 |
| zoë (@blokyk) | * nvm it's just that every source path is pointing to /build/lix instead of /lix | 16:43:16 |
 Qyriad | This is a persistent problem we have with everything we build that doesn't substitute from Nixpkgs (where nixseparatedebuginfod works) >.> | 16:44:34 |
| 29 Apr 2026 |
 antifuchs | to close the loop, here | 13:54:38 |
| antifuchs | * to close the loop, I think I fixed the thing https://github.com/NixOS/nixpkgs/pull/514441 | 13:54:48 |
| zoë (@blokyk) | actually Qyriad i removed this line that you added in f9d08cc44c, and i do get correct sources in lldb and gdb; is there some nuance i'm missing there? | 15:12:57 |
| zoë (@blokyk) | * actually Qyriad i removed this line that you added in f9d08cc44c, and i do get correct sources in lldb and gdb without needing any setup in the debugger (eg source-map in lldb); is there some nuance i'm missing there? | 15:13:45 |
| zoë (@blokyk) | * actually Qyriad i removed this line that you added in f9d08cc44c, and i do get correct sources in lldb and gdb without needing any setup in the debugger (eg source-map in lldb); is there some nuance i'm missing there? | 15:13:52 |
| 30 Apr 2026 |
|  Deez Nutz Right Wing joined the room. | 01:21:10 |
| Deez Nutz Right Wing | Your tos is a hoot | 01:21:24 |
 electria | I didn't know Lix had a Terms of Service (TOS), considering it's not a service...
A development chat is also most certainly not the right place for this
| 01:27:31 |
| 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 |
| samrose | yes it's a rather large undertaking | 17:28:52 |
