Cabal uses something like system "ghc --version >tmp" in order to determine the version of GHC. After the last changes in CVS the above line no longer produces the right result. The temporary file is created but it is empty. It seems like the stdout/stderr handles are flushed in GHC.TopHandler.runMainIO but only if the program terminates without exception. I tried to flush handles in the catch clause but this doesn't help. Any ideas? Cheers, Krasimir
The temporary file is created but it is empty. It seems like the stdout/stderr handles are flushed in GHC.TopHandler.runMainIO but only if the program terminates without exception.
Should be fixed now; when terminating using exitWith, the handles are now flushed. Note that they are still not flushed for other exceptions. Cheers, Wolfgang
On Sun, Jan 23, 2005 at 03:22:55PM -0500, Wolfgang Thaller wrote:
The temporary file is created but it is empty. It seems like the stdout/stderr handles are flushed in GHC.TopHandler.runMainIO but only if the program terminates without exception.
Should be fixed now; when terminating using exitWith, the handles are now flushed. Note that they are still not flushed for other exceptions.
It seems they should always be flushed. certainly if a program fails via 'fail' in IO or 'error' as these are common ways for programs to report an error and losing output would definitly be counter intuitive and make it quite tricky to debug. especially when you can't flush stdout before calling error. I would think it should flush all buffers on any type of exit. On a another note relating to errors, when profiling is turned on and you write any profiling data out, programs always return a 'success' error code no matter how they quit. It would also be nice to get partial profiling data if one aborts the program early with ^C. John -- John Meacham - ⑆repetae.net⑆john⑈
It seems they should always be flushed. certainly if a program fails via 'fail' in IO or 'error' as these are common ways for programs to report an error and losing output would definitly be counter intuitive and make it quite tricky to debug. especially when you can't flush stdout before calling error. I would think it should flush all buffers on any type of exit.
I agree (after thinking about it again). Done. Cheers, Wolfgang
participants (3)
-
John Meacham -
Krasimir Angelov -
Wolfgang Thaller