🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | log inspection situation still under development | For MoarVM see #moarvm
Set by lizmat on 22 May 2021.
00:02 reportable6 left 01:05 reportable6 joined 02:18 [Coke] left 02:19 [Coke] joined
releasable6 Next release in ≈6 days and ≈15 hours. 4 blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 03:00
03:19 evalable6 left, linkable6 left 03:21 linkable6 joined 03:41 [Coke] left 04:02 [Coke] joined 04:21 evalable6 joined 04:28 kjp left 04:31 kjp joined 05:31 bisectable6 left, greppable6 left, committable6 left, reportable6 left, sourceable6 left, quotable6 left, shareable6 left, coverable6 left, releasable6 left, unicodable6 left, squashable6 left, statisfiable6 left, tellable6 left, benchable6 left, nativecallable6 left, linkable6 left, notable6 left, bloatable6 left, evalable6 left 05:32 releasable6 joined, quotable6 joined, tellable6 joined, bloatable6 joined 05:33 greppable6 joined, linkable6 joined 05:34 reportable6 joined, notable6 joined, benchable6 joined 06:02 reportable6 left 06:12 dogbert12 joined 06:32 nativecallable6 joined 06:33 coverable6 joined 06:34 shareable6 joined 07:03 reportable6 joined 07:29 Xliff joined
Xliff \o 07:29
Full suite compilings are going to be cancelled this week due to an increasingly growing number of compiler bugs. 07:30
This makes 3 weeks in a row I've been forced to cancel timing rakudo with my suite of projects. That hasn't happened since I started this almost 2 years ago.
I will be making a bug report with a log of all of the problems in a moment.
nine Xliff: there are 3 open pull requests that should increase stability a lot: github.com/MoarVM/MoarVM/pull/1612 github.com/MoarVM/MoarVM/pull/1611 github.com/MoarVM/MoarVM/pull/1610 07:31
Xliff: could you try with those merged? 07:32
Xliff nine: Hmm.... I can try. Let me let this single project finish, write up the bug report and then download a fresh version of rakudo for merging.
Be forewarned, I am awake in the middle of the night, so at any point in that list, there is a significant risk of napping. 07:33
So here's hoping I can get this done within the next 8 or so hours. :/
07:33 sourceable6 joined 07:34 committable6 joined
Xliff If all goes well, it should take me less than 90 minutes. 07:34
nine PR #1611 definitely fixes the Glib build issue you reported on this channel
Xliff Checking 07:50
OK. I will reorder. I will go ahead and merge these and recompile. 07:52
Then bug report whatever remains.
nine: Getting this on configure - "Unhandled exception: Bytecode validation error at offset 126, instruction 20: 07:58
operand type 64 does not match register type 56 for op sp_guardobj in frame <dependencies+deserialize>"
nine: Running compile. Takles about 10-15 minutes. 08:09
*argh* 08:32
Was looking good until near the end.
08:33 evalable6 joined
Xliff nine: Looks like a parsing error: "No such private method 'SET-SELF' on Map" 08:34
:q!
nine: Also not repeatable, so it is a flapper. Filing the new bug report now. 08:37
08:44 lizmat_ joined 08:45 RakuIRCLogger left, Geth left 08:46 lizmat left
Xliff github.com/rakudo/rakudo/issues/4655 08:53
nine: Thanks for the hard work! 08:54
If someone can fix 4655 this week, I can do late timings.
timo bug reproduction goes rr 09:24
09:33 bisectable6 joined 09:34 squashable6 joined, unicodable6 joined
moon-child haha 09:55
10:00 nebuchad` is now known as nebuchadnezzar 10:34 statisfiable6 joined 10:36 lizmat_ left, TempIRCLogger joined 10:42 Xliff_ joined
lizmat Files=1349, Tests=117873, 310 wallclock secs (34.93 usr 9.34 sys + 4309.06 cusr 340.35 csys = 4693.68 CPU) 11:03
nine So far no joy catching it in rr 11:14
11:30 _Xliff joined 11:59 gfldex__ joined 12:00 gfldex__ left, gfldex__ joined, gfldex__ left 12:02 reportable6 left 12:03 Guest33 joined
timo bt whenever you use rr, i find it very useful to use the "mark stdio" flag that gives you event numbers you can use to jump to whatever moment outputted some text, which is especially helpful in multi-process situations 12:24
12:27 Guest33 left
[Tux] Rakudo v2021.10-128-gad1fddbb3 (v6.d) on MoarVM 2021.10-115-g54aa83655
csv-ip5xs0.855 - 0.861
csv-ip5xs-205.281 - 5.306
csv-parser4.196 - 4.209
csv-test-xs-200.412 - 0.413
test7.183 - 7.209
test-t1.629 - 1.661
test-t --race0.964 - 1.029
test-t-2024.021 - 24.546
test-t-20 --race7.878 - 7.967
12:45
14:03 andinus left 14:05 reportable6 joined 14:30 Xliff left 14:46 Xliff joined
Xliff OK, so I have rr going as well. 14:50
So far, no good. I was hoping to use the parallel builder to speed things up, but aparently rr thought of that and set things to uniproc. 14:51
And its ssllllooooowwww
14:53 _Xliff left
nine Xliff: remember to use a MoarVM with --debug and --no-optimize. Otherwise a rr recording is significantly less useful 15:18
Meanwhile I've let my computer work on this for hours without catching a single failure :(
Xliff Crap. I didn't compile with --no-optimize 15:19
nine You only need to re-compile MoarVM and make install. No need to re-install anything else 15:21
Xliff Actually had to restart the ICal build because I went back to non-patched rakudo after reboot. 15:22
nine But if you have an rr recording of a failure, that's great even without --no-optimize. It's just a lot harder to dump interesting data, since the compiler often optimizes away function arguments and you have to look it up in upper callframes
Xliff Rerunning now. Takes over 700 seconds for ICal
I'm runnind with --debug only. Will recompile with --no-optimize afterwards. 15:23
Since you didn't trigger with --no-optimize, I want to cover different ground. :) 15:24
nine Well I can reproduce the error without rr. Even got it with --ll-exception 15:29
Xliff Ah. That's good. 15:32
Wow. Captured data is over 2G in size, now.
I still have over 2T, so I should be good. =) 15:33
Where does rr keep stdout? 16:02
timo indirectly, i assume
Xliff OK. 16:03
7.3 G of replay data.
Total compile time: 2804.98617062s 16:11
8.5G capture
timo yeah it does incur some penalty :( 16:12
in terms of speed
Xliff Yeah. I think I captured the wrong thing. I captured the build process. Not the build task. Have to rewrite. 16:14
timo oh no, rr records whole process trees 16:15
it's just very awkward to navigate between processes
two and a half hours before you joined i pointed out the "mark stdio" flag of rr 16:16
it works in replay mode, probably also in record mode
Xliff OK. Each invocation of raku is now getting its own private trace. Will make it easier to find, since its numbered. 16:36
At least as long as I have the scrollback.
And...with that... I nap.
17:09 Xliff left 17:32 Xliff joined 18:02 reportable6 left 18:05 reportable6 joined
nine So far all I can say is that it's not JIT related 18:10
18:43 discord-raku-bot left 19:08 discord-raku-bot joined 19:17 discord-raku-bot left, discord-raku-bot joined 19:22 discord-raku-bot left 19:30 discord-raku-bot joined
Xliff nine: I to have had no luck with rr 19:41
s/to/too/
timo you're probably already using the "chaos mode"? 19:45
20:23 Xliff_ left 22:43 evalable6 left, linkable6 left 22:44 evalable6 joined
releasable6 Next release in ≈5 days and ≈19 hours. 4 blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 23:00
gfldex m: for (1,2; 3,4) -> [$,$] { $++ }; 23:35
camelia ( no output )
gfldex m: for (1,2; 3,4; 5,6) -> [$,$] { $++ };
camelia 5===SORRY!5=== Error while compiling <tmp>
Unsupported use of C-style "for (;;)" loop. In Raku please use: "loop
(;;)".
at <tmp>:1
------> 3for 7⏏5(1,2; 3,4; 5,6) -> [$,$] { $++ };
gfldex Dear Rakudo, I do actually want a semi-list at that spot. 23:36
m: for (1,2; 3,4; 5,6; 7,8) -> [$,$] { $++ };
camelia ( no output )
gfldex :D
m: for [1,2; 3,4; 5,6] -> [$,$] { $++ }; 23:37
camelia ( no output )
gfldex I'm not sure if this is LTA or a false C-ism error. 23:38
23:46 linkable6 joined