Thanks Evan,
Evan Laforge writes:
> https://github.com/elaforge/karya/blob/work/Cmd/ReplGhc.hs
Yes what you're doing is very similar. I'm also adding args_left as
modules because they tend to be RTS and home modules. But it looks like
you always use False for object code. You're also using
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
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
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
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
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
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
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
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
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 /
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
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
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
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'
14 matches
Mail list logo