Integrate UTF-8 hPutStr to standard hPutStr#589
Conversation
Lysxia
left a comment
Lysxia
left a comment
There was a problem hiding this comment.
Inspecting the textEncodingName of TextEncoding like you did seems like the right way.
BebeSparkelSparkel
force-pushed
the
directly-write-utf8
branch
from
47987f8 to
603dffc
Compare
Lysxia
force-pushed
the
directly-write-utf8
branch
from
2a5714e to
e1068f1
Compare
|
I merged with master (adapting to changes from #600 which moved the logic of |
|
@Lysxia shall we drop GHC 8.2 CI job? |
| -- | Write a string to a handle, followed by a newline. | ||
| hPutStrLn :: Handle -> Text -> IO () | ||
| hPutStrLn h t = hPutStreamOrUtf8 h (streamLn t) (Just putUtf8) | ||
| where putUtf8 = hPutBuilder h (encodeUtf8Builder t <> charUtf8 '\n') |
There was a problem hiding this comment.
Why not B.hPutStrLn h (encodeUtf8 t)?
There was a problem hiding this comment.
It would have to be B.hPutStrLn h (encodeUtf8 (t <> '\n')). I couldn't find another way to append the '\n' at the end in constant time. Open to suggestions.
There was a problem hiding this comment.
I'd expect B.hPutStrLn to append '\n' on its own, am I missing something?
There was a problem hiding this comment.
Oh I didn't see your Ln. There is no B.hPutStrLn... right?
There was a problem hiding this comment.
hPutStrLn :: Handle -> ByteString -> IO ()
hPutStrLn h ps = hPut h ps >> hPut h (L.singleton 0x0a)There was a problem hiding this comment.
I do not like the B.hPutStrLn implementation since it breaks the atomic printing that was just implemented for strict hPustStrLn in #600
There was a problem hiding this comment.
I'd say that non-100%-atomicity of B.hPutStrLn is for bytestring to resolve, not for us. But does hPutBuilder guarantee atomic printing?
There was a problem hiding this comment.
B.hPutBuilder does if it can fit in the buffer.
There was a problem hiding this comment.
I reopened haskell/bytestring#200 and added a comment.
|
Thanks a ton! |
Lysxia
changed the title
hPutStr to standard hPutStr
3 participants
Data.Text.IO.Utf8.hPutStrwas implemented in #503 and has much better performance thanData.Text.IO.hPutStrwhen the encoding is"UTF-8"and the neline isLF, so I added it.Question: Is there a faster way to check for the encoding without checking for string equality?