🦋 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.
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
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")
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
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
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
Geth rakudo: MasterDuke17++ created pull request #4701:
Remove some no longer needed CALL-MEs		 13:01
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
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
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
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
[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.
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
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

Powered by Cro and the Raku® Programming Language.

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

Thank you!