May 2001 - Glasgow-haskell-users

RE: Poll: System.exitWith behaviour
by Simon Marlow 25 May '01

25 May '01

> I think, having the third point is good, because the Haskell > report requires that > > Computation exitWith code terminates the program, > returning code to the program's caller. Either way we still conform to the report in the case of a single threaded program (actually, we've already deviated from the report in allowing you to catch the ExitException and carry on). For a multi-threaded program, it's not clear to me what exitWith should do. What should happen if a Haskell callback invokes exitWith? Should it terminate the Haskell main thread? I must admit I'm leaning more towards omitting the third point, and that's what I've implemented for now. Cheers, Simon

3 2

Re: ghc-5.00.1 is available
by Steinitz, Dominic J 24 May '01

24 May '01

Of course I meant hPutStr handle (map (chr .word8ToInt) protocolElement) Dominic J Steinitz@baexternal 24/05/2001 18:47 To: v-julsew cc: glasgow-haskell-users haskell bcc: Dominic Steinitz Subject: Re: ghc-5.00.1 is available Will this - Initial Unicode support - the Char type is now 31 bit cause me a problem? I am sending protocol elements via a socket. I represent these as [Word8]. I had assumed that when I want to send something I do hPutStr (map (ord .word8ToInt) protocolElement) essentially doing a type coercion. But this looks like bits actually get changed into something the respondent won't recognise. Dominic. -------------------------------------------------------------------------------- ----------------- 21st century air travel http://www.britishairways.com _______________________________________________ Haskell mailing list Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell ------------------------------------------------------------------------------------------------- 21st century air travel http://www.britishairways.com

1 0

Re: ghc-5.00.1 is available
by Steinitz, Dominic J 24 May '01

24 May '01

Will this - Initial Unicode support - the Char type is now 31 bit cause me a problem? I am sending protocol elements via a socket. I represent these as [Word8]. I had assumed that when I want to send something I do hPutStr (map (ord .word8ToInt) protocolElement) essentially doing a type coercion. But this looks like bits actually get changed into something the respondent won't recognise. Dominic. ------------------------------------------------------------------------------------------------- 21st century air travel http://www.britishairways.com

1 0

RE: Endangered I/O operations
by Simon Marlow 24 May '01

24 May '01

> A related wish I have is that a Haskell program receiving a HUP signal > should flush its buffers before terminating. > > Or even better, flush on some other signal that does not terminate > the program. Well, you can catch HUP in the program and initiate a flush. Actually just doing System.exitWith will cause all the open handles to be flushed and closed, but note that if you do System.exitWith from a signal handler it won't terminate the program any more... ;-) I think we've just found an argument in favour of having System.exitWith always terminate the program even from a child thread. If you want to *just* flush all the open handles from a signal handler, you'll need to keep track of the open handles and flush them by hand from the signal handler. See the Posix library documentation for details on setting up a signal handler. Cheers, Simon

1 0

RE: Endangered I/O operations
by Simon Marlow 24 May '01

24 May '01

> Simon Marlow <simonmar(a)microsoft.com> writes: > > > .... > > You obtain the ordering properties by setting the handle to > NoBuffering, > > otherwise you get buffered input/output. Wouldn't it be > deviating from > > the report to do extra flushing in the buffered case? > > The report is very silent about this, so I guess that reduces > the question > to what the end-user would prefer, (a) go non-buffered or > make sure you > call hFlush at the right time, or (b) have the IO > implementation flush when > required. I prefer (b), which is why I implemented this at > the time, as it > is > more useable (and more efficient to boot). > > FWIW, notice that stdio implementations diverge on this issue too, all > Win32 impls I've seen does the flushing for you, as did > earlier impls of > glibc, I seem to recall. Ok, the concensus seems to be that folk would prefer the flushing to be done automatically. There's bound to be some overhead, though... Cheers, Simon

1 0

Re: Endangered I/O operations
by cwitty＠newtonlabs.com 23 May '01

23 May '01

"Simon Marlow" <simonmar(a)microsoft.com> writes: > You obtain the ordering properties by setting the handle to NoBuffering, > otherwise you get buffered input/output. Wouldn't it be deviating from > the report to do extra flushing in the buffered case? (this is > something of a technicality, actually we already do non-report flushing > in several cases and our line-buffered input isn't line-buffered at > all). If the report does not allow the implementation to flush buffers at any time, I would call that a bug in the report. I would much rather use an implementation where stdout and stderr came out in the right order, and reading from stdin flushed stdout. (As another example, an implementation might want to flush all buffers before doing a fork(), to avoid duplicated output.) The only caveat is that if such flushing is allowed but not required, it might encourage writing sloppy, nonportable code. Carl Witty

2 1

RE: Endangered I/O operations
by Simon Marlow 23 May '01

23 May '01

> > > If you handle std{in,out,err} connectedness in other ways, I > > > think you've > > > covered 99.2% of the uses of hConnectTo. Neat idea borrowed from > > > Korn & Vo's SFIO, but it hasn't proved to be all that useful. > > > > I wasn't planning to handle connectedness at all. Is it > important, do > > you think? (I'm not against the feature, just trying to > avoid feeping > > creaturism...) > > > > Yes, crucial I think - if stdout and stderr are connected to the same > device, > don't you want their output to be synchronised, e.g., > > main = putStr "foo" >> hPutStr stderr " bar" > > should return "foo bar" on your TTY. Ditto for flushing > stdout/stderr when > peeking stdin. You obtain the ordering properties by setting the handle to NoBuffering, otherwise you get buffered input/output. Wouldn't it be deviating from the report to do extra flushing in the buffered case? (this is something of a technicality, actually we already do non-report flushing in several cases and our line-buffered input isn't line-buffered at all). But I'm still not convinced we need to special case this. Cheers, Simon

2 1

RE: Poll: System.exitWith behaviour
by Simon Marlow 22 May '01

22 May '01

> In reply to Simon Marlow, > > - introduce a new exception constructor: > > ExitException ExitCode > > > > - System.exitWith causes (ExitException code) to be > > raised in the current thread. > > Not entirely relevant, in fact, barely at all but what are > the odds of user > extensible Exceptions (like ML) coming into GHC and having a > proper hierarchy > of exceptions integrated in the libraries? Well, we could do a proper job of extensible data types, which probably isn't hard but is certainly a fair amount of work. Or we could treat Exception as a special case, like ML. Or we could take the Dynamic-typed exception stuff and try to use that in a general way to provide an extensible exception type... I'm open to suggestions. Cheers, Simon

2 1

RE: Endangered I/O operations
by Simon Marlow 22 May '01

22 May '01

> If you handle std{in,out,err} connectedness in other ways, I > think you've > covered 99.2% of the uses of hConnectTo. Neat idea borrowed from > Korn & Vo's SFIO, but it hasn't proved to be all that useful. I wasn't planning to handle connectedness at all. Is it important, do you think? (I'm not against the feature, just trying to avoid feeping creaturism...) Cheers, Simon

2 1

hTell
by Simon Marlow 21 May '01

21 May '01

Quick question: can anyone tell me why IOExts.hTell returns a HandlePosition, whereas IO.hSeek takes an Integer?

2 1