| 9 Nov 2025 |
 Sergei Zimmerman (xokdvium) | Ah I see, that might be my SNAFU hmmm | 17:26:33 |
 aloisw | In reply to @xokdvium:matrix.org
Updates never replace anything - they copy to a new attribute set though. It's puzzling "Replace" not in the sense that it's an in-place update, but that the keys overlap. I think it allocates sum of the sizes many entries and then is supposed to shrink if not all were needed due to overlap. | 17:28:12 |
| Sergei Zimmerman (xokdvium) | Capacity never actually gets shrunk and size is only incremented when doing a push_back to the bindings. Something looks broken in the ExprOpUpdate::eval code. | 17:35:41 |
| aloisw | Weirdly nrOpUpdateValuesCopied is still 2 on my machine. | 17:41:18 |
| Sergei Zimmerman (xokdvium) | Ah sorry I was confused omg lol. Don't mind the noise | 17:43:37 |
| aloisw | Also it doesn't give false if replacing f by an integer. So it's related to the pointer/function mess. | 17:45:45 |
| Sergei Zimmerman (xokdvium) | Yeah so doing this does help:
diff --git a/lix/libexpr/eval.cc b/lix/libexpr/eval.cc
index f1ba9e01c..5a5acd6aa 100644
--- a/lix/libexpr/eval.cc
+++ b/lix/libexpr/eval.cc
@@ -2682,6 +2682,7 @@ bool EvalState::eqValues(Value & v1, Value & v2, const PosIdx pos, std::string_v
/* Functions are incomparable. */
case nFunction:
+ if (pointerEq()) return true;
return false;
case nExternal:
But I'm not sure about all the consequences :)
| 17:49:35 |
| Sergei Zimmerman (xokdvium) | * Yeah so doing this does help:
diff --git a/lix/libexpr/eval.cc b/lix/libexpr/eval.cc
index f1ba9e01c..5a5acd6aa 100644
--- a/lix/libexpr/eval.cc
+++ b/lix/libexpr/eval.cc
@@ -2682,6 +2682,7 @@ bool EvalState::eqValues(Value & v1, Value & v2, const PosIdx pos, std::string_v
/* Functions are incomparable. */
case nFunction:
+ if (pointerEq()) return true;
return false;
case nExternal:
But I'm not sure about all the consequences :)
| 17:49:49 |
| Sergei Zimmerman (xokdvium) | * ~~What's even more cursed is this~~:
- xokdvium got confused, don't mind the noise *
| 17:53:14 |
| aloisw | let a = { f = x: x; }; in a.f == a.f would now return true. | 17:58:31 |
| aloisw | I think https://git.lix.systems/lix-project/lix/commit/80654b84b610f4c0622dd10f0af78a8a2ce97048 is the offending change btw. Currently building that and its parent to confirm. | 18:01:20 |
| Sergei Zimmerman (xokdvium) | Worth mentioning on https://gerrit.lix.systems/c/lix/+/4556. But the cat is out of the bag on this and compat with cppnix wasn't a design decision for that patch? | 18:01:28 |
| aloisw | In reply to @aloisw:julia0815.de
I think https://git.lix.systems/lix-project/lix/commit/80654b84b610f4c0622dd10f0af78a8a2ce97048 is the offending change btw. Currently building that and its parent to confirm. It's not, weirdly enough I get true there? | 18:06:22 |
| aloisw | Ah fuck I forgot to change f back to a function. | 18:10:03 |
| aloisw | Confirmed this is the breaking change. | 18:12:25 |
 raitobezarius | https://gerrit.lix.systems/c/lix/+/4556 | 18:16:23 |
| raitobezarius | not totally | 18:16:49 |
| raitobezarius | we looked hard and we were not able to disprove our theory that we were enabling more correctness | 18:17:03 |
| raitobezarius | like we ran evaluation regression testing and we had no failure but new successes | 18:17:22 |
| raitobezarius | after looking hard at the new success, we were unable to say "ah it's wrong", but more like: ah it's possibly a fun eq ptr bug | 18:17:44 |
| raitobezarius | put in another way, breaking bug to bug compatibility: yes, by having a behavior that agrees on successes: yes, new failures: not an intended objective | 18:19:11 |
| raitobezarius | * put in another way, breaking bug to bug compatibility: yes, by having a behavior that agrees on existing successes: yes, new failures: not an intended objective | 18:19:21 |
| Sergei Zimmerman (xokdvium) | In reply to @raitobezarius:matrix.org
put in another way, breaking bug to bug compatibility: yes, by having a behavior that agrees on existing successes: yes, new failures: not an intended objective Yeah, that’s why I meant by compat. | 18:19:38 |
| raitobezarius | in general, i'd like to kick pointer inequality out of the lang | 18:20:18 |
| Sergei Zimmerman (xokdvium) | Seems like it would be beneficial to run a regression on older nixpkgs as well, since apparently it suffers much more from pointer equality footguns. | 18:20:18 |
| raitobezarius | yep | 18:20:25 |
| raitobezarius | we should definitely do that | 18:20:30 |
| Sergei Zimmerman (xokdvium) | In reply to @raitobezarius:matrix.org
in general, i'd like to kick pointer inequality out of the lang Indeed. I doubt anybody wants to keep it around, but it’s not like frontend semantics where one can just copy the parser code. If one wants to keep the ability to eval legacy nix code then it doesn’t seem possible to get the object model benefits (like single-pointer values) without also keeping bug-for-bug compat | 18:24:26 |
 Taeer Bar-Yam | I've been talking with Sergei Zimmerman (xokdvium) about this issue over the last couple weeks, and one idea that I had was to go further in the opposite direction. Rather than running pointer equality on functions (or perhaps in addition), have functions compare equal if they comprise the same Expr and Env.
Also be aware I haven't looked at Lix code only CppNix, so maybe this doesn't make sense given how they've diverged.
| 18:25:21 |
| Sergei Zimmerman (xokdvium) | In reply to @raitobezarius:matrix.org
in general, i'd like to kick pointer inequality out of the lang * Indeed. I doubt anybody wants to keep it around, but it’s not like frontend semantics where one can just copy the parser code. If one wants to keep the ability to eval legacy nix code then it doesn’t seem possible to get the object model benefits (like single-pointer values) without also ~~keeping~~ yeeting bug-for-bug compat | 18:26:18 |
