🦋 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:07 reportable6 left 01:07 linkable6 left, evalable6 left, bisectable6 left 01:10 reportable6 joined, bisectable6 joined 02:08 evalable6 joined 03:41 frost joined
japhb vrurg: What's the current status of Vikna? Now that new-disp is done, does it Just Work, or is it necessary to be on one or more branches to make it work still? 05:09
06:07 reportable6 left 06:10 linkable6 joined 07:10 linkable6 left, bisectable6 left, sourceable6 left, greppable6 left, nativecallable6 left, releasable6 left, notable6 left, unicodable6 left, shareable6 left, committable6 left, tellable6 left, coverable6 left, evalable6 left, squashable6 left, benchable6 left, statisfiable6 left, bloatable6 left, quotable6 left 07:11 benchable6 joined, greppable6 joined, linkable6 joined 07:12 tellable6 joined, bisectable6 joined, bloatable6 joined 07:13 notable6 joined, shareable6 joined, sourceable6 joined 07:14 unicodable6 joined 08:08 reportable6 joined 08:11 squashable6 joined, statisfiable6 joined 08:13 releasable6 joined, evalable6 joined, nativecallable6 joined
MasterDuke m: dd Array[Str]("a", "b", "c")   # huh, for some reason i wouldn't have expected this to work, it looks like a C-style cast to me. the syntax that's printed (with the .new) is what i'm used to 08:37
camelia Array[Str].new("a", "b", "c")
09:11 committable6 joined 09:12 coverable6 joined 09:13 quotable6 joined
lizmat Files=1351, Tests=117889, 347 wallclock secs (36.25 usr 9.56 sys + 4789.12 cusr 390.35 csys = 5225.28 CPU) 09:26
vrurg ^^ this seems a lot more than it was, will check again tomorrow if this was a fluke
10:20 discord-raku-bot left, discord-raku-bot joined 10:23 Geth__ joined 10:25 Geth left
Geth__ rakudo: 59929f0a23 | (Elizabeth Mattijsen)++ | src/core.c/Any.pm6
Make dd output consistent for arrays and hashes
 10:41
rakudo: a8498e8ae2 | (Elizabeth Mattijsen)++ | src/core.c/Any.pm6
Fix Nil warning in dd
 11:00
rakudo: b2f0a9d22e | (Elizabeth Mattijsen)++ | src/core.c/Array.pm6
Remove check for nullness of descriptor

Apparently, Arrays nowadays always have a descriptor
11:01 Geth__ left, Geth joined
Geth rakudo: 95d6062334 | (Elizabeth Mattijsen)++ | src/core.c/Any.pm6
Fix dd for nameless things

This will make [1,2] just show as '[1,2]' instead of as
  'Array % = [1,2]'		 11:21
11:50 Altai-man joined 12:07 reportable6 left
Geth rakudo: MasterDuke17++ created pull request #4701:
Remove some no longer needed CALL-MEs		 13:01
13:10 reportable6 joined 13:38 carlmasak joined
Geth rakudo: 25ca2064cb | (Daniel Green)++ | 3 files
Remove some no longer needed CALL-MEs

I'm not exactly sure as of when these aren't needed, but likely after new-disp landed.		 13:57
rakudo: 9d58b5dce7 | MasterDuke17++ (committed using GitHub Web editor) | 3 files
Merge pull request #4701 from MasterDuke17/remove_some_no_longer_needed_CALL-MEs
MasterDuke i'm guessing the reason we don't run spectests in rakudo's CI is that it'd take too long. but what if we created one new job that doesn't run rakudo tests and instead runs a spectest?
the current linux jobs take ~10m, of which the rakudo tests take ~4m. we know we have up to ~25m, because that's how long the windows jobs take
so that would give us ~20m for a spectest run 13:58
13:59 Geth left, Geth joined
nine Both test and spectest are important. They do test different things 14:02
MasterDuke so you're saying we deliberately don't want to run spectests in CI? 14:03
nine No, I mean that we should still run tests as well 14:05
MasterDuke oh yeah, i was just proposing one entirely new CI entry that runs a spectest instead of the rakudo tests 14:06
i.e., a new one of these github.com/rakudo/rakudo/blob/mast...ml#L36-L97 14:07
Altai-man MasterDuke, that's likely not the best idea, because our spectest is flappy and people are already suspicious of the CI for being flappy by itself, then you multiply failures from both worlds. 14:09
14:10 frost left
MasterDuke i think the only pure-CI flappiness is when the windows builds sometimes die saying they can't find the nqp version. otherwise i believe all the flappiness is in spectests/rakudo/nqp/moarvm. but i'm not convinced that it's so terribly flappy right now that there's no value 14:12
nine has fixed a lot of the worst flappers
i'll PR adding it, just to see if it's feasible. we can always disable that job even if it's added, at least then we have something to turn back on 14:14
Altai-man yup, that's partly my point. when your normal tests are flappy and the spec is flappy we'll just get more annoyance when an innocent PR are not passing.
vrurg japhb: new-disp still have some functionality unimplemented. But worse, I don't have that much time for Vikna as I used to. :( 14:17
Geth rakudo: MasterDuke17++ created pull request #4702:
Add CI job that runs a spectest instead of Rakudo tests		 14:23
vrurg lizmat: There are some tests added. But that's unlikely the primary reason. And I didn't see much difference in my runs. There could be some slowdown because certain cases may require fallback to .ACCEPTS.Bool. And some routines could become uninlinable because of a few additional ops to correctly handle junctions or regexes. But on the other hand where types of operands (especially RHS) are inferrable things must get faster. 14:33
lizmat: 2021.12, specs as of Dec 20: Files=1349, Tests=117851, 121 wallclock secs (36.52 usr 7.46 sys + 4725.38 cusr 335.11 csys = 5104.47 CPU) 14:41
lizmat: master, specs master: Files=1351, Tests=117866, 119 wallclock secs (35.41 usr 7.31 sys + 4764.75 cusr 331.95 csys = 5139.42 CPU)
lizmat vrurg: yeah, we'll find out tomorrow, after I had a spectest run on a cold CPU 15:12
vrurg lizmat: since I've got a dedicated workstation, I don't do it my macbook anymore. It just can't be trusted. :) 15:13
Geth rakudo: 7ef7b6eddf | (Daniel Green)++ | azure-pipelines.yml
Add CI job that runs a spectest instead of Rakudo tests
 15:14
rakudo: d12a00b8a8 | MasterDuke17++ (committed using GitHub Web editor) | azure-pipelines.yml
Merge pull request #4702 from MasterDuke17/add_a_CI_job_that_runs_a_spectest_instead_of_rakudo_tests
[Coke] wonder if we could do benchmark runs that tracked CPU cycles used instead of wallclock; I know jnthn occasionally reports out that way for some of his more micro-benches. 15:15
MasterDuke i do that occasionally when i'm testing something locally, the problem is that it's really slow. i would like to add a bunch of benchmarks to our CI, but haven't gotten around to it 15:17
15:29 Geth left, reportable6 left, discord-raku-bot left, quotable6 left, coverable6 left, committable6 left, nativecallable6 left, evalable6 left, releasable6 left, statisfiable6 left, squashable6 left, unicodable6 left, sourceable6 left, shareable6 left, notable6 left, bloatable6 left, bisectable6 left, tellable6 left, linkable6 left, greppable6 left, benchable6 left, sena_kun left, [Coke] left, sjn left, MasterDuke left, bartolin left, Kaiepi left, lucs left, tonyo left, ugexe left, zostay left, camelia left, kawaii_ left, dogbert11 left, djinni` left, moon-child left, SmokeMachine left, nebuchadnezzar left, leont left, rba left, JRaspass left, jdv left, masak left, Altai-man left, kjp left, Voldenet left, gfldex left, maettu_ left, sivoais left, TempIRCLogger left, eof left, jjatria left, ilogger2 left, nine left, vrurg left, samcv left, timo left, rypervenche left, tbrowder left, Util_ left, codesections left, Xliff left, andinus left, samebchase left, [Tux] left, japhb left, qorg11 left, lizmat left, carlmasak left 15:32 timo joined, samcv joined, vrurg joined, nine joined, ilogger2 joined, jjatria joined, codesections joined, Util_ joined, tbrowder joined, rypervenche joined, carlmasak joined, rba joined, leont joined, zostay joined, camelia joined, nebuchadnezzar joined, SmokeMachine joined, moon-child joined, djinni` joined, ugexe joined, dogbert11 joined, tonyo joined, kawaii_ joined, lucs joined, MasterDuke joined, Kaiepi joined, bartolin joined, sjn joined, [Coke] joined, sena_kun joined, benchable6 joined, greppable6 joined, linkable6 joined, tellable6 joined, bisectable6 joined, bloatable6 joined, notable6 joined, shareable6 joined, sourceable6 joined, unicodable6 joined, squashable6 joined, statisfiable6 joined, releasable6 joined, evalable6 joined, nativecallable6 joined, committable6 joined, coverable6 joined, quotable6 joined, discord-raku-bot joined, reportable6 joined, Geth joined, Xliff joined, andinus joined, samebchase joined, [Tux] joined, JRaspass joined, jdv joined, masak joined, TempIRCLogger joined, eof joined 15:33 japhb joined, qorg11 joined, lizmat joined, Altai-man joined, kjp joined, Voldenet joined, gfldex joined, maettu_ joined, sivoais joined
japhb I think my last comment got lost in the netsplit, resending .... 15:41
Well, what kinds of things do people want to have benchmarked? Writing good benchmark suites is a fair amount of work, so if I were to put some energy into it, I'd want it to be stuff people actually care about. (I've written a lot of benchmarks over the years that aren't used.)
MasterDuke oh sure, benchmarks are hard. but right now we don't really have anything other than what people report. we can look at other projects for inspiration (e.g., i believe rust has a bot that runs benchmarks on PRs and reports the data) 15:45
japhb Oh, it's not the framework I'm curious about, we've got a lot of bot creators and can make that happen. I'm actually asking *what things do people want to test*? What do people care about knowing the long term performance of? [Tux]'s CSV tests and the runtime of roast have been the closest we've had to that long-term 15:53
MasterDuke parsing, regex interpolation 15:58
16:03 carlmasak left 16:20 discord-raku-bot left 16:21 discord-raku-bot joined 16:37 discord-raku-bot left 16:38 discord-raku-bot joined
[Tux] Rakudo v2021.12-74-gd12a00b8a (v6.d) on MoarVM 2021.12-11-g39e9a6be0
csv-ip5xs0.874 - 0.894
csv-ip5xs-205.603 - 5.858
csv-parser4.181 - 4.233
csv-test-xs-200.410 - 0.416
test7.031 - 7.066
test-t1.664 - 1.717
test-t --race0.931 - 0.968
test-t-2024.216 - 24.764
test-t-20 --race7.382 - 8.061
 17:02
[Coke] Comparison of the effects of gradual typing (e.g. adding types to method sigs) 17:40
japhb [Coke]: Was that a benchmark suggestion? 17:50
tonyo japhb: i have long term plans of adding benchmark stuff to either fez or zef, that'll probably happen after i get the regression roaster for modules reporting correctly for osx/linux/unix/windows 18:01
the Bench module is a straight port of the Benchmark module from perl with an enhancement to use the hires timer when available
[Coke] japhb: yes.
18:06 linkable6 left, reportable6 left 18:08 reportable6 joined, linkable6 joined 18:40 Altai-man left 18:41 squashable6 left 18:44 squashable6 joined
Geth rakudo: 8321ce10da | (Elizabeth Mattijsen)++ | src/core.c/Proc/Async.pm6
Re-imagine PR 2425

The PR was basically accepted and needed its conflicts solved. It appeared easier to just re-imagine the PR and reduce any overhead a little.		 19:06
rakudo: 27ede8cb0e | (Elizabeth Mattijsen)++ | src/core.c/Capture.pm6
Re-imagince PR 3276

The original PR was unsalvageable.		 20:16
rakudo: 56b57f617d | Altai-man++ (committed using GitHub Web editor) | t/05-messages/03-errors.t
Test return constraints for role implementors (#3249)

Closes github.com/rakudo/rakudo/issues/2385		 20:18
20:19 linkable6 left
Geth rakudo/WHY-on-role-group: 1000 commits pushed by 37 authors
review: github.com/rakudo/rakudo/compare/a...52c06a0300		 20:24
rakudo/WHY-on-role-group: 01567ff731 | (Elizabeth Mattijsen)++ | src/Perl6/Metamodel/ParametricRoleGroupHOW.nqp
Add curly that was missed in a conflict fix

Unfortunately, this shows that there are two different opinions about what the method !get_default_candidate means. I have insufficient fu to fix that one.		 20:37
22:12 Xliff left 22:33 Geth left 22:34 Geth__ joined 22:49 sena_kun left 22:51 sena_kun joined 23:19 Geth__ left, Geth joined 23:20 RakuIRCLogger__ left

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!