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 <marlo...@gmail.com> wrote: > 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 21:49, David Feuer <da...@well-typed.com> wrote: >> >> 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 want. >> I believe it's fairly clear that, as Simon M wrote, >> >> > [W]e'll want at least -fignore-optim-changes to be the default, so that >> > GHCi >> > does the expected thing when you have compiled object files. >> >> Based on Simon PJ's comment, I believe we want to *continue* to discard >> optimization flags when -fobject-code is not enabled. As for my suggestion >> in (2), >> I spent the last couple hours attempting to figure out what would be >> necessary >> to allow :load *M to load a module interpreted even when using >> -fobject-code, >> but found myself utterly lost in the module loading logic. I see that the >> IIModule >> constructor is deeply involved in this, but I haven't been able to figure >> out >> where/how that interacts with -fobject-code to determine whether the >> module >> will actually be loaded interpreted or compiled. Can someone give me a >> clue? >> >> On Thursday, November 2, 2017 10:21:07 AM EST Simon Marlow wrote: >> > On 31 October 2017 at 15:42, David Feuer <da...@well-typed.com> 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/ticket/13604#comment:48 >> > > >> > > 1. Optimization flags (except -O0) imply -fobject-code. This ensures >> > > that >> > > GHC respects optimization flags regardless of --interactive. >> > > >> > > 2. Even when -fobject-code is on, :load *M will load M as bytecode. >> > > This >> > > provides the "escape hatch" from -fobject-code that you need to use >> > > debugging features, etc. >> > > >> > >> > Yes, I think this is probably what we want. I'm not sure how smooth it >> > will >> > be to implement though. >> > >> > >> > > 3. New -fignore-optim-changes and -fignore-hpc-changes (Phab:D4123) >> > > flags should enable users to put together object code and bytecode >> > > with >> > > diverse optimization levels/options and HPC options while still >> > > updating >> > > automatically based on source changes and whether profiling is >> > > enabled. >> > > >> > >> > As I mentioned on the diff, I think we'll want at least >> > -fignore-optim-changes to be the default, so that GHCi does the expected >> > thing when you have compiled object files. >> > >> > Cheers >> > Simon > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs