- Glasgow-haskell-users

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

Endangered I/O operations
by Simon Marlow 18 May '01

18 May '01

I'm currently re-implementing GHC's I/O library, and I'd like to get people's opinions on the following I/O extensions currently provided by GHC - should we continue to provide them or not. 1. IOExts.hConnectTo This was designed to be a way to have one handle automatically flushed before we flush another handle (eg. outputting to stderr causes stdout to be flushed first). The current implementation has a number of problems: errors and blocking arenn't handled properly when doing the connected flush. If no-one is using it, I'd like to get rid of it. 2. IOExts.withHandleFor This is a cunning hack to allow you to temporarily redirect one handle to another, like 2>&1 in shell speak. I'm dubious as to whether it works consistently - there's certainly not enough error checking in the implementation, so if no-one is using it I'd like to drop it. 3. IOExts.hGetBuf, IOExts.hPutBuf, IOExts.hGetBufBA, IOExts.hPutBufBA These are the "non-blocking" versions of hGetBufFull, hPutBufFull etc. I can't remember why we have both blocking and non-blocking versions, although I distinctly remember implementing and documenting them :-) If anyone is using, or knows of a good use for, the non-blocking versions, then I'll keep them. Otherwise, I'd like to rename hGetBufFull to hGetBuf, and similarly for the others. Cheers, Simon

2 1

Re: Problems building GHC 5.00 on Solaris 2.5.1
by Alister Whitford 17 May '01

17 May '01

I forgot to mention in my first mail that I also got nearly 4000 warnings of the form, "call-clobbered register used for global register variable". They all occur in ghc/include/Reg.h, on the lines that declare the registers F1, F2, F3, F4, D1 and D2. However, in ghc/include/MachReg.h, we see: #if sparc_TARGET_ARCH ... #define CALLER_SAVES_F1 #define CALLER_SAVES_F2 #define CALLER_SAVES_F3 #define CALLER_SAVES_F4 #define CALLER_SAVES_D1 #define CALLER_SAVES_D2 So I am assuming that this warning may safely be ignored - is this correct? Btw, apologies that my original message was in MIME format. Sadly Outlook sends it like that even if you select plain text as your message format, so I have resorted to composing my messages in vi and using the unix mail command...

1 0

Problems building GHC 5.00 on Solaris 2.5.1
by Whitford, Alister 16 May '01

16 May '01

I'm trying to build GHC 5.00 on Solaris 2.5.1. I've got most of the way there. So far, I've had to: - Hack glafp-utils/sgmlverb/Makefile because by lex doesn't support the -8 option. - Hack mk/target.mk in several places because my ld doesn't support the -x option. - Hack configure.in to prevent it from trying to build ReadLine (which was failing.) (Any comments on the above?) The compiler and standard libraries have all built. I'm now attempting to build DrIFT, but I get the following error: ../../../ghc/compiler/ghc-inplace -o DrIFT -ldl -cpp -fglasgow-exts -package text -O ChaseImports.o CommandP.o DataP.o DigitToInt.o DrIFT.o Literate.o ParseLib2.o PreludData.o Pretty.o RuleUtils.o StandardRules.o UserRuleBinary.o UserRuleXml.o UserRules.o Undefined first referenced symbol in file siginterrupt /tmp/ajw/ghc-5.00-build-from-4.08.2/ghc/driver/../rts/libHSrts.a(Signals.o) ld: fatal: Symbol referencing errors. No output written to DrIFT In fact, this occurs whenever I run ghc-inplace to try to create an executable :-( It turns out that siginterrupt is defined in /usr/ucblib/libucb.a, so if I muck about a bit, I can get a working executable like so: /tmp/ajw/ghc-5.00-build-from-4.08.2/ghc/compiler/ghc-inplace -o test -L/usr/ucblib -lucb test.lhs So the question is: how do I get libHSrts.a to link automatically with /usr/ucblib/libucb.a so that the compiler will work properly? Many thanks in advance for any help! Cheers, Alister.

1 0

RE: Windows binary installation for GHC 5.00
by Simon Peyton-Jones 16 May '01

16 May '01

Yes, it'll be 'soon' (days, or a week or three, but not months) Simon | -----Original Message----- | From: Bernd Holzmüller [mailto:holzmueller@ics-ag.de] | Sent: 16 May 2001 08:38 | To: glasgow-haskell-users(a)haskell.org | Subject: Windows binary installation for GHC 5.00 | | | Is there any prediction for when the Windows (NT) binary | distribution for GHC 5.00 will be available? I would not want | to install GHC5.00 from the source distribution in case the | binary distribution is going to be released "soon". Anyway, I | would expect getting an appropriate note via the | glasgow-haskell-users mailing list. | | Bernd Holzmüller | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-| users |

1 0