RE: -Werror Request
At 2002-11-20 01:38, Simon Peyton-Jones wrote: >Done! Thanks! -- Ashley Yakeley, Seattle WA ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: re-opening a closed stdin?
On Wed, 20 Nov 2002, Volker Stolz wrote: (snip) > The other way involves opening /dev/stdin on hosts that support this > (with the same limitation as above), including that that's currently (snip) Sometimes /dev/tty will work too. -- Mark ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Request: suppress specific warnings at specific places
If the switches take affect at the line granularity there would seem
to be a straightforward implementation that's orthogonal to most
everything else: store the excluded regions in separate data structure
and check that data structure before printing a message.
mike
> > GHC's excellent warnings are very helpful. They would be somewhat
> > more so if it were possible to suppress a warning about a specific bit
> > of code. One possible syntax (to which I gave no commitment) would be
> >
> > {-# WOFF "non-exhaustive pattern matches" #-}
> >
> > {-# WON "non-exhaustive pattern matches" #-}
> >
> > . Another would be
> >
> > {-# WOFF 523 #-}
> >
> > {-# WON 523 #-}
> >
> > where 523 is a warning number emitted with the warning message.
> >
> > This would be particularly useful with the recently granted wish for
> > -Werror.
>
> This would be nice, but it would be tricky to implement: declarations
> have to be tagged with a list of "exceptions" to the prevailing warning
> settings. I doubt we'll do this any time soon, but patches are welcome
> as usual...
>
> (of course, the workaround is to put the offending code into a module of
> its own, and use OPTIONS to turn off the appropriate warnings).
>
> Cheers,
> SImon
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: re-opening a closed stdin?
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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Request: suppress specific warnings at specific places
> GHC's excellent warnings are very helpful. They would be somewhat
> more so if it were possible to suppress a warning about a specific bit
> of code. One possible syntax (to which I gave no commitment) would be
>
> {-# WOFF "non-exhaustive pattern matches" #-}
>
> {-# WON "non-exhaustive pattern matches" #-}
>
> . Another would be
>
> {-# WOFF 523 #-}
>
> {-# WON 523 #-}
>
> where 523 is a warning number emitted with the warning message.
>
> This would be particularly useful with the recently granted wish for
> -Werror.
This would be nice, but it would be tricky to implement: declarations
have to be tagged with a list of "exceptions" to the prevailing warning
settings. I doubt we'll do this any time soon, but patches are welcome
as usual...
(of course, the workaround is to put the offending code into a module of
its own, and use OPTIONS to turn off the appropriate warnings).
Cheers,
SImon
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: re-opening a closed stdin?
> > 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 hdup.hs Description: hdup.hs
RE: re-opening a closed stdin?
> 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! ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: re-opening a closed stdin?
Bernard James POPE wrote: > 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. As others have pointed out, you can (on Unix at least) duplicate the underlying descriptor. However, this may affect the semantics of closing that descriptor (e.g. a TCP socket isn't "closed" at the TCP layer until *all* corresponding descriptors have been closed). Also, you can't (AFAICT) re-assign Haskell's stdin globally operation in the manner of ANSI C's freopen(), although you can re-assign it locally using IOExts.withStdin. If you need to "really" close stdin (i.e. you can't duplicate the descriptor), it may not be possible to reopen it, e.g. if it is an unnamed pipe, a file which has since been deleted, a socket etc. Even if it is technically possible, you may not always be able to determine exactly how to reopen it, e.g. if it was a file, what was its pathname? However, for the specific case of a terminal on Unix, you can use Posix.getTerminalName; re-opening that will typically work. -- Glynn Clements <[EMAIL PROTECTED]> ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
