vista: GHCi not loading 80% of the time

[guest]

Running windows vista 32-bit, trying to run GHCi it randomly does not bring up the Prelude> prompt about 80% of the time.

It just displays the Loading package base ... linking ... done. and then appears to lock.

[igloo]

Simon will be looking at the Vista problems

[simonmar]

I can't repeat this one. Could you try a recent snapshot, e.g.

http://www.haskell.org/ghc/dist/current/dist/ghc-6.7.20070816-i386-unknown-mingw32.exe

[simonmar]

unable to repeat. I'm trying with a freshly installed Vista and a new Windows installer generated from today's sources, GHCi never fails to start for me.

[haskell-ghc@…]

I have hit this bug as well, except I would estimate in my case the probability of failure is much higher - I've got to a Prelude prompt only once in two full evenings of fiddling.

I've tried with the snapshot you suggested above, and the bug is reproduced. The output from GHCi is:

"GHCi, version 6.7.20070816: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done."

Running from an administrator priveleged command prompt doesn't help, nor does marking ghci.exe and ghc.exe as "run as administrator".

ghc.exe is able to compile to executables just fine, and runhaskell also works.

I have a cygwin installation, and running via ghcii.sh in a cygwin shell exhibits the same hanging behaviour. I've tried removing all signs of cygwin from my path, but this makes no difference.

I have attached the outputs from "ghci -v5 > ghci.log 2> ghci2.log".

Please let me know if there is any additional information I can provide, or anything you'd like me to try.

[haskell-ghc@…]

To preempt an obvious question, the problem is also present in the snapshot installed with "ghc-6.8.20070909-i386-unknown-mingw32.exe".

The later snapshot from "ghc-6.8.20070912-i386-unknown-mingw32.exe" results in a ghci failure ": not built for interactive use", which I imagine may be unrelated.

[haskell-ghc@…]

I've had a chance to fool around and get a build (6.8.0.20070919) going and I think I now know what's going on: it's a Windows bug. GHCi is hanging on a call to setConsoleCP in compiler/ghci/InteractiveUI.hs, line 1560). A short C program which calls SetConsoleCP also fails in the way described above for GHCi. Even the built-in DOS command to change the codepage 'chcp' fails in the same way.

The bug doesn't seem to be particularly prevalent, but there are a few forum posts about it in odd places (e.g.  here (search for chcp)) suggesting that it's a tablet PC related problem (I'm using a Lenovo X60 Tablet). Interestingly there's a hotfix for Windows XP SP2 which sounds like it fixes this problem  http://support.microsoft.com/kb/925271 but I see nothing similar for Vista.

I've found a rather cheezy workaround. Before running GHCi from the command prompt one can try and change the codepage manually with 'chcp 28591'. This usually hangs, but it can be broken out of with Ctrl-C. This seems to change the codepage nontheless (or at least it reports it as changed). Subsequently running GHCi in that console window always leads to a Prelude> prompt and normal operation.

This bug seems so niche that I'd imagine it doesn't warrant any change to the code, and furthermore, I can't really imagine what could be done without unreasonable effort. I've added an entry to the  FAQ detailing the workaround which should get people going if they run into this problem.

Jony

[igloo]

Thanks for looking into this, and for adding an FAQ entry, Jony!

I can see two easy options: Just close the bug, or add a flag to disable setting the code page. The comment in the source says

On Windows we need to set a known code page, otherwise the characters
we read from the console will be be in some strange encoding, and
similarly for characters we write to the console.

Does anyone know how likely it is that something sane will happen if the code page is not set? Presumably we won't have too long a wait until there is a Vista fix?

[simonmar]

I think the setConsoleCP stuff was a result of a previous bug report, but I can't seem to find the bug.

It's questionable whether we should be changing the code page at all here, see #1649. I suppose the right thing to do is to decode the input according to the current code page. I don't know exactly how to do this, though (pointers welcome).

[simonmar]

Fixed, see #782.