| 23 Feb 2026 |
 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.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 If 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 |
| piegames | Things are likely to break even within one implementation as soon as memoization hits | 23:48:21 |
| sterni | besides, language changes may just as well change evaluator behavior where the difference is not failure / success, but actual results | 23:49:36 |
| piegames | To be clear I'm fine with that, as long as functions that may result in unsoundness are marked as unsafe in a meaningful way (preferably beyond just convention). Maybe also provenance tracking, that would be awesome but also likely expensive (I haven't looked much into string context as prior art yet) | 23:49:50 |
| sterni | there it would help correctness overall if the expression author had the chance to mitigate this by looking at feature flags | 23:49:55 |
| piegames | In reply to @sternenseemann:systemli.org
besides, language changes may just as well change evaluator behavior where the difference is not failure / success, but actual results No, this is not supposed to happen without some hard language versioning | 23:50:37 |
| piegames | (It admittedly does happen though, but on the evaluator side we've been trying really hard to avoid it) | 23:51:02 |
| raitobezarius | In reply to @piegames:flausch.social
To be clear I'm fine with that, as long as functions that may result in unsoundness are marked as unsafe in a meaningful way (preferably beyond just convention). Maybe also provenance tracking, that would be awesome but also likely expensive (I haven't looked much into string context as prior art yet) Once bytecode is there :> | 23:51:04 |
| raitobezarius | The largest lang change with value difference is the recent ptr equality stuff | 23:53:09 |
| raitobezarius | Empirically over many expressions, it makes more evaluation go well due to the maximal sharing while making more "logical" ptr equalities coherent | 23:54:03 |
| sterni | i actually need to check whether that killed any test cases i think i wrote pretty comprehensive (albeit simple) ones for tvix | 23:54:29 |
| raitobezarius | Interested in the result | 23:55:13 |
| piegames | In reply to @piegames:flausch.social
To be clear I'm fine with that, as long as functions that may result in unsoundness are marked as unsafe in a meaningful way (preferably beyond just convention). Maybe also provenance tracking, that would be awesome but also likely expensive (I haven't looked much into string context as prior art yet) Also to get there, we need to finally formally specify what the evaluation model even is and what purity guarantees it even provides etc. | 23:56:39 |
| piegames | * Also to get there, we need to finally formally specify what the evaluation model even is and what purity/soundness guarantees it even provides etc. | 23:56:54 |
| raitobezarius | .oO(banning readFile to /proc) | 23:59:58 |
| 24 Feb 2026 |
| sterni | you know I always use /proc/sys/kernel/random/uuid for my random numbers | 00:14:27 |
| sterni | okay already Lix 2.93 hits thos annoying argument strictness changes in 2.18 I'll need to look at that again | 00:15:23 |
| sterni | Lix 2.94 "fails"
https://code.tvl.fyi/tree/tvix/eval/src/tests/tvix_tests/notyetpassing/eval-okay-non-identifier-pointer-inequality.nix
https://code.tvl.fyi/tree/tvix/eval/src/tests/tvix_tests/eval-okay-value-pointer-equality.nix | 00:20:16 |
| sterni | look like intentional changes, but you may want to double check | 00:20:32 |
| raitobezarius | I will double check but yeah looks good to me | 00:24:49 |
| sterni | i think someone should rush to introduce a dependency on pointer equality on thunks that contain a throw in nixpkgs | 00:38:37 |
| sterni | how has stdenv not managed that yet | 00:38:43 |
| sterni | raitobezarius: ofc not everything changed, see https://buildkite.com/tvl/depot/builds/41104#019c8d14-b993-4f9b-a53c-4757516eea43, a bit annoying to weed through what exactly changed (ignore the non pointer equality ones) | 00:40:56 |
|  TikTorchic18 joined the room. | 03:47:24 |
| raitobezarius | 2026-02-24 00:38:56 UTC
--- tvix_tests/eval-okay-value-pointer-equality.out 2026-02-24 00:38:56.777431331 +0000
2026-02-24 00:38:56 UTC
+++ tvix_tests/eval-okay-value-pointer-equality.exp 1970-01-01 00:00:01.000000000 +0000
2026-02-24 00:38:56 UTC
@@ -1 +1 @@
2026-02-24 00:38:56 UTC
-[ true true true true true true false true true true true true true true true true false false ]
2026-02-24 00:38:56 UTC
+[ true true true true false false false true true true true true true true true true false false ]
so, 2 things that were false became true which is coherent with our intended outcome | 09:14:31 |
| raitobezarius | 2026-02-24 00:38:56 UTC
--- tvix_tests/notyetpassing/eval-okay-non-identifier-pointer-inequality.out 2026-02-24 00:38:56.973429050 +0000
2026-02-24 00:38:56 UTC
+++ tvix_tests/notyetpassing/eval-okay-non-identifier-pointer-inequality.exp 1970-01-01 00:00:01.000000000 +0000
2026-02-24 00:38:56 UTC
@@ -1 +1 @@
2026-02-24 00:38:56 UTC
-[ true true true true true true true true ]
2026-02-24 00:38:56 UTC
+[ false false false false false true false false ]
same here | 09:14:46 |
| raitobezarius | eval-okay-non-identifier was exploiting implementation details about how Nix was doing copies | 09:15:19 |
| raitobezarius | now Lix performs true pointer equality | 09:15:27 |
