Jonathan Cast wrote:
On 31 Jan 2008, at 1:23 AM, Reinier Lamers wrote:
Bayley, Alistair wrote:
More than one person has posted previously about the flaws and traps
of lazy IO. A common position seems to be don't do lazy IO.
Still, when I was browsing the Haskell' wiki a few days ago, I
Bayley, Alistair wrote:
More than one person has posted previously about the flaws and traps of lazy IO. A common
position seems to be don't do lazy IO.
Still, when I was browsing the Haskell' wiki a few days ago, I couldn't
find any proposal to remove lazy I/O or move it into some special
Wasn't there a Linux file system (possibly a FUSE user-space one) that
worked on writable CDs? IIRC it worked by marking the previous copy of
the file as erased, and writing a new copy.
On Wed, 2008-01-30 at 23:05 -0500, [EMAIL PROTECTED]
wrote:
PS: I would love to see an immutable filesystem
On Jan 31, 2008 5:07 AM, Gary Bickford [EMAIL PROTECTED] wrote:
Wasn't there a Linux file system (possibly a FUSE user-space one) that
worked on writable CDs? IIRC it worked by marking the previous copy of
the file as erased, and writing a new copy.
Probably you're thinking of layering a
On 31 Jan 2008, at 1:23 AM, Reinier Lamers wrote:
Bayley, Alistair wrote:
More than one person has posted previously about the flaws and
traps of lazy IO. A common position seems to be don't do lazy IO.
Still, when I was browsing the Haskell' wiki a few days ago, I
couldn't find any
On Wednesday 30 January 2008 13:03:27 you wrote:
Just don't use hGetContents in any serious code, or any program longer
than 4 lines.
What else do you suggest? I just want to read something out of the socket
without knowing it's length beforehand (my example here used ordinary
Strings, but
Your bug here is hGetContents.
Don't use it.
Lazy IO gremlins bite once again.
Your client is waiting for the server to close the socket before it
prints anything. But your server is waiting for the client to close the
socket before *it* prints anything.
Just don't use hGetContents in any
Timo B. Hübel wrote:
On Wednesday 30 January 2008 13:03:27 you wrote:
Just don't use hGetContents in any serious code, or any program longer
than 4 lines.
What else do you suggest? I just want to read something out of the socket
without knowing it's length beforehand (my example here
Timo B. Hübel wrote:
On Wednesday 30 January 2008 13:32:42 you wrote:
Timo B. Hübel wrote:
On Wednesday 30 January 2008 13:03:27 you wrote:
Just don't use hGetContents in any serious code, or any program longer
than 4 lines.
What else do you suggest? I just want to read something out of the
On Wednesday 30 January 2008 13:32:42 you wrote:
Timo B. Hübel wrote:
On Wednesday 30 January 2008 13:03:27 you wrote:
Just don't use hGetContents in any serious code, or any program longer
than 4 lines.
What else do you suggest? I just want to read something out of the socket
without
Timo B. Hübel wrote:
On Wednesday 30 January 2008 13:51:58 you wrote:
Okay, but then I have to make sure that my strings won't contain any
newline characters, right? If this is the case, another question raises
up: I am using Data.Binary to do the serialization of my data structures
to
On Wednesday 30 January 2008 14:09:31 you wrote:
This sounds good, but don't I throw away all (possible) performance gains
of transmitting ByteStrings directly when using show/read to convert them
to ordinary strings and back?
Probably not all of them, but some of them, definitely.
If
To: Timo B. Hübel
Cc: haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] Simple network client
Your bug here is hGetContents.
Don't use it.
Lazy IO gremlins bite once again.
Your client is waiting for the server to close the socket before it
prints anything. But your server
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Peter
Verswyvelen
As a newbie I made a nice little program that called readFile
and writeFile on the same filename, but of course the file
handle of the readFile was not closed yet = access denied. A
nice case of getting
Peter Verswyvelen wrote:
Then I tried the seq hack to force the handle opened by readFile to be
closed, but that did not seem to work either. For example, the following
still gave access denied:
main = do
cs - readFile L:/Foo.txt
writeFile L:/Foo.txt $ seq (length cs) cs
This is
On Jan 30, 2008 4:32 AM, Jules Bean [EMAIL PROTECTED] wrote:
The third, but more sophisticated answer is to use non-blocking IO, read
'only what is available', decide if it's enough to process, if not
store it in some local buffer until next time. This is much more work
and easy to implement
On Jan 30, 2008 8:31 AM, Bryan O'Sullivan [EMAIL PROTECTED] wrote:
Peter Verswyvelen wrote:
Then I tried the seq hack to force the handle opened by readFile to be
closed, but that did not seem to work either. For example, the following
still gave access denied:
main = do
cs -
Judah Jacobson wrote:
On Jan 30, 2008 8:31 AM, Bryan O'Sullivan [EMAIL PROTECTED] wrote:
Peter Verswyvelen wrote:
Then I tried the seq hack to force the handle opened by readFile to be
closed, but that did not seem to work either. For example, the following still gave
access denied:
main =
One rather funky but effective solution might be to use the tftp
protocol. No security, but simple, flexible and efficient. I think
there are C libraries that implement it. This would take care of
handshaking binary data. I have no idea if anyone has ever used it in
Haskell.
GB
On Wed,
Adam Langley wrote:
Also, if you want the above approach (read a bit, see if it's enough),
see IncrementalGet in the binary-strict package which is a Get with a
continuation monad that stops when it runs out of bytes and returns a
continuation that you can give more data to in the future.
On Jan 30, 2008 12:04 PM, Bryan O'Sullivan [EMAIL PROTECTED] wrote:
Adam Langley wrote:
I'd have expected it to look more like this:
data Result a = Failed String
| Finished B.ByteString a
| Partial (B.ByteString - Result a)
(The change here is from a list to a
Adam Langley wrote:
On Jan 30, 2008 1:07 PM, Adam Langley [EMAIL PROTECTED] wrote:
So, if I don't hear otherwise soon, I'll probably push a new version
of binary-strict later on today with the interface above.
It's in the darcs now, http://darcs.imperialviolet.org/binary-strict
Thanks!
And even better is
main = do
cs - strictReadFile L:/Foo.txt
writeFile L:/Foo.txt cs
Yes. By making these mistakes I understand the problem very well now. But it
*is* hard to see if the function in question is strict or lazy.
For example, the problem to me appears to be that this
On Jan 30, 2008 1:07 PM, Adam Langley [EMAIL PROTECTED] wrote:
So, if I don't hear otherwise soon, I'll probably push a new version
of binary-strict later on today with the interface above.
It's in the darcs now, http://darcs.imperialviolet.org/binary-strict
AGL
--
Adam Langley
Peter Verswyvelen wrote:
main = do
cs - getLine
putStrLn (Hello ++cs)
looks so much like
main = do
cs - readFile foo
writeFile foo cs
but in the first one cs is strict, while the second it is lazy... But that's
not obvious.
Now I'm confused (which happens
Dan Weston wrote:
Now I'm confused (which happens quite a lot, I'm afraid!)
Prelude readFile undefined
*** Exception: Prelude.undefined
Prelude readFile undefined = \cs - putStrLn Hello
*** Exception: Prelude.undefined
It seems that readFile is strict in its argument. As for getLine, it has
PS: I would love to see an immutable filesystem that does not allow writing
to files, it only creates new files and garbage collects files that have no
incoming reference anymore... Just like a garbage collected heap, and a bit
like an OLAP databases (as far as I remember my DB theory...)
Hi
Timo B. Hübel wrote:
Hello,
I am using the very simple interactTCP example from [1] to play around with
Haskell network programming but I just can't get a simple client for that
example to work (it works like a charm with my telnet client, as described in
the article).
This is
On Tuesday 29 January 2008 14:44:42 Mads Lindstrøm wrote:
If you replace the `putStrLn (show res)` with this:
mapM_ (\x - putStr (show x) hFlush stdout) res
it works.
Hm, unfortunately not for me (Linux, GHC 6.8.2) ...
I _think_ the problem is that `putStrLn (show res)` will wait until
On Tuesday 29 January 2008 17:12:19 you wrote:
There was a similar bug in lazy bytestring's hGetContents a while back
which involve it waiting for a whole chunk and not returning short
reads, but from watching the strace of this code, GHC is reading
byte-by-byte (which is actually pretty dumb,
On Jan 29, 2008 6:28 AM, Timo B. Hübel [EMAIL PROTECTED] wrote:
Hm, unfortunately not for me (Linux, GHC 6.8.2) ...
That's odd, because it works for me on the exact same setup.
There was a similar bug in lazy bytestring's hGetContents a while back
which involve it waiting for a whole chunk and
31 matches
Mail list logo
