Fwd: how to get ghci to load compiled modules in 7.8?

I sent this to haskell-cafe, but there was no response. On stackoverflow there was no response either. I'm trying one last time, but adding ghc-users (which I should have done at the beginning!). Surely it can't be that no one knows how to load modules in ghci? I know a lot of work was done to enable this, as in https://ghc.haskell.org/trac/ghc/wiki/DynamicByDefault, it seems a waste if no one actually knows how to use it! The 7.8.1 release notes make reference to -dynamic-too, and an unexplained "Dynamic Ghci", but implies ghci should just work. Do I need to compile ghci myself in a dynamic way? The DynamicByDefault page also implies that, but I assumed the binary distributions would come with it compiled the right way. This has almost disabled ghci for my work (it can be used, but very slowly and with much retyping of commands, and I find myself avoiding the REPL now), so it's a big regression from 7.6! I added another paragraph from the stackoverflow question. Also, I can't get this to work on linux either, not just OS X. BTW, I got a nice bump in my profiles after upgrading, so 7.8 is mostly good news. Just this one awkward thing keeps it from being all good news. ---------- Forwarded message ---------- I recently upgraded to 7.8.2 and I have a silly question. How do you get ghci to load compiled modules? When I try this: % cat >T.hs module T where x :: Int x = 42 % ghc -c -dynamic-too T.hs % s T.dyn_hi T.dyn_o T.hi T.hs T.o % ghci GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package filepath-1.3.0.2 ... linking ... done. Prelude> :l T [1 of 1] Compiling T ( T.hs, interpreted ) Ok, modules loaded: T. *T> It still loads the file interpreted, even though there is a .dyn_o present. What am I doing wrong? This is on x86-64 OS X. There is one other thing which may be related. Since I load everything interpreted now, I've noticed that the input gets very laggy when I have a hundred or so modules loaded. Also the haskeline state gets confused, e.g. I hit escape k to get the previous line, but then it spontaneously goes back into insert mode again. It stays balky and awkward for about 15 seconds before returning to normal slightly. It's almost as if, after loading all the bytecode, it's still doing tons of work in the background, with constant GC freezes. But what work could it be doing? The bytecode is loaded and I haven't asked it to do anything yet! I don't know if this is new to 7.8, or if it's a result of loading bytecode instead of binary. Update: loading with -fobject-code to force compilation reduces some of the balkiness, but some is still there! So maybe this is a regression from 7.6?

On Mon, Jul 14, 2014 at 1:08 PM, Evan Laforge
I sent this to haskell-cafe, but there was no response. On stackoverflow there was no response either. I'm trying one last time, but adding ghc-users (which I should have done at the beginning!). Surely it can't be that no one knows how to load modules in ghci? I know a lot of work was done to enable this, as in https://ghc.haskell.org/trac/ghc/wiki/DynamicByDefault, it seems a waste if no one actually knows how to use it!
See https://ghc.haskell.org/trac/ghc/ticket/8736. The current workaround for GHC 7.8 is to compile with -dynamic, not -dynamic-too. Regards, Reid Barton

On Mon, Jul 14, 2014 at 10:36 AM, Reid Barton
See https://ghc.haskell.org/trac/ghc/ticket/8736. The current workaround for GHC 7.8 is to compile with -dynamic, not -dynamic-too.
That was it! Thanks so much. As an aside, I was kind of expecting a faster link time due to -dynamic, but apparently not. Oh well, I'm happy enough ghci is back. One thing, how about an addition to the release notes in the -dynamic-too section saying "By the way, this doesn't actually work, see https://ghc.haskell.org/trac/ghc/ticket/8736." I'll go update my stackoverflow question. I'm a little surprised, no one else seems to use ghci, or I'd think there would be lots of shouting about this. Or maybe no one has upgraded to 7.8 yet.

On Mon, Jul 14, 2014 at 11:13 AM, Evan Laforge
As an aside, I was kind of expecting a faster link time due to -dynamic, but apparently not. Oh well, I'm happy enough ghci is back.
Aha, I needed to pass -dynamic when linking too. Sorry for the noise.

On Mon, Jul 14, 2014 at 11:13 AM, Evan Laforge
On Mon, Jul 14, 2014 at 10:36 AM, Reid Barton
wrote: See https://ghc.haskell.org/trac/ghc/ticket/8736. The current workaround for GHC 7.8 is to compile with -dynamic, not -dynamic-too.
That was it! Thanks so much.
Actually... not quite. -dynamic seems let ghci load, but when I load with the GHCI API, I get this: compile error: <interactive session>: cannot find normal object file ‘build/debug/obj/Util/Contro.o’ while linking an interpreted expression The proper name is 'Control.hs.dyn_o', so it looks like the suffix mangling code is getting confused. I must be doing something different than ghci anyway, because I have to pass -dynamic in the GHCI API to load, while ghci doesn't seem to need it. And of course ghci doesn't get the mangled filename. One thing is that I'm using '-osuf .hs.o', which is a bit confusing, since it should actually be '.hs.o_dyn', but there's no -odynsuf and I don't really know how all the name mangling in there works. I'll take a look in the ghci code to see how it's doing things.

On Mon, Jul 14, 2014 at 12:35 PM, Evan Laforge
Actually... not quite. -dynamic seems let ghci load, but when I load with the GHCI API, I get this:
compile error: <interactive session>: cannot find normal object file ‘build/debug/obj/Util/Contro.o’ while linking an interpreted expression
Ack.. I keep doing this. It turns out this goes away if I link with '-dynamic' too. I had turned it off when playing the flag permutation game. So I think I finally have everything working now! Still, the Contro.o thing does look buggy.
participants (2)
-
Evan Laforge
-
Reid Barton