Hi Volker,
Volker Wysk [EMAIL PROTECTED] writes:
On Mit, 2002-03-20 at 07:00, Jens Petersen wrote:
Jens Petersen [EMAIL PROTECTED] writes:
The problem is that the child process doesn't
receive all the data which the parent sends. It's as
if hPutStr vonh txt sends the data
Hi
On 21 Mar 2002, Jens Petersen wrote:
Volker Wysk [EMAIL PROTECTED] writes:
POpen-1.0.0 contains the same bug which I made. It doesn't ensure that
the values which are needed after the call of forkProcess, before that
of executeFile, are fully evaluated. So, if they are read lazily from
I don't think mmap() provides exactly the right behaviour.
It lets you
specify that modifications made by the current process
aren't committed
to the file, but what we want is to snapshot the file so
that subsequent
modifications by *other* processes aren't seen by the local
On Mit, 2002-03-20 at 07:00, Jens Petersen wrote:
Jens Petersen [EMAIL PROTECTED] writes:
The problem is that the child process doesn't receive all the data which
the parent sends. It's as if hPutStr vonh txt sends the data lazily
somehow, and hClose vonh closes the pipe prematurely.
On Mon, 2002-03-18 at 18:30, Simon Marlow wrote:
The spec could perhaps *require* that it was a pure value,
so that the
file contents is snapshotted at the time of the hGetContents and you
always get the same result regardless of subsequent or
concurrent I/O
operations. This can
I've been following this discussion with some interest. It seems to
me on important underlying problem is being hinted at, but has never
been made explicit:
* When we fork(), we lose sharing. *Any* lazy computation which
passes to both children is going to penalize you, sometimes in very
* When we fork(), we lose sharing. *Any* lazy computation which
passes to both children is going to penalize you, sometimes in very
surprising ways.
I'm not sure I understand why loss of sharing is the problem - losing
sharing for pure computations is by no means a disaster, it just
Jens Petersen [EMAIL PROTECTED] writes:
The problem is that the child process doesn't receive all the data which
the parent sends. It's as if hPutStr vonh txt sends the data lazily
somehow, and hClose vonh closes the pipe prematurely.
It varies from run to run exactly which data gets
On Fre, 2002-03-15 at 15:05, Volker Stolz wrote:
Am 15. Mar 2002 um 14:39 MET schrieb Volker Wysk:
- If instead the child's child (echo.c) closes stdin
immediately after
being executed, some data is lost.
Where's the use in closing stdin when you're passing arguments as
Yes, it's a NOP (just to be sure). The difference is in child.hs:
callIO (\ps - Kommando fehlgeschlagen mit ++ show ps
++ :\n ++ kommando prog par)
(executeFile' prog True par Nothing)
-- instead, to avoid bug:
-- (hClose stdin executeFile' prog True
Am 18. Mar 2002 um 13:51 MET schrieb Simon Marlow:
unevaluated until the child process needs to construct its argument list
to pass to executeFile. Hence the child process pokes on the lazy
stream, and when the parent process subsequently demands data from the
lazy stream, there is a
In local.glasgow-haskell-bugs, you wrote:
I've stripped down my program to produce an example. In the process, the
problem disappeard a few times. I hope it shows up on your machine. The
attached files reproduce it on my machine, but the exact results vary
from run to run.
There's no bug in
In local.glasgow-haskell-bugs, you wrote:
I've stripped down my program to produce an example. In the
process, the
problem disappeard a few times. I hope it shows up on your
machine. The
attached files reproduce it on my machine, but the exact
results vary
from run to run.
Just to be sure, I've changed to example program a bit (see attachment).
I think it now demonstrates clearly that there must be a bug in the
libraries.
- If the child closes its child's stdin before calling executeFile, all
data gets through.
- If instead the child's child (echo.c) closes stdin
Am 15. Mar 2002 um 14:39 MET schrieb Volker Wysk:
- If instead the child's child (echo.c) closes stdin immediately after
being executed, some data is lost.
Where's the use in closing stdin when you're passing arguments as
parameters? This is effectively a NOP and shouldn't influence the
On Fre, 2002-03-15 at 15:05, Volker Stolz wrote:
Am 15. Mar 2002 um 14:39 MET schrieb Volker Wysk:
- If instead the child's child (echo.c) closes stdin immediately after
being executed, some data is lost.
Where's the use in closing stdin when you're passing arguments as
parameters? This
On Mon, 11 Mar 2002, Simon Marlow wrote:
There seems to be a bug in the IO libraries. I'm using the following
procedure to call an external program and send it data through a pipe.
Could you send us a complete example that we can run to reproduce the
problem?
I've stripped down my
Hello
There seems to be a bug in the IO libraries. I'm using the following
procedure to call an external program and send it data through a pipe.
pipeto :: String - String - [String] - IO ()
pipeto txt prog par = do
catch (do
-- create pipe
(zu, von) - createPipe
Volker Wysk [EMAIL PROTECTED] writes:
(zu, von) - createPipe
vonh - fdToHandle von
hSetBuffering vonh NoBuffering
mpid - forkProcess
case mpid of
Nothing - do -- child
-- connect pipe's read end to stdin
--
19 matches
Mail list logo