Appears to be:
a47b62cb3685 Second attempt to fix sizeExpr
https://perf.haskell.org/ghc/#revision/9d62d09a6c399c98491b7a63a7a1366c89fcf5db
2016-06-22 22:24 GMT+01:00 Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org>:
> Does anyone know what made T7257 better?
>
> Simon
>
> | -Original M
Does anyone know what made T7257 better?
Simon
| -Original Message-
| From: ghc-commits [mailto:ghc-commits-boun...@haskell.org] On Behalf Of
| g...@git.haskell.org
| Sent: 22 June 2016 22:08
| To: ghc-comm...@haskell.org
| Subject: [commit: ghc] master: Accept new (lower) allocations for
If we're just talking about building one or two transformers then I'd say we
should avoid incurring the dependency. The outcry would far far outweigh the
code sharing advantage for one or two types. E.g. base duplicates State
internally for mapAccumL for instance for this sort of reason.
Sent f
Currently, containers does not depend on transformers, so it has to
duplicate its functionality or just do without. Since transformers is also
a GHC boot package, I believe it should be feasible to make containers
depend on it. To what extent would that reduce
parallelizability of GHC builds or oth
On Jun 22, 2016, at 10:38 AM, Simon Marlow wrote:
> Thanks for the feedback Richard. It's helpful to know which parts of the
> implementation you found non-obvious. I will write some more Notes, but
> first:
I think what would help most is a place that describes the little state machine
th
One other thing:
On 22 June 2016 at 14:36, Richard Eisenberg wrote:
> It seems there are nice advantages to this approach, and so I'm fine
> requiring support from TH. But here is a comment I just posted on D2286
> requesting more comments in the code:
>
> ---
> I've just spent some time staring
Yes - I wasn't planning on dropping support for the in-process interpreter,
for that reason.
I haven't thought about plugins very much, but aren't they always compiled
code? We don't need an in-process interpreter for those, but we do need
in-process linking. Maybe that doesn't simplify things m
Hello Simon,
I have no exception to having it be default and dropping the special
case support for building profiled/dynamic so that TH works. But
I don't think support for loading code in-process for GHC should be dropped,
c.f. Manuel's email
https://mail.haskell.org/pipermail/ghc-devs/2015-Nove
Thanks for the feedback Richard. It's helpful to know which parts of the
implementation you found non-obvious. I will write some more Notes, but
first:
* On why we need a RemoteRef of an IORef - because the IORef lives on the
server, so GHC has a RemoteRef to it. Did you see Note [External GHC
It seems there are nice advantages to this approach, and so I'm fine requiring
support from TH. But here is a comment I just posted on D2286 requesting more
comments in the code:
---
I've just spent some time staring at GHCi/TH.hs and friends, and it's starting
to make sense. Would it be possib
It’s a great start, thanks
Simon
From: Simon Marlow [mailto:marlo...@gmail.com]
Sent: 22 June 2016 12:32
To: Simon Peyton Jones
Cc: ghc-devs@haskell.org
Subject: Re: Require -fexternal-interpreter support for future TH changes?
How's this?
https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compi
How's this?
https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/ExternalInterpreter
I don't want to go into too much detail in the wiki, because details are
more likely to stay current if they're in Notes in the code. There are
already a few Notes (e.g.
https://phabricator.haskell.org/diffu
On 22 June 2016 at 11:37, Simon Peyton Jones wrote:
> I’m ok with this. *It would certainly be great not to support TWO
> mechanisms indefinitely*.
>
>
>
> What are the disadvantages to committing to this path? Would anyone even
> notice?
>
Yes, people who are making changes to TH will need t
I’m ok with this. It would certainly be great not to support TWO mechanisms
indefinitely.
What are the disadvantages to committing to this path? Would anyone even
notice?
There are a lot of moving parts to the implementation, and I for one am utterly
ignorant of how it all works. I would l
*Background*
A few months ago I added -fexternal-interpreter to GHC:
- docs:
http://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghci.html#ghc-flag--fexternal-interpreter
- wiki, rationale: https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi
When -fexternal-interpreter is used,
15 matches
Mail list logo
