These are chat archives for non/algebra

29th
Jul 2015
Erik Osheim
@non
Jul 29 2015 13:06
Hey folks, I want to release algebra-0.3.0 so we can have scala.js support
any objections?
@tixxit @johnynek ^^
@InTheNow from your POV algebra is ready for a scala.js release right?
(it looks ready to me.)
InTheNow
@InTheNow
Jul 29 2015 13:08
@non - LGTM
Erik Osheim
@non
Jul 29 2015 13:10
great. i'll wait a little bit for folks who are 3 hours behind to get a chance to weigh-in ;)
Erik Osheim
@non
Jul 29 2015 14:36
@InTheNow oh wait, i think algebra's tests may have found some bugs in scala.js
InTheNow
@InTheNow
Jul 29 2015 14:37
?
these laws passed in the JVM but failed in JS -- they are all Int-related
InTheNow
@InTheNow
Jul 29 2015 14:39
just looking.....
Erik Osheim
@non
Jul 29 2015 14:39
i'm going to take a closer look but just wanted to mention it in case you had ideas about what was going on.
InTheNow
@InTheNow
Jul 29 2015 14:42
I was actually running the algebra tests earlier with no problems
Erik Osheim
@non
Jul 29 2015 14:43
one of the tests is relatively simple: -2147483648 < 2147483647 and 2147483647 > -2147483648 should both be true
InTheNow
@InTheNow
Jul 29 2015 14:43
Are you running from master?
Erik Osheim
@non
Jul 29 2015 14:43
but it seems like the latter was false.
yes, i think i just merged it. i'll check again.
yup, this is master.
InTheNow
@InTheNow
Jul 29 2015 14:46
weird - works locally for me and on travis https://travis-ci.org/non/algebra/builds/72297765
Erik Osheim
@non
Jul 29 2015 14:47
is there an easy way for me to launch a JS-based REPL?
this is strange. i'll try writing an explicit test with those values and see if it works.
can you write a test that uses those values explicitly? it could be that other scalacheck runs did not hit that particular case.
InTheNow
@InTheNow
Jul 29 2015 14:48
thats posssible, yes
Erik Osheim
@non
Jul 29 2015 14:52
ok weird, it seems like my ad-hoc test with those values passes. hm.
i'm stepping through, now testing Order[Int]
Erik Osheim
@non
Jul 29 2015 14:59
ok i can reproduce on a simple test
@InTheNow try dropping this test file in and see what happens: https://gist.github.com/non/3dcc7a1bf86fea973a94
for me, "literal ops" and "compare-based ops" pass, and the others fail
in the first example, those constants are being inlined by the compiler (i think)
but in direct ops algebra is not being used, and the y > x comparison fails (although x < y succeeds)
and all the "compare" stuff succeeds, so it seems like that method is workign.
anyway this is very confusing. please let me know if you can reproduce (or not).
InTheNow
@InTheNow
Jul 29 2015 15:05
I was already doing something similar and it works fine, as do your tests
Erik Osheim
@non
Jul 29 2015 15:05
oh man. let me run clean and try again.
fortunately it sounds like something on my machine is just wonky.
InTheNow
@InTheNow
Jul 29 2015 15:07
Could be that the @drdozer macros have infected your build :wink2:
Erik Osheim
@non
Jul 29 2015 15:09
haha i hope not. well, after restarting SBT and cleaning the build, i'm still getting this error. ugh.
Erik Osheim
@non
Jul 29 2015 15:17
@tixxit hey, assuming i figure out the weirdness with this scala.js test, are you ok with me releasing algebra 0.3.0 ?
InTheNow
@InTheNow
Jul 29 2015 15:17
I've just git diff'ed my local code against master and It's identical (bar the new tests)
Erik Osheim
@non
Jul 29 2015 15:18
@InTheNow yeah same here. i'll try deleting scala.js from my ivy cache i guess
@InTheNow is there any way we can compare "js bytecode" or something similar to ensure we are running the same thing?
something i can send you a checksum of?
InTheNow
@InTheNow
Jul 29 2015 15:20
sure
laws/js/target/scala-2.11/algebra-laws-test-fastopt.js
Erik Osheim
@non
Jul 29 2015 15:23
my sha-256 of that file is: 23b12437f3bed4067a31988134f8e8e333c8dcf31e17bd1ee9c4f730531488d3
md5: 6176574c830c9779079ccbcde866f969
InTheNow
@InTheNow
Jul 29 2015 15:23
not mine
Erik Osheim
@non
Jul 29 2015 15:24
ok, great.
InTheNow
@InTheNow
Jul 29 2015 15:24
what size is it?
Erik Osheim
@non
Jul 29 2015 15:24
8152
InTheNow
@InTheNow
Jul 29 2015 15:24
4173272
Erik Osheim
@non
Jul 29 2015 15:25
ok so maybe i am not running that file somehow?
InTheNow
@InTheNow
Jul 29 2015 15:29
is rm -fr ~/.ivy2/ too dramatic?
Erik Osheim
@non
Jul 29 2015 15:29
@InTheNow oh, when i was compiling i was using test-only so maybe it wasn't packaging everything.
that's why my .js file was different.
i'm just running test now, i'll report back shortly
i would prefer not to nuke all of .ivy2 but i'll do it if necessary.
(nuking ivy reminds me of the bad old days with sbt and scala years ago.)
InTheNow
@InTheNow
Jul 29 2015 15:31
Yep, know that feeling alright ;)
Erik Osheim
@non
Jul 29 2015 16:08
i just ran package and also test, i still have the very small -fastopt.js file.
InTheNow
@InTheNow
Jul 29 2015 16:09
all very strange
Erik Osheim
@non
Jul 29 2015 16:09
@InTheNow if you run package, what sizes/checksums do you get for your jars?
InTheNow
@InTheNow
Jul 29 2015 16:10
test should be all you need - package is of no use for the test file
Erik Osheim
@non
Jul 29 2015 16:10
right, i am worrying about whether any jars i publish will have this issue.
a09c7627d09a0d9bec371a408b285dc9 ./core/.js/target/scala-2.11/algebra_sjs0.6_2.11-0.3.0-SNAPSHOT.jar
885ccd3afa7ec32e828d95b1cdd22783 ./laws/js/target/scala-2.11/algebra-laws_sjs0.6_2.11-0.3.0-SNAPSHOT.jar
689d9cb6ea1725b8f047981479f1f12c ./std/js/target/scala-2.11/algebra-std_sjs0.6_2.11-0.3.0-SNAPSHOT.jar
sizes are:
27976 ./core/.js/target/scala-2.11/algebra_sjs0.6_2.11-0.3.0-SNAPSHOT.jar
1072 ./laws/js/target/scala-2.11/algebra-laws_sjs0.6_2.11-0.3.0-SNAPSHOT.jar
2472 ./std/js/target/scala-2.11/algebra-std_sjs0.6_2.11-0.3.0-SNAPSHOT.jar
do those look reasonable?
InTheNow
@InTheNow
Jul 29 2015 16:12
ll core/.js/target/scala-2.11/algebra_sjs0.6_2.11-0.3.0-SNAPSHOT.jar -rw-r--r-- 1 alistair users 14349511
what do you have for the JVM ones?
-rw-r--r-- 1 alistair users 3158106 Jul 29 18:10 core/.jvm/target/scala-2.11/algebra_2.11-0.3.0-SNAPSHOT.jar
Erik Osheim
@non
Jul 29 2015 16:16
14323305 ./core/.js/target/scala-2.11/algebra_sjs0.6_2.11-0.3.0-SNAPSHOT.jar
545050 ./laws/js/target/scala-2.11/algebra-laws_sjs0.6_2.11-0.3.0-SNAPSHOT.jar
1263577 ./std/js/target/scala-2.11/algebra-std_sjs0.6_2.11-0.3.0-SNAPSHOT.jar
(those sizes are from ls -l)
so they are close but not identical!
InTheNow
@InTheNow
Jul 29 2015 16:17
547954 and 1265848
yep, but the sjs ones are whacky
Erik Osheim
@non
Jul 29 2015 16:18
3158109 ./core/.jvm/target/scala-2.11/algebra_2.11-0.3.0-SNAPSHOT.jar
353976 ./laws/jvm/target/scala-2.11/algebra-laws_2.11-0.3.0-SNAPSHOT.jar
341640 ./std/jvm/target/scala-2.11/algebra-std_2.11-0.3.0-SNAPSHOT.jar
(for the JVM jars)
InTheNow
@InTheNow
Jul 29 2015 16:18
what jvm version do you have?
Erik Osheim
@non
Jul 29 2015 16:19
java version "1.8.0_51"
Java(TM) SE Runtime Environment (build 1.8.0_51-b16)
Java HotSpot(TM) 64-Bit Server VM (build 25.51-b03, mixed mode)
InTheNow
@InTheNow
Jul 29 2015 16:19
java -version java version "1.7.0_67" Java(TM) SE Runtime Environment (build 1.7.0_67-b01) Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)
Erik Osheim
@non
Jul 29 2015 16:22
hm
wonder if it's java 7 vs 8 somehow?
InTheNow
@InTheNow
Jul 29 2015 16:22
just using 8 now
InTheNow
@InTheNow
Jul 29 2015 16:29
works fine - and I get much similar sizes to you on java 8
Erik Osheim
@non
Jul 29 2015 16:29
great
Erik Osheim
@non
Jul 29 2015 16:35
@InTheNow since this is still a pre-release, i am inclined to publish 0.3.0 even though i'm seeing these test issues. but if you want i can wait.
actually, nevermind. i should figure this out now before moving forward.
InTheNow
@InTheNow
Jul 29 2015 16:36
time for drastic action?
Erik Osheim
@non
Jul 29 2015 16:41
yeah i'm gonna move .ivy2
Erik Osheim
@non
Jul 29 2015 16:51
ok i am slowly rebuilding after blowing away .ivy2
@InTheNow dumb question -- what JS interpreter is actually running the tests?
could we have different versions of that somehow? is that a dep managed outside of SBT?
InTheNow
@InTheNow
Jul 29 2015 16:51
not a dumb Q - node.js
Erik Osheim
@non
Jul 29 2015 16:52
test is still failing after blowing away .ivy2
InTheNow
@InTheNow
Jul 29 2015 16:52
node --version v0.10.31
Erik Osheim
@non
Jul 29 2015 16:53
node --version
v0.10.26
could the node versions cause this?
InTheNow
@InTheNow
Jul 29 2015 16:53
possible
Erik Osheim
@non
Jul 29 2015 16:56
hm. well, i install node.js through homebrew on osx
so it might be a bit of work for me to update it to 0.10.31
InTheNow
@InTheNow
Jul 29 2015 16:57

another option is to comment out this line in build.sbt

//scalaJSStage in Test := FastOptStage

Erik Osheim
@non
Jul 29 2015 16:57
hm, i'll try that with my small test
InTheNow
@InTheNow
Jul 29 2015 16:57
then it will just use Rhino
Erik Osheim
@non
Jul 29 2015 16:58
haha ok all the tests pass then
so it is a fastoptstage bug
i'm going to go to lunch, and worry about this later ;)
thanks for your help.
InTheNow
@InTheNow
Jul 29 2015 16:58
or node...
np - en guete :)