Re: slow load and typecheck

I'm not sure if I'm doing the same thing as you, but I use a GHC repl for my program. It loads a 200-300 modules in under a second, and is able to reload changed ones dynamically, just like ghci. The source is https://github.com/elaforge/karya/blob/work/Cmd/ReplGhc.hs, see 'parse_flags' and its

Re: Proposed changes to merge request workflow

+1 from me. > On Oct 8, 2019, at 7:19 PM, Shayne Fletcher via ghc-devs > wrote: > > All sounds very sensible to me. > > On Tue, Oct 8, 2019 at 2:17 PM Ben Gamari > wrote: > tl;dr. I would like feedback on a few proposed changes [1] to our merge >request

Re: Proposed changes to merge request workflow

All sounds very sensible to me. On Tue, Oct 8, 2019 at 2:17 PM Ben Gamari wrote: > tl;dr. I would like feedback on a few proposed changes [1] to our merge >request workflow. > > > Hello everyone, > > Over the past six months I have been monitoring the operation of our > merge request

Proposed changes to merge request workflow

tl;dr. I would like feedback on a few proposed changes [1] to our merge request workflow. Hello everyone, Over the past six months I have been monitoring the operation of our merge request workflow, which arose rather organically in the wake of the initial move to GitLab. While it works

Re: slow load and typecheck

Brandon Allbery writes: > It reuses the .hi files already built for other modules. Those aren't in > the source directory but under a build directory. If they don't exist > there, it will build the dependencies to create them. The .hi files exist in the target directory and my tool has informed

Re: slow load and typecheck

If they are loading each other, they likewise need .hi files. .o files are optional if you aren't linking them. On Tue, Oct 8, 2019 at 10:59 AM Sam Halliday wrote: > Brandon Allbery writes: > > > you really do want those .hi files, otherwise it must compile the > > dependency module to

Re: slow load and typecheck

It reuses the .hi files already built for other modules. Those aren't in the source directory but under a build directory. If they don't exist there, it will build the dependencies to create them. On Tue, Oct 8, 2019 at 10:57 AM Sam Halliday wrote: > Brandon Allbery writes: > > > It's doing

Re: slow load and typecheck

Brandon Allbery writes: > you really do want those .hi files, otherwise it must compile the > dependency module to generate one. Right, exactly! But I thought that's what targetAllowObjCode=True was doing, is it not? Is there another setting that I'm missing? Should I use that for all my

Re: slow load and typecheck

Brandon Allbery writes: > It's doing what you — but not ghc — consider "extra work", though. ghc > expects to be compiling code, and doesn't have a separate code path for > "load symbols from an external module by parsing its source code" instead > of "load symbols from an external module by

Re: slow load and typecheck

I already mentioned needing .hi (I may have said hsc, whoops; Haskell Interface files) from dependencies; you really want to turn that part on, at least. And possibly ensure your other options are compatible with existing .hi files, so they can be loaded directly. I think the .o isn't used until

Re: slow load and typecheck

Matthew Pickering writes: > Are you writing interface files (-fwrite-interface)? It makes no sense > for HscInterpreted to be faster than HscNothing. Nope, not writing anything like that (I just checked the ghc flags from hie-bios to confirm)... and I agree that this makes no sense. -- Best

Re: slow load and typecheck

Are you writing interface files (-fwrite-interface)? It makes no sense for HscInterpreted to be faster than HscNothing. Cheers, Matt On Tue, Oct 8, 2019 at 3:30 PM Sam Halliday wrote: > > A quick follow-up to this, Rahul Muttinieni gave me some advice to try > out > > HscInterpreted /

Re: slow load and typecheck

It's doing what you — but not ghc — consider "extra work", though. ghc expects to be compiling code, and doesn't have a separate code path for "load symbols from an external module by parsing its source code" instead of "load symbols from an external module by loading its .hsc file and object

Re: slow load and typecheck

A quick follow-up to this, Rahul Muttinieni gave me some advice to try out HscInterpreted / LinkInMemory instead of HscNothing / NoLink and now I am no longer seeing home modules being compiled, and everything is a lot faster. Woohoo! But I have no idea why this speeds things up... my

Re: slow load and typecheck

I think the only path for loading a dependency that doesn't involve loading object code of some kind is the {-# SOURCE #-} hack as part of .hs-boot files, which isn't general enough to be reused here as I understand it. A decent chunk of the compiler would need to be duplicated to avoid this, and

slow load and typecheck

Hello all, I am writing an interactive tool using the ghc api. It is able to load and typecheck a source file in a user's package. I obtain the flags that cabal uses to compile the user's package via the hie-bios trick, and I `parseDynamicFlagsCmdLine' them inside my tool, then I `setTargets'