On 01/03/2012 02:26, Ian Lynagh wrote:
On Wed, Feb 29, 2012 at 10:31:31AM +0000, Simon Marlow wrote:
On 28/02/2012 13:07, Ian Lynagh wrote:
On Tue, Feb 28, 2012 at 10:44:35AM +0000, Simon Marlow wrote:
On 28/02/2012 09:03, Simon Marlow wrote:
The safeHaskell failures disappeared on my second validate run, so I'm
not sure what happened (I had pulled into the tree first, and there were
no patches between the two runs that should have affected this). Perhaps
there's some missing cleaning somewhere? Anyway I wouldn't worry about
it unless the failures come back.
I just remembered: my second validate was with --fast, so it seems
the safeHaskell failures only show up without --fast. Probably some
bad interaction with BINARY_DIST=YES?
It's because ghc has a different program name (ghc-stage2 vs ghc)
depending on whether it is in in-tree GHC or not.
The testsuite would normalise this on stderr, but ghc/InteractiveUI.hs
showException is printing the exception on stdout. I didn't get as far
as working out whether that's the right thing for it to do or not.
I think our policy in GHCi is to print everything to stdout, except
for program output that is explicitly sent to stderr of course. It
doesn't seem to make sense for an interactive session to send some
output to stdout and some to stderr, risking strange interleaving
due to buffering and whatnot.
It looks like type errors, both in expressions typed at the prompt and
in modules that are loaded, go to stderr.
I think it's standard behaviour for interactive tools to behave like
that.
Well, if it's standard behaviour then I have no objection.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
