<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">> In particular, I'd avoid utf8rewind because the author believes that <br></div><div dir="ltr"><div dir="ltr">deviating from a standard improves security.<div><br></div><div>The length function is indeed problematic, so we roll our own, but the rest part of utf8rewind comply with Unicode 8.0 AFAICT, the code quality seems good too, but like you said, we're not going to commit to a specific UTF-8 implementation. As for now un8rewind seems a pretty good choice. </div><div><br></div><div>> You should split the library, into stuff that does fast byte shoving, </div>and into stuff that does fast byte processing.<br>That way, things can start to improve and evolve independently.<span class="m_-6501672096887689654gmail-im" style="color:rgb(80,0,80)"><br></span></div><div dir="ltr"><br></div><div>I just haven't got that much energy to do that, if we got lots of users some day, and people think spliting is better, then we can do that of course ; )</div><div><br></div><div>Cheers </div><div>Dong</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Feb 16, 2019 at 10:30 PM Joachim Durchholz <<a href="mailto:jo@durchholz.org" target="_blank">jo@durchholz.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Am 16.02.19 um 13:23 schrieb 寒东:<br>> Some unicode processing such as normalization and casefolding is also provide, based on a C unicode libraryutf8rewind  <<a href="https://bitbucket.org/knight666/utf8rewind" rel="noreferrer" target="_blank">https://bitbucket.org/knight666/utf8rewind</a>>.<br>
<br>FWIW the rest looks fine, but committing to a specific UTF-8 <br>implementation is risky. Unicode is a large and complicated standard, <br>and constantly evolving; I am sceptical that a one-man library like <br>utf8rewind can keep up with that, and I'd wrap a mature Unicode library <br>(such as ICU) rather than place my bet on a one-man show like utf8rewind.<br>
<br>In particular, I'd avoid utf8rewind because the author believes that <br>deviating from a standard improves security.<br>(See his comment in <br>
<a href="https://bitbucket.org/knight666/utf8rewind/issues/8/length-function-should-not-use-strlen" rel="noreferrer" target="_blank">https://bitbucket.org/knight666/utf8rewind/issues/8/length-function-should-not-use-strlen</a> <br>.)<br>I do not think that's a well-considered policy, and certainly does not <br>make me think that his code is well-audited. Including such a thing in <br>such a basic library as stdio seems unwise to me.<br>
<br>> To make our package more useful, we rebuild Builder and Parser type from groud, add TCP socket and filesystem support, so that user can start using it to do some simple task, such as parsing a CSV file or starting a TCP server and communicate in protocols. We also provide high performance timer and logger module, which is useful in practical engineering tasks.<br>
<br>You should split the library, into stuff that does fast byte shoving, <br>and into stuff that does fast byte processing.<br>That way, things can start to improve and evolve independently.<br>
<br>> For installation guide and examples, please see the project's README. As we (I and Tao He) both are not native english speakers, the document quality is not as satisfying as it can be, please help!<br>
<br>Judging from this message, your English seems pretty good actually :-)<br>
<br>Regards,<br>Jo<br>_______________________________________________<br>Haskell-Cafe mailing list<br>To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>Only members subscribed via the mailman list are allowed to post.</blockquote></div>
</div></div>