- Libraries - Haskell.org

RE: getting a Binary module into the standard libs
by Simon Marlow 18 Dec '02

18 Dec '02

> (I'll try to > do some perf measurements on BinIO vs. BinMem later today, that should > give us a rough idea). I did a rough test using GHC's current Binary library hacked to be standalone. The test was writing 100000 Ints, followed by reading back 100000 Ints. Results: using BinMem took about 0.25 secs, BinIO took about 1.1 secs. That is, BinMem is current 4-5 times faster than BinIO. I should stress that this isn't a realistic benchmark. I conjecture the difference is mostly due to the overhead of going through the IO library each time a character is written. When I wrote the Binary library I was pretty careful to make sure that putWord8/getWord8 on a BinMem was just straight-line code (that's what the FastMutInt stuff is for). The upshot is that if you want really good performance for BinIO, there will have to be a cache in the BinHandle. Cheers, Simon

3 5

Re: showUnique
by George Russell 11 Dec '02

11 Dec '02

I support the suggestion of providing instance Show Unique I would also support having instance Read Unique As John says, the representation of a Unique value as a String should be completely undefined except that u == u' iff showUnique u == showUnique u' In UniForM we have a similar type to Unique which also instances (Eq,Ord,Show,Read) One advantage of instancing Show is that it makes it easier to debug programs which use Unique values. Read is more debatable, but I'm sure we use it somewhere.

1 0

showUnique
by John Meacham 10 Dec '02

10 Dec '02

how about adding a show instance for Unique in Data.Unique? oftentimes arbitrary unique labels need to be generated, but 'hashUnique' doesnt guarentee the returned Int is unique. there is no way to add this functionality outside of the Data.Unique module since Unique is opaque. John -- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john(a)foo.net ---------------------------------------------------------------------------

2 2

Re: Posix.installHandler issues.
by Volker Stolz 05 Dec '02

05 Dec '02

In local.libraries, you wrote: > solution: add another argument to Posix.installHandler which takes a > list of flags as described in sigaction(3) (including SA_ONESHOT). I > apologize if i am misinterpreting the behavior of my program. I'm not sure that the other flags are (generally) useful or apply at all to Haskell (e.g. SA_NODEFER: is a Haskell-handler equivalent to a C signal handler?). Furthermore, it's probably not necessary to break the API. How about a new function with the parameter indicating ONESHOT or not and then expressing installHandler through this? I don't like primInstallHandler or installHandler', so if somebody has a suggestion... BTW: One might argue that you could simply write your own in-Haskell signalstack by simply setting MVars/Semaphores in the signal handler and then have one Concurrent Haskell thread which decides what to do with those 'signals'. -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME

1 0

Posix.installHandler issues.
by John Meacham 05 Dec '02

05 Dec '02

I cant seem to figure out how to do one-shot signals in haskell, the problem is that signals are queued to be run on a haskell thread so I cannot do a 'installHandler _ Default _' without the possiblility of more signals coming in before the thread gets scheduled. Proposed solution: add another argument to Posix.installHandler which takes a list of flags as described in sigaction(3) (including SA_ONESHOT). I apologize if i am misinterpreting the behavior of my program. John -- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john(a)foo.net ---------------------------------------------------------------------------

1 0

RE: getting a Binary module into the standard libs
by Simon Marlow 03 Dec '02

03 Dec '02

> > BinMem and BinIO differ quite a bit here: for BinMem you can write > > straight into the array, whereas for BinIO we need a cache > - a single > > byte at the least, but ideally more. BinMem is the most > important case > > to optimise (for us in GHC anyhow), since BinIO is already > significantly > > slower due to the overhead of the Handle interface. > > Currently the BinIO implementation doesn't do any caching, though, > right? I actually rarely use the BinMem implementation, so I would be > more interested in improving the speed of BinIO. Presumably, > however, the > Handle actually does buffering, which should take care of a > large part of this, right? The problem is the overhead of the Handle interface. hPutChar is quite expensive, because it has to lock/unlock the Handle. Using a cache in the BinIO implementation would help a lot, but it also means that you have to keep exclusive access to the Handle while doing binary operations. There is already a similar problem, because the library caches the file pointer outside the Handle, so someone doing an hSeek on the same Handle will cause the cached version to be out of sync with the real one. Should multiple threads be allowed to access the same BinHandle simultaneously? Probably not in write mode, but it might be useful when reading. Maybe we could provide dupBin :: BinHandle -> IO BinHandle this is easy enough to implement, and the separate BinHandles could be used from different threads. > > There should really be a closeBin function too; it's quite simple to > > add. > > On files this would flush the current byte then close the file handle, > right? What would it do on BinMems (other than flush the byte)? closeBin can throw away a BinMem. If it needs to be written to a file, then we provide writeBinMem. Cheers, Simon

3 3

RE: IOError vs. Exception vs. IOException
by Simon Marlow 27 Nov '02

27 Nov '02

> Just a thought, but what are the ramifications of taking the other > route, relaxing the haskell 98 spec to allow implementations to expand > the set of valid exceptions? a function can be used to > determine whether > it is something not covered by the haskell 98 spec (even if > we dont know > anything else about it..) and we can at least rethrow it or > 'show' it in > logs or whatever. lots of useful little functions can be written which > are haskell 98 but should be general enough to handle random > exceptions, > it would be silly to have to keep 2 versions around... <snip> It's difficult to "relax the Haskell 98 spec" in this way, since most compilers can be used in a strict Haskell 98 mode. Up to now this hasn't required using a different set of libraries, but if -fglasgow-exts changed the meaning of IO.catch then it would. Instead, I'd suggest deprecating System.IO.catch and perhaps the rest of the IOError support in System.IO. It is all available from System.IO.Error and Control.Exception anyhow. Cheers, Simon

