RE: hGetBuf (or something related) broken for 6.2 with sockets
> ... I've attached a working version which you can use instead of > System.IO.hGetBuf ... But that version had a bug in it too (sigh). Here's another attempt... Cheers, Simon HGetBuf.hs Description: HGetBuf.hs ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: hGetBuf (or something related) broken for 6.2 with sockets
> The problem with downloading things direct from CVS is that I > don't expect people > to run substantial tests before checking things into CVS. > (We don't on our CVS > server.) Of course I don't expect a snapshot release to have > the same reliability > as a real release, but at least snapshot releases seem to > compile and succeed in compiling themselves. Well, you can always check the build reports from the nightly builds at http://haskell.org/pipermail/cvs-ghc/ and then check out the sources from CVS on a likely-looking date using 'cvs co -r ghc-6-2-branch -D'. > Anyway Simon, is there a workaround to the sockets problem I > posted or not? hGetBuf is buggy in 6.2, thanks for bringing it to our attention. I've attached a working version which you can use instead of System.IO.hGetBuf, please let me know if this helps, so we can make sure that 6.2.1 gets it right. Incedentally, hGetBufNonBlocking isn't right either. Cheers, Simon HGetBuf.hs Description: HGetBuf.hs ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: hGetBuf (or something related) broken for 6.2 with sockets
Simon Marlow wrote (snipped): BTW George: there are plenty of 6.1.xxx snapshots available - these are the 6.2 prereleases. There are, but no recent ones. What I would like to have had is a 6.2-epsilon version, not 6.1 and a bit. We don't snapshot along the STABLE branch at the moment; no real deep reason, we'd just have to figure out a version numbering scheme, and this might upset various scripts that expect to parse the GHC version number. Since you have to build from source anyway, why not download the sources from CVS? The problem with downloading things direct from CVS is that I don't expect people to run substantial tests before checking things into CVS. (We don't on our CVS server.) Of course I don't expect a snapshot release to have the same reliability as a real release, but at least snapshot releases seem to compile and succeed in compiling themselves. Anyway Simon, is there a workaround to the sockets problem I posted or not? ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: hGetBuf (or something related) broken for 6.2 with sockets
> On Fri, Dec 19, 2003 at 11:39:28AM +0100, Tomasz Zielonka wrote: > > > > Well, I think that it would be better if hGetBuf didn't block if all > > requested data was already in buffer, but I don't insist on > it. However > > this change of semantics can brake existing programs. > > I am mixing things again: > > The change of hGetBuf's semantics happened between GHC 6.0 and 6.2. > I thinks the semantics in 6.0 is more intuitive. > > Now we have hGetBufNonBlocking with the old semantics of hGetBuf. > Wouldn't it be better to have hGetBuf with old semantics and > hGetBufBlocking with the new one? This way we wouldn't break existing > programs. hGetBuf isn't supposed to have different semantics, although its implementation changed considerably to optimise the case for small reads. It's possible I made a mistake, I'm looking into it right now. BTW George: there are plenty of 6.1.xxx snapshots available - these are the 6.2 prereleases. We don't snapshot along the STABLE branch at the moment; no real deep reason, we'd just have to figure out a version numbering scheme, and this might upset various scripts that expect to parse the GHC version number. Since you have to build from source anyway, why not download the sources from CVS? Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: hGetBuf (or something related) broken for 6.2 with sockets
On Fri, Dec 19, 2003 at 11:39:28AM +0100, Tomasz Zielonka wrote: > > Well, I think that it would be better if hGetBuf didn't block if all > requested data was already in buffer, but I don't insist on it. However > this change of semantics can brake existing programs. I am mixing things again: The change of hGetBuf's semantics happened between GHC 6.0 and 6.2. I thinks the semantics in 6.0 is more intuitive. Now we have hGetBufNonBlocking with the old semantics of hGetBuf. Wouldn't it be better to have hGetBuf with old semantics and hGetBufBlocking with the new one? This way we wouldn't break existing programs. Best regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: hGetBuf (or something related) broken for 6.2 with sockets
On Fri, Dec 19, 2003 at 10:26:02AM -, Simon Marlow wrote: > > > On Thu, Dec 18, 2003 at 09:53:50PM +0100, Tomasz Zielonka wrote: > > > On Thu, Dec 18, 2003 at 07:44:58PM +0100, George Russell wrote: > > > > > > It seems to work when I change hGetBuf to > > hGetBufNonBlocking. The name > > > is a bit misleading - the action _does_ wait for some data, > > but it doesn't > > > wait for all requested bytes. > > > > I've made a mistake here. > > > > hGetBuf waits for filling the whole Handle's reading buffer > > (or reaching > > EOF), even if the buffer contains enough data to satisfy the request. > > I'm a bit lost. Do things work as you expect, or not? Well, I think that it would be better if hGetBuf didn't block if all requested data was already in buffer, but I don't insist on it. However this change of semantics can brake existing programs. In my programs I rather use Data.Array.IO.hGetArray. I was only trying to help George. I am sorry if I only made things more complicated :) > Cheers, > Simon Best regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: hGetBuf (or something related) broken for 6.2 with sockets
> On Thu, Dec 18, 2003 at 09:53:50PM +0100, Tomasz Zielonka wrote: > > On Thu, Dec 18, 2003 at 07:44:58PM +0100, George Russell wrote: > > > > It seems to work when I change hGetBuf to > hGetBufNonBlocking. The name > > is a bit misleading - the action _does_ wait for some data, > but it doesn't > > wait for all requested bytes. > > I've made a mistake here. > > hGetBuf waits for filling the whole Handle's reading buffer > (or reaching > EOF), even if the buffer contains enough data to satisfy the request. I'm a bit lost. Do things work as you expect, or not? Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: hGetBuf (or something related) broken for 6.2 with sockets
On Thu, Dec 18, 2003 at 09:53:50PM +0100, Tomasz Zielonka wrote: > On Thu, Dec 18, 2003 at 07:44:58PM +0100, George Russell wrote: > > It seems to work when I change hGetBuf to hGetBufNonBlocking. The name > is a bit misleading - the action _does_ wait for some data, but it doesn't > wait for all requested bytes. I've made a mistake here. hGetBuf waits for filling the whole Handle's reading buffer (or reaching EOF), even if the buffer contains enough data to satisfy the request. Best regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: hGetBuf (or something related) broken for 6.2 with sockets
On Thu, Dec 18, 2003 at 07:44:58PM +0100, George Russell wrote: > > (b) The server module only gets part of the data. In fact for me it comes > to a stop > with > [239][240][241][242][243Iterating > despite there being more data to come. (And despite the fact that the > client has > done hFlush). > > I don't know any way of working around (b), so I suspect that means > ghc6.2 is unusable for us. What a pity no development snapshot was > made for 6.2 shortly before its release, as it might have been > possible for me to discover this bug in time for it to be fixed in > 6.2.(I did try to test the 6.3 development snapshot but was > grounded by the instances bug I've reported elsewhere.) It seems to work when I change hGetBuf to hGetBufNonBlocking. The name is a bit misleading - the action _does_ wait for some data, but it doesn't wait for all requested bytes. Best regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
