2025-02-24 Nix team meeting minutes #215, #216

Development Nix
1

2025-02-24 Nix team meeting minutes #215

Monday work session

Attendees:

Agenda

Indent JSON when stdout is terminal · Issue #12555 · NixOS/nix · GitHub

Opened feature issue

packaging: Use correct stdenv for x86_64-darwin by roberth · Pull Request #12557 · NixOS/nix · GitHub

Opened build-problem fix

error: path is not valid using nix ==2.18.0 · Issue #9052 · NixOS/nix · GitHub

Worked on by @Ericson2314

2025-02-26 Meeting minutes #215

Wednesday triage meeting

Attendees: @edolstra @roberth @tomberek @Ericson2314

Triage

libexpr: Fix use-after-free of StaticEnv::up by xokdvium · Pull Request #12544 · NixOS/nix · GitHub

Reviewed together

We’re gonna just merge this as it seems to make things both better and not make anything (to our knowledge worse). However, in reviewing the PR we’re realizing how much design debt there is in the memory management of the evaluator.

The design and its ramifications really ought to be written down so that we’re not stuck assembling on oral tradition of whatever the hell is going on on video call during PR review next time :slight_smile:

Here are some things to think about:

  • GC root scanning in the presence of std::shared_ptr and GC-allocated values

    • Finalizers cannot be trusted, so GC object cannot own std::shared_ptr object

    • @edolstra mentions that bdw-gc definitely scans the stack for roots. However, do std::shared_ptr-allocated still get traced for roots, or has the debugger broken GC for a long time? Probably, see debugger issues.

  • What are the performance impacts of std::shared_ptr?

    • Expr* objects are only created by the parser, not during evaluation, so OK if they are more expensive to allocate
    • However, could reference counter churn could be noticable?

The dearth of a documented design applies to the evaluator as a whole, but is especially noticable for the debugger implementation, as the debugger implementation is far useful, and does funny things which may well be breaking undocumented invariants. In other words, the debugging isn’t necessary easy to truly fix in its current state. It’s possible the design is kinda screwed in that all these small tweaks adjacent to the status quo fix one problem only to create another problem.

Contributions investigating the current design and collecting this information in writing would be extremely valuable, but at the same time it’s probably on the team to spearhead this.

Release prep

Fix #9052 by Ericson2314 · Pull Request #12558 · NixOS/nix · GitHub

Has its own issue. Will revert on the maintenance branch, then use a release cycle to solve the problems.

More granular `pure-eval` · Issue #12493 · NixOS/nix · GitHub

However we also have a large monorepo, which prevents us from using flakes at this time.

It looks like the core issue is solved with lazy trees. At that point, pure eval is workable with very large repos. It is probably easier to avoid x-y problems if we continue this discussion assuming lazy trees already in-use, finished and merged to Nix master, etc.

Packaging issues

Assigned to @roberth

2 Likes