5 4

Re: re-opening a closed stdin?
by Dean Herington 21 Nov '02

21 Nov '02

Bernard James POPE wrote: > [Dean wrote:] > Wouldn't you want the debugger to use stdin and stdout for its > interaction with the > > user, and run the object program with stdin and stdout handles of its own > > creation? (In that case your question seems moot.) I've always been very confused > > by debuggers that try to share stdin/stdout with the debugged program. > > Dean > > Hi Dean, > > You make a good point. > > One thing to note is that in my debugger the user's program is run to > completion before debugging begins. This means that the debugger does not need > to use stdin/stdout until after the user's program is finished with them. > > In a debugger that intersperses its own I/O with that of the user's program, > it would make a lot of sense to do as you say above. > > I (perhaps naively) thought that it would be simpler for my debugger to > reuse the stdin/stdout handles. > > Were you thinking of using a system call to dup, or something else. > > I am not a terminal expert, as you can probably guess, so > I'd appreciate any comments that you feel are appropriate. > > Thanks, > Bernie. Glynn Clements mentioned some good reasons why you shouldn't try to "reuse" stdin and stdout. For example, stdin or stdout (or both) could be connected to files, pipes, etc. If your debugger truly runs the user program to completion, there shouldn't be any problem: The operating system "reuses" "terminal"-connected stdin/stdout when a subprocess completes. So I suspect you need the user program process to stick around for post-"completion" debugging. In this case I still think the clean approach is to have the debugger create fresh stdin/stdout handles for execution of the user program. When the user program does want to do "terminal" input and/or output, on Unix I would first consider pseudo-terminals (man pty). Dean

1 0

RE: re-opening a closed stdin?
by Simon Marlow 21 Nov '02

21 Nov '02

> Simon Marlow writes: > > I've been thinking about duplicating/replacing Handles for a while. > > Here's a possible interface: > > > > -- |Returns a duplicate of the original handle, with its > own buffer > > -- and file pointer. The original handle's buffer is flushed, > > including > > -- discarding any input data, before the handle is duplicated. > > hDuplicate :: Handle -> IO Handle > > -- |Makes the second handle a duplicate of the first handle. The > > -- second handle will be closed first, if it is not already. > > hDuplicateTo :: Handle -> Handle -> IO () > > I'm not too sure of the issues here. Some examples that use > them would be helpful. Well, I can redirect stdout like this: > hPutStrLn stdout "foo" foo > h <- openFile "/tmp/foo" WriteMode > :!cat /tmp/foo > hPutStrLn h "bar" > :!cat /tmp/foo > hFlush h > :!cat /tmp/foo bar > hDuplicateTo h stdout > putStrLn "wibble" > :!cat /tmp/foo bar wibble > (note that it was GHCi that set stdout into NoBuffering mode after the hDuplicateTo). > The only suggestion I'd make is that the names be something > with handle in them: > > huDupHandle, hDupHandleTo Hmm, I chose the names to be consistent with the rest of the IO library, where anything beginning with 'h' is assumed to act on a Handle. > > The remaining questions are: > > - Should you be allowed to duplicate a Handle which refers > > to a file opened in WriteMode? Haskell 98 forbids having > > two Handles pointing to the same file opened for writing, > > but IMHO it's quite a reasonable thing to do. If we don't allow > > this, then there needs to be another version of hDuplicateTo > > which invalidates the original Handle. > > Why does Haskell 98 make this restriction (I don't think that > the library report says why)? One reason, I think, is lazy I/O(*). It's to stop you accidentally writing to a file which is being read from lazilly and getting unexpected results. Cheers, Simon (*) kill it! die! die!

1 0

RE: re-opening a closed stdin?
by Simon Marlow 21 Nov '02

21 Nov '02

> There's probably a really obvious answer to this, but I can't find it. > > Is there any way in GHC to reopen stdin if it has been closed? There's no way to do this at present, except in GHCi where you can revert CAFs to their unevaluated state. > You may wonder why I'd want this. Well I'm writing a debugger > for Haskell 98 (*) and my debugger wants to do some > interaction on the terminal > _after_ the user's program has run. If the user's program > puts stdin into > a closed or semi-closed state then that causes trouble for my > debugger. > > What I'd like to do is close stdin after the end of the > user's program, > flush any input waiting in the buffer, then reopen it fresh > for reading. > > If this can't be easily done perhaps there is another > solution you can think of. I've been thinking about duplicating/replacing Handles for a while. Here's a possible interface: -- |Returns a duplicate of the original handle, with its own buffer -- and file pointer. The original handle's buffer is flushed, including -- discarding any input data, before the handle is duplicated. hDuplicate :: Handle -> IO Handle -- |Makes the second handle a duplicate of the first handle. The -- second handle will be closed first, if it is not already. hDuplicateTo :: Handle -> Handle -> IO () These are fairly straightforward to implement in GHC (I've got a working prototype), and given these primitives you can implement the other interfaces that have been talked about in the past (withStdin/withStdout/withStderr, for example). The remaining questions are: - Should you be allowed to duplicate a Handle which refers to a file opened in WriteMode? Haskell 98 forbids having two Handles pointing to the same file opened for writing, but IMHO it's quite a reasonable thing to do. If we don't allow this, then there needs to be another version of hDuplicateTo which invalidates the original Handle. - Should these be exported by System.IO? Are there any fundamental problems which would make these hard or impossible to implement in Hugs or NHC? Cheers, Simon

2 1