Re: [Haskell-cafe] Re: [Haskell] Re: ANNOUNCE: enumerator, an alternative iteratee package
On Mon, Aug 23, 2010 at 9:00 AM, Simon Marlow wrote: > I think it's the latter. bufRead loops until it has read the full amount of > data requested, or EOF is reached. Hmmm... sorry about the noise then =). Cheers, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: ANNOUNCE: enumerator, an alternative iteratee package
On 23/08/2010 12:57, Felipe Lessa wrote: On Mon, Aug 23, 2010 at 8:51 AM, Simon Marlow wrote: Hmm, RawIO.read looks ok: -- | Read up to the specified number of bytes, returning the number -- of bytes actually read. This function should only block if there -- is no data available. If there is not enough data available, -- then the function should just return the available data. A return -- value of zero indicates that the end of the data stream (e.g. end -- of file) has been reached. that seems pretty clear to me. No? It says that it "should only block if there is no data available". I assumed that fillReadBuffer has the same semantics. If both do not block if there is data, then hGetBuf would not wait for the buffer to be filled, if I am reading its source correctly [1]. Either they do block until the buffer is filled, or I'm misreading hGetBuf/bufRead. =) I think it's the latter. bufRead loops until it has read the full amount of data requested, or EOF is reached. Cheers, Simon [1] http://www.haskell.org/ghc/docs/6.12.2/html/libraries/base-4.2.0.1/src/GHC-IO-Handle-Text.html#line-820 Cheers! =) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: ANNOUNCE: enumerator, an alternative iteratee package
On Mon, Aug 23, 2010 at 8:51 AM, Simon Marlow wrote: > Hmm, RawIO.read looks ok: > > -- | Read up to the specified number of bytes, returning the number > -- of bytes actually read. This function should only block if there > -- is no data available. If there is not enough data available, > -- then the function should just return the available data. A return > -- value of zero indicates that the end of the data stream (e.g. end > -- of file) has been reached. > > that seems pretty clear to me. No? It says that it "should only block if there is no data available". I assumed that fillReadBuffer has the same semantics. If both do not block if there is data, then hGetBuf would not wait for the buffer to be filled, if I am reading its source correctly [1]. Either they do block until the buffer is filled, or I'm misreading hGetBuf/bufRead. =) [1] http://www.haskell.org/ghc/docs/6.12.2/html/libraries/base-4.2.0.1/src/GHC-IO-Handle-Text.html#line-820 Cheers! =) -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: ANNOUNCE: enumerator, an alternative iteratee package
On 23/08/2010 12:38, Felipe Lessa wrote: On Mon, Aug 23, 2010 at 8:29 AM, Simon Marlow wrote: Which documentation are you referring to? This looks ok to me: http://www.haskell.org/ghc/docs/6.12.2/html/libraries/base-4.2.0.1/System-IO.html#v%3AhGetBuf Indeed, while there isn't a big fat warning, it does say that it reads 'count' bytes. However, both RawIO.read and BufferedIO.fillReadBuffer are a bit misleading. The former says that it doesn't block when there isn't data available, the latter doesn't say anything. http://hackage.haskell.org/packages/archive/base/4.2.0.1/doc/html/src/GHC-IO-Device.html#RawIO http://hackage.haskell.org/packages/archive/base/4.2.0.1/doc/html/src/GHC-IO-BufferedIO.html#BufferedIO Hmm, RawIO.read looks ok: -- | Read up to the specified number of bytes, returning the number -- of bytes actually read. This function should only block if there -- is no data available. If there is not enough data available, -- then the function should just return the available data. A return -- value of zero indicates that the end of the data stream (e.g. end -- of file) has been reached. that seems pretty clear to me. No? I'll expand the documentation for fillReadBuffer. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: ANNOUNCE: enumerator, an alternative iteratee package
On Mon, Aug 23, 2010 at 8:29 AM, Simon Marlow wrote: > Which documentation are you referring to? This looks ok to me: > > http://www.haskell.org/ghc/docs/6.12.2/html/libraries/base-4.2.0.1/System-IO.html#v%3AhGetBuf Indeed, while there isn't a big fat warning, it does say that it reads 'count' bytes. However, both RawIO.read and BufferedIO.fillReadBuffer are a bit misleading. The former says that it doesn't block when there isn't data available, the latter doesn't say anything. http://hackage.haskell.org/packages/archive/base/4.2.0.1/doc/html/src/GHC-IO-Device.html#RawIO http://hackage.haskell.org/packages/archive/base/4.2.0.1/doc/html/src/GHC-IO-BufferedIO.html#BufferedIO Cheers! =) -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: ANNOUNCE: enumerator, an alternative iteratee package
On 23/08/2010 12:10, Felipe Lessa wrote: Hello, Simon! On Mon, Aug 23, 2010 at 8:00 AM, Simon Marlow wrote: The issue is that hGet always waits for a complete buffer-full of data before returning. The hWaitForInput/hGetNonBlocking combination fixes that problem, but you have to be careful to make sure that the Handle is in binary mode, otherwise hWaitForInput will not behave the way you expect (it will decode the input byte stream, and wait for a full character). For more information, see http://hackage.haskell.org/trac/ghc/ticket/3808 A better fix is to use hGetBufSome, but (a) it is only available in GHC 6.14 which isn't released yet, and (b) there isn't a bytestring wrapper for it yet. So there really is a problem in the documentation of hGetBuf. I assume it got fixed in HEAD together with hGetBufSome. Which documentation are you referring to? This looks ok to me: http://www.haskell.org/ghc/docs/6.12.2/html/libraries/base-4.2.0.1/System-IO.html#v%3AhGetBuf Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: ANNOUNCE: enumerator, an alternative iteratee package
Hello, Simon! On Mon, Aug 23, 2010 at 8:00 AM, Simon Marlow wrote: > The issue is that hGet always waits for a complete buffer-full of data > before returning. The hWaitForInput/hGetNonBlocking combination fixes that > problem, but you have to be careful to make sure that the Handle is in > binary mode, otherwise hWaitForInput will not behave the way you expect (it > will decode the input byte stream, and wait for a full character). For more > information, see > > http://hackage.haskell.org/trac/ghc/ticket/3808 > > A better fix is to use hGetBufSome, but (a) it is only available in GHC 6.14 > which isn't released yet, and (b) there isn't a bytestring wrapper for it > yet. So there really is a problem in the documentation of hGetBuf. I assume it got fixed in HEAD together with hGetBufSome. Cheers! =) -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Re: ANNOUNCE: enumerator, an alternative iteratee package
On 21/08/2010 04:30, John Millikin wrote: This also changes the binary enumHandle to use non-blocking IO, as recommended by Magnus Therning. I'm embarrassed to admit I still don't understand the improvement, exactly, but three people so far have told me it's a good idea. The issue is that hGet always waits for a complete buffer-full of data before returning. The hWaitForInput/hGetNonBlocking combination fixes that problem, but you have to be careful to make sure that the Handle is in binary mode, otherwise hWaitForInput will not behave the way you expect (it will decode the input byte stream, and wait for a full character). For more information, see http://hackage.haskell.org/trac/ghc/ticket/3808 A better fix is to use hGetBufSome, but (a) it is only available in GHC 6.14 which isn't released yet, and (b) there isn't a bytestring wrapper for it yet. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
