 | Lix | 1123 Members |
| Lix user channel. Feel free to discuss on-topic issues here and give each other help. For matrix.to links to the rest of the Lix channels, see: https://wiki.lix.systems/books/lix-organisation/page/matrix-rooms | 305 Servers |
| Lix | 1123 Members |
| Lix user channel. Feel free to discuss on-topic issues here and give each other help. For matrix.to links to the rest of the Lix channels, see: https://wiki.lix.systems/books/lix-organisation/page/matrix-rooms | 305 Servers |
| Sender | Message | Time |
|---|---|---|
| 23 Feb 2026 | ||
 MangoIV | Hi guys, I checked the issue tracker and there was no open issue about lix (nix build) not recognising derivations that upstream nix and the lix repl (+:b) - is that a known issue? I also know that I did build this derivation with lix at some point without changing it so I think this is a regression. | 22:55:20 |
 raitobezarius | In reply to @mangoiv.:matrix.orgSurprising, do you have a reproducer? | 23:15:09 |
 sterni | hm, I don't think the frozen nixVersion in Lix is so good either since we are doing breaking language changes after all. | 23:24:46 |
| sterni | it is not possible, for example to write code that deals with NUL bytes correctly since there is no way to check for Lix 2.94 other than crashing the evaluator if <= 2.93 | 23:25:55 |
| MangoIV | I do have one but I don't know if you're gonna enjoy that... ^^ | 23:30:51 |
| raitobezarius | In reply to @sternenseemann:systemli.orgThere's been discussions to move to feature based testing aka builtins.features.nulbytes or something | 23:33:19 |
| MangoIV | after comitting it does not reproduce anymore | 23:33:35 |
| MangoIV | horrible | 23:33:37 |
| raitobezarius | In reply to @mangoiv.:matrix.orgDo tell | 23:33:47 |
| MangoIV | no I mean after comitting it doesn't reproduce anymore so I was lying but I was not expecting that | 23:34:09 |
| MangoIV | I do have eye witnesses though | 23:34:14 |
 piegames | In reply to @sternenseemann:systemli.orgThe problem is, what would an in-lang check even do in such a case? Jist fail more gracefully? | 23:35:07 |
 Lun | committing did some crlf -> lf munging? | 23:35:14 |
| MangoIV | if you still want the thing that did reproduce it before comitting github:mangoiv/haskell-language-server/90c6f790c44c862f1b9726a9277c71f3c61b1ee4 | 23:35:33 |
| piegames | In reply to @raitobezarius:matrix.orgThat would be inherently unsafe. Really, any such checks should be moved out of language ASAP | 23:36:02 |
| raitobezarius | In reply to @piegames:flausch.socialCould you reiterate why? I can see why some feature testing is dangerous but throwing an error in absence of NUL bytes support seems fine to me | 23:39:33 |
| raitobezarius | Crashing as an alternative doesn't seem better to me as an error message | 23:39:53 |
| piegames | Yes but ideally that checking amd error message should be done outside of the Nix code, before even attempting to evaluate it | 23:40:53 |
| raitobezarius | Arguably we don't spend too much time trying to cater to decades of brokenness and we assume that many features are available without feature detection | 23:40:53 |
| sterni | piegames: well if I could properly check whether NUL bytes can be in strings I could actually process 100% of all valid strings in all Nix impls https://cl.tvl.fyi/c/depot/+/14011/1/users/sterni/nix/char/default.nix | 23:41:12 |
| sterni | and this is already a problem with much more mundane things, e.g. if you want to check whether a string doesn't have a NUL byte in it, you can't actually implement that easily | 23:42:11 |
| sterni | since you need to have a string that contains a NUL byte | 23:42:23 |
| raitobezarius | In reply to @sternenseemann:systemli.orgBut then arguably the proposal here is that you have a test runner that passes the right charset path depending on Lix actual version | 23:42:51 |
| raitobezarius | Idk | 23:42:58 |
| raitobezarius | In reply to @sternenseemann:systemli.orgThe difficulty of smuggling NUL byte atm is a feature imho because I'd rather see us going slowly on this rather than open the flood gates of binary manipulations in Nixlang | 23:44:10 |
| piegames | In reply to @raitobezarius:matrix.org Given the information about what features an interpreter implements, there are exactly two allowed things which may be done with:
Upholding that invariant is up to the nix code and failing to violate it may result in unsoundness, therefore functions providing this should be deemed "unsafe" | 23:44:26 |
| raitobezarius | I am not going to stand against making Nix expressions less prone to evaluation path divergence due to weird witnesses we would leave in the language | 23:47:05 |
| raitobezarius | Until we get better eval level provenance, the solution of doing it outside won't change the end result of causing divergence by feature testing though, albeit people crafting weird contraptions gets weird results | 23:47:46 |
| piegames | In reply to @sternenseemann:systemli.orgIf that code ever makes it into a derivation, then the derivation will evaluate differently based on the used Nix interpreter and version. That's what I call unsound (admittedly somewhat handwavingly) | 23:47:51 |
| sterni | not necessarily :) | 23:48:17 |