[00:00] *** timo left [00:00] *** TempIRCLogger joined [00:00] *** discord-raku-bot joined [00:00] *** timo joined [00:02] *** reportable6 left [00:03] *** reportable6 joined [01:03] *** quotable6 joined [01:04] *** melezhik left [01:22] *** melezhik joined [01:30] *** melezhik left [02:17] *** rakuUser left [04:03] *** quotable6 left [04:03] *** notable6 left [04:03] *** nativecallable6 left [04:03] *** evalable6 left [04:03] *** statisfiable6 left [04:03] *** tellable6 left [04:03] *** squashable6 left [04:03] *** bloatable6 left [04:03] *** greppable6 left [04:03] *** unicodable6 left [04:03] *** linkable6 left [04:03] *** coverable6 left [04:03] *** committable6 left [04:03] *** benchable6 left [04:03] *** sourceable6 left [04:03] *** reportable6 left [04:03] *** bisectable6 left [04:03] *** releasable6 left [04:03] *** shareable6 left [04:04] *** evalable6 joined [04:04] *** benchable6 joined [04:05] *** committable6 joined [04:05] *** coverable6 joined [04:05] *** statisfiable6 joined [04:05] *** linkable6 joined [04:06] *** bloatable6 joined [04:06] *** unicodable6 joined [04:06] *** nativecallable6 joined [04:06] *** tellable6 joined [04:06] *** greppable6 joined [04:06] *** releasable6 joined [05:04] *** shareable6 joined [05:07] *** reportable6 joined [06:02] *** reportable6 left [06:03] *** reportable6 joined [06:04] *** notable6 joined [06:05] *** bisectable6 joined [06:06] *** squashable6 joined [06:09] *** squashable6 left [06:10] *** Razetime joined [06:11] *** squashable6 joined [07:31] *** frost joined [08:06] *** sourceable6 joined [09:55] *** evalable6 left [09:55] *** linkable6 left [09:56] *** linkable6 joined [09:56] <[Tux]> Rakudo v2021.08-20-g57841911f (v6.d) on MoarVM 2021.08-9-g4b7ffe3af [09:56] <[Tux]> csv-test-xs-20 0.373 - 0.378 [09:56] <[Tux]> test-t --race 1.000 - 1.089 [09:56] <[Tux]> csv-ip5xs 1.162 - 1.238 [09:56] <[Tux]> test-t 1.955 - 2.120 [09:56] <[Tux]> test 8.947 - 9.243 [09:56] <[Tux]> csv-ip5xs-20 10.093 - 10.667 [09:56] <[Tux]> test-t-20 --race 10.832 - 12.109 [09:56] <[Tux]> csv-parser 29.141 - 30.326 [09:56] <[Tux]> test-t-20 35.519 - 35.828 [09:58] ¦ nqp/new-disp: 107 commits pushed by (Jonathan Worthington)++, (Stefan Seifert)++ [09:58] ¦ nqp/new-disp: review: https://github.com/Raku/nqp/compare/3ae8272f45de...83e2ca6d608c [09:58] ¦ rakudo/new-disp: 133 commits pushed by (Jonathan Worthington)++, (Stefan Seifert)++ [09:58] ¦ rakudo/new-disp: review: https://github.com/rakudo/rakudo/compare/bb6bee28412f...5ceb90319554 [10:15] ¦ rakudo/new-disp: 1116b3913e | (Stefan Seifert)++ | src/core.c/Junction.pm6 [10:15] ¦ rakudo/new-disp: Fix overzealous autothreading of Junctions even on Mu parameters [10:15] ¦ rakudo/new-disp: [10:15] ¦ rakudo/new-disp: A Mu type constraint on a parameter is supposed to avoid autothreading of [10:15] ¦ rakudo/new-disp: junctions for that parameter. Usually this is ensured by the the dispatcher [10:15] ¦ rakudo/new-disp: only considering autothreading on bind failures. However when there are [10:15] ¦ rakudo/new-disp: multiple Junction arguments, it's possible that some should be passed through [10:15] ¦ rakudo/new-disp: (i.e. Mu type constraints on the parameters) and some should be autothreaded. [10:15] ¦ rakudo/new-disp: <…commit message has 15 more lines…> [10:15] ¦ rakudo/new-disp: review: https://github.com/rakudo/rakudo/commit/1116b3913e [10:19] Failed to create directory '/home/nine/rakudo/t/04-nativecall/.precomp/E5BEAE0DF29D9477F2D8489D167BE887A1A5B93F/64' with mode '0o777': Failed to mkdir: File exists [10:20] This ^^^ is rather common. Seen it a few times on CI and I suspect it's the reason for those random make test errors I get [10:20] Happens when running highly parallel tests, e.g. TEST_JOBS=20 make test after some change to rakudo [10:28] *** frost left [10:42] *** linkable6 left [10:44] *** linkable6 joined [10:55] *** evalable6 joined [11:06] *** quotable6 joined [12:02] *** reportable6 left [12:29] ¦ rakudo: 87152ebabc | (Elizabeth Mattijsen)++ | 3 files [12:29] ¦ rakudo: Introduce -Msafe-snapper [12:29] ¦ rakudo: [12:29] ¦ rakudo: Snapper functionality that allows you to press Control-c and *still* [12:29] ¦ rakudo: get a Telemetry report. Removes that functionality from -Msnapper. [12:29] ¦ rakudo: [12:29] ¦ rakudo: Problem with Control-c safety is that it will start up the supervisor [12:29] ¦ rakudo: thread to handle the pressing of Control-c, which causes extra load [12:29] ¦ rakudo: and reduces the number of available threads, thus affecting the Telemetry [12:29] ¦ rakudo: data. [12:29] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/87152ebabc [12:29] ¦ rakudo: b451f89b68 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | 3 files [12:29] ¦ rakudo: Merge pull request #4502 from rakudo/safe-snapper [12:29] ¦ rakudo: [12:29] ¦ rakudo: Introduce -Msafe-snapper [12:29] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/b451f89b68 [12:58] lizmat: did you think on the suggestion i had for the safe snapping functionality? [12:58] I must have missed that ? [12:59] OK, what i said was like, the op that you use to subscribe to signals like ctrl-c just asks you to pass a ConcBlockingQueue on which a message is sent when the signal has been sent [13:00] i'm not sure what happens if you subscribe with this op twice, i.e. once with the theoretical supervisorless safe snapper and another time with signal(blah).tap [13:00] but it's possible that that just works fine [13:01] well, that's true on the MoarVM end only, no? [13:02] in any case, nobody had anything to say about the PR, and since it is relatively safe, I merged it [13:02] hm, actually, what "just" happens is that the sub signal uses $*SCHEDULER [13:02] maybe spawning a thread and using SameThreadScheduler is possible here? [13:03] that'd be simpler than stealing the code that uses nqp::signal from signals.pm6 [13:04] plus it looks like you can freely call nqp::signal multiple times [13:05] *** reportable6 joined [13:06] you know, it's not uncommon for programs to react to SIGUSR1 or SIGUSR2 with some status output, for example dd does that [13:06] the snapper could do that as well, dump recorded data so far when it receives that [13:07] perhaps making the signal it uses configurable with something like an env var for cases where your user's program already uses SIGUSR1 for something else [13:12] feels like over-engineering to me atm :-) [13:17] OK [13:27] I'll take PR's :-) [14:17] *** b2gills left [14:18] *** b2gills joined [14:41] *** Razetime38 joined [14:44] *** Razetime left [15:58] *** Razetime joined [16:00] *** Razetime38 left [16:39] *** Razetime left [18:02] *** reportable6 left [19:04] *** reportable6 joined [20:21] *** discord-raku-bot left [20:22] *** discord-raku-bot joined [20:25] *** Xliff joined [22:04] *** evalable6 left [22:04] *** linkable6 left [22:05] *** linkable6 joined [23:06] *** evalable6 joined