Repository : ssh://darcs.haskell.org//srv/darcs/packages/bytestring On branch : master
http://hackage.haskell.org/trac/ghc/changeset/3b432859b4062561fa9478e4a171b22c6c3f0915 >--------------------------------------------------------------- commit 3b432859b4062561fa9478e4a171b22c6c3f0915 Author: Duncan Coutts <[email protected]> Date: Tue May 17 13:54:50 2011 +0000 Remove some old done TODO items >--------------------------------------------------------------- TODO | 15 --------------- 1 files changed, 0 insertions(+), 15 deletions(-) diff --git a/TODO b/TODO index 99a053e..d7116a2 100644 --- a/TODO +++ b/TODO @@ -28,21 +28,6 @@ Todo items * unchunk, Data.ByteString.Lazy -> [Data.ByteString] - and that'd work for any Lazy.ByteString, not just hGetContents >>= lines -* consider if lazy hGetContents should use non-blocking reads. This should - allow messaging style applications (eg communication over pipes, sockets) - to use lazy ByteStrings. I think that at the moment since we demand 64k - it'd just block. With a messaging style app you've got to be careful not - to demand more data than is available, hence using non-blocking read - should do the right thing. And in the disk file case it doesn't change - anything anyway, you can always get a full chunk. - -* think about lazy hGetContents and IO exceptions - -* consider dropping map' as ghc-6.5 optimises map much better so there's now - little difference between them (15% rather than 40%) and with the new fusion - system we may be able to get even closer. Look at the benchmarks for filter' - to see if we can do the same there. - * It might be nice to have a trim MutableByteArray primitive that can release the tail of an array back to the GC. This would save copying in cases where we choose to realloc to save space. This combined with GC-movable strings _______________________________________________ Cvs-libraries mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-libraries
