GHCi 6.12.3 stdout redirection works for :type, but not for :info

[Simon Marlow]

On 22/09/2010 18:14, Claus Reinke wrote:
>> good diagnosis.  want to make a ticket?
>
> done:
>
> http://hackage.haskell.org/trac/ghc/ticket/4332
>
> On second thought: is there any reason to use haskelline for
> *output*, as opposed to *input* history logging/editing?

I think we were using Haskeline for output in order to get proper 
Unicode encoding.  Since then, the IO library has gained support for 
Unicode encoding, so we don't need to do this any more.  It looks like I 
tried to modify GHCi to bypass Haskeline for output, but didn't do a 
complete job:

Fri Sep 18 15:40:41 BST 2009  Simon Marlow <marlowsd at gmail.com>
   * remove encoding of output using Haskeline; the IO library does it 
now (#3398)

http://hackage.haskell.org/trac/ghc/ticket/3398

Cheers,
	Simon


> If not, avoiding that might be the easiest fix.
>
> Claus
>
>> | -----Original Message-----
>> | From: glasgow-haskell-users-bounces at haskell.org
>> [mailto:glasgow-haskell-
>> | users-bounces at haskell.org] On Behalf Of Claus Reinke
>> | Sent: 22 September 2010 16:05
>> | To: GHC users
>> | Subject: Re: GHCi 6.12.3 stdout redirection works for :type, but not
>> for
>> | :info
>> |
>> |
>> | > The problem is that my code for redirecting the output
>> | > of GHCi commands still works for things like :type, but
>> | > no longer for things like :info (this is my smallest example
>> | > demonstrating the effect).
>> |
>> | The difference seems to be between commands that use
>> | old-style GHCi output (works with redirection) versus
>> | commands that output via Haskelline (redirection fails).
>> |
>> | ':type' calls typeOfExpr, which still uses 'printForUser',
>> | which ultimately goes down to
>> | 'compiler/utils/Pretty.lhs:printDoc', where it just calls
>> | 'hPutChr/Str stdout'.
>> |
>> | ':info' calls 'info', which uses 'outputStrLn', which
>> | ultimately goes down to
>> | 'Haskelline/Backend/Win32.hsc:putOut', where it
>> | calls either 'WriteConsole' (if to terminal), or
>> | 'Data.ByteString.putStr' (no terminal).
>> |
>> | The distinction between terminal and no terminal
>> | is currently done only once per GHCi session, so
>> | redirecting stdout to a file for just one command
>> | will call 'WriteConsole' on a non-terminal handle
>> | (redirecting the whole session works, though it is
>> | useless for writing advanced GHCi commands).
>> |
>> | I consider this a serious GHCi regression (never
>> | mind the inconsistencies between GHCi commands),
>> | as it breaks all the nice .ghci goodies from my old
>> | tutorial (*) that people keep writing to me about.
>> |
>> | If this analysis is correct, possible fixes would be:
>> |
>> | - use 'printForUser/outputStrLn' consistently
>> | (why is the latter needed for some commands,
>> | but not for others?), and ensure that terminal
>> | status is checked for each GHCi command,
>> | instead of once per session (the main problem
>> | is the version of 'putOut' that goes into the
>> | 'RunTerm structure's 'putStrOut' field - it is
>> | set by 'myRunTerm' in 'runInputTWithPrefs')
>> |
>> | - expose a GHCi command that allows users
>> | to trigger Haskelline's terminal status check,
>> | and rewrite the redirection code accordingly
>> |
>> | Sadly, I won't be able to implement either myself
>> | at the moment - is there a chance of getting this
>> | fixed for the 7.0.1 release (the first variant would
>> | be the proper fix, the second variant a quick hack
>> | to restore functionality)?
>> |
>> | Claus
>> |
>> | (*) http://haskell.org/haskellwiki/Ghci#Using_.ghci.2C_a_mini-tutorial
>> |
>> | > With the attached GHCi script defining a
>> | >
>> | > :redir <var> <command>
>> | >
>> | > command that should redirect the ouput of <command>
>> | > into variable <var>, we get the output appended below
>> | > (note the Exception for WriteConsole "handle is invalid",
>> | > which is written into the temporary file when :info is
>> | > called while stdout is redirected to that temporary file;
>> | > in other words, the error message appears where the
>> | > output of the command fails to appear).
>> | >
>> | > Is that an expected change with a known workaround,
>> | > so that I just need to update my code, or is that
>> | > unexpected behaviour that can only be fixed in GHCi?
>> | >
>> | > Claus
>> | >
>> | > PS. This is on Windows 7, if that matters.
>> | >
>> | > ------------- example session output
>> | > $ ghcii.sh -ignore-dot-ghci
>> | > GHCi, version 6.12.3: http://www.haskell.org/ghc/ :? for help
>> | > ..
>> | > Prelude> :cmd readFile "redir.script"
>> | > Prelude> :redir x :t map
>> | > ..
>> | > Prelude> x
>> | > "-- logging GHCi stdout\nmap :: (a -> b) -> [a] -> [b]\n"
>> | > Prelude> :redir y :i map
>> | > Prelude> y
>> | > "-- logging GHCi stdout\n*** Exception: WriteConsole: invalid
>> argument
>> | > (Das
>> | > Handle ist ung\252ltig.)\n"
>> | >
>> |
>> |
>> |
>> | _______________________________________________
>> | Glasgow-haskell-users mailing list
>> | Glasgow-haskell-users at haskell.org
>> | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>>
>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users