https://ghc.haskell.org/trac/ghc/ticket/13604 was just closed, I look
forward to trying it out. Thanks to dfeuer for the fix!
On Wed, Nov 22, 2017 at 12:41 AM, Simon Marlow wrote:
> David,
>
> Perhaps it would be good to defer changing the behaviour of :load *M (I
> believe you that it's hard, t
David,
Perhaps it would be good to defer changing the behaviour of :load *M (I
believe you that it's hard, that code is quite convoluted) and for now just
focus on making GHCi able to load compiled object code again, which I think
is a much simpler problem?
Cheers
Simon
On 21 November 2017 at 2
David Feuer writes:
> I started digging back into this today, particularly considering Simon PJ's
> view
> that it's a bit odd for optimization flags to imply -fobject-code
> (specifically
> because we could potentially support optimization for the bytecode
> interpreter some day). I'm left eve
I started digging back into this today, particularly considering Simon PJ's view
that it's a bit odd for optimization flags to imply -fobject-code (specifically
because we could potentially support optimization for the bytecode
interpreter some day). I'm left even more lost about exactly what we wa
On 31 October 2017 at 15:42, David Feuer wrote:
> Changes in GHC 8.2.1 lead to a lot of recompilation, because GHCi now
> refuses to load optimized
> code unless -fobject-code (and optimization flags) are enabled. I propose
> the following slight
> modification to https://ghc.haskell.org/trac/ghc
On Wed, Nov 1, 2017 at 1:46 AM, Simon Peyton Jones via ghc-devs
wrote:
> I'm lost.
>
> * What causes the undesired behaviour in GHC 8.2.1?
> Is it this?
> - GHCi wants to load module B with flags F
> - There is a B.o but the flags differ
> - So GHCi recompiles B to bytecode
>
> * How
Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of David
| Feuer
| Sent: 31 October 2017 15:42
| To: ghc-devs@haskell.org
| Subject: GHCi recompilation avoidance UI
|
| Changes in GHC 8.2.1 lead to a lot of recompilation, because GHCi now
| refuses to load optim
I updated the trac ticket, but here's a copy-paste:
I still don't feel like 1 is necessary, I'd rather flags cause other
flags to be ignored with a warning, rather than turn on other flags.
But that's just a vague preference, with no strong evidence for it.
Maybe it could emit a warning if you did
Changes in GHC 8.2.1 lead to a lot of recompilation, because GHCi now refuses
to load optimized
code unless -fobject-code (and optimization flags) are enabled. I propose the
following slight
modification to https://ghc.haskell.org/trac/ghc/ticket/13604#comment:48
1. Optimization flags (except -O