Подтвердить что ты не робот

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

У меня странная проблема с функциями 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 некоторые тонкие настройки терминала? Или скомпилированный код загружает библиотеки по-другому?

ДОБАВЛЕНО:

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

4b9b3361

Ответ 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.