Miko/LSL-PyOptimizer
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
8d4750b6d0decf4bdcaeb4dd835ddef84d934b5d
LSL-PyOptimizer/unit_tests/expr.suite/llord-char-hash.out

38 lines
369 B
Plaintext
Raw Normal View History

Add newly introduced functions llOrd, llChar, llHash
2021-05-08 18:57:09 +02:00
[ 0
, 0
, 46
, 46
, 0
, 0
, 240
Deal with changes in llChar, strengthen some tests Previously, llChar formed an UTF-8-1993 string with the given code and converted that, resulting in multiple question marks when the conversion to Unicode forced by Mono caused errors in multiple characters. They have changed the implementation and now it also considers U+FFFF invalid, and only returns one U+FFFD character if the input is invalid, and LSO behaves the same as Mono (no UTF-8-1993 anymore). We've also detected problems with Windows (who else would it be) for the Unicode "astral" planes (planes beyond the Basic Multilingual Plane), so now there are new tests that include characters > U+FFFF. And since some builds of Python 2 use UTF-16 internally, we also check llSubString and friends with positions after an astral plane character. This is currently failing under Windows, as there are numerous encoding and line ending problems happening on that OS, especially with Python 3.
2022-12-08 13:22:54 +01:00
, 119808
Add newly introduced functions llOrd, llChar, llHash
2021-05-08 18:57:09 +02:00
, 119070
, 119808
, 0
, 0
Deal with changes in llChar, strengthen some tests Previously, llChar formed an UTF-8-1993 string with the given code and converted that, resulting in multiple question marks when the conversion to Unicode forced by Mono caused errors in multiple characters. They have changed the implementation and now it also considers U+FFFF invalid, and only returns one U+FFFD character if the input is invalid, and LSO behaves the same as Mono (no UTF-8-1993 anymore). We've also detected problems with Windows (who else would it be) for the Unicode "astral" planes (planes beyond the Basic Multilingual Plane), so now there are new tests that include characters > U+FFFF. And since some builds of Python 2 use UTF-16 internally, we also check llSubString and friends with positions after an astral plane character. This is currently failing under Windows, as there are numerous encoding and line ending problems happening on that OS, especially with Python 3.
2022-12-08 13:22:54 +01:00
, 0
Add newly introduced functions llOrd, llChar, llHash
2021-05-08 18:57:09 +02:00
, 64982
, 65535
Deal with changes in llChar, strengthen some tests Previously, llChar formed an UTF-8-1993 string with the given code and converted that, resulting in multiple question marks when the conversion to Unicode forced by Mono caused errors in multiple characters. They have changed the implementation and now it also considers U+FFFF invalid, and only returns one U+FFFD character if the input is invalid, and LSO behaves the same as Mono (no UTF-8-1993 anymore). We've also detected problems with Windows (who else would it be) for the Unicode "astral" planes (planes beyond the Basic Multilingual Plane), so now there are new tests that include characters > U+FFFF. And since some builds of Python 2 use UTF-16 internally, we also check llSubString and friends with positions after an astral plane character. This is currently failing under Windows, as there are numerous encoding and line ending problems happening on that OS, especially with Python 3.
2022-12-08 13:22:54 +01:00
, "%EF%BF%BD"
, "%EF%BF%BD"
, "%EF%BF%BD"
Add newly introduced functions llOrd, llChar, llHash
2021-05-08 18:57:09 +02:00
, ""
, "%01"
, "%C2%A9"
, "%C5%8D"
, "%E2%80%90"
Deal with changes in llChar, strengthen some tests Previously, llChar formed an UTF-8-1993 string with the given code and converted that, resulting in multiple question marks when the conversion to Unicode forced by Mono caused errors in multiple characters. They have changed the implementation and now it also considers U+FFFF invalid, and only returns one U+FFFD character if the input is invalid, and LSO behaves the same as Mono (no UTF-8-1993 anymore). We've also detected problems with Windows (who else would it be) for the Unicode "astral" planes (planes beyond the Basic Multilingual Plane), so now there are new tests that include characters > U+FFFF. And since some builds of Python 2 use UTF-16 internally, we also check llSubString and friends with positions after an astral plane character. This is currently failing under Windows, as there are numerous encoding and line ending problems happening on that OS, especially with Python 3.
2022-12-08 13:22:54 +01:00
, "%EF%BF%BD"
, "%EF%BF%BD"
, "%EF%BF%BD"
, "%EF%BF%BD"
Add newly introduced functions llOrd, llChar, llHash
2021-05-08 18:57:09 +02:00
, "%F0%9F%98%80"
, "%F4%8F%BF%BF"
Deal with changes in llChar, strengthen some tests Previously, llChar formed an UTF-8-1993 string with the given code and converted that, resulting in multiple question marks when the conversion to Unicode forced by Mono caused errors in multiple characters. They have changed the implementation and now it also considers U+FFFF invalid, and only returns one U+FFFD character if the input is invalid, and LSO behaves the same as Mono (no UTF-8-1993 anymore). We've also detected problems with Windows (who else would it be) for the Unicode "astral" planes (planes beyond the Basic Multilingual Plane), so now there are new tests that include characters > U+FFFF. And since some builds of Python 2 use UTF-16 internally, we also check llSubString and friends with positions after an astral plane character. This is currently failing under Windows, as there are numerous encoding and line ending problems happening on that OS, especially with Python 3.
2022-12-08 13:22:54 +01:00
, "%EF%BF%BD"
, "%EF%BF%BD"
, "%EF%BF%BD"
, "%EF%BF%BD"
, "%EF%BF%BD"
Add newly introduced functions llOrd, llChar, llHash
2021-05-08 18:57:09 +02:00
, 1203819346
, 0
, 1172851538
]
Reference in New Issue Copy Permalink