GHCi recompilation avoidance UI

[Evan Laforge]

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 <marlowsd at 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 <david at 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 <david at 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>