travis-ci | Rakudo build passed. Elizabeth Mattijsen 'Make Str.rindex about 30% faster | 00:03 | |
travis-ci.org/rakudo/rakudo/builds/145277854 github.com/rakudo/rakudo/compare/f...fe3c04ed47 | |||
gfldex | I used to work for a former subsidiary for Lufthansa and we had one gentleman who was still working for Lufthansa proper as a manager. He used to carry the name Süß but after having to travel a lot to northern america he changed his name to Suess. At times he was even on lists because of his uncomputable name. | 00:10 | |
s/was/wasn't/ | 00:11 | ||
m: say "in Massen".fc ~~ "in Maßen".fc | 00:24 | ||
camelia | rakudo-moar 980f49: OUTPUT«True» | ||
gfldex | :-/ | ||
that means that "a lot" is the same as "in moderation" | 00:25 | ||
Zoffix | $ perl -wlE 'say fc "in Massen" eq fc "in Maßen" ? "Yeah" : "Nope"' | 00:26 | |
Nope | |||
m: "ß".fc.say | |||
camelia | rakudo-moar 980f49: OUTPUT«ss» | ||
Zoffix | m: "ß".fc.uninames.say | ||
camelia | rakudo-moar 980f49: OUTPUT«(LATIN SMALL LETTER S LATIN SMALL LETTER S)» | ||
Zoffix | Oh, nm, I forgot use utf8 in Perl 5. It also says the two are equal. | 00:27 | |
gfldex | that means it's wrong in Perl 5 in the same way | 00:28 | |
that also means that for german texts you have to scan for ß and special case it | 00:29 | ||
Zoffix | m: say "in Massen".fc ~~ "in Maẞen".fc | 00:30 | |
camelia | rakudo-moar 980f49: OUTPUT«True» | ||
gfldex | m: say "ẞ".uninames.say | 00:36 | |
camelia | rakudo-moar 980f49: OUTPUT«(LATIN CAPITAL LETTER SHARP S)True» | ||
travis-ci | Rakudo build passed. Zoffix Znet '.polymod with a lazy list must not lose mods if the list runs out | ||
travis-ci.org/rakudo/rakudo/builds/145282087 github.com/rakudo/rakudo/compare/f...0f496fa8be | |||
Zoffix | shush | ||
gfldex | m: say "ẞ".uninames.say # called "Versaleszetts" in german | 00:37 | |
camelia | rakudo-moar 980f49: OUTPUT«(LATIN CAPITAL LETTER SHARP S)True» | ||
gfldex | m: say "Haßloch".fc | 00:38 | |
camelia | rakudo-moar 980f49: OUTPUT«hassloch» | ||
gfldex | context: de.wikipedia.org/wiki/Ha%C3%9Floch | ||
i wouldn't want to live in hatehole | 00:39 | ||
Zoffix | Jesus swift's docs are shit | 00:42 | |
Can't find a list of methods on a String | |||
(╯°□°)╯︵ ┻━┻ | 00:45 | ||
Wanted to see what it gives for "in Massen".fc ~~ "in Maẞen".fc but I can't even find a .foldcaseString method | |||
gfldex | Zoffix: maybe developer.mozilla.org/en-US/docs/W...eLowerCase | 00:47 | |
Zoffix | Well, there's stringByFoldingWithOptions but I've no idea how to use it. | 01:08 | |
And I can't even find one working example of swift code.... Either that or glot.io/new/swift is busted. | 01:09 | ||
Zoffix chucks Swift into "annoying languages" bin | |||
.uppercaseString ~_~ who thought of such a verbose name | |||
So basically "in Massen".fc ~~ "in Maẞen".fc => True makes sense. Since it erases case, there's no little s or big S, there's no case so both of them are the same | 01:20 | ||
m: dd 'ß'.fc, 'ẞ'.fc, 'SS'.fc, 'ss'.fc | 01:21 | ||
camelia | rakudo-moar 980f49: OUTPUT«"ss""ss""ss""ss"» | ||
Zoffix | m: say so 'assen' ~~ 'aẞen' | 01:22 | |
camelia | rakudo-moar 980f49: OUTPUT«False» | ||
Zoffix | m: say so 'assen' ~~ 'aẞen'.fc | ||
camelia | rakudo-moar 980f49: OUTPUT«True» | ||
Zoffix | m: say 2.Rat.polymod: 0 | 02:19 | |
camelia | rakudo-moar 980f49: OUTPUT«Attempt to divide 2 by zero using polymod in any at /home/camelia/rakudo-m-inst-2/share/perl6/runtime/CORE.setting.moarvm line 1 in block <unit> at <tmp> line 1» | ||
dalek | kudo/nom: 7976fe9 | (Zoffix Znet)++ | src/core/ (2 files): .polymod with zero divisor must not reference guts in error Fixes RT#128646 |
02:23 | |
synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128646 | ||
dalek | ast: c61b572 | (Zoffix Znet)++ | S32-num/polymod.t: .polymod with zero divisor does not reference guts in error RT#128646 |
||
synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128646 | ||
lizmat | bisectable: good=2015.12 bad=HEAD my int $i = 10; say Buf.new($i +& 0xFF) | 10:22 | |
bisectable | lizmat: No build for 'bad' revision | ||
lizmat | bisectable: good=2015.12 bad=b06a99ebdd79393ce109cc214a6019ada5a0218a my int $i = 10; say Buf.new($i +& 0xFF) | 10:23 | |
bisectable | lizmat: bisect log: gist.github.com/c8804ae8cbbe7200f7...cfd72517d0 | ||
lizmat: (2016-07-11) github.com/rakudo/rakudo/commit/de5d9e7 | |||
lizmat | ok, so what's weird about this is that the error message actually states: | ||
"expected uint8 but got Int" | |||
which means that this: | 10:25 | ||
m: use nqp; say nqp::istype(uint8,Int) | |||
camelia | rakudo-moar 7976fe: OUTPUT«1» | ||
lizmat | returned 0 instead of 1 | ||
psch | m: for &infix:<+&>.candidates -> $cand { try say Buf.new($cand(my int $ = 10, 255)).WHAT if \(my int $, 0) ~~ $cand.signature } | 10:38 | |
camelia | rakudo-moar 7976fe: OUTPUT«(Buf)(Buf)(Buf)» | ||
psch | m: for &infix:<+&>.candidates -> $cand { try say Buf.new($cand(my int $ = 10, 255)) if \(my int $, 0) ~~ $cand.signature } | ||
camelia | rakudo-moar 7976fe: OUTPUT«Buf:0x<0a>Buf:0x<0a>Buf:0x<0a>» | ||
psch | oh, that just sinks the 255 'cause the my gobbles it i think | 10:39 | |
m: for &infix:<+&>.candidates -> $cand { try say Buf.new($cand((my int $ = 10), 255)) if \(my int $, 0) ~~ $cand.signature } | |||
camelia | rakudo-moar 7976fe: OUTPUT«Buf:0x<0a>Buf:0x<0a>Buf:0x<0a>» | ||
psch | hm, maybe not. i don't get it :S | ||
i guess it could use a different candidate for infix:<+&> for some reason..? | 10:40 | ||
nine | lizmat: $i +& 0xFF returns an Int, even if both arguments are ints | ||
lizmat | yes, which *should* make nqp::istype($a,Int) return a 1, instead of a 0 | 10:41 | |
so, this is something *really* weird | 10:42 | ||
dalek | ar: 69c56ad | (Steve Mynott)++ | docs/announce/2016.07.md: roll in some of the rakudo changelog from 2016.07 |
14:23 | |
timotimo | we still have "none-multi's" in there | 14:24 | |
dalek | ar: 9c3b904 | (Steve Mynott)++ | docs/announce/2016.07.md: tweak formating |
14:27 | |
ar: 52be35f | (Steve Mynott)++ | modules/ (10 files): bump submodule versions |
14:31 | ||
kudo/nom: c889250 | (Zoffix Znet)++ | docs/ChangeLog: Fix typo |
14:42 | ||
Zoffix | timotimo, I saw you mentioning it in #perl6, which made no sense: irclog.perlgeek.de/perl6/2016-07-15#i_12847397 | 14:43 | |
I didn't even realize you were talking about the Rakudo's ChangeLog | |||
dalek | ar: a2e2f2c | (Steve Mynott)++ | docs/announce/2016.07.md: changelog for submodules |
14:56 | |
Zoffix | Does anyone know the story of why diag() prints to STDERR? It does so in Perl 5 too, but I'm reading testanything.org/tap-specification.html and it has no mention of STDERR and in fact, states "A harness must only read TAP output from standard output and not from standard error." | 14:59 | |
dalek | kudo/nom: 20a648a | niner++ | src/core/CompUnit/PrecompilationRepository.pm: Don't die generating a debug message if source file is unavailable |
15:00 | |
kudo/nom: d1604b5 | niner++ | tools/build/install-core-dist.pl: Fix make DESTDIR not finding CompUnit::Repository::Staging |
|||
nine | Zoffix: maybe diag() is not considered TAP? | 15:05 | |
Zoffix: it's purpose is to communicate something to the user after all and not to the harness | 15:06 | ||
Zoffix | Ah | ||
mst | exactly what I just said when he cross-spammed the question to #perl | ||
Zoffix | Sorry | ||
mst | in this case, I think getting the same answer twice is no bad thing | ||
note also that #perl-qa is the best channel for this sort of question, followed by #toolchain | 15:07 | ||
dalek | ar: e9effe0 | (Steve Mynott)++ | / (3 files): bump to 2016.07 |
15:08 | |
nine | If packagers notice an issue with the Staging repo, please advise them to include commit d1604b5c8e | 15:10 | |
dalek | ar: 90934e5 | (Steve Mynott)++ | tools/star/Makefile: bump rakudo, nqp and moarvm versions to 2016.07 |
15:14 | |
[TuxCM] | This is Rakudo version 2016.07-11-gd1604b5 built on MoarVM version 2016.07 | 15:30 | |
test 15.184 | |||
test-t 8.047 | |||
csv-parser 16.043 | |||
8.NUL! | |||
FWIW CSV::Parser also went down from 35 in May to 16 today | 15:32 | ||
Well done! | |||
Zoffix | :o | 15:33 | |
dalek | ar: b1629bf | (Steve Mynott)++ | .gitmodules: use same lpw-simple upstream as panda with recent test fix |
15:40 | |
ar: e93c762 | (Steve Mynott)++ | modules/perl6-lwp-simple: correct commit sha for new upstream lwp-simple |
15:46 | ||
kudo/nom: 9d0055c | (Zoffix Znet)++ | / (3 files): Do not lose diag()'s output at start of test file or during TODO tests diag() is internally used for many types of messages, including TODO test outputs. It uses todo and test run counts to decide whether to place output into STDOUT or STDERR. This creates a problem when diag() is explicitly used by a module's user at the start of the test files or in the middle of a set of TODO runs. To avoid that, we use an internal _diag() internally and export a diag() that will ask _diag() to always place user's messages into STDERR. Fixes RT#128098 nine++ mst++ 480d8c0 | (Zoffix Znet)++ | / (3 files): Revert "Do not lose diag()'s output at start of test file or during TODO tests" This reverts commit 9d0055cfd27460817e2fe2b86b9fa5884a93e592. |
16:11 | ||
synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128098 | ||
Zoffix | github.com/rakudo/rakudo/commit/9d0055c | ||
>_< I'm dumb | 16:26 | ||
kudo/nom: 68b66c2 | (Zoffix Znet)++ | / (3 files): Unrevert "Do not lose diag()'s output at start of test file or during TODO tests"" This unreverts commit 9d0055cfd27460817e2fe2b86b9fa5884a93e592 and fixes a bug in its code (incorrect precedence of conditional when assigning to $is_todo in _diag()) |
16:55 | ||
Zoffix | Well, this was embarrassingly messy. :/ | 16:56 | |
stmuk | pl6anet.org/drop/rakudo-star-2016.07-RC0.tar.gz | 17:01 | |
gfldex | m: (join('', "un" xx 10) ~ "revert").tc.say | 17:06 | |
camelia | rakudo-moar 480d8c: OUTPUT«Ununununununununununrevert» | ||
gfldex | Zoffix: ^^^ Perl 6 can help you with that! :-> | ||
ugexe | lizmat: gist.github.com/ugexe/7ce08d3ad4cf...7ba9713471 This points at the commit `Add "push-all" to sequential-map "normal"` | 17:36 | |
psch | r: sub f { loop { print $++; last } };f;f;f;f; | 18:25 | |
camelia | rakudo-jvm cd19db: OUTPUT«0123» | ||
..rakudo-moar 68b66c: OUTPUT«0000» | |||
psch | that's #126528 | ||
synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=126528 | ||
psch | r: sub f { loop { state $x; print $x++; last } };f;f;f;f; | 18:28 | |
camelia | rakudo-jvm cd19db: OUTPUT«0123» | ||
..rakudo-moar 68b66c: OUTPUT«0000» | |||
psch | which looks to me like either we do state vars wrong on jvm, or the loop block doesn't get its own call frame on jvm | 18:41 | |
bartolin | . o O ( or both ) # SCNR | 18:44 | |
psch | yes, or that :) | 18:47 | |
Zoffix | Isn't the JVM version the correct one? | 18:48 | |
psch | Zoffix: well, if it is our Perl 6 level implementation of HYPER is wrong | ||
Zoffix | r: my $x; sub f { loop { print $x++; last } };f;f;f;f; | 18:49 | |
camelia | rakudo-moar 68b66c, rakudo-jvm cd19db: OUTPUT«0123» | ||
psch | r: sub f { state $x; loop { state $y; say $x++, $y++ } };f;f;f;f | ||
oh duh | 18:50 | ||
didn't last >_> | |||
camelia | rakudo-moar 68b66c: OUTPUT«(timeout)0011223344556677889910101111121213131414151516161717181819192020212122222323242425252626272728282929303031313232333334343535363637373…» | ||
..rakudo-jvm cd19db: OUTPUT«00112233445566778899101011111212131314141515161617171818191920202121222223232424252526262727282829293030313132323333343435353636373738383939…» | |||
psch | now *that* is interesting | ||
'cause moar changes its tune when there's a state in the sub block | 18:51 | ||
also, i hope the jvm just didn't tell us that it timed out and isn't still running :S | |||
Zoffix | m: state $x; say print $x | ||
camelia | rakudo-moar 68b66c: OUTPUT«Use of uninitialized value $x of type Any in string contextAny of .^name, .perl, .gist, or .say can stringify undefined things, if needed. in block <unit> at <tmp> line 1True» | ||
Zoffix | m: state $x; say print $x++ | ||
camelia | rakudo-moar 68b66c: OUTPUT«0True» | ||
Zoffix | The '0000' is wrong. state $x keeps $x around, so those ++ should keep increasing the same variable and growing its values. So JVM's version is the correct one. | 18:52 | |
m: state $x; say $x; say $x++ | |||
camelia | rakudo-moar 68b66c: OUTPUT«(Any)0» | ||
Zoffix | This kinda iffy IMO, 'cause the value ++ returns is different than the original | 18:53 | |
psch | Zoffix: right, which means moar erroneously binds to the loop block instead of the sub block | ||
Zoffix | m: my $x = class {}; say $x; say $x++ | 18:54 | |
camelia | rakudo-moar 68b66c: OUTPUT«(<anon|63429520>)0» | ||
psch | well, i suppose that means we can retag the ticket to [moarvm] and then rewrite &HYPER | 18:55 | |
i suppose the rewrite could limit itself to using a lexical instead of a state var in the loop in &HYPER | 18:57 | ||
Zoffix | .tell stmuk not sure if it affects R* release, but FYI the 2016.07 release seems to have issues with custom DESTDIR that I think are fixed in HEAD: rt.perl.org/Ticket/Display.html?id=128652 | 19:00 | |
yoleaux2 | Zoffix: I'll pass your message to stmuk. | ||
Zoffix | m: my $x = Str but role { method gist { 'speshul' } }; say $x++ | 19:02 | |
camelia | rakudo-moar 68b66c: OUTPUT«0» | ||
Zoffix | m: my $x = 0 but role { method gist { 'speshul' } }; say $x++ | ||
camelia | rakudo-moar 68b66c: OUTPUT«speshul» | ||
Zoffix | ¯\_(ツ)_/¯ probably OK. | ||
psch | r: sub f { state $x; loop { state $y; say $x++, $y++; last } };f;f;f;f | 19:04 | |
camelia | rakudo-jvm cd19db: OUTPUT«00112233» | ||
..rakudo-moar 68b66c: OUTPUT«00102030» | |||
psch | there, i was wrong | ||
not lasting obviously changes the behavior | |||
because, well, we loop contiuously so none of the state vars get reset | 19:05 | ||
i really don't know if a loop block tracks its state var seperately from the next outer | |||
m: sub f { state $x; say $x++, (state $y)++ for ^1 }; f;f;f;f; | 19:06 | ||
camelia | rakudo-moar 68b66c: OUTPUT«00112233» | ||
psch | r: sub f { state $x; say $x++, (state $y)++ for ^1 }; f;f;f;f; | ||
camelia | rakudo-moar 68b66c, rakudo-jvm cd19db: OUTPUT«00112233» | ||
Zoffix | m: sub f { state $x; for ^4 { state $y; dd [$x++, $y++]; last if $_ > 2} };f;f;f;f | 19:07 | |
camelia | rakudo-moar 68b66c: OUTPUT«[0, 0][1, 1][2, 2][3, 3][4, 0][5, 1][6, 2][7, 3][8, 0][9, 1][10, 2][11, 3][12, 0][13, 1][14, 2][15, 3]» | ||
psch | that is clearly correct, statement mod if doesn't block scope, so yeah | ||
m: sub f { state $x; g($x++) }; sub g($x) { state $y; say $x, $y++ };f;f;f;f; | |||
camelia | rakudo-moar 68b66c: OUTPUT«00112233» | ||
psch | ...are loop block that different to new subs? | 19:08 | |
Zoffix | hm? | ||
psch | Zoffix: well, my last example prints the same that the loop example does on jvm | ||
Zoffix | I'm not sure what you mean by 'clearly correct'. The output in my eval is buggy. The numbers should be increasing the same. `last` seems to re-init state | 19:09 | |
psch | Zoffix: i wasn't talking about your code | ||
Zoffix | Ah. Sorry | ||
psch | Zoffix: i was talking about mine, the statement level if | ||
Zoffix | m: sub f { state $x; for ^4 { state $y; dd [$x++, $y++]; next if $_ > 2} };f;f;f;f | 19:10 | |
camelia | rakudo-moar 68b66c: OUTPUT«[0, 0][1, 1][2, 2][3, 3][4, 0][5, 1][6, 2][7, 3][8, 0][9, 1][10, 2][11, 3][12, 0][13, 1][14, 2][15, 3]» | ||
psch | i actually kind of want to assume moar does right | ||
mostly ad authoritam, though :P | |||
which is annoying, 'cause it means another icky bug on nqp-j | 19:11 | ||
Zoffix | I don't think we need to make any assumptions. Initialization of state happens just once. That isn't the case on MoarVM. | 19:14 | |
Here's Perl 5's version too: $ perl -E 'sub f { state $x; for (1..4) { state $y; print $x++ . " " . $y++ . " | "; last if $_ > 2} };f;f;f;f' | |||
0 0 | 1 1 | 2 2 | 3 3 | 4 4 | 5 5 | 6 6 | 7 7 | 8 8 | 9 9 | 10 10 | 11 11 | | |||
psch | right, i was mostly complaining about exactly that assumption :) | 19:15 | |
*of mine | |||
ugexe | m: my $s := (^5).rotor(3, :partial).map: -> $c { slip(@$c) }; my $buf = Buf.new($s || 0); say $buf.perl # lizmat: this is the golf | 19:20 | |
camelia | rakudo-moar 68b66c: OUTPUT«Buf.new(0,3,4)» | ||
ugexe | its always index 1 and 2 | ||
lizmat | ugexe: it's really weird | 19:21 | |
ugexe | seems related to rotor somehow | ||
lizmat | I'm looking at !push-list in src/core/Buf | ||
and it's getting a BOOTInt (no .WHAT associated with that) | |||
which makes the nqp::istype fail, which in turn makes it croak | 19:22 | ||
now, an int +& 0xFF should create an Int, so no idea *how* it becomes a native | |||
ugexe | m: my $s := (^5).rotor(3, :partial).map: -> $c { slip(@$c) }; my $buf = Buf.new($s); say $buf.perl | 19:24 | |
camelia | rakudo-moar 68b66c: OUTPUT«Buf.new(0,1,2,3,4)» | ||
psch | lizmat: maybe inlining? | 19:25 | |
i mean, it sounds like it could be from not-guarded-enough inlining | |||
lizmat | yeah, feels like that, because it's also a Heisenbug: adding debug text to infix:<+&> fixes the problem it seems :-( | ||
ugexe | m: my $s := (^5).rotor(3, :partial).map: -> $c { slip(@$c) }; say $s.elems; my $buf = Buf.new($s || 0); say $buf.perl | 19:26 | |
camelia | rakudo-moar 68b66c: OUTPUT«5Buf.new(0,1,2,3,4)» | ||
dalek | ast: 2fb0068 | usev6++ | S32-list/combinations.t: Skip test on JVM that started to die recently |
19:27 | |
lizmat | ugexe: I just fixed the problem by adding an nqp::say to the +& candidate that is *not* being called :-( | 19:32 | |
timotimo | oh lord :( | 19:33 | |
ugexe | m: my $s := (^5).rotor(3).map: -> $c { slip(@$c) }; say $s.elems; my $buf = Buf.new($s || 0); say $buf.perl | 19:34 | |
camelia | rakudo-moar 68b66c: OUTPUT«3Buf.new(0,1,2)» | ||
ugexe | m: my $s := (^5).rotor(3).map: -> $c { slip(@$c) }; my $buf = Buf.new($s || 0); say $buf.perl # oops | ||
camelia | rakudo-moar 68b66c: OUTPUT«Buf.new(0)» | ||
lizmat | ugexe: I'm focusing on: | ||
m: my int $i = 10; say Buf.new($i +& 0xFF) | |||
camelia | rakudo-moar 68b66c: OUTPUT«Type check failed in initializing element #0 to Buf; expected uint8 but got Int (10) in any at gen/moar/m-Metamodel.nqp line 1736 in block <unit> at <tmp> line 1Actually thrown at: in any at gen/moar/m-Metamodel.nqp line 3055 in any…» | ||
lizmat | j: my int $i = 10; say Buf.new($i +& 0xFF) | 19:36 | |
camelia | rakudo-jvm cd19db: OUTPUT«Type check failed in initializing element #0 to Buf; expected uint8 but got Int (10) in any at gen/jvm/Metamodel.nqp line 1725 in block <unit> at <tmp> line 1Actually thrown at: in any at gen/jvm/Metamodel.nqp line 3044 in any at ge…» | ||
lizmat | hmmm... so it is actually consistent across backends! | ||
I'm starting to feel this is something related to the method caching algorithm | 19:46 | ||
somehow confusing (Int:D \a, Int:D \b) with (int $a, int $b) | 19:47 | ||
ugexe | lizmat: when I first ran into this I manually iterated through commits and got the method caching commit from around the same time | ||
lizmat | if I remove the infix:<+&>( int $a, int $b ) candidate altogether, it's ok :-( | 19:48 | |
dalek | ast: a1c52ba | usev6++ | S04-phasers/in-loop.t: Add test for RT #126001 |
19:51 | |
synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=126001 | ||
ugexe | my int $i = 10; say Buf.new($i +& 0xFF) works with --optimize=0 or 1 | 19:57 | |
timotimo | that's a good tip. so maybe it's compile-time-deciding what candidate to use for +& there? | 19:58 | |
lizmat | the profile for the above code is bizarre | 20:00 | |
ugexe++ | 20:01 | ||
ugexe | fwiw gist.github.com/ugexe/baa168a64189...812724f76d (after-after.pm6) would "always fails first time after `rm -rf lib/.precomp` with a segfault but always passes all subsequent runs" | 20:02 | |
lizmat | ok, it's definitely some kind of mixup between candidates | 20:17 | |
if I add an nqp::null to the int/int candidate, all is fine | |||
if I add a "nqp::say("foo") to the Int:D/Int:D candidate, it does *not* get executed, and I get the error | 20:18 | ||
dalek | ast: 47b646c | (Zoffix Znet)++ | S24-testing/line-numbers.t: Use `like` instead of ok() with smartmatch |
||
lizmat | so it looks like it is calling the int/int candidate with incorrect parameters | ||
timotimo | i wonder if the thing you're adding is preventing the static optimizer from setting the inline info on the sub? | ||
lizmat | could well be | 20:19 | |
I mean, an nqp::null in sink context... what could it do? :-) | 20:20 | ||
timotimo | hm, we should be able to grab the node attribute out of the qast when we do the "add inline info" and build a little "report" about all the things that do get inline info | ||
lizmat | timotimo: how? | ||
another way to fix the issue, is to add an .Int to the result of the nqp::bitand_i in the int/int candidate | 20:21 | ||
so at least it gets the right type of return value (for this case) | |||
timotimo | well, we should be able to just print out "code object named 'foobar' on line 1234 got inline info" or "failed to make inline info for reason $foo" and parse that with a tiny script | 20:22 | |
lizmat | m: say Buf.new(12354352413543265165462154654261546573625765389836927693761897681768271768726187623876876812763876128366524165465241 +& 0xFF) | 20:23 | |
camelia | rakudo-moar 68b66c: OUTPUT«Buf:0x<99>» | ||
lizmat | m: say Buf.new(1235435241354326516546215465426154657362576538983692769376189768176827176872618762387687302909283098210983209820139803126812763876128366524165465241 +& 0xFF) | ||
camelia | rakudo-moar 68b66c: OUTPUT«Buf:0x<99>» | 20:24 | |
lizmat | always 0x99, seems odd ? | ||
timotimo: ok, where do I add this debug info ? | |||
timotimo | i think the method is in Actions somewhere? | 20:25 | |
literally "add_inline_info" | |||
actually, i think it has "try" in its name | |||
lizmat | add_inlining_info_if_possible | ||
dalek | ast: 49ef2b1 | usev6++ | S11-modules/require.t: Change back to dir that contains executable When this testfile was run before 'make install' it blowed up on rakudo-j because executable './perl6-j' was not found in 't/packages/packages'. Probably a precompilation process was started in that dir. |
20:26 | |
timotimo | that's it | ||
it's not straightforward to get the line number out of a node attribute, i believe | |||
you have to go through the compiler object i think? | 20:27 | ||
there's other places that should show you how it's done | |||
lizmat | timotimo: so the plan is to actually prevent it from being inlined ? | 20:31 | |
timotimo | er, maybe? | ||
lizmat | if so, that feels wrong to me, as the inlining is just exposing the bug | ||
timotimo | i'm not so sure | ||
i thought that report thing would be a debug help | |||
lizmat | we have an Int:D/Int:D and an int/int candidate | ||
it calls the int/int candidate with the Int:D/Int:D parameters | 20:32 | ||
*that* is the issue, as far as I can see | |||
which smells like a method cache issue | |||
to me | |||
timotimo | but don't we generate code in that case to make it still work right? | ||
i dunno :( | |||
i think we used to have - or maybe still do have - trouble picking the native candidates properly in the static optimizer? i'm not sure any more what that was about :( | |||
dalek | ast: 35eaee5 | (Zoffix Znet)++ | S04-statements/for.t: [TODO FUDGE] ("{$_}") inside for loop has correct value RT#128054 |
20:35 | |
synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128054 | ||
timotimo | my suggestions may be absolutely useless :| | 20:40 | |
lizmat | fwiw, RT #128655 | 21:13 | |
synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128655 | ||
dalek | kudo/nom: 242baf2 | lizmat++ | src/core/Int.pm: Temporary fix for RT #128655 By removing the int/int candidates for now, we can at least ensure correct functionality. |
21:15 | |
synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128655 | ||
ast: e0330b7 | lizmat++ | S03-operators/buf.t: Add tests for RT #128655 |
21:28 | ||
synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128655 | ||
raiph | psch: Zoffix: Aiui: state vars are init'd per "closure clone". `sub ...` creates a closure clone each time the declaration is called. usually once in a program. `loop ...` creates and loops a closure clone each time it's called. Or something like that. I think moar's output is correct. | 21:29 | |
lizmat | hope jnthn has some insights tomorrow | ||
good night, #perl6-dev! | 22:04 | ||
timotimo | gnite liz | ||
Zoffix | raiph, and Perl 5 is wrong? And state is pretty much useless? I disagree. | 22:05 | |
In fact, your reasoning is flawed in that `state` works fine in the loop, it's the last/next that break it, not the loop. | 22:06 |