Las
Evaluating the derivation of a haskell.nix project seems to take a very long amount of time even if every IFD has already been built. Maybe more processing could happen "inside"...
A possibly big improvement for caching of build results (especially combined with content-addressing), could be having a single derivation per Haskell module. This would allow caching to be much more...
Currently, AFAICT, haskell.nix makes extensive use of IFD in the form of essentially importing the materialisation. This is problematic because of many obvious reasons: - IFD blocks evaluation, so if...
See #1339. That PR is an attempt to enable this functionality, however, it's a hack, just like the `package: ${pkg}` approach @angerman proposes. Like @michaelpj wrote, we want a clean...
Currently, `modules` in `cabalProject'` and such only apply to the post-plan building AFAICT. It seems useful to be able to define a module that will affect the arguments to `cabalProject`',...
I'm looking at https://github.com/input-output-hk/plutus/tree/master/nix/pkgs/haskell/materialized-linux to understand materialisation properly. If I have any misunderstandings please do say. AFAICT, materialisation is simply a way to skip a bunch of IFD that haskell.nix...
### Summary While UPLC/PLC/PIR are strict, a simplification pass assumes the code is to be interpreted lazily, thus resulting in the following behaviour: `let c x _ = x in...
**Describe the bug** There doesn't seem to be any documentation wrt. this.
It has to be removed from `nonReinstallablePkgs`. This makes somewhat sense, but a warning/error or similar would be great even if it can't be "fixed". In my case, it was...
## Which section of the Halo 2 book were you reading? https://zcash.github.io/halo2/design/proving-system/multipoint-opening.html ## What was unclear? It's not clear why `q1` and `q2` are added again. My background is FRI,...