On Mon, Dec 6, 2010 at 23:04, Eelco Dolstra <[email protected]> wrote: > Hi, > > On 12/06/2010 07:52 PM, Nicolas Pierron wrote: > >> I am trying to bring up a tool to analyze NixOS option and >> automatically detect where options are used. I already made an >> expression which produce a pdf file >> (nixos/maintainers/option-usage.nix). > > How does it work? It sounds like a fairly tricky problem (without support in > the evaluator).
It first evaluate the config (1), and inject the config where one option value (2) has been replaced by an error and re-evaluate the new config (3) (extraArgs is used to replace the config attribute). Comparing errors between the config (1) and the config (3) determines the options impacted by the modification of (2). This "almost" correspond to one step of a fix-point on the whole configuration. >> I updated it considering the >> memory consumption in order to benefit from the garbage collector of >> nix expressions. >> >> Unfortunately, the tryEval primitive has changed since. > > The semantics of tryEval did change once, but I think that was quite a long > time > ago... indeed, this was a long time ago, and I also mention this issue. And If I remember well, you answer me that this could leave the interpreter in a bad state. >> When I >> started this script it was catching everything, but now it only catch >> assertions errors. Sadly, evaluating strictly NixOS configurations >> can lead to unexpected errors, such as throw, bad types, ... > > Why do you need to evaluate it strictly? Because I need to raise the error by forcing the usage of the inserted failure. > That seems dangerous (even if you > could catch all exceptions) due to the risk of infinite recursion. This could be a risk, how does toXML handles infinite recursions? -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ _______________________________________________ nix-dev mailing list [email protected] https://mail.cs.uu.nl/mailman/listinfo/nix-dev
