'Encode' Extension Gives Different Result from Desktop Version

[TheBizzle]

@CIVITAS-John writes:

Try the following example:

show encode:string-to-bytes "„"

In NLW, it responds [ 8222 ]; in desktop, it responds [-30 -128 -98].

It is clear that the implementation of the NLW extension is different from that of desktop. It returns UTF-16 representation and does not consider more complex situations.

[CIVITAS-John]

Hi,

This fix is problematic: UInt8Array supports 0-255, while in NetLogo, we commonly use -127-128. So, for example, if we do this:

encode:bytes-to-string encode:string-to-bytes "测试"

The bug persists, only in a different form.

[CIVITAS-John]

Please reopen the issue since it seems not completely fixed at this moment.

[TheBizzle]

When testing headlessly with the latest version of Tortoise, running encode:bytes-to-string (encode:string-to-bytes x) will return the value of x, when using either "„" or "测试" for x.

So the fix simply hasn't been deployed to netlogoweb.org yet.

[CIVITAS-John]

Did you try the output of encode:string-to-bytes "测试"?

The underlying implementation, Array.from(Encoder.encode("测试")), would result in [230, 181, 139, 232, 175, 149].

I did not see where we transform the unsigned byte array to the signed form. So... I don't see why you would get the correct result. P.S. could you tell me how to test Tortoise (with probably a command center) in headless mode?

[CIVITAS-John]

Hi @TheBizzle Any update on this? Or we could wait until it gets online and test..

Maybe I need to set up an instance of local Galapagos soon :D