Thanks a lot. .this really helps.. On Feb 3, 2015 10:35 PM, "Tristan Seligmann" wrote:

On 4 February 2015 at 05:23, Madhu Babu wrote:

...

Basically, in the following code, we print a line first and the read the line from stdin. This behavior works perfectly fine when using “runhaskell guess.hs”. But when i say “./guess”, i had to type in a number directly ( i.e. first prompt is skipped ).

This is most likely due to stdio buffering; usually stdin/stdout are line buffered, so data you write with putStr may not actually be written until a newline is written. This post / thread details some ways to handle this problem:

https://www.haskell.org/pipermail/beginners/2010-March/003692.html -- mithrandi, i Ainil en-Balandor, a faer Ambar

I just want to pop up and say that on modern computers... Seriously though, wouldn't it be reasonable if putStr flushed? Often in Haskell one constructs a long string to be output and there could still be buffering. On Feb 4, 2015 4:36 AM, "Brandon Allbery" wrote:

On Tue, Feb 3, 2015 at 10:23 PM, Madhu Babu wrote:

...

Basically, in the following code, we print a line first and the read the line from stdin. This behavior works perfectly fine when using “runhaskell guess.hs”. But when i say “./guess”, i had to type in a number directly ( i.e. first prompt is skipped ).

runhaskell is presumably using unbuffered I/O for some reason, so outputting directly to the terminal. The compiled program follows standard Unix buffering conventions: line buffering on output to a terminal, so the putStr is sitting in a buffer waiting to see a newline output.

C / C++ programs also do buffering, but there's a heinous hack which detects reads on stdin and flushes stdout beforehand. (Heinous because there is no guarantee that they are actually related --- but naïve programmers invariably do not learn about line buffering and expect all output to be unbuffered(*), and C standard library programmers eventually gave up and catered to them after years of trying to get them to pay attention. I have a nasty suspicion we're going to end up with a similar horrible hack in Haskell eventually.)

You can use hFlush from System.IO to flush the prompt out to the terminal, or disable output buffering with hSetBuffering in the same module.

(*) At some point someone will pop up and say that on modern computers, buffering is obsolete because it's fast enough that horribly inefficient character-at-a-time I/O is good enough. Yet, I can *still* see visible hesitations when character-at-a-time I/O is used on a modern Intel core i5/i7. And your disk benchmarks will *tank* even with server-class disk subsystems.

-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Wed, Feb 4, 2015 at 10:10 PM, Richard A. O'Keefe wrote:

Given things like sockets, STREAMS, and ptys, I am not sure that it is _possible_ for a Unix system to determine whether two streams are or are not "related" reliably.

It's not. I was not implying that it was, or that it was even a good idea to try to do so. On the other hand, flushing *every* line-buffered FILE is rather overkill but less heinous than highly dubious and untestable assumptions about relationships. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net