[TuxCM] | This is Rakudo version 2016.11-147-g4fd6e9482 built on MoarVM version 2016.11-27-g3171dbbe | 07:15 | |
csv-ip5xs 3.205 | |||
test 13.975 | |||
test-t 6.511 | |||
csv-parser 13.905 | |||
brrt | [Coke]: what day is today? | 08:18 | |
7th... | |||
hmmm | |||
alright, I'll do my best | |||
well, in fact, i'll just do it :-) | |||
nine | ++brrt | 08:24 | |
jnthn | ooh, brrt post coming up soon? :) | 09:34 | |
pmurias | m: say((-1) ** 99999999999999999999999999999999999999999); | 09:46 | |
camelia | rakudo-moar 4fd6e9: OUTPUT«Numeric overflow in block <unit> at <tmp> line 1Actually thrown at: in block <unit> at <tmp> line 1» | ||
pmurias | j: say((-1) ** 99999999999999999999999999999999999999999); | ||
camelia | rakudo-jvm 8ca367: OUTPUT«-1» | ||
pmurias | jnthn: should I special case that on the MoarVM backend too? | ||
jnthn | Not particularly inclined to | 09:49 | |
pmurias | j: say(2 ** 99999999999999999999999999999999999999998); | 09:58 | |
camelia | ( no output ) | ||
pmurias | j: say(2 ** 99999999999999999999999999999999999999998); | ||
camelia | rakudo-jvm 8ca367: OUTPUT«Inf» | ||
pmurias | j: say(2 ** 99999999999999999999999999999999999999999); | ||
camelia | rakudo-jvm 8ca367: OUTPUT«-Inf» | ||
pmurias | jnthn: you mean I should make -1 ** big-numers work (and you plan to work on something else) or it's not worth working on? | 10:08 | |
jnthn | I'm not sure it's worth special-casin | 10:10 | |
*special-casing | |||
I mean, what practical problem would it actually solve, in the name of slowing down every other case? | |||
brrt | sooner than planned, I have my work cut out for me :-) | 10:16 | |
pmurias | jnthn: it would only slow down the path when the exponent is too big | 10:29 | |
jnthn | Hm, true. But still... | 10:30 | |
Seems a slightly odd discontinuity | |||
pmurias | it's specced in roast | 10:31 | |
just skipped on moarvm | 10:32 | ||
isn't (-1)**n sometimes used in mathematic equations? | |||
DrForr | Quite a bit, yes. | ||
Especially when you're learning about divergent sequences, it's a great way to get alternating signs. | 10:33 | ||
jnthn | So it's actually potentially useful? | ||
That beats "only works on -1"? | 10:34 | ||
DrForr | Oh, definitely. | ||
en.wikipedia.org/wiki/1_%E2%88%92_...20_%2B_... | 10:35 | ||
pmurias | I'll fix that then | 10:36 | |
jnthn | OK, fair enough | 10:42 | |
dalek | ast: 2387fff | jnthn++ | S32-io/IO-Socket-Async-UDP.t: Add UDP socket re-use test. |
11:11 | |
p: 43b37f1 | jnthn++ | tools/build/MOAR_REVISION: Bump MOAR_REVISION for fixes. |
11:12 | ||
kudo/nom: b2ac4e4 | jnthn++ | tools/build/NQP_REVISION: Bump to get latest MoarVM. * Fixes a couple of premature frees in async sockets when errors occur * Optimizations for Int -> int coercion |
11:13 | ||
ast: 28c5e0d | jnthn++ | integration/weird-errors.t: Test to cover RT #128985. |
12:06 | ||
AlexDaniel | bisect: old=2016.03 say ^1000 .grep: -> $n {([+] ^$n .grep: -> $m {$m and $n %% $m}) == $n } | 13:13 | |
bisectable6 | AlexDaniel, Bisecting by exit signal (old=2016.03 new=b2ac4e4). Old exit signal: 11 (SIGSEGV) | ||
AlexDaniel, bisect log: gist.github.com/4960ed59f8d4f6c5b1...ca2689a0da | |||
AlexDaniel, ‘bisect run’ failure | |||
AlexDaniel | perhaps it is this bump: github.com/rakudo/rakudo/commit/95...0b3c403dc8 | 13:17 | |
or let's see what caused it | 13:26 | ||
bisect: new=2016.03 say ^1000 .grep: -> $n {([+] ^$n .grep: -> $m {$m and $n %% $m}) == $n } | |||
bisectable6 | AlexDaniel, Bisecting by exit signal (old=2015.12 new=2016.03). Old exit signal: 0 (None) | ||
AlexDaniel, bisect log: gist.github.com/e2e3ed219c6c500fa3...62ec5444f2 | 13:27 | ||
AlexDaniel, (2016-03-02) github.com/rakudo/rakudo/commit/62...9f61bf6cc5 | |||
[Coke] asks a NYI ticket author for a pointer to where it says it SHOULD be I. get an IRC link pointing at TimToday. :| | 13:57 | ||
jnthn | [Coke]: Which ticket? | 13:58 | |
[Coke] | #130253 | 13:59 | |
jnthn | Yeah, I expect we'll do that at some point | 14:01 | |
babydrop | m: sub (Int) {}(Failure.new) | 14:42 | |
camelia | rakudo-moar b2ac4e: OUTPUT«Earlier failure: FailedFinal error: Type check failed in binding to <anon>; expected Int but got Failure (Failure.new(exception...) in sub at <tmp> line 1 in block <unit> at <tmp> line 1» | ||
babydrop | m: sub (Int()) {}(Failure.new) | ||
camelia | rakudo-moar b2ac4e: OUTPUT«FailedActually thrown at: in sub at <tmp> line 1 in block <unit> at <tmp> line 1» | ||
babydrop | weird | ||
m: multi sub infix:<zz>(Mu \x, Int() $n) is pure {}; 42 zz '123aaa' | 14:44 | ||
camelia | ( no output ) | ||
babydrop | m: sub zz(Int() $n) {}; zz('123aaa') | 14:45 | |
camelia | ( no output ) | ||
babydrop | m: sub zz(Int() $n) {}('123aaa') | ||
camelia | ( no output ) | ||
babydrop | m: sub (Int() $n) {}('123aaa') | ||
camelia | ( no output ) | ||
babydrop | oh ok, never mind | ||
dalek | rakudo/nom: 5bacb05 | (Zoffix Znet)++ | src/core/List.pm: | 14:48 | |
rakudo/nom: Fix poor error with infix:<xx> with non-numeric Str | |||
rakudo/nom: | |||
rakudo/nom: When '123aaa' is given, the Failure occurs inside the coercion, | |||
rakudo/nom: which we then attempt to store in a native int, triggering a bad error | |||
rakudo/nom: | |||
rakudo/nom: Fix by moving the coercer into the Num() multi, where such a Failure | |||
rakudo/nom: would explode in the .Int method. | |||
rakudo/nom: | |||
rakudo/nom: Fixes RT#130288: rt.perl.org/Ticket/Display.html?id=130288 | |||
rakudo/nom: | |||
synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=130288 | ||
dalek | rakudo/nom: P.S: this is probably a deeper issue with our coercers; IIRC there's | ||
rakudo/nom: a ticket that they don't check the final type. | |||
babydrop | github.com/rakudo/rakudo/commit/5b...f2cce18233 | 14:49 | |
dalek | ast: 5f708dc | (Zoffix Znet)++ | S03-operators/repeat.t: Test exception for infix:<xx> with non-numeric Str RT#130288: rt.perl.org/Ticket/Display.html?id=130288 Rakudo fix: github.com/rakudo/rakudo/commit/5b...ce9458c2e6 |
||
synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=130288 | ||
dalek | p: e423c36 | (Pawel Murias)++ | src/vm/jvm/runtime/org/perl6/nqp/runtime/Ops.java: [jvm] Fix pow_I when trying to calculate 2 ** large_odd_number. |
15:50 | |
jnthn | m: 'x' ~~ /<before>/ | 16:24 | |
camelia | rakudo-moar 5bacb0: OUTPUT«===SORRY!===Cannot find method 'ann' on object of type NQPMu» | ||
jnthn | So, I've just hunted down that goes wrong here | ||
babydrop | \o/ | ||
jnthn | And fixed | 16:25 | |
The cause of the crash | |||
Was actually in the NFA construction | |||
Now it survives to runtime | |||
and tells you before needs an argument | |||
Not sure if that's sufficiently awesome but at least it's better :) | |||
TimToady | that should probably be a disallowed empty regex | 16:39 | |
jnthn | Detect before/after specially? | ||
TimToady | anything that takes a regex as an argument | 16:40 | |
jnthn | Well, anything in theory can take a regex as an argument... ;) | ||
TimToady | well, but without // | ||
<before .*> vs <febore /.*/> | |||
jnthn | m: /<my-name-here .+>/ | ||
camelia | ( no output ) | ||
TimToady | well, I guess there'd need to be colon or parens for that | 16:41 | |
jnthn | I thought it was general syntax? | ||
At least, we've been parsing it that way so far :) | |||
TimToady | well, but we know it's regex due to the absence of colon or parens | ||
hmm, I wonder... | |||
jnthn | For sure | ||
TimToady | m: 'x' ~~ /<before >/ | ||
camelia | rakudo-moar 5bacb0: OUTPUT«===SORRY!=== Error while compiling <tmp>Null regex not allowedat <tmp>:1------> 'x' ~~ /<before ⏏>/» | ||
TimToady | there we go | 16:42 | |
jnthn | But <my-name-here> is fine, where we'd probably like <before> to not be fine | ||
TimToady | it's using the space currently | ||
geekosaur | dont forget the case where someone defined a rule called after and then tried to use <after ...> | ||
jnthn | I'm...not entirely sure what we can do about that case. | ||
geekosaur | there's some thinking needed about this whole thing I'm afraid | ||
jnthn | I mean, that's just a plain old extensibility question | 16:43 | |
We don't, in general, ban people from overriding built-in names. | |||
TimToady | well beforeoids should at least fail to dispatch without an argument | ||
jnthn | Well, they will with the local patch I have | 16:44 | |
Before, the lack of argument upset the NFA builder | |||
Which then exploded with a useless message | |||
TimToady | nodnod | ||
jnthn | m: 'a' ~~ /<before('x')>/ | ||
camelia | rakudo-moar 5bacb0: OUTPUT«===SORRY!===Cannot find method 'rxtype' on object of type NQPMu» | ||
jnthn | That one now just gives a differently weird error :) | ||
But question is if we want to catch it | 16:45 | ||
TimToady | m: 'a' ~~ /<before(/x/)>/ | ||
camelia | rakudo-moar 5bacb0: OUTPUT«===SORRY!===Cannot find method 'rxtype' on object of type NQPMu» | ||
jnthn | That works out OK it seems | 16:46 | |
$ ./nqp-m -e 'say("ok") if "a" ~~ / <before(/a/)> /' | |||
ok | |||
geekosaur | I think my point is that if <before ...> and <after ...> are going to be parsed differently, they should probably refer to a different kind of thing than "rule". but also, the general conflict between that syntax and rules with parameters makes me think either that whole area needs to be formalized better, or before/after should become a different grammtical construct that doesn't collide | ||
jnthn | m: /<general >/ | 16:47 | |
camelia | rakudo-moar 5bacb0: OUTPUT«===SORRY!=== Error while compiling <tmp>Null regex not allowedat <tmp>:1------> /<general ⏏>/» | ||
jnthn | That is also general | ||
I'd always figured that <foo .+> was a regular shorthand for <foo(/.+/> | |||
uh, with the missing paren | |||
So we're not parsing before/after differently so far as I can tell | |||
TimToady | yes, it's a general syntax, triggered by the space | 16:48 | |
jnthn | It's just the most common way to use them is the shorthand way | ||
The only thing that's special about before is that the NFA constructor pays attention to it | 16:49 | ||
OTOH, after is more special because it flips the AST before compiling it... | |||
dalek | p: 768b20d | jnthn++ | src/QRegex/NFA.nqp: Make NFA builder cope with <before>. Also, with <before('x')>. Both caused it to explode unhelpfully before, with no indication of where things went wrong. |
16:57 | |
jnthn | Anyway, that makes the error less sucky | ||
Also, it makes the code in rt.perl.org/Ticket/Display.html?id=130273 work fine | 17:00 | ||
Since overriding before/after is possible and, without the NFA constructor getting confused, does the right thing | |||
TimToady: I left a comment on rt.perl.org/Ticket/Display.html?id...1f87285294 | 17:10 | ||
TimToady: Not quite sure what you'd prefer we do of the options I present at the end :) | 17:11 | ||
I mean, the status quo with my patch is the code the user wrote now works, so we could just roast it... :) | |||
geekosaur | that "where do we draw the line" is actually where I was going... I think we might want a new indicator there | 17:12 | |
another reason for that.. .what exactly does <!foo> mean? | |||
it's legal currently but I have no idea what a user defined rule foo would do about it (or how it would know about it) | 17:13 | ||
jnthn | <!foo> just means "foo doesn't match here" | ||
e.g. "use foo as a negative lookeahead" | 17:14 | ||
Like <?foo> means "use foo as a positive lookahead" | |||
They generalize very easily, you just call the rule normally, look at whether it matched or not, but don't advance the cursor of the caller. | 17:15 | ||
The more contentious ones are <+foo> and <-foo> | |||
Where you'll get potentially odd results at the moment if your foo doesn't match a single char | |||
I suspect only <+foo> is actually afflicted, and that may be because the code-gen cheats and pretends it's <.foo> rather than <?foo> . | 17:17 | ||
Though of course there's also the question of whether something called as <+foo> or <-foo> not matching exactly one char should be a warning/error/match fial | 17:18 | ||
*fail | |||
Dinner time :) bbl | 17:22 | ||
dalek | kudo/fix-powers-with-big-exponents: cf05254 | (Pawel Murias)++ | src/core/Int.pm: Stop relying on a bug in infix:<**>(Int, Int). |
17:30 | |
babydrop | hmm | 17:43 | |
There's a point on that topic that bugged me before: | |||
m: say 2e0 ** 99999999999999 | |||
camelia | rakudo-moar 5bacb0: OUTPUT«Inf» | ||
babydrop | m: say 2 ** 99999999999999 | ||
camelia | rakudo-moar 5bacb0: OUTPUT«Numeric overflow in block <unit> at <tmp> line 1Actually thrown at: in block <unit> at <tmp> line 1» | ||
babydrop | So... what if we remove all those checks and feed the args straight to pow_I; giving an Inf on overflow? | 17:44 | |
And then we have consistency between Num, and Int candidates | |||
babydrop notes pmurias isn't here, so comments on the PR instead | 17:46 | ||
[Coke] | babydrop: are there cases where INT ** INT gives you a Num? | 17:54 | |
I think that's the diff there, NUM ** INT can give you Inf-the-specialist-of-Nums. | |||
(but if we have other cases where we do that type-change, that's fine.) | 17:55 | ||
babydrop | m: put chars 1.7975e308.Int * 1.7975e308.Int * 1.7975e308.Int * 1.7975e308.Int * 1.7975e308.Int * 1.7975e308.Int * 1.7975e308.Int * 1.7975e308.Int * 1.7975e308.Int * 1.7975e308.Int * 1.7975e308.Int * 1.7975e308.Int * 1.7975e308.Int * 1.7975e308.Int * 1.7975e308.Int * 1.7975e308.Int * 1.7975e308.Int * 1.7975e308.Int * 1.7975e308.Int * 1.7975e308.Int * 1.7975e308.Int * 1.7975e308.Int * 1.7975e308.Int * | ||
camelia | rakudo-moar 5bacb0: OUTPUT«===SORRY!=== Error while compiling <tmp>Missing required term after infixat <tmp>:1------> .Int * 1.7975e308.Int * 1.7975e308.Int *⏏<EOL> expecting any of: prefix term» | ||
babydrop | 1.7975e308.Int * 1.7975e308.Int * 1.7975e308.Int | ||
m: put chars 1.7975e308.Int * 1.7975e308.Int * 1.7975e308.Int * 1.7975e308.Int * 1.7975e308.Int * 1.7975e308.Int * 1.7975e308.Int * 1.7975e308.Int * 1.7975e308.Int * 1.7975e308.Int * 1.7975e308.Int * 1.7975e308.Int * 1.7975e308.Int * 1.7975e308.Int * 1.7975e308.Int * 1.7975e308.Int * 1.7975e308.Int * 1.7975e308.Int * 1.7975e308.Int * 1.7975e308.Int * 1.7975e308.Int * 1.7975e308.Int * 1.7975e308.Int | |||
camelia | rakudo-moar 5bacb0: OUTPUT«7090» | ||
babydrop | So is that a proper 7090-digit long number? | ||
timotimo | probably? | 17:56 | |
babydrop | So why can't the pow_I op do the same type of thing? | ||
timotimo | good Q | ||
babydrop doesn't know anything of those low-level details :( | |||
timotimo | well, i expect the problem appears inside moarvm's c code | 17:58 | |
dalek | p: 8151d0c | (Pawel Murias)++ | src/vm/js/nqp-runtime/bignum.js: [js] Fix nqp::pow_I. |
18:00 | |
p: fb3fa50 | (Pawel Murias)++ | t/nqp/060-bigint.t: Test nqp::pow_I more (check if it handles -1 ** large_number, returns nqp::inf when overflowing etc.). |
|||
pmurias | babydrop: re why not do those checks and returns Inf, it would change the semantics | 18:03 | |
travis-ci | NQP build failed. Pawel Murias 'Test nqp::pow_I more (check if it handles -1 ** large_number, returns nqp::inf when overflowing etc.).' | ||
travis-ci.org/perl6/nqp/builds/182038550 github.com/perl6/nqp/compare/768b2...3fa504a5d5 | |||
babydrop | pmurias: fair enough. | 18:04 | |
pmurias | timotimo: the problem with too big arguments is that we don't have when we create that number we run out of memory | ||
timotimo | *shrug*, if you build a number this big, you'll get what you want | 18:05 | |
dalek | p: af8eadd | (Pawel Murias)++ | tools/build/MOAR_REVISION: Bump moar for pow_I fixes. |
18:07 | |
pmurias | TimToady: what should 2**(2**200) do? throw an exception or return Inf? | 18:08 | |
babydrop | TimToady: or give a giant number? | ||
timotimo | yeah, that'll be ... a bit big :) | 18:10 | |
travis-ci | NQP build passed. Pawel Murias 'Bump moar for pow_I fixes.' | ||
travis-ci.org/perl6/nqp/builds/182040385 github.com/perl6/nqp/compare/fb3fa...8eaddad580 | |||
psch | j: use java::lang::BigInteger:from<Java>; say BigInteger.new(-1).pow(99999999999999) | 18:11 | |
psch .oO( of course that's right when the irc.p6c.org connection to freenode times out... ) | |||
camelia | rakudo-jvm 8ca367: OUTPUT«===SORRY!===Could not find java::lang::BigInteger at line 1 in: /home/camelia/.perl6 /home/camelia/rakudo-j-inst-2/share/perl6/site /home/camelia/rakudo-j-inst-2/share/perl6/vendor /home/camelia/rakudo-j-inst-2/share/perl6 C…» | ||
psch | oh, probably "math" actually :s | 18:12 | |
j: use java::math::BigInteger:from<Java>; say BigInteger.new(-1).pow(99999999999999) | |||
camelia | rakudo-jvm 8ca367: OUTPUT«===SORRY!===Could not find java::math::BigInteger at line 1 in: /home/camelia/.perl6 /home/camelia/rakudo-j-inst-2/share/perl6/site /home/camelia/rakudo-j-inst-2/share/perl6/vendor /home/camelia/rakudo-j-inst-2/share/perl6 C…» | ||
psch | grr | ||
pmurias | babydrop: it's more die from lack of memory rather then return a giant number | ||
psch | that's what i get for implementing different specs for jre and user-supplied-classes | ||
j: use java::math::BigInteger:from<JavaRuntime>; say BigInteger.new(-1).pow(99999999999999) | 18:13 | ||
camelia | rakudo-jvm 8ca367: OUTPUT«Couldn't find a constructor with types class java.lang.Long. in block <unit> at <tmp> line 1» | ||
psch | j: use java::math::BigInteger:from<JavaRuntime>; say BigInteger.new("-1").pow(99999999999999) # but *now* | ||
camelia | rakudo-jvm 8ca367: OUTPUT«-1» | ||
psch | r: say (-1)**99999999999999 | ||
camelia | rakudo-jvm 8ca367: OUTPUT«-1» | ||
..rakudo-moar 5bacb0: OUTPUT«Numeric overflow in block <unit> at <tmp> line 1Actually thrown at: in block <unit> at <tmp> line 1» | |||
psch | okay so | ||
i wanna say that r-m shouldn't screw things up r-j can do | 18:14 | ||
cause r-j is kinda crippled and well | |||
mind, that's probably not the best reasoning | |||
r-j is similarly bound to ieee754, minus some boxing concerns which mostly don't matter | 18:15 | ||
babydrop | pmurias: it's a byte per 8 positions, right? | ||
psch | (as in, we have the boxing types as kinda fallback but not really because they also adhere to ieee754) | ||
babydrop | Well, wolframalpha does it somehow: www.wolframalpha.com/input/?i=2**%282**200%29 | 18:16 | |
psch | j: use java::math::BigInteger:from<JavaRuntime>; say BigInteger.new("2").pow(BigInteger.new("2").pow(200)) | ||
camelia | rakudo-jvm 8ca367: OUTPUT«This type cannot unbox to a native integer in block <unit> at <tmp> line 1» | ||
psch | ah, marshalling screws that over | 18:17 | |
'cause we unbox BigInteger.new("2").pow(200) before passing it to the other .pow | |||
babydrop | ah | ||
psch | because apparently we don't have robust enough bigint marshalling rules yet :/ | ||
(...patches welcome..? :P ) | |||
babydrop | j: use java::math::BigInteger:from<JavaRuntime>; say BigInteger.new("9999999999").pow(BigInteger.new("9999999999")) | 18:18 | |
camelia | rakudo-jvm 8ca367: OUTPUT«===SORRY!=== Error while compiling <tmp>Unable to parse expression in argument list; couldn't find final ')' at <tmp>:1------> say BigInteger.new("9999999999").pow(Big⏏Integer.new("9999999999")) expecting any of: i…» | ||
psch | whu | ||
is there some sneaky unicode there..? | 18:19 | ||
babydrop | oh, yeah appears so | ||
j: use java::math::BigInteger:from<JavaRuntime>; say BigInteger.new("9999999999").pow(BigInteger.new("9999999999")) | |||
camelia | rakudo-jvm 8ca367: OUTPUT«This type cannot unbox to a native integer in block <unit> at <tmp> line 1» | ||
psch | mhm, so unmarshalling is similarly weird | 18:20 | |
probably falling back to natives where it shouldn't :/ | |||
dalek | kudo/nom: cf05254 | (Pawel Murias)++ | src/core/Int.pm: Stop relying on a bug in infix:<**>(Int, Int). |
18:22 | |
kudo/nom: 3836012 | (Paweł Murias)++ | src/core/Int.pm: Merge pull request #938 from rakudo/fix-powers-with-big-exponents Stop relying on a bug in infix:<**>(Int, Int). |
|||
pmurias | psch: re (-1)**99999999999999 # this should now work on rakudo-moar | 18:23 | |
psch | pmurias++ | 18:24 | |
dalek | kudo/nom: f367e4e | (Zoffix Znet)++ | src/core/List.pm: Fix MVMArray Error on .pick with negative numbers ...by restricting range to UInt. However, for some ops, like infix:<xx> we treat negatives as zero (see irclog.perlgeek.de/perl6/2016-12-07#i_13698488) I'm commiting this as a fix for very LTA error, but will leave the ticket[^1] open. I will review what we do for most of our methods to see if there's any sort of consistency we can make out of it. [1] rt.perl.org/Ticket/Display.html?id=130284 |
18:25 | |
kudo/nom: 00541a5 | (Lucas Buchala)++ | src/Perl6/Compiler.nqp: De-indent 4 spaces the "perl -h" message output |
18:34 | ||
kudo/nom: 419f7bd | (Zoffix Znet)++ | src/Perl6/Compiler.nqp: Merge pull request #939 from lucasbuchala/patch-1 De-indent 4 spaces the "perl -h" message output |
|||
pmurias | rt.perl.org/Public/Bug/Display.html?id=125938 - needs checking on Mac OS X so that we can close the ticket | 18:46 | |
[Coke] | pmurias: we have os x tests on jenkins, no? | 18:56 | |
dalek | ast: 714abc9 | (Pawel Murias)++ | S03-operators/overflow.t: Test that 2**-10000000000 throws an overflow exception. |
19:00 | |
psch | j: 2**-10000000000 | 19:01 | |
camelia | rakudo-jvm 8ca367: OUTPUT«WARNINGS for <tmp>:Useless use of "**" in expression "2**-" in sink context (line 1)Numeric overflow in block <unit> at <tmp> line 1Actually thrown at: in method throw at gen/jvm/CORE.setting line 27529 in method throw at gen/jvm/COR…» | ||
psch | j: say 2**-10000000000 | ||
camelia | rakudo-jvm 8ca367: OUTPUT«Numeric overflow in block <unit> at <tmp> line 1Actually thrown at: in method throw at gen/jvm/CORE.setting line 27529 in method throw at gen/jvm/CORE.setting line 30188 in method gist at gen/jvm/CORE.setting line 30222 in sub say …» | ||
babydrop | hm, did we bump nqp for the pow thing? I'm getting a bunch of failures on t/spec/S03-operators/overflow. and t/spec/S32-num/power. | 19:22 | |
nope. I'll bump | 19:23 | ||
pmurias | sorry for not bumping NQP | 19:28 | |
babydrop | It's fine. I like bumping thing :) | 19:29 | |
pmurias | aren't github.com/perl6/roast/blob/master...wer.t#L115 and github.com/perl6/roast/blob/master...wer.t#L118 contradictory? | 19:32 | |
geekosaur | www.youtube.com/watch?v=UfM3kMz-6c4 do the bump :p | ||
babydrop | pmurias: the tests themselves look OK to me, one's power ends in ⁵⁴ and the other ends in ⁴⁵ | 19:35 | |
and the odd one tests for the result being -1 | |||
psch | right, one has an even exponent, the other an odd one | ||
also, neat song :3 | 19:36 | ||
dalek | kudo/nom: 2d01981 | (Zoffix Znet)++ | tools/build/NQP_REVISION: (nqp bump) Fix for nqp::pow_I with large exponents NQP changes: github.com/perl6/nqp/compare/e423c.....af8eadda |
19:38 | |
pmurias | do those weird unicody powers work? | 19:41 | |
babydrop | yup | ||
m: say 2² | |||
camelia | rakudo-moar 419f7b: OUTPUT«4» | ||
babydrop | ZOFVM: Files=1204, Tests=130255, 153 wallclock secs (23.78 usr 3.52 sys + 3539.04 cusr 274.42 csys = 3840.76 CPU) | 19:42 | |
pmurias | they are stored in an int | 19:46 | |
dalek | kudo/fix-powers-with-big-exponents: 4e2bf14 | (Pawel Murias)++ | src/Perl6/Actions.nqp: Support superscript powers that are larger then we could store in an int. |
20:50 | |
kudo/nom: 0428b79 | (Pawel Murias)++ | src/Perl6/Actions.nqp: Support superscript powers that are larger then we could store in an int. |
20:51 | ||
ast: a099498 | (Pawel Murias)++ | S (2 files): Unfudge tests that should no longer be a problem. |
20:54 | ||
pmurias | [Coke]: where is that jenkins you mention? | 20:55 | |
[Coke] | er... said jenkins, meant travis | 20:59 | |
so if you have arecent enough rakudo build passing with bumps that include your fixes. (or a PR that passes), I think OS X is on that list. | 21:00 | ||
RabidGravy | I've got a jenkins building rakudo here | ||
pmurias | RabidGravy: on OS X? | 21:02 | |
the 3 tickets for infix:<**> need to be closed: RT #124798, #127493, #127500 | 21:24 | ||
synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=124798 | ||
Link: rt.perl.org/rt3//Public/Bug/Displa...?id=127493 | |||
Link: rt.perl.org/rt3//Public/Bug/Displa...?id=127500 | |||
RabidGravy | pmurias, no :) Though I can't see any reason why it wouldn't work | 21:26 | |
travis-ci | Rakudo build errored. Zoffix Znet 'Fix MVMArray Error on .pick with negative numbers | 22:18 | |
travis-ci.org/rakudo/rakudo/builds/182045511 github.com/rakudo/rakudo/compare/3...67e4edc189 | |||
buggable | [travis build above] ✓ All failures are due to timeout (1), missing build log (0), or GitHub connectivity (0). | ||
babydrop | pmurias: done. | 22:58 | |
.ask pmurias I assume the `fix-powers-with-big-exponents` branch can be deleted? It's the one that included a fix to avoid the bug explotation of pow_I in Int ** Int, but that was merged. | 23:11 | ||
yoleaux2 | babydrop: I'll pass your message to pmurias. |