Fails to init websocket if compiled on Windows

[steveoc64]

From latest commit edfe1438a4184bea0b3f9e35fd77969061676d9c

If I gopherjs compile my app on Linux, the generated app.js works fine.

If I gophejs compile the identical code on Windows, the generated app.js fails whilst calling websocket.init

Both generated app.js files are different sizes (is that even right ???) 4,453,535 app.js (windows) 4,420,712 app.js (linux)

In both cases, I am running go1.6, and have removed github.com/gopherjs and then go get github.com/gopherjs go get github.com/gopherjs/websocket Before compiling, so it should be the same gopherjs compiler.

If I compile on Linux, and then scp the generated app.js to the offending Windows machine, and host it from there, it works as expected, (so its not a hosting issue)

Stack trace during a failure on the generated app.js from Windows :

Uncaught Error: system calls not available, see https://github.com/gopherjs/gopherjs/blob/master/doc/syscalls.md$callDeferred @ app.js:4$panic @ app.js:4$packages.syscall.AM.ptr.mustFind @ app.js:20$packages.syscall.AM.ptr.Addr @ app.js:20$packages.syscall.LX @ app.js:20$packages.net.ET @ app.js:71$packages.net.ES @ app.js:71$packages.net.$init @ app.js:71$packages.github.com/gopherjs/websocket.$init @ app.js:72$packages.main.$init @ app.js:107$goroutine @ app.js:4$schedule @ app.js:4$go @ app.js:4(anonymous function) @ app.js:111(anonymous function) @ app.js:114

The call at $packages.github.com/gopherjs/websocket.$init looks like it is referencing some code in zsyscall_windows.go, for whatever reason. Hopefully this explains the difference in file sizes of the generated app.js files (although that still looks a bit odd to me)

Its a bit hard to look any deeper than this on this Windows 10 machine that Im stuck on for the day. Its not my machine, and the tools on it are typically abysmal.

I cant be sure exactly when things broke, but I know that 2 weeks ago, I could compile on this Windows machine, and then host the result with no issues. Since then, the only change in the environment was this modification of gopherjs/websocket, from what I can see.

Hope that helps.

[steveoc64]

On closer examination, what I am seeing is identical to this issue reported in gopherjs :

https://github.com/gopherjs/gopherjs/issues/424

The code is failing on a call to probeWindowsIPStack, which only seems to occur when you import the "net" package.

This is only happening now, because the change to gopherjs/websocket now requires an import of the "net" package.

neelance suggests that the best fix for this is :

Okay, so this is a Windows specific issue. I think we can simply mock probeWindowsIPStack with an empty function, because there is no support for syscalls on Windows at all.

Will give that a go and report back

[dmitshur]

Yeah, this is gopherjs/gopherjs#424. Thanks for reporting and analyzing the problem. We should fix that problem in GopherJS.

[steveoc64]

Thanks D.

Turns out to be a trivial fix in the GopherJS compiler, and no action needed in this websocket package.

After having some fun digging through the compiler code :8ball: ...... I did this pull req as an excuse to document how the GopherJS compiler provides mocks and other custom functions to override library code.

https://github.com/gopherjs/gopherjs/pull/437

Very keen now to get much deeper into this codebase, looks like fun.

[dmitshur]

Nicely done, thanks!