Re: [Haskell-cafe] GHC + interactive input/output

2008-02-17 Thread Ian Lynagh

Hi Richard,

On Mon, Feb 11, 2008 at 12:37:27PM +1300, Richard A. O'Keefe wrote:
 
 On 9 Feb 2008, at 2:29 pm, Philip Weaver wrote:
 
 GHC certain *could* do this, but it's arguably not the right thing  
 to do.
 
 I have reminded the GHC maintainers before that the Haskell  
 specification
 *REQUIRES* a Haskell system to support this;

[this is flushing stdout when we read from stdin, if I have followed
correctly]

Can you please say where the report says this? I've just skimmed
http://haskell.org/onlinereport/io.html
and didn't see it mentioned.

Also, if there's a GHC bug about this, can you please point me to it? A
quick search didn't find anything.

 there is an example that  
 makes
 no sense whatever without it.

I'm not sure which example you're referring to, but the first example on
the above page
21.10.1  Summing Two Numbers
starts off by doing
hSetBuffering stdout NoBuffering
which implies to me that implementations are not expected to do the
flushing hack.


Thanks
Ian

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


Re: [Haskell-cafe] GHC + interactive input/output

2008-02-10 Thread Richard A. O'Keefe


On 9 Feb 2008, at 2:29 pm, Philip Weaver wrote:

GHC certain *could* do this, but it's arguably not the right thing  
to do.



I have reminded the GHC maintainers before that the Haskell  
specification
*REQUIRES* a Haskell system to support this; there is an example that  
makes
no sense whatever without it.  (And the other Haskell systems I use  
get it

right.)

I note that David Bacon's SETL implementation has explicit support for
tying an input stream and an output stream together so that any time  
input

is done on the input stream the output stream is flushed; this is done
automatically for sockets and is *seriously* useful in avoiding  
mistakes.


Note that this should make essentially no difference to performance  
because
(a) the flushing is only needed when the input buffer is exhausted,  
which

happens once per line,
(b) the kinds of streams where you want it (terminals, STREAMs, sockets,
serial ports, c) generally have other costs so high you won't be
able to measure this one,
(c) it *only* applies to bidirectional streams or to explicitly coupled
streams, so I/O to disc files or memory sticks or other high speed
block devices should never be affected at all (unless someone  
chooses
to do it explicitly, in which case it's still going to be faster  
than

anything they could have done by hand).


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


[Haskell-cafe] GHC + interactive input/output

2008-02-08 Thread Jonathan Cast

$ cat  foo.c
#include stdio.h

int
main()
{
  char s[1024];
  printf(gsi );
  gets(s);
  printf(%s\n, s);
  return 0;
}
$ make foo
cc gsi.c   -o gsi
$ ./foo
warning: this program uses gets(), which is unsafe.
gsi hello
hello
$ cat  foo.hs
main = do
  putStr gsi 
  s - getLine
  putStrLn s
$ ghc foo.hs -o foo
$ ./foo
hello
gsi hello

(This is on MacOS X).  It strikes me that GHC is being  
extraordinarily unhelpful here.  Is there anyone on the planet who  
ever actually wants this behavior?


jcc

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


Re: [Haskell-cafe] GHC + interactive input/output

2008-02-08 Thread Brandon S. Allbery KF8NH


On Feb 8, 2008, at 19:41 , Philip Weaver wrote:

Your gsi  is buffered because there's no newline at the end.  To  
flush the buffer and force it to be printed immediately, use  
'hFlush' from the System.IO library, or use 'hSetBuffering' from  
that same library: http://haskell.org/ghc/docs/latest/html/ 
libraries/base/System-IO.html


I believe you can observe the same behavior in C.


Most C stdio libraries in my experience have extra code in the  
functions that read stdin to flush stdout first, specifically because  
of lazy people who don't pay attention to buffering.


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH


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


Re: [Haskell-cafe] GHC + interactive input/output

2008-02-08 Thread Philip Weaver
Your gsi  is buffered because there's no newline at the end.  To flush
the buffer and force it to be printed immediately, use 'hFlush' from the
System.IO library, or use 'hSetBuffering' from that same library:
http://haskell.org/ghc/docs/latest/html/libraries/base/System-IO.html

I believe you can observe the same behavior in C.

- Phil


