| 10 Nov 2025 |
 Qyriad | yeah that's whatI don't like either | 08:57:14 |
| Qyriad | * yeah that's what I don't like either | 08:57:34 |
 Rutile (Commentator2.0) feel free to ping | == vs ===? /hj | 09:11:18 |
| Qyriad | ban == for sets entirely and require defining a __eq? /hj | 09:11:58 |
 piegames | So my take is that for most data structures ("types"), the code doesn't change between most instances. So it could be factored out of the comparison. Only attrs that actually need per-value functions to be different would be incomparable | 09:16:14 |
| piegames | Yknow, just the normal stuff from most every other language | 09:16:25 |
 K900 | I mean having a user defined __eq would be good for other reasons as well | 09:17:59 |
| K900 | But it's also a super hard compat break | 09:18:06 |
| Qyriad | I think something that is clear at the least is that Nixpkgs lib should have a lib.attrsets.equalsWithoutFunctions or something | 09:23:42 |
 Sergei Zimmerman (xokdvium) | It is there btw | 09:23:58 |
| K900 | There's lib.platforms.equals or something | 09:24:20 |
| K900 | But it will never be used consistently if the obvious thing is allowed | 09:24:30 |
| Sergei Zimmerman (xokdvium) | Also lib.systems.equals is horribly slow and inefficient | 09:25:04 |
| K900 | Imagine having sane platform definitions | 09:25:21 |
| K900 | tbh | 09:25:22 |
| Sergei Zimmerman (xokdvium) | I wanted to highlight that, yeah. There's no supporting the borked equality semantics with a more "optimized" object model. You either a) ditch support for old nix expressions b) suffer the lack of manoeuvrability in terms of the implementation. | 09:27:50 |
 Taeer Bar-Yam | In reply to @piegames:flausch.social
The would probably not mesh well with future performance optimisations What future performance optimisations are you thinking of? Maybe we can solve those problems too! | 13:53:59 |
| Taeer Bar-Yam | So one issue I'm seeing is that "best effort" or "marginal effort" function equality checking will tend to be unstable because the set of functions we can determine equal, and the set of functions that we can distinguish between will both fluctuate based on our implementation.
How's this for a plan?
(a) fix nixpkgs so it doesn't use function equality checking
(b) output a warning when people try to use function equality checking. something to the effect of "this is unstable and exists for backwards compatibility"
(c) maintain an unstable version of function equality checking, that is only guaranteed to work in situations where function equality currently works.
We can introduce a flag --no-function-equality like we have --no-url-literals
That way people can continue to evaluate old versions of nixpkgs, but people are unlikely to depend on how the features is implemented now (certainly in nixpkgs), so we are free to adjust it to new implementations, even though it breaks edge cases, since nobody will be using those edge cases.
| 15:14:21 |
| piegames | Bytecode interpreter with compiler optimizations, inlining, common subexpression elimination etc | 16:13:23 |
 aloisw | What is tristate about that? It has five values out of which three are "not supported". | 17:04:22 |
| K900 | That's the joke yes | 17:11:26 |
 raitobezarius | It's unclear that in our case we can re-emulate fully the funext behavior | 18:54:26 |
| raitobezarius | This week, I'm swamped with a lot of $WORK, so I'm not sure I will have time to react to anything | 18:54:47 |
| 11 Nov 2025 |
| raitobezarius | Some after the work thoughts on pointer equality, my conclusion is similar to Taeer's ones.
I look at it this way: for pointer equality use be sound, you need to have a **reflexive** binary relation to apply it to. Structural comparisons are mostly like this except when it comes to incomparable pieces of opaque value like functions. But that's a historical accident and one that I fail to convince myself you can rely on in good faith to write production Nix code. As a result, I would be in favor of making that comparison true even if it was not before. I am quite against reverting the whole thing because now accidental infinite recursions have decreased in occurrence by the virtue of sharing more (graphs with cycles of the exact same object identity wise collapsed into DAGs).
Obviously, we need to go and empirically prove that this change won't worsen things.
The idea of offering a modified equality operator is interesting in the context because we could abuse scopedImport to create a compatibility mode and we could (no one is gonna let me do that but who knows) expose builtins to construct your own flavor of pointer equality to pass to the scoped import to make broken code run again. | 01:33:24 |
| raitobezarius | (extra spiciness: > desugars... and involves pointer equality albeit irreflexive?) | 01:39:12 |
 Winter | logged in to forgejo, got a 500 (from fj). kept refreshing, getting 500s, then eventually got back to the dashboard (logged out). clicked log in again, then everything worked. | 06:04:51 |
| Winter | jfyi | 06:04:57 |
 delroth | scrapers are hammering git.lix.systems and causing too many postgres connections | 11:15:34 |
| delroth | I just looked into it again and figured out that our extremely basic anti-scraping was in fact not doing anything due to a corrupted nftables internal state | 11:15:57 |
| delroth | so uh hopefully we have fewer problems from now on and nobody got accidentally false-positived | 11:16:25 |
