[00:02] *** reportable6 left [00:05] *** Xliff left [00:05] *** reportable6 joined [01:05] *** coverable6 left [01:05] *** reportable6 left [01:05] *** notable6 left [01:05] *** evalable6 left [01:05] *** linkable6 left [01:05] *** sourceable6 left [01:05] *** tellable6 left [01:05] *** benchable6 left [01:05] *** squashable6 left [01:05] *** quotable6 left [01:05] *** unicodable6 left [01:05] *** bloatable6 left [01:05] *** statisfiable6 left [01:05] *** shareable6 left [01:05] *** committable6 left [01:05] *** releasable6 left [01:05] *** nativecallable6 left [01:05] *** bisectable6 left [01:05] *** greppable6 left [01:06] *** coverable6 joined [01:06] *** shareable6 joined [01:06] *** reportable6 joined [01:07] *** nativecallable6 joined [01:08] *** tellable6 joined [01:08] *** greppable6 joined [01:32] *** frost joined [02:01] *** nine left [02:01] *** nine joined [02:06] *** releasable6 joined [02:06] *** bisectable6 joined [02:06] *** sourceable6 joined [02:07] *** statisfiable6 joined [02:07] *** evalable6 joined [02:07] *** unicodable6 joined [02:07] *** committable6 joined [02:07] *** benchable6 joined [02:08] *** linkable6 joined [03:06] *** bloatable6 joined [03:07] *** notable6 joined [03:08] *** quotable6 joined [04:06] *** [Coke] left [04:06] *** [Coke] joined [04:06] *** squashable6 joined [04:19] *** ugexe left [04:19] *** samcv left [04:19] *** ugexe joined [04:20] *** samcv joined [06:00] good *, #moarvm [06:02] *** reportable6 left [06:05] *** reportable6 joined [07:31] jnthnwrthngtn: https://gcc.gnu.org/gcc-11/changes.html -- Several new features from the upcoming C2X revision of the ISO C standard are supported [...] Labels may appear before declarations and at the end of a compound statement. [07:31] finally... [08:20] *** squashable6 left [08:22] *** squashable6 joined [08:45] *** squashable6 left [09:40] moarning o/ [09:41] Nicholas: Now we just have to wait another decade for it to be widespread enough to use... :/ Or maybe make babel, but for C :D [09:42] \o [09:48] *** squashable6 joined [10:48] *** evalable6 left [10:48] *** linkable6 left [10:49] *** linkable6 joined [10:56] *** sena_kun joined [11:24] anything interesting going on here today? [11:29] my @a = ^1000; for ^10000 { @a[$_] for ^1000 }; say now - INIT now [11:29] m: my @a = ^1000; for ^10000 { @a[$_] for ^1000 }; say now - INIT now [11:29] rakudo-moar 10b327292: OUTPUT: «0.372348021␤» [11:29] m: my @a = ^1000; for ^10000 { @a.AT-POS($_) for ^1000 }; say now - INIT now [11:29] rakudo-moar 10b327292: OUTPUT: «0.34283105␤» [11:31] I sorta expected there to be no noticeable difference between the two [11:35] and yet another Rakudo Weekly News hits the Net: https://rakudoweekly.blog/2021/09/13/2021-37-receding/ [11:42] m: say 0.372 / 0.342 [11:42] rakudo-moar 10b327292: OUTPUT: «1.087719␤» [11:43] It's not that significant, given there's a (mostly optimized away) extra multiple dispatch in there [11:44] To see how well the optimizer is doing at reducing that cost, try timing them with MVM_SPESH_DISABLE=1; I'd imagine the relative difference will be larger. [11:56] *** linkable6 left [11:58] *** linkable6 joined [12:04] *** reportable6 left [12:16] huh, there is a race (?) in Concurrent::Stack it seems. [12:16] ❌ TST: No exception handler located for catch [12:16] ❌ TST: from t/stress.t:15 (:) [12:16] not sure how reproducible this is [13:07] *** reportable6 joined [14:17] No exception handler located for catch [14:17] at SETTING::src/core.c/Exception.pm6:62 (/home/dogbert/.rakudobrew/versions/moar-master/install/share/perl6/runtime/CORE.c.setting.moarvm:throw) [14:17] from SETTING::src/core.c/Failure.pm6:63 (/home/dogbert/.rakudobrew/versions/moar-master/install/share/perl6/runtime/CORE.c.setting.moarvm:throw) [14:17] from SETTING::src/core.c/Failure.pm6:93 (/home/dogbert/.rakudobrew/versions/moar-master/install/share/perl6/runtime/CORE.c.setting.moarvm:Int) [14:17] from SETTING::src/core.c/atomicops.pm6:154 (/home/dogbert/.rakudobrew/versions/moar-master/install/share/perl6/runtime/CORE.c.setting.moarvm:infix:<⚛+=>) [14:19] *** leont left [14:19] *** leont joined [14:19] it's reproducible then, I guess [14:20] dogbert11: Can you run it with --ll-exception? [14:20] jnthnwrthngtn: sure, gimme a sec [14:22] sena_kun: yes [14:22] I guess that means also a regression, maybe thanks to one of the recent changes [14:23] https://gist.github.com/dogbert17/136be8a876cb6a5ab2de229a0396de18 [14:24] let me know if you want something more done [14:25] MVM_SPESH_DISABLE and MVM_JIT_DISABLE too [14:25] ok ... [14:26] There's not that many commits sicne the last blin run though so can also bisect it between MoarVM HEAD and the bump before last [14:27] while MVM_SPESH_DISABLE=1 MVM_JIT_DISABLE=1 perl6 -Ilib --ll-exception t/stress.t; do :; done # this also fails after a number of iterations. Stack trace is the same. [14:28] jnthnwrthngtn, it bisects to the last rakudo bump [14:30] sena_kun: Yes but it's the MoarVM commit that causes it that is of particular interest I think [14:31] Although...wow, if spesh being disabled doesn't affect it, that's...well, we don't really have more commits to look at [14:31] Every single MoarVM change is a spesh/jit one [14:31] jnthnwrthngtn, well, Blin doesn't bisect moar revisions between bumps. [14:35] sena_kun: I figured; thus why it's worth doing manually on MoarVM commits [14:35] I just fail to see a likely candidate [14:49] No exception handler located for catch [14:49] dogbert@dogbert-VirtualBox:~/repos/p6-concurrent-stack$ perl6 -v [14:49] Welcome to 𝐑𝐚𝐤𝐮𝐝𝐨™ v2021.08-27-g10b327292. [14:49] Implementing the 𝐑𝐚𝐤𝐮™ programming language v6.d. [14:49] Built on MoarVM version 2021.08-9-g4b7ffe3af. [14:49] so, it's present on master as well [14:51] Oh [14:53] *** frost left [14:53] it usually take a few iterations for it to fail so blin might have been easily fooled [14:57] jnthnwrthngtn: I have a new-disp bug if you're interested [14:58] try this if you're bored :) # while MVM_SPESH_NODELAY=1 ./rakudo-m -e 'sleep 1; sub f($str) { my $num = +$str; }; f "3.0/2"'; do :; done [14:59] * dogbert11 goes for an afternoon walk [15:10] *** linkable6 left [15:25] <[Coke]> build failure on windows for new-disp [15:25] <[Coke]> https://gist.github.com/coke/f17a5e56c0c36c492990357b81d82a53 [15:26] <[Coke]> https://github.com/MoarVM/MoarVM/blob/new-disp/src/jit/expr.c#L705 [15:26] <[Coke]> Dynamic array sizign. [15:27] Huh, and MSVC doesn't support that? [15:28] That's crap. [15:28] It's only been in the C standard for 22 darn years. [15:28] Wonder if it supports alloca [15:30] <[Coke]> I am using VS 2017. Maybe I need to update [15:33] I can't remember what we actually support. [15:33] I thought "something that does C99", but it might be "something that does more of C99 than MSVC used to" [15:33] i do believe it supports alloca [15:35] Ah, they don't plan to ever support VLAs, it seems... https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-support-arriving-in-msvc/ [15:37] vla is kind of tasty [16:11] *** linkable6 joined [17:27] *** sena_kun left [18:02] *** reportable6 left [18:26] *** kjp left [18:28] *** kjp joined [18:51] *** evalable6 joined [19:05] *** reportable6 joined [19:26] I went back to moar-2019.11 and the problem exposed by Concurrent::Stack is present there as well [20:03] *** squashable6 left [21:03] *** reportable6 left [21:03] *** statisfiable6 left [21:03] *** linkable6 left [21:03] *** sourceable6 left [21:03] *** committable6 left [21:03] *** evalable6 left [21:03] *** bisectable6 left [21:03] *** nativecallable6 left [21:03] *** unicodable6 left [21:03] *** benchable6 left [21:03] *** shareable6 left [21:03] *** greppable6 left [21:03] *** notable6 left [21:03] *** quotable6 left [21:03] *** bloatable6 left [21:03] *** releasable6 left [21:03] *** tellable6 left [21:03] *** coverable6 left [21:03] *** releasable6 joined [21:04] *** sourceable6 joined [21:04] *** linkable6 joined [21:04] *** benchable6 joined [21:04] *** coverable6 joined [21:05] *** squashable6 joined [21:05] *** quotable6 joined [21:06] *** evalable6 joined [21:06] *** nativecallable6 joined [21:31] dogbert11: Wow, so not a new-disp regression after all. Thanks for checking. [22:03] *** unicodable6 joined [22:04] *** tellable6 joined [22:05] *** greppable6 joined [22:05] *** notable6 joined [22:06] *** shareable6 joined [22:06] *** bloatable6 joined [22:11] *** Xliff joined [22:31] *** Mutter joined [22:32] timo: btw, while the directives dyn variable is never explicitly set, another variable is bound to it and then pushed to, that’s how it gets populated [22:40] can you point me to where that happens? my searching has turned up nothing [22:40] https://github.com/Raku/nqp/blob/9858768b7720d26e803fe1a0bfdc6b738826ae36/src/HLL/World.nqp#L194 [22:42] 760: my @clds := @*comp_line_directives; [22:42] *** squashable6 left [22:42] not this right? [22:42] That’s it [22:42] ok interesting, where is the dynamic variable ever declared though? [22:43] Dunno/don’t remember [22:44] *** squashable6 joined [22:44] Obviously the overall mechanism works somehow, but like I (MasterDuke) said before, it was implemented a long time ago, so it may be ripe for improvement [22:45] are these directives the things that give us the #?line 0 blah.nqp feature? [22:45] Yeah [22:46] And so you can give a name/label to EVALs [22:51] I though I don’t remember if it’s actually specced or not [22:52] i think its not a language feature [22:58] Does your commit break either of those? [22:59] IMPOSSIBLE [22:59] it actually gets entries [22:59] uiaedturianedutrinaedtruinaetdruinaetdruinaetdruniae [23:02] i do not understand. [23:03] ? [23:04] *** bisectable6 joined [23:05] *** committable6 joined [23:05] *** statisfiable6 joined [23:06] without a declaration, how are we finding a dynamic variable of that name? [23:07] Magic I guess? [23:07] No declaration needed in NQP? [23:08] if you dont declare something you get nqpnull, but this is @ sigiled so i think it gives you an array anyway [23:09] like can you find any mention of comp line directives that is preceded by a my that declares it? im losing my mind here?!? [23:09] nqp: say(nqp::isnull($*blah)) [23:09] nqp-moarvm: OUTPUT: «0␤» [23:10] nqp: say(($*blah)) [23:10] nqp-moarvm: OUTPUT: «␤» [23:10] how do we check in nqp if a dynamic variable lookup failed? [23:10] isconcrete? [23:12] nqp: sub a() { nqp::push(@*a, 1); say(nqp::elems(@*a)) ; a; a; a;a; a; a; [23:12] nqp-moarvm: OUTPUT: «Unable to parse expression in blockoid; couldn't find final '}' at line 2, near ""␤ at gen/moar/stage2/NQPHLL.nqp:1053 (/home/camelia/rakudo-m-inst-1/share/nqp/lib/NQPHLL.moarvm:panic)␤ from gen/moar/stage2/NQPHLL.nqp:1073 (/home/camelia/rakudo-m-inst-1…» [23:12] nqp: sub a() { nqp::push(@*a, 1); say(nqp::elems(@*a)) }; a; a; a;a; a; a; [23:12] nqp-moarvm: ( no output ) [23:12] hum? [23:13] nqp: say(nqp::isconcrete($*blah)) [23:13] nqp-moarvm: OUTPUT: «0␤» [23:13] nqp: say(nqp::isconcrete(@*blah)) [23:13] nqp-moarvm: OUTPUT: «1␤» [23:13] Ah ha [23:13] so this shows we get a list allocated for us when the lookup fails [23:14] but it would have to be the same list eaäch time for the behaviour im seeing [23:15] nqp: sub a() { say(nqp::objectid(@*a)) }; a; a; a;a; a; a; [23:15] nqp-moarvm: ( no output ) [23:15] so what am i doing wrong here [23:16] Are parens required? [23:16] nqp: sub a() { say(nqp::objectid(@*a)) }; a(); a(); a();a(); a(); a(); [23:16] nqp-moarvm: OUTPUT: «22665816␤22665816␤22665816␤22665816␤22665816␤22665816␤» [23:16] apparently [23:17] well this is frickin weird [23:17] nqp: sub a() { say(nqp::objectid(@*a)); say(nqp::objectid(@*a)); }; a(); a(); a();a(); a(); a(); [23:17] nqp-moarvm: OUTPUT: «21513000␤21513000␤21513000␤21513000␤21513000␤21513000␤21513000␤21513000␤21513000␤21513000␤21513000␤21513000␤» [23:17] but where does it go tho [23:18] That great big dyn array in the sky? [23:19] nqp: sub a() { say(nqp::objectid(@*a)); }; sub m() { say(nqp::objectid(@*a)); }; a(); a(); m();m(); a(); m(); [23:19] nqp-moarvm: OUTPUT: «35862472␤35862472␤35862472␤35862472␤35862472␤35862472␤» [23:21] nqp: sub a() { say(nqp::objectid(@*a)); }; sub m() { say(nqp::objectid(@*a)); }; sub x() { a(); m(); }; a(); a(); x(); m();m(); a(); m(); [23:21] nqp-moarvm: OUTPUT: «17618104␤17618104␤17618104␤17618104␤17618104␤17618104␤17618104␤17618104␤» [23:26] does that mean that line directives leak between evals as well? [23:26] im practicing with my new keyboard and its slow and frustrating so i dont really want to write a lot of code to test this hypothesis right now [23:27] I’m on my phone, so likewise [23:28] ha [23:34] *** Mutter left