<div dir="auto">After more digging, I realised it's because Ur is converting all non-ASCII characters into Unicode escapes, when the test expects straight UTF-8.<div dir="auto">I made a small PR that attempts a UTF-8 conversion for all printable characters that don't need escaping (like < and &):</div><div dir="auto"><br></div><div dir="auto"><a href="https://github.com/urweb/urweb/pull/177">https://github.com/urweb/urweb/pull/177</a><br></div><div dir="auto"><br></div><div dir="auto">It now passes the Fortunes test and the others in that site, but I know very little about Unicode, Ur/Web and C, so your feedback on it would be most welcome!</div><div dir="auto"><br></div><div dir="auto">Oisín</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 11 Aug 2019, 17:52 Karn Kallio, <<a href="mailto:tierpluspluslists@skami.org">tierpluspluslists@skami.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> Hello! I used "git bisect" to find the commit that introduced<br>
> behaviour that causes Ur/Web to fail the Fortunes test in the<br>
> benchmarks. It's commit 5cc729b48aad084757a049b7e5cdbadae5e9e400 from<br>
> November 2018. Unfortunately that's a pretty big squashed commit from<br>
> a PR:<br>
> <a href="https://github.com/urweb/urweb/commit/5cc729b48aad084757a049b7e5cdbadae5e9e400" rel="noreferrer noreferrer" target="_blank">https://github.com/urweb/urweb/commit/5cc729b48aad084757a049b7e5cdbadae5e9e400</a><br>
> <br>
> It'd be great if someone could take a look and see why it strips UTF-8<br>
> output in that benchmark test. Note that the test runs in a Docker<br>
> container, so perhaps it's trying to infer a system-wide i18n setting?<br>
> <br>
> Once we fix this, we can update the benchmarks repo and solve the<br>
> sorry state of affairs with Ur/Web way down the performance rankings.<br>
> I'd love to see more people active in the community, and things like<br>
> this would help raise awareness of the project.<br>
> <br>
> Oisín<br>
> <br>
<br>
I suspect this has to do with the difference between LTR and RTL<br>
languages.  A given database, in the fortunes table, may have Arabic<br>
text stored "backwards", and without any markings such as U+200F<br>
RIGHT-TO-LEFT MARK and so the U8_NEXT macro is seeing a trailing byte<br>
of a UTF-8 encoded character and failing to loop.<br>
<br>
_______________________________________________<br>
Ur mailing list<br>
<a href="mailto:Ur@impredicative.com" target="_blank" rel="noreferrer">Ur@impredicative.com</a><br>
<a href="http://www.impredicative.com/cgi-bin/mailman/listinfo/ur" rel="noreferrer noreferrer" target="_blank">http://www.impredicative.com/cgi-bin/mailman/listinfo/ur</a><br>
</blockquote></div>