On 06/10/2011 16:34, Chris Smith wrote:
Simon, thank you! That makes sense then.
I'd missed the fact that including the entire top-level scope requires
the module to be interpreted. I suppose the "right" thing to do would
be to not do that; but sadly, that seems to also mean that modules
witho
Simon, thank you! That makes sense then.
I'd missed the fact that including the entire top-level scope requires
the module to be interpreted. I suppose the "right" thing to do would
be to not do that; but sadly, that seems to also mean that modules
without a 'module Foo where' only export the si
On 04/10/2011 21:33, Chris Smith wrote:
Here's a version with fewer flags/features, that acts the same.
I tried removing the loading of an external module, and that did *not*
exhibit the problem. It also does *not* fail when the file name is
different each time, so the fact that it's the same f
Thanks everyone for the help!
I'm working now on reproducing this with HEAD, and if I do, I'll write a
ticket. On the other hand, it only seems to be an issue when one is
recompiling a file within one second of the first attempt, and Felipe's
workaround of deleting the .hi and .o files fixes it e
On Tue, Oct 4, 2011 at 5:32 PM, Felipe Almeida Lessa
wrote:
> This may have something to do with timestamps on the files. I cannot
> reproduce the error with
>
> $ while ./T; do sleep 1; done
> ...
>
> However, I *am* able to reproduce the error with
>
> $ while ./T ; do sleep 0.9; done
> Jus
Here's a version with fewer flags/features, that acts the same.
I tried removing the loading of an external module, and that did *not*
exhibit the problem. It also does *not* fail when the file name is
different each time, so the fact that it's the same file, A.hs, each
time is somehow part of th
This may have something to do with timestamps on the files. I cannot
reproduce the error with
$ while ./T; do sleep 1; done
...
However, I *am* able to reproduce the error with
$ while ./T ; do sleep 0.9; done
Just 42
Just 42
Just 42
Just 42
Just 42
T: mkTopLevEnv: not interpr
Here's a test case: the complete source code is in the following. I
compile it with:
ghc -package ghc --make Test.hs
The GHC version is
cdsmith@godel:~$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.2.1
Then run the application several times in a row. If
| Sent: 03 October 2011 14:43
| To: Simon Peyton-Jones
| Cc: glasgow-haskell-users@haskell.org
| Subject: RE: mkTopLevEnv: not interpreted main:Main
|
| Thanks, Simon.
|
| I will work on building a smaller complete test case that reproduces the
| issue, and I could have done a better job of at lea
Thanks, Simon.
I will work on building a smaller complete test case that reproduces the
issue, and I could have done a better job of at least pointing out the
relevant code for you. Sorry about that.
I'm definitely not building my own IIModule. The use of the GHC API is
as follows. (I'm fairly
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
11 matches
Mail list logo