Разница для ncurses между интерпретированным и скомпилированным Haskell?

Question

У меня странная проблема с функциями timeout и getch из библиотеки ncurses, используемой в Haskell. Когда я использую их из GHCi или runhaskell, они работают так, как ожидалось. getch ждет число миллисекунд, выданных timeout, а затем возвращается, даже если вход не был дан. Но когда я скомпилировать тот же файл, используя GHC, getch немедленно возвращается.

Я попробовал две привязки ncurses для Haskell; hscurses:

import UI.HSCurses.Curses 

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

и ncurses:

import UI.NCurses 

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

Оба ведут себя так же странным образом, описанный ранее.

Я также попытался эквивалентную программу в C:

#include <ncurses.h> 

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

Это один работает, как ожидалось.

Так что мой вопрос: что может измениться при использовании терминалов из интерпретируемых и скомпилированных Haskell? Нужны ли runhaskell и ghci некоторые тонкие настройки терминала? Или скомпилированный код загружает библиотеки по-другому?

ДОБАВЛЕНО:

Я пытался вызвать программу С из скомпилированного Haskell с использованием FFI и немедленно возвращается (что неверно). Я думаю, это означает, что проблема не в библиотеках, а где-то в среде исполнения GHC.

Answer 1

Я попробовал ваш код - слегка измененный с большим значением тайм-аут - с помощью runhaskell и GHC со следующими командами:

$ runhaskell so_15305317.hs 

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

В обоих случаях, я закончил с ожидаемым поведением. Ваша установка ghc должна быть сломанной или команда, используемая для компиляции, включая параметры, нарушающие поведение библиотеки.

Версия ghc - 6.12.1, а hcurses - 1.13.0.2, на системе debian 6.0.5.