Thanks
This information is a bit spread out over the wiki page.
Which wiki page? Yes, it'd be fantastic to write this out clearly. Thanks!
$ git checkout a12b34c56 && git submodule update --init
$ ./hadrian/build.sh test --only-perf
$ git checkout x98y76z54 && git submodule update --init
While it's true that in principle one could imagine a case where you would want
a CAFfy Cmm proc, I can't think of any stuck cases in the RTS today.
Consequently it wouldn't surprise me if this was broken.
Frankly, I wouldn't worry too much about this if it's nontrivial to fix.
Cheers,
-
It is slightly disheartening that this relatively simple use-case requires
reaching so deeply into the typechecker.
If there really exusts no easier interface then perhaps we should consider
adopting your elaborateExpr as part of the GHC API.
Cheers,
- Ben
On January 23, 2020 4:04:03 AM
I don't know the exact semantics of the interactive context, etc., but that
looks plausible. It won't give the *wrong* answer. :)
Thanks for sharing!
Richard
> On Jan 23, 2020, at 4:52 AM, Yiyun Liu wrote:
>
> Thank you all for your help! It turns out that I was missing the constraint
>
How about using `hscCompileCoreExprHook` to intercept the `CoreExpr`
from the ghci pipeline? There exist GHC API to evaluate a String to a
ForeignHValue iirc; we are not interested in the final ForeignHValue
in this case, we just want the CoreExpr, and the logic of generating
and linking BCO can
The main problem I'm trying to solve is explained in my comment [1]. Basically
when building .cmm files the new SRT algorithm re-order definitions in a way
that breaks dependency ordering, which in turn breaks C backend, because in C we
should declare before using. (see my comment for why we don't
We store the metrics in git notes *per-commit*. All metrics for commit XX are
stored on the git note for commit XX. You can even view the raw data with this
command (where XX is the commit hash):
OK. But the master repo *already* has perf notes for that commit (I assume).
Do mine somehow
This recently came up again. It seems that `+RTS -h -i0` will just turn
every minor collection into a major one:
https://gitlab.haskell.org/ghc/ghc/issues/17387#note_248705
`-i0` seems significantly different from `-i0.001`, say, in that it just
turns minor GCs into major ones and doesn't
