Conversation
|
As an example, the following call: toPretty {
recursionLimit = 2;
nextState = line: left:
if left == 0 then { return = null; }
else builtins.trace line (left - 1);
initialState = 300;
} pkgs.libwhen evaluated using Nix master (for this fix), prints the following within a fraction of a second: DetailsNote that I only limited it to 300 lines for demonstration, but the implementation can handle arbitrary big numbers. Or alternatively, this call: toPretty {
recursionLimit = 2;
nextState = line: left:
if left == 0 then { return = null; }
else builtins.trace line (left - 1);
initialState = 10;
} pkgsprints and evaluates only the first couple packages of So this new implementation stops evaluation as soon as |
|
@GrahamcOfBorg eval |
|
@jonringer It fails as expected btw, I haven't updated the tests for this change |
|
@infinisil there was another issue going on around the time you made the PR #98808 |
|
I just ran eval on all PRs that were failing |
Profpatsch
left a comment
There was a problem hiding this comment.
This is basically my comment on the other PR, but times 100, since toPretty is a monster now. I count these responsibilities:
- handling failing subexpressions
- recursion limit detection/limiting
- pretty printing of values (the original functionality)
- multiline printing & indentation
- streaming of the output
I don’t think this is viable.
We have a lazy functional language here, so we should be able to split this up into at least 3 different, orthogonal functions that compose nicely, instead of one giant blob of interleaved responsibilities.
|
For example, constructing a data structure of streaming values (and consuming those) is a task that is completely orthogonal to how things are formatted. Same goes with indentation/pretty printing of multiline values. |
|
I marked this as stale due to inactivity. → More info |
|
I’d tentatively close this now, I think my opposition to this change is still the same, we shouldn’t overcomplicate |
Motivation for this change
This changes the implementation of
lib.generators.toPrettysignificantlyOutput streaming
Adds the ability to stream its output in a generic way. This can be done using the new
initialStateandnextStatearguments, which thread some arbitrary state through the execution.nextStateis a function that takes two arguments:initialStatefor the first invocation)The function should then return the new state, incorporating the given line into it. The function may also abort execution by returning an attribute set with a
returnattribute.The result of the
toPrettycall will be the last state.Examples:
Limiting recursion depth
Allows the function to stop recursing at a certain depth using the
recursionLimitargument. Attribute sets that aren't recursed into are shown as{ <N attributes> }, while lists are shown as[ <N elements> ]. The number of items is shown because that information is available without recursing.Handling failing values
Values that fail to evaluate are shown as
<failure>. This was a bit tricky to get right, but the implementation here should be very solid.Printing of string-coercible attribute sets
Attribute sets that have an
outPathor__toStringattribute are now printed by usingtoStringon it.Ping @Profpatsch @edolstra
Things done