- Glasgow-haskell-users

RE: how can I use Posix in win32 cygwin ?
by Simon Peyton-Jones 25 Nov '02

25 Nov '02

We don't support Posix for Win32. It's probably not impossible to implement it, but we have not devoted the time to do so. Maybe you can? Simon | -----Original Message----- | From: Ahn Ki-yung [mailto:kyagrd@bawi.org] | Sent: 25 November 2002 06:37 | To: glasgow-haskell-users(a)haskell.org | Subject: how can I use Posix in win32 cygwin ? | | ghc 5.04.1 binary distribution for win32 does not contain Posix. | | How can I use the posix package in win32 cygwin platform ? | | thanks. | | -- | Ahn Ki-yung | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

how can I use Posix in win32 cygwin ?
by Ahn Ki-yung 25 Nov '02

25 Nov '02

ghc 5.04.1 binary distribution for win32 does not contain Posix. How can I use the posix package in win32 cygwin platform ? thanks. -- Ahn Ki-yung

1 0

Silly question about IORefs and MVars
by Nicolas Oury 23 Nov '02

23 Nov '02

Hello, I have a silly question about IORefs and MVars. When do we have to use MVars if a var is accessed by multiple threads. In fact, I wonder why IORefs updates aren't safe : it seems that preemptive scheduling takes place during memory allocation and I can't see where there could be an allocation (and so a switch) in a read or a write of an IORef. Related question : how less performant is a MVar comparated to simple ref. best regards, Nicolas Oury

2 1

Re: re-opening a closed stdin?
by Albert Lai 22 Nov '02

22 Nov '02

"Simon Marlow" <simonmar(a)microsoft.com> writes: > One reason, I think, is lazy I/O(*). It's to stop you accidentally [...] > (*) kill it! die! die! So you want main = readFile "/dev/zero" >> return () to terminate violantly rather than terminate peacefully? :) Seriously, I understand that the IO monad is the most intuitive and robust when it is strict. But sometimes it is also nice if one could map a file to a lazy string.

1 0

RE: -Werror Request
by Ashley Yakeley 21 Nov '02

21 Nov '02

At 2002-11-20 01:38, Simon Peyton-Jones wrote: >Done! Thanks! -- Ashley Yakeley, Seattle WA

1 0

re-opening a closed stdin?
by Bernard James POPE 21 Nov '02

21 Nov '02

Hi all, 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? 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. (*) www.cs.mu.oz.au/~bjpop/buddha/ Cheers, Bernie.

4 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

> > You can call 'System.Posix.IO.dup stdin' and save this value. > > However, I think you then need to explicitely read from this fd as > > it is not possible to reset what GHC thinks stdin is currently to > > this new fd (I'll dig into this and maybe we'll get a > > setStdin :: Fd -> IO () > > from this, IIRC somebody else was asking for this, too). > > How does this interact with Simon's proposal for hDuplicate? If you actually want to change what stdin/stdout/stderr refer to, or re-open one of these file descriptors after it has been closed, then you need hDuplicateTo. I've enclosed a version of these functions which works with GHC 5.04.1. Cheers, Simon

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