lizmat hoelzro [Coke] : what is the issue with github.com/rakudo/rakudo/commit/949a7c7 exactly ? 03:06
hoelzro lizmat: I don't think it's that commit 03:08
lizmat ah, then what is the issue ?
hoelzro git bisect points to e2f1fa7 as the culprit
lizmat m: say Inf.Int ?
camelia rakudo-moar c59e4d: OUTPUT«===SORRY!=== Error while compiling /tmp/najt2FFAyS␤Confused␤at /tmp/najt2FFAyS:1␤------> say Inf.Int⏏ ?␤ expecting any of:␤ infix␤ infix stopper␤ postfix␤ statement end␤ statement modif…»
lizmat m: say Inf.Int
camelia rakudo-moar c59e4d: OUTPUT«Cannot coerce Inf to an Int␤ in block <unit> at /tmp/FiH9DU3sWE line 1␤␤Actually thrown at:␤ in block <unit> at /tmp/FiH9DU3sWE line 1␤␤»
lizmat m: say Inf.Rat 03:09
camelia rakudo-moar c59e4d: OUTPUT«Cannot coerce Inf to a Rat␤ in block <unit> at /tmp/3qubssiryh line 1␤␤Actually thrown at:␤ in block <unit> at /tmp/3qubssiryh line 1␤␤»
hoelzro Inf.Rat, iirc
6.c-errata has a failure around that
lizmat well, the question was really, should it fail or not 03:12
before my change, Inf.Int failed, and Inf.Rat did not
there are todoed tests for Inf.Int expecting to fail 03:13
*not
and there are tests for Inf.Rat expecting to not fail
so, either we make Inf.Int *and* Inf.Rat *not* fail 03:14
or we make them both fail
hoelzro so you're saying we should modify 6.c-errata?
lizmat well, not until we decided what the behaviour should be
the behaviour between Inf.Int and Inf.Rat was inconsistent
hoelzro right
lizmat I made it consistent, but maybe the wrong way
I don't think jnthn has any strong feelings about it either way 03:15
wonder what TimToady's thoughts on it are
fwiw, I expect a coercer to return a value of the type being coerced to
hoelzro that makes sense 03:16
lizmat since Inf is not an Int, or a Rat, returning Inf seems wrong
hoelzro I don't object to the idea behind the change - I just want a clean test for the release
lizmat indeed...
now, barring any last minute intervention from TimToady or jnthn
I suggest we fix the tests to expect a failure 03:17
hoelzro I'm inclined to say revert for now - at least then the behavior is consistent with 2016.04, if inconsistent in other ways
lizmat fine by me :-) 03:18
at least I tried :-)
hoelzro it's a good idea! I think we'll just have to figure out the right thing to do for 2016.06
thank you for your input
lizmat yw
dalek p: 8abff19 | hoelzro++ | tools/build/MOAR_REVISION:
Bump required MoarVM version for release
 05:42
p: ac50b73 | hoelzro++ | VERSION:
Bump our version for release
p: 61b3f00 | hoelzro++ | t/ (2 files):
Mark new failing JVM tests as TODO

Pawel introduced some new tests for the JS backend, which is a great way to kick the tires on the *other* backends, such as the JVM. Unfortunately, the functionality tested isn't ready yet for ca37f08 | hoelzro++ | docs/release_guide.pod: Add myself to people to bug about tarball uploads
kudo/nom: f3f7d8a | hoelzro++ | docs/release_guide.pod:
Update release guide regarding code names
 05:53
kudo/nom: c7f3c08 | hoelzro++ | tools/create-release-announcement.pl:
Add a helper script for generating release announcments

  [release] Add changelog entries for 2016.05
kudo/nom: 6d432dc | hoelzro++ | docs/release_guide.pod:
Fix example path for panda in release guide
kudo/nom: 636e030 | hoelzro++ | docs/announce/2016.05.md:
[release] Add changelog entries to release announcement
kudo/nom: 61f78e0 | hoelzro++ | docs/release_guide.pod:
Add myself to list of people to bug about tarball uploading
rakudo/nom: 9de8896 | hoelzro++ | docs/release_guide.pod:
rakudo/nom: Mention my release announcement helper script
ast: ce73638 | usev6++ | / (3 files):
Unfudge tests for JVM (FIRST works now)
 12:00
ast: 66c6258 | usev6++ | S32-list/minmax.t:
Fix description (quotes) for skipped test
 14:28
lizmat hoelzro++ # 2016.05 release 14:33
dalek ast: ffeafe1 | usev6++ | S0 (2 files):
Unfudge two passing tests for JVM
 14:48
lizmat m: sub a(&c) { gather { take 42; c() } }; a {fail} # LTA error 14:59
camelia rakudo-moar 4f046d: OUTPUT«===SORRY!===␤Failed␤»
lizmat m: sub a(&c) { gather { c(); take 42 } }; a {fail} # much better error 15:00
camelia rakudo-moar 4f046d: OUTPUT«Failed␤ in block <unit> at /tmp/8f4fjqbJwm line 1␤␤»
lizmat m: sub a(&c) { gather { take 42; take Failure.new} }; a {fail} # much better error 15:02
camelia rakudo-moar 4f046d: OUTPUT«Failed␤ in block <unit> at /tmp/QRlBxHshkm line 1␤␤Actually thrown at:␤ in block at /tmp/QRlBxHshkm line 1␤␤»
lizmat jnthn TimToady : my point being is that it shouldn't make a difference whether a "take" has been done inside a gather on how a "fail" is handled 15:03
and I *think* we can fix this by always "take"ing a fail inside a gather 15:04
TimToady we would have to know that lexotically or dynamically 15:29
on the Int vs Rat issue, I'd just note that we *can* represent Inf in Rat with 1/0 or so, so maybe inconsistent is okay 15:47
(and -Inf with -1/0)
yeah, I know that's mathematically wrongish some of the time, but we're just talking about conventional values
and NaN could even be represented with 0/0 15:48
m: say 1/0
camelia rakudo-moar 4f046d: OUTPUT«Attempt to divide 1 by zero using div␤ in block <unit> at /tmp/76tvEuFgM_ line 1␤␤Actually thrown at:␤ in block <unit> at /tmp/76tvEuFgM_ line 1␤␤»
TimToady didn't that used to say Inf?
star: say 1/0 15:49
camelia star-m 2016.01: OUTPUT«Attempt to divide 1 by zero using div␤ in block <unit> at /tmp/1b6Iwx_nu3 line 1␤␤Actually thrown at:␤ in block <unit> at /tmp/1b6Iwx_nu3 line 1␤␤»
TimToady mebbe not
m: say <1/0>.Num
camelia rakudo-moar 4f046d: OUTPUT«Inf␤»
TimToady that's what I was thinking
m: say <-1/0>.Num
camelia rakudo-moar 4f046d: OUTPUT«-Inf␤»
TimToady m: say <0/0>.Num
camelia rakudo-moar 4f046d: OUTPUT«Inf␤»
TimToady that one should be NaN 15:50
but we could stringify/gist those the same way
then our policy could be, if you want an Int that supports ±Inf and NaN, use Rat instead 15:51
in other words, don't make Rat consistent with Int, make it consistent with Num
geekosaur that makes a lot more sense than trying to force those onto a type that doesn't support them 15:52
TimToady Rat is sort of a lazy Num, really, especially since it can autopromote to Num anyway 15:53
so I think we should just extend that to Str/gist
I suppose we could even go so far as to promote to Num as soon as we notice the 0 in the denominator 15:55
then other things besides Str/gist would perhaps work more consistently too 15:56
dalek ast: ca3abde | usev6++ | integration/weird-errors.t:
Fudge test for JVM, related to RT #128123
 18:12
ast: 4e8b2e0 | LLFourn++ | / (4 files):
Tests for RT #128156
 19:55

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!