mkTopLevEnv: not interpreted main:Main

[Simon Peyton-Jones]

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
  IIDecl instead.)

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.

Simon

| -----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
| src/Source.hs.
| 
| 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
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users