Enable Development on Windows about weblas HOT 4 OPEN

This would be great. Before issuing PRs it would be nice to know if we're not breaking things. Being not too familiar with any unit testing system, currently doing some archaic testing which is prone to skip offending scenarios. I noticed errors when first building weblas intent on developing for it. Not wishing to deviate myself too much from actual feature improvement, is there any help on this side of things you need (i'm on windows). Some notes:

npm run build requires npm install glslify,npm install async and npm install arrayloader

npm run data runs without issues after installing python

but i'm unable to simply run npm run test even after modules tape and floader are installed

it appears browserify it is not liking those multiple entry points and testling is having windows issues interpreting $npm_config_browser env var, to circumvent the issues i ultimately created a file
test_win.cmd

cmd /c "browserify test/sgemm.js | testling -x "C:\Program\ Files\Mozilla\ Firefox\firefox.exe""

which properly informs the path to firefox in my windows install (note the escaped spaces). The test is now run and the browser launched (sgemm tests passed btw). Maybe there is a simpler way to get this working more smoothly. Yet this is still cumbersome since i don't see a way to crunch all the test/*.js in one go (aside of recalling old dos command magic).

npm run min appears to be ok and do its job in spite of minifyify complaining that my browserify should be >= 5 and npm install browserify only got me to 3.6.0.

npm run benchmark results on Win10/Firefox 46.0.1/HD 7950:

TAP version 13
ok 1 sgemm: 128x128 . 128x128
# 2.106 GFlops/sec  ±45.04%  n = 45 µ = 2ms
ok 2 sgemm: 128x256 . 256x128
# 2.796 GFlops/sec  ±51.74%  n = 44 µ = 3ms
ok 3 sgemm: 256x256 . 256x256
# 7.034 GFlops/sec  ±38.78%  n = 39 µ = 5ms
ok 4 sgemm: 512x256 . 256x512
# 10.017 GFlops/sec  ±78.23%  n = 13 µ = 13ms
ok 5 sgemm: 256x512 . 512x256
# 5.870 GFlops/sec  ±70.33%  n = 25 µ = 11ms
ok 6 sgemm: 512x512 . 512x512
# 9.585 GFlops/sec  ±74.17%  n = 21 µ = 28ms
ok 7 sgemm: 513x513 . 513x513
# 2.979 GFlops/sec  ±52.73%  n = 24 µ = 91ms
ok 8 sgemm: 1024x512 . 512x1024
# 12.581 GFlops/sec  ±67.70%  n = 18 µ = 85ms
ok 9 sgemm: 512x1024 . 1024x512
# 11.198 GFlops/sec  ±74.85%  n = 21 µ = 48ms
ok 10 sgemm: 1024x1024 . 1024x1024
# 21.048 GFlops/sec  ±86.45%  n = 18 µ = 102ms
ok 11 sgemm: 2048x2048 . 2048x2048
# 84.676 GFlops/sec  ±1.23%  n = 9 µ = 203ms

1..11
# tests 11
# pass  11

# ok

required npm install benchmark and the same strategy applied to test as above, also complained about browserify version ! >=5 (but actual version is 13.0.1)

from weblas.

well it got weirder when i tried to get chrome working for testing.

First of all, when npm was supposedly reporting browserify version, it was actualy reporting it's own version: npm -v browserify merely ignores the module argument, i had to npm view browserify version to get an actual browserify version. Second, the version reported is 13.0.1, ie. above the required >= 5, maybe this is the reason it complains but works ok in any case? (I edited out this misdirection from above post)

Third there was no escaping character, quotes or double quotes to get testling to launch chrome.exe given an absolute path. I ultimately added the chrome root path to my user environment variables and use
cmd /c "browserify test/sgemm.js | testling -x chrome.exe". (from inside a .cmd file it does not work from the package.json)
If you're wondering about the cmd /c ... which i employed previously, it is so that the command string is fully interpreted otherwise it breaks at inadvertent places.

windows must be an afterthought as far as npm/node is concerned.

from weblas.

I'll boot into Windows (on Linux right now) later today and take a look at this. Glad to have someone trying to improve the experience on Windows.

from weblas.

Additional info:
I was able to suppress the npm warnings by instaling browserify locally (as opposed to globally) its version is now correctly reported. This appears to be an issue with npm >3 and is claimed to be intentional.

from weblas.