Difference for ncurses between interpreted and compiled Haskell?

Question

I have a strange problem with functions timeout and getch from the ncurses library used in Haskell. When I use them from GHCi or runhaskell, they work as expected -- getch waits for the number of miliseconds given to timeout and then returns, even if no input was given. But when I compile the same file using GHC, getch returns immediately.

I tried two ncurses bindings for Haskell; hscurses:

import UI.HSCurses.Curses

main = do
  initCurses
  timeout 1000
  c <- getch
  endWin
  print c

and ncurses:

import UI.NCurses

main = do
  e <- runCurses $ do
    win <- defaultWindow
    getEvent win $ Just 1000
  print e

Both behave the same strange way described before.

I also tried equivalent program in C:

#include <ncurses.h>

int main()
{
  initscr();
  wtimeout(stdscr,1000);
  int c = getch();
  endwin();
  printf("%d\n", c);
  return 0;
}

This one works as expected.

So my question is: what can make the difference when using terminal from interpreted and from compiled Haskell? Do runhaskell and ghci modify some subtle terminal settings? Or does the compiled code load libraries a different way?

ADDED:

I tried to call a the C program from compiled Haskell using FFI and it returned immediately (which is incorrect). I think that means that the problem isn't in the libraries, but somewhere in GHC's runtime.

if the code shown above really behaves as described when compiled, you should submit a bug report to the library maintainers. — didierc, Mar 09 '13 at 08:16
The Haskell libraries should do essentialy the same as the C program and they work correctly when interpreted, so I don't think that the problem is here. — Jan Špaček, Mar 09 '13 at 14:20
well, it works for me either from the repl or with runhaskell. — didierc, Mar 09 '13 at 15:06
tbh, I modified the timeout to 5000 in order to be certain the code did wait. — didierc, Mar 09 '13 at 15:09
@didierc Yes, it works from ghci and runhaskell; the problem is that it doesn't work when compiled (for me). — Jan Špaček, Mar 09 '13 at 15:18

didierc · Answer 1 · 2013-03-09T16:39:03.357

1

I tried your code - slightly modified with a larger timeout value - using runhaskell, and ghc with the following commands:

$ runhaskell so_15305317.hs

$ ghc -packages hscurses -lncurses so_15305317.hs
$ ./a.out

In both cases, I ended up with the expected behaviour. Your installation of ghc must be broken, or the command used for compilation including parameters breaking the library behaviour.

ghc version is 6.12.1, and hcurses is 1.13.0.2, on a debian 6.0.5 system.

edited Mar 09 '13 at 16:39

answered Mar 09 '13 at 16:00

didierc

14,572
3
32
52

Tried with the same commands (only the package name is `hscurses`), got the wrong result. My GHC is version 7.4.1, which might be the reason. – Jan Špaček Mar 09 '13 at 16:27
ah yes, the name is indeed hscurses, it's a typo in my answer. – didierc Mar 09 '13 at 16:37
so I guess we're back to the bug report idea. – didierc Mar 09 '13 at 16:41
OK, I think you're right. I will try some other GHC versions to find out which one introduced this change of behavior. – Jan Špaček Mar 09 '13 at 16:48
2

@honzasp "I tried to call a the C program from compiled Haskell using FFI and it returned immediately (which is incorrect)." It's intended behaviour (now, at least). It changed on the 7.2 to 7.4 step. cf. http://hackage.haskell.org/trac/ghc/ticket/7745 – Daniel Fischer Mar 09 '13 at 16:48
So I suppose that the hcurses library C backend should also include the `SIGVTALRM` handlers, which it probably does not, hence your problem. – didierc Mar 09 '13 at 17:00

Difference for ncurses between interpreted and compiled Haskell?

1 Answers1