'Encode' Extension Gives Different Result from Desktop Version

Question

'Encode' Extension Gives Different Result from Desktop Version

Closed this issue 3 years ago · 5 comments

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.

Answer 1 · 2022-03-09T23:05:46.000Z

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.

Answer 2 · 2022-03-09T23:19:19.000Z

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

Answer 3 · 2022-03-11T00:21:18.000Z

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.

Answer 4 · 2022-03-11T02:02:10.000Z

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?

Answer 5 · 2022-03-15T15:34:36.000Z

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