🦋 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:00 timo left, TempIRCLogger joined, discord-raku-bot joined, 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, notable6 left, nativecallable6 left, evalable6 left, statisfiable6 left, tellable6 left, squashable6 left, bloatable6 left, greppable6 left, unicodable6 left, linkable6 left, coverable6 left, committable6 left, benchable6 left, sourceable6 left, reportable6 left, bisectable6 left, releasable6 left, shareable6 left 04:04 evalable6 joined, benchable6 joined 04:05 committable6 joined, coverable6 joined, statisfiable6 joined, linkable6 joined 04:06 bloatable6 joined, unicodable6 joined, nativecallable6 joined, tellable6 joined, greppable6 joined, 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, linkable6 left 09:56 linkable6 joined
[Tux] Rakudo v2021.08-20-g57841911f (v6.d) on MoarVM 2021.08-9-g4b7ffe3af
csv-ip5xs1.162 - 1.238
csv-ip5xs-2010.093 - 10.667
csv-parser29.141 - 30.326
csv-test-xs-200.373 - 0.378
test8.947 - 9.243
test-t1.955 - 2.120
test-t --race1.000 - 1.089
test-t-2035.519 - 35.828
test-t-20 --race10.832 - 12.109
Geth nqp/new-disp: 107 commits pushed by (Jonathan Worthington)++, (Stefan Seifert)++
review: github.com/Raku/nqp/compare/3ae827...e2ca6d608c
rakudo/new-disp: 133 commits pushed by (Jonathan Worthington)++, (Stefan Seifert)++
review: github.com/rakudo/rakudo/compare/b...eb90319554
rakudo/new-disp: 1116b3913e | (Stefan Seifert)++ | src/core.c/Junction.pm6
Fix overzealous autothreading of Junctions even on Mu parameters

A Mu type constraint on a parameter is supposed to avoid autothreading of junctions for that parameter. Usually this is ensured by the the dispatcher only considering autothreading on bind failures. However when there are multiple Junction arguments, it's possible that some should be passed through
  (i.e. Mu type constraints on the parameters) and some should be autothreaded.
... (15 more lines)
nine Failed to create directory '/home/nine/rakudo/t/04-nativecall/.precomp/E5BEAE0DF29D9477F2D8489D167BE887A1A5B93F/64' with mode '0o777': Failed to mkdir: File exists 10:19
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
Geth rakudo: 87152ebabc | (Elizabeth Mattijsen)++ | 3 files
Introduce -Msafe-snapper

Snapper functionality that allows you to press Control-c and *still* get a Telemetry report. Removes that functionality from -Msnapper.
Problem with Control-c safety is that it will start up the supervisor thread to handle the pressing of Control-c, which causes extra load and reduces the number of available threads, thus affecting the Telemetry data.
rakudo: b451f89b68 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | 3 files
Merge pull request #4502 from rakudo/safe-snapper

Introduce -Msafe-snapper
timo lizmat: did you think on the suggestion i had for the safe snapping functionality? 12:58
lizmat I must have missed that ?
timo 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 12:59
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
lizmat well, that's true on the MoarVM end only, no? 13:01
in any case, nobody had anything to say about the PR, and since it is relatively safe, I merged it 13:02
timo hm, actually, what "just" happens is that the sub signal uses $*SCHEDULER
maybe spawning a thread and using SameThreadScheduler is possible here?
that'd be simpler than stealing the code that uses nqp::signal from signals.pm6 13:03
plus it looks like you can freely call nqp::signal multiple times 13:04
13:05 reportable6 joined
timo 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
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:07
lizmat feels like over-engineering to me atm :-) 13:12
timo OK 13:17
lizmat I'll take PR's :-) 13:27
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, linkable6 left 22:05 linkable6 joined 23:06 evalable6 joined