| 23 Feb 2026 |
 Evie (they/she) | Where can I read more about the "move flakes out of core" initiative/plan? | 20:56:39 |
 raitobezarius | what info are you looking for? | 21:15:16 |
| raitobezarius | we have https://wiki.lix.systems/books/development/page/flakes-feature-freeze mostly — but it doesn't explain the plan | 21:15:36 |
 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.org
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. Surprising, 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.org
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 There'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.org
I do have one but I don't know if you're gonna enjoy that... ^^ Do 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.org
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 The 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.org
There's been discussions to move to feature based testing aka builtins.features.nulbytes or something That would be inherently unsafe. Really, any such checks should be moved out of language ASAP | 23:36:02 |
| raitobezarius | In reply to @piegames:flausch.social
That would be inherently unsafe. Really, any such checks should be moved out of language ASAP Could 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.org
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 But 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.org
since you need to have a string that contains a NUL byte The 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
Could 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 Given the information about what features an interpreter implements, there are exactly two allowed things which may be done with:
- Error out
- Provide a semantically equivalent polyfill
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 |
