mkTopLevEnv: not interpreted main:Main
simonpj at microsoft.com
Mon Oct 3 15:24:48 CEST 2011
I don't have a good answer here. FWIW
* I believe that the only call to mkTopLevEnv is in InteractiveEval.findGlobalRdrEnv,
which in turn only calls mkTopLev on imports which are specified by an IIModule
specification (see HscTypes.InteractiveImport).
* I think that IIModule things should always be interpreted modules
else we don't *know* their full top-level environment
* I can't account for how you are getting an IIModule of your main:MyModule,
because all the places that create IIModule specs check that the module
is interpreted. Could you be creating that IIModule yourself? (If so use
It's hard to say more without a reproducible test case -- and I'm not too keen on trying to build your entire project unless there is no alternative -- usually there are lots of other dependencies.
maybe others have ideas too.
| -----Original Message-----
| From: glasgow-haskell-users-bounces at haskell.org [mailto:glasgow-haskell-users-
| bounces at haskell.org] On Behalf Of Chris Smith
| Sent: 02 October 2011 05:59
| To: glasgow-haskell-users at haskell.org
| Subject: mkTopLevEnv: not interpreted main:Main
| So I'm trying to fix a bug in a web application that's using the GHC API
| with GHC 7.2. If it helps, the application is gloss-web, source code at
| https://github.com/cdsmith/gloss-web and the relevant module is
| The error I'm getting is
| <no location info>: mkTopLevEnv: not interpreted main:MyModule
| I get this occasionally when two pieces of source code happen to get
| compiled at approximately the same time, but most of the time everything
| works fine. The module name there is whichever one I've defined in the
| source code I'm compiling. It's correct that the module is not
| interpreted; I'm specifying options
| hscTarget = HscAsm
| ghcLink = LinkInMemory
| But it's unclear to me why GHC occasionally decides to require that it
| be interpreted and complain, when compiling the code works fine in any
| other circumstance. Anyone else seen anything like this, or know what
| the cause is?
| A few notes:
| 1. It doesn't appear to be a straight-forward reentrancy issue, as
| wrapping uses of the GHC API with an MVar lock doesn't affect it at all.
| However, it definitely *is* correlated with multiple compiles at
| approximately the same time. Very odd there.
| 2. On a whim, I tried adding a performGC before and after each use of
| the compiler to try to isolate the uses of the GHC API more completely.
| Oddly enough, a performGC before the compile makes the problem much
| WORSE. I found that interesting; maybe it's a hint.
| 3. If you want to build my code and reproduce it, the easiest way is to
| comment out line 110 (keepAlive cmap digest 30) of src/Source.hs. Doing
| so will break the bit that caches recently compiled source code, making
| it much easier to actually call the GHC API several times in rapid
| succession just by rapidly clicking the Run button in the web app.
| If there's anything I can do to get more information, I'm happy to do so
| as well. I'm not terribly familiar with the flags or options for GHC,
| as I've never done this before.
| Chris Smith
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users at haskell.org
More information about the Glasgow-haskell-users