Plugin on Windows 8 will not compile script containing the degree symbol (work around herein)

[antipole2]

This simple script

print("Degree is º\n");
print("The degree symbol from code is ", String.fromCharCode(0xB0), "\n");

fails to compile on Windows 8, giving the error message

SyntaxError: source decode failed

If you comment out the first line, the second then compiles and prints

The degree symbol from code is °

The JavaScript engine on Windows cannot handle non-ASCII characters, including the degree symbol 0xD0. The plugin works around this by substituting an ASCII character 0x07 on all inputs and switching it back on all outputs.

This is not happening on Windows 8, presumably because WINDOWS is not defined in this build.

I have made a special build of v3.0.1 which does not use WINDOWS and does the substitution on all platforms. This special build works correctly on Windows 8.

Windows 8 users can obtain this special build from this link. Download javascript-3.0-msvc-wx32-10-tarball build e51c9da, import into the plugin and update the JavaScript plugin.

Thanks to @Erickalon for helping identify this and for doing numerous tests.

@Rasbats Can you advise on the way to a solution, please?

[Rasbats]

Should we be using #ifdef WXMSW Instead of #ifdef WINDOWS

Version 2.0 seems to use #ifdef WXMSW

ifdef WINDOWS may have been introduced during my testing.

[Rasbats]

No problem with the script on Windows 10.

[antipole2]

The Duktape engine is configured for Windows thus

#if defined(_WIN32) || defined(WIN32) || defined(_WIN64) || defined(WIN64) || \
    defined(__WIN32__) || defined(__TOS_WIN__) || defined(__WINDOWS__)
#define DUK_F_WINDOWS
#if defined(_WIN64) || defined(WIN64)
#define DUK_F_WIN64
#else
#define DUK_F_WIN32
#endif
#endif

So maybe we should use DUK_F_WINDOWS? After all, we are doing this for Duktape's benefit.

[Rasbats]

Let me test on a Windows 8 box. This may take time as I compile on Win 10 and then transfer the tarball by hand.

[antipole2]

No need, I have built using DUK_F_WINDOWS and it is in my alpha repo here. Build 76e6b90.

Test script

print("Degree is º\n");
degree = "º";
print("Code used for degree is 0x", degree.charCodeAt(0).toString(16), "\n");
print("The degree symbol from code is ", String.fromCharCode(0xB0), "\n");

On MacOS output is

Degree is ° Code used for degree is 0xb0 The degree symbol from code is °

confirming no substitution. On all Windows expect 0x07 in second line.

[antipole2]

@Erickalon can you give it a go on your OpenPlotter?

[Rasbats]

Windows 8 source decode failed (line 0)

[Erickalon]

The result on OpenPlotter is: Degree is ° Code used for degree is 0xb0 The degree symbol from code is ° result: undefined

Don't have you made a confusion between the previous results of our tests? The wrong result for degree symbol was given on the OpenPlotter Raspberry when configured with ISO-8859-1. I have not get this issue with Windows 8.

[Rasbats]

How about reverting duk_f_windows and changing from #ifdef WINDOWS to #ifdef WXMSW in functions.cpp?

[antipole2]

My thinking is that __duk_f_windows__ is the outcome of duktape's multiple tests for all the many Windows varieties and is how duktape decides it is Windows. And the problems with degree et al arise from that decision. So why not follow that decision for this?

[antipole2]

Sorry - only just spotted you had a fail @Rasbats. Will try _WXMSW_ as alternative. Stand by for another test build.

[antipole2]

Whoops - my bad. I was testing on __DUK_F_WINDOWS__ when it should have been DUK_F_WINDOWS Tried again. I am using DUK_F_WINDOWS when it is about the duktape difficulty with non-ASCII characaters and __WXMSW__ when it is about Windows machine issues like screen resolution and console park position.

Build bd44d77 this time.

@Erickalon I meant to ask you to test it on Windows 8

[Erickalon]

@antipole2 The result of your script on Windows 8 is: The degree symbol from code is ° result: undefined The degree symbol from code is °° result: undefined Degree is ° Code used for degree is 0x7 The degree symbol from code is ° result: undefined

[Rasbats]

My Windows 8: Degree is ° Code used for degree is 0x7 The degree symbol from code is ° result: undefined

[antipole2]

@Erickalon Only expecting three prints - perhaps you had detritus from other tests still in the pane. The last three lines

Degree is ° Code used for degree is 0x7 The degree symbol from code is °

are correct. Thank you.

[Erickalon]

Sorry, I forget to clean result pane before run.

[antipole2]

I assume this is OK with Windows 10 or whatever. So this is resolved? I propose to adopt this for next release and stick with the work-around until then. Any dissent?

[Rasbats]

Good on Windows 10. No dissent here.

[antipole2]

Work-around for JavaScript v3.0.1 Build e365187in the Alpha repository is the one for Windows 8 users to use if you have problems with the version in the catalogue. It works on all Windows variants tested.

1. Download the binary
2. Use OpenCPN Options->Plugins Import
3. Update using the button in the JavaScript plugin entry

[antipole2]

Plugin version 3.0.2 uses DUK_F_WINDOWS and works on all tried Windows platforms. This includes Windows 8, so no need for the special build.

Can we close this now?

[Rasbats]

@antipole2 : Yes please.