[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 1␤␤Actually 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:␤ Failed␤␤Final 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«Failed␤␤Actually 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 allowed␤at <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 allowed␤at <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 1␤␤Actually 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 infix␤at <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 1␤␤Actually 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(Big​Integer.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 1␤␤Actually 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 1␤␤Actually 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.

Powered by Cro and the Raku® Programming Language.

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

Thank you!