Bug in GHCi

2002-01-25 Thread Koen Claessen

Hi,

This is a bug which has been in GHCi from the beginning.

Bug
===

GHCi interprets a module while the compiled version is
present and up-to-date.

Details
===

When I (for example) have the following module structure:

  module A where
...

  module B where
import A
...

The following thing happens in GHCi:

First, I start GHCi (without any arguments). Then I compile
both modules (I am using the command-line here, but that has
nothing to do with the bug.)

  Prelude :!ghc --make B
  ghc-5.02.2: chasing modules from: B
  Compiling A( A.hs, A.o )
  Compiling B( B.hs, ./B.o )

This looks fine. Now, I load B into GHCi:

  Prelude :l B 
  Skipping  A( A.hs, A.o )
  Skipping  B( B.hs, ./B.o )
  Ok, modules loaded: B, A.

Both modules are loaded, and it is the compiled version for 
both.

Now, I am making changes to A:

  B :!touch A.hs

And I recompile the whole thing:

  B :!ghc --make B
  ghc-5.02.2: chasing modules from: B
  Compiling A( A.hs, A.o )
  Compiling B( B.hs, ./B.o )

Still everything is fine. However, when I now reload using
:r, GHCi recognizes that A.hs has changed, but it does *not*
recognize that the new A.o file is already there!

  B :r
  Compiling A( A.hs, interpreted )
  Compiling B( B.hs, interpreted )
  Ok, modules loaded: B, A.

So, I get the interpreted versions of both! (This is wrong.)  
The only way to get the compiled versions, is to load B
freshly:

  B :l B
  Skipping  A( A.hs, A.o )
  Skipping  B( B.hs, ./B.o )
  Ok, modules loaded: B, A.

This leads to the state that I want GHCi to be in.

/Koen.


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs



The Handle returned by connectTo and accept is unbuffered by default.; oh yeah?

2002-01-25 Thread George Russell

According to the GHC libraries manual, 6.2.1: The Handle returned by connectTo and 
accept is unbuffered by default.   However, with such a handle and hPutStrLn, 
I am getting buffering, even when use IO.hSetBuffering to NoBuffering.   When I
put in an explicit hFlush after the hPutStrLn it works.

___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs