cvs commit: fptools/libraries/base/GHC ConsoleHandler.hsfptools/libraries/base/cbits consUtils.cfptools/libraries/base/include consUtils.hfptools/ghc/compiler/ghci InteractiveUI.hs

[Sigbjorn Finne]

Thanks, believe it is a bit better behaved now in
that usage mode.

--sigbjorn

----- Original Message ----- 
From: "Krasimir Angelov" <kr.angelov at gmail.com>
To: "Sigbjorn Finne" <sof at haskell.org>
Cc: <cvs-libraries at haskell.org>; <cvs-ghc at haskell.org>
Sent: Thursday, May 12, 2005 03:40
Subject: Re: cvs commit: fptools/libraries/base/GHC 
ConsoleHandler.hsfptools/libraries/base/cbits 
consUtils.cfptools/libraries/base/include 
consUtils.hfptools/ghc/compiler/ghci InteractiveUI.hs


> Hi Sigbjorn,
>
> The workaround breaks another useful feature of GHC. You can't spawn
> GHCi through runInteractiveProcess anymore. You should use
> flushConsole only if the stdin is console handle.
>
> Cheers,
>  Krasimir
>
> On 5/6/05, Sigbjorn Finne <sof at haskell.org> wrote:
>> sof         2005/05/05 17:30:58 PDT
>>
>>  Modified files:
>>    libraries/base/GHC   ConsoleHandler.hs
>>    libraries/base/cbits consUtils.c
>>    libraries/base/include consUtils.h
>>    ghc/compiler/ghci    InteractiveUI.hs
>>  Log:
>>  [mingw only]
>>  Work around bug in win32 Console API which showed up in the GHCi UI:
>>  if the user typed in characters prior to the appearance of the prompt,
>>  the first of these characters always came out as a 'g'. The GHCi UI does
>>  for good reasons one-character reads from 'stdin', which causes the
>>  underlying APIs to become confused. A simple repro case is the following
>>  piece of C code:
>>
>>  /*----------------------*/
>>  #include <stdio.h>
>>  #include <windows.h>
>>  int main()
>>  {
>>      char ch1,ch2;
>>      HANDLE hStdIn = GetStdHandle(STD_INPUT_HANDLE);
>>      DWORD dw;
>>
>>      /* Type in some characters before the prompt appears and be amused.. 
>> */
>>      sleep(1000); printf("? ");
>>      ReadConsoleA(hStdIn,&ch1,1,&dw,NULL);
>>      ReadConsoleA(hStdIn,&ch2,1,&dw,NULL);
>>  /*  or, if you want to use libc:
>>      read(0,&ch1,1); read(0,&ch2,1); */
>>
>>      printf("%c%c\n", ch1,ch2);
>>      return 0;
>>  }
>>  /*----------------------*/
>>
>>  This happens across win32 OSes, and I can't see anything untoward as far
>>  as API usage goes (the GHC IO implementation uses read(), but that
>>  reduces to ReadConsoleA() calls.) People inside the Behemoth might want
>>  to have a closer look at this..
>>
>>  Not much we can do about this except work around the problem by flushing
>>  the input buffer prior to reading from stdin. Not ideal, as type-ahead
>>  is a useful feature. Flushing is handled by 
>> GHC.ConsoleHandler.flushConsole
>>
>>  Merge to STABLE.
>>
>>  Revision  Changes    Path
>>  1.8       +13 -0     fptools/libraries/base/GHC/ConsoleHandler.hs
>>  1.5       +13 -0     fptools/libraries/base/cbits/consUtils.c
>>  1.2       +1 -0      fptools/libraries/base/include/consUtils.h
>>  1.203     +9 -0      fptools/ghc/compiler/ghci/InteractiveUI.hs
>> _______________________________________________
>> Cvs-ghc mailing list
>> Cvs-ghc at haskell.org
>> http://www.haskell.org/mailman/listinfo/cvs-ghc
>>
> _______________________________________________
> Cvs-libraries mailing list
> Cvs-libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/cvs-libraries