On Feb 8, 2008 4:14 PM, Jonathan Cast [EMAIL PROTECTED] wrote:

 $ cat  foo.c
 #include stdio.h

 int
 main()
 {
   char s[1024];
   printf(gsi );
   gets(s);
   printf(%s\n, s);
   return 0;
 }
 $ make foo
 cc gsi.c   -o gsi
 $ ./foo
 warning: this program uses gets(), which is unsafe.
 gsi hello
 hello
 $ cat  foo.hs
 main = do
   putStr gsi 
   s - getLine
   putStrLn s
 $ ghc foo.hs -o foo
 $ ./foo
 hello
 gsi hello

 (This is on MacOS X).  It strikes me that GHC is being
 extraordinarily unhelpful here.  Is there anyone on the planet who
 ever actually wants this behavior?

 jcc

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

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


Re: [Haskell-cafe] GHC + interactive input/output

2008-02-08 Thread Jonathan Cast

On 8 Feb 2008, at 4:50 PM, Brandon S. Allbery KF8NH wrote:



On Feb 8, 2008, at 19:41 , Philip Weaver wrote:

Your gsi  is buffered because there's no newline at the end.   
To flush the buffer and force it to be printed immediately, use  
'hFlush' from the System.IO library, or use 'hSetBuffering' from  
that same library: http://haskell.org/ghc/docs/latest/html/ 
libraries/base/System-IO.html


I believe you can observe the same behavior in C.


Most C stdio libraries in my experience have extra code in the  
functions that read stdin to flush stdout first, specifically  
because of lazy people who don't pay attention to buffering.


Why can't GHC implement the same thing?

jcc

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


Re: [Haskell-cafe] GHC + interactive input/output

2008-02-08 Thread Jonathan Cast

On 8 Feb 2008, at 5:29 PM, Philip Weaver wrote:

GHC certain *could* do this, but it's arguably not the right thing  
to do.  For performance, the operating system buffers writes until  
it is ready to write large chunks at a time.  If you do not want  
this behavior, change the buffering mode from its default.


To what?

BlockBuffering is worse, not better, and the docs *explicitly* say  
that switching to NoBuffering will break ^D (if it wasn't broken  
already...)  My specification for a working program is `one that  
works exactly like every other program on my machine'.  I don't see  
how to produce such a program with GHC.(1)


jcc

(1) Using readline might work (although I'm kind of sceptical given  
what's preceded it), but I haven't gotten it to link thus far...


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


Re: [Haskell-cafe] GHC + interactive input/output

2008-02-08 Thread Jonathan Cast

On 8 Feb 2008, at 6:34 PM, Ryan Ingram wrote:


import System.IO

myGetLine = hFlush stdout  getLine


That fixes this issue, certainly (although it's superfluous; my  
program really does contain only a single call to getLine)...


Nevertheless, it would be nice to at least have it in the standard  
library; it's much more useful than any of the input functions that  
already exist.


jcc


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


Re: [Haskell-cafe] GHC + interactive input/output

2008-02-08 Thread Jonathan Cast

On 8 Feb 2008, at 6:50 PM, Jonathan Cast wrote:


On 8 Feb 2008, at 6:34 PM, Ryan Ingram wrote:


import System.IO

myGetLine = hFlush stdout  getLine


That fixes this issue, certainly (although it's superfluous; my  
program really does contain only a single call to getLine)...


Nevertheless, it would be nice to at least have it in the standard  
library; it's much more useful than any of the input functions that  
already exist.


Also, for some reason, this doesn't seem to be necessary inside an  
Emacs buffer...  Do we not care about performance in that case?


jcc

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


Re: [Haskell-cafe] GHC + interactive input/output

2008-02-08 Thread Ryan Ingram
import System.IO

myGetLine = hFlush stdout  getLine

  -- ryan

On 2/8/08, Jonathan Cast [EMAIL PROTECTED] wrote:
 On 8 Feb 2008, at 5:29 PM, Philip Weaver wrote:

  GHC certain *could* do this, but it's arguably not the right thing
  to do.  For performance, the operating system buffers writes until
  it is ready to write large chunks at a time.  If you do not want
  this behavior, change the buffering mode from its default.

 To what?

 BlockBuffering is worse, not better, and the docs *explicitly* say
 that switching to NoBuffering will break ^D (if it wasn't broken
 already...)  My specification for a working program is `one that
 works exactly like every other program on my machine'.  I don't see
 how to produce such a program with GHC.(1)

 jcc

 (1) Using readline might work (although I'm kind of sceptical given
 what's preceded it), but I haven't gotten it to link thus far...

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

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