"Simon Marlow" <[EMAIL PROTECTED]> writes:
> It is nice, but it introduces too many problems. What happens to any
> I/O errors encountered by the lazy I/O? They have to be discarded,
> which means you can't effectively use lazy I/O for robust applications
> anyway.
Damn, I forgot that "file" me
> Simon Marlow wrote:
>
> > > Simon Marlow:
> > > > [Lazy I/O] is nice, but it introduces too many problems. What
> > > > happens to any I/O errors encountered by the lazy I/O?
> They have to
> > > > be discarded, which means you can't effectively use lazy I/O for
> > > > robust applications a
On Mon, Nov 25, 2002 at 11:22:56AM -0500, Dean Herington wrote:
> Is even the following example from the library report (section 11.8.2)
> problematic?
>
> import System
> import Char( toUpper )
>
> main = do
> [f1,f2] <- getArgs
> s <- readFile f1
> writeFile f2 (map t
Simon Marlow wrote:
> > Simon Marlow:
> > > [Lazy I/O] is nice, but it introduces too many problems. What
> > > happens to any I/O errors encountered by the lazy I/O? They have to
> > > be discarded, which means you can't effectively use lazy I/O for
> > > robust applications anyway.
> >
> > Sur
> Simon Marlow:
> > [Lazy I/O] is nice, but it introduces too many problems. What
> > happens to any I/O errors encountered by the lazy I/O? They have to
> > be discarded, which means you can't effectively use lazy I/O for
> > robust applications anyway.
>
> Surely they are thrown as exceptions
On Mon, Nov 25, 2002 at 10:09:01AM -, Simon Marlow wrote:
> It is nice, but it introduces too many problems. What happens to any
> I/O errors encountered by the lazy I/O? They have to be discarded,
> which means you can't effectively use lazy I/O for robust applications
> anyway.
*mumble*Exc
Simon Marlow:
> [Lazy I/O] is nice, but it introduces too many problems. What
> happens to any I/O errors encountered by the lazy I/O? They have to
> be discarded, which means you can't effectively use lazy I/O for
> robust applications anyway.
Surely they are thrown as exceptions which can the
> "Simon Marlow" <[EMAIL PROTECTED]> 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? :)
>
> Seriousl
"Simon Marlow" <[EMAIL PROTECTED]> 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
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-h
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
>
> > 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 ()
> >
> 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
> >
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 interacti
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
> 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,
> 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 wri
In local.glasgow-haskell-users, you wrote:
> Is there any way in GHC to reopen stdin if it has been closed?
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 currentl
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
19 matches
Mail list logo
