| 24 Feb 2026 |
emily | the other reasonable alternative is to make it equivalent to map (name: [ name set1.${name} ]) (attrNames set1) == map (name: [ name set2.${name} ]) (attrNames set2) but this is:
- I think inevitably strictly slower in terms of runtime perf because there are cases where you will recurse into expensive thunks that the other variant never will
- more difficult to express in terms of in-language primitives
- less compatible - for every program that returns true or false from such a comparison, the other variant will also return that value, but this variant will abort/loop forever/throw strictly more often
both of them are entirely consistent with "angelic" choice of nondeterministic comparison orderings, but I don't think the interleaved variant has any merits
| 15:21:32 |
emily | other reasons comparing names separately makes more sense:
- consistent with lists,
[ abort abort ] != [ abort ] compares lengths before values already, and list lengths are analogous to attrset key sets
- indeed the interleaving version can't legitimately even short-circuit on the number of names without complicating semantics because of
{ a = abort; } != { b = abort; c = abort; } -- whereas if you compare names first, you can legitimately do that short circuit because attr name set comparison happens before any thunks are forced
| 15:44:34 |
emily | I'll put a summary of this up on the Nix PR in a few hours since this is getting verbose :) | 15:49:55 |
emily | but I firmly believe attrNames set1 == attrNames set2 && attrValues set1 == attrValues set2 is the right semantics on both practical and theoretical grounds (and we should fix anywhere Nixpkgs still relies on pointer equality dodging type errors/aborts/throws/infinite loops and then move towards not doing that by default) | 15:51:51 |
piegames | Okay | 16:23:57 |
| 25 Feb 2026 |
| @kirottu:kirottu.com left the room. | 16:55:51 |
| isabel changed their profile picture. | 21:51:40 |
| 26 Feb 2026 |
| Lily Foster changed their profile picture. | 14:01:48 |
| 16 May 2024 |
| zrsk joined the room. | 13:54:49 |
samrose | In reply to @lunaphied:lunaphied.me I think there were a few CLs on the Gerrit but nothing being actively worked The other thing that I could do if it helps is test things and try to find bugs. I did do some C++ work in the past, but may lack the time to do it justice here at least for about 30 days or so | 15:55:29 |
Qyriad | we are not in any rush 🙂 | 17:20:53 |
samrose | Would it help to also test out the existing Lix code and try to find issues/bugs etc? | 17:23:21 |
Qyriad | absolutely | 17:23:41 |
samrose |
- how do people feel about the existing test suite that comes along with nix source code or Lix?
| 17:23:48 |
Qyriad | it's pitiful | 17:24:10 |
samrose | heh | 17:24:16 |
raitobezarius | expanding it is cool | 17:24:23 |
raitobezarius | writing new tests for builtins which are not tested | 17:24:30 |
raitobezarius | new test behaviors, etc. | 17:24:32 |
Qyriad | we have three flavors of test:
gtest (offer only available in libexpr and libutil) bash script virtual machine
the vast, vast majority of testing is in the "bash script" flavor and it is a mess | 17:25:01 |
samrose | I was just going to ask on the "functional" tests: do we still like using bash there? | 17:25:56 |
samrose | the last time that I worked on a major nix related cli project that used bash, or bats for testing, over time it became rather kind of hard to maintain | 17:26:42 |
samrose | I am not usually a big python fan, but in that project we heard from some in the Rust community that they actually use Python to test CLI and seem to have success there. | 17:27:59 |
Qyriad | no gods please kill bash testing. the problem is that it's kind of really difficult to migrate an entire test suite and be sure that you actually migrated the test suite correctly and won't lose coverage accidentally in the process, which makes any kind of migration a bit nerve wracking | 17:28:36 |
samrose | yes it's a rather large undertaking | 17:28:52 |
samrose | could be done in chunks | 17:28:59 |
Qyriad | at the very least though, it would be wonderful to have an option for new tests to not just be a mess of bash | 17:29:17 |
samrose | yes it could be to choose a new approach that this community is truly happy with, rewrite some of the old tests, use it for all new, and then over time rewrite all old | 17:30:00 |
Qyriad | yeah | 17:30:31 |
samrose | and also probably you all would want to speak into the testing paradigm to make sure the tests are relevant | 17:30:52 |