| 28 Jun 2023 |
 @ninjatrappeur:alternativebit.fr | * andi- improved my not-so-fonctional ebpf profiler into something pretty fonctional. I lost the branch though. | 13:19:37 |
| @ninjatrappeur:alternativebit.fr | The real issue is the viewer, there's too much information in these traces. We were tracing each and every thunk forcing. | 13:20:06 |
 andi- | In reply to @ninjatrappeur:alternativebit.fr
andi- improved my not-so-fonctional ebpf profiler into something pretty fonctional. I lost the branch though. https://github.com/andir/nix/tree/andir/profiling | 13:21:05 |
 @pennae:matrix.eno.space | fwiw disabling docs on our current system makes no significant difference in eval time, disabling the spit options build adds 30% | 13:22:24 |
 Sandro | In reply to @andi:kack.it
https://github.com/andir/nix/tree/andir/profiling Does that improve the existing tracing or add a new one? | 13:30:02 |
| andi- | new one, proper nix-internal call frames and all | 13:30:24 |
| Sandro | In reply to @pennae:matrix.eno.space
fwiw disabling docs on our current system makes no significant difference in eval time, disabling the spit options build adds 30% spit options? split options? | 13:30:27 |
| Sandro | In reply to @andi:kack.it
new one, proper nix-internal call frames and all you just set NIX_SHOW_TRACE ? | 13:30:46 |
| @pennae:matrix.eno.space | split options, yes | 13:30:49 |
| Sandro | so setting documentation.nixos.options.splitBuild to false improves eval time if I don't build docs? | 13:47:18 |
| @pennae:matrix.eno.space | if you don't build docs setting it to false makes no difference. if you do build docs settings it to false slows down the build by 30% | 13:59:48 |
| Sandro | ah, good that we cleared that up | 14:33:17 |
| @pennae:matrix.eno.space | if it ever did speed up the build to set it to false we should remove it again :) | 14:37:23 |
| @pennae:matrix.eno.space | the infra needed to make it works is a royal pain, if we can get away without it then good riddance | 14:37:43 |
 sterni | do we have an overview of what markdown extensions/custom stuff you can use in the manual somewhere? | 18:04:34 |
| sterni | ah in the obvious place, nice :) | 18:05:17 |
| sterni | pennae: fricklerhandwerk: basically if you do this dynamically you have the same problem, but it is even more complicated; you need to map a value to its definition point and we have no overarching semantics that would fix the meaning of that (e.g. unsafeGetAttrPos would be closest, but also doesn't apply for the reasons pennae outlines). Additionally doing it dynamically means that you have to write a treewalker again and that it'll be slower than statically generating docs | 18:14:28 |
| sterni | I think the RFC should end up in a form where we enforce some kind of convention that means files are nixdoc-able and we can (optionally) also retrieve documentation at runtime in the repl (because it is convenient), but I'd sacrifize the latter if need be—it is a losing battle, since Nix has no module system-like semantics | 18:15:52 |
 fricklerhandwerk | sterni: which RFC do you mean? The one by Johannes Kirschbauer @hsjobeki or some hypothetical one that codifies nixdoc-like semantics? | 18:49:39 |
| sterni | the former | 18:50:09 |
| sterni | and with the current trajectory I think it could be the latter (although I'm a bit fuzzy on what is written down currently) | 18:50:30 |
 @johannes.kirschbauer:scs.ems.host | @sterni if i understand your concerns: yes treewalker would be slow (as slow as evaluation) but at least accurate.
I guess you‘d suggest some limited set of patterns and nesting if you wanted static analysis solution.
And as the RFC got critical mass of sheperds i am thrilled to make progress as soon as @lassulus schedules the first meetups. | 20:48:41 |
| @johannes.kirschbauer:scs.ems.host | Or just use the rfc outcome and build static analysis that can opt-in for dynamic evaluation in edge cases that are not possible with static analysis alone. | 20:52:56 |
| @pennae:matrix.eno.space | fwiw the renovated nixdoc (especially with our most recent pr) is a non-evaluating treewalker with a restricted set of allowed trees that are doc-able | 21:09:09 |
| @pennae:matrix.eno.space | it may be a bit too lax in what it accepts still | 21:09:19 |
| @johannes.kirschbauer:scs.ems.host | Yes the most recent PRs where really good. Especially #36 cleaned up a lot. And made good sense overall. The title is a little bit misleading as you did a lot of cleanup work there.
However nixdoc is (currently) limited to analysing the AST.
A real evaluator can track values and attach meta (e.g docs) inside the engine. Which results in much more reliable and generally applicable docs. But this is also way more slow because one need to run the evaluator. I think @sterni refers to a „treewalker“ as this thing that „walkes“ through the nested attributes dynamically.
Imagine writing a nix function that collects all nested nixpkgs attributes path in a big list. (Funny slow thing but i know some including me, who tried) | 21:20:59 |
| @johannes.kirschbauer:scs.ems.host | * Yes the most recent PRs where really good. Especially #36 cleaned up a lot. And made good sense overall. The title is a little bit misleading as you did a lot of cleanup work there.
However nixdoc is (currently) limited to analysing the AST.
A real evaluator can track values and attach meta (e.g docs) inside the engine. Which results in much more reliable and generally applicable docs. But this is also way more slow because one need to run the evaluator. I think @sterni refers to a „treewalker“ as this thing that „walkes“ through the nested attributes dynamically.
Imagine writing a nix function that collects all nested nixpkgs attributes path in a big list. (Funny slow thing but i know some including me, who tried) | 21:21:50 |
| @pennae:matrix.eno.space | yeah, that's what we would like to do too in the end. it needn't even be that expensive | 21:23:27 |
| @pennae:matrix.eno.space | until then walking the ast with minimal awareness of nix semantics is our best bet | 21:23:47 |
| @pennae:matrix.eno.space | In reply to @sternenseemann:systemli.org
do we have an overview of what markdown extensions/custom stuff you can use in the manual somewhere? as for that: the extension list in the manual is not entirely complete. there are a few more we haven't documented yet (most or even all of which predate the markdown tooling itself) | 21:26:54 |
