00:17 MasterDuke joined
MasterDuke . 00:17
tellable6 2024-04-05T14:03:43Z #raku-dev <[Tux]> MasterDuke: tux.nl/Talks/CSV6/speed4-20.html
MasterDuke [Tux]: cool, thanks
00:44 japhb left 00:45 japhb joined 01:31 MasterDuke left
Geth nqp/main: e90292265a | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump MoarVM for MasterDuke++ optimizations
 07:23
rakudo/main: b4d7db184c | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP to get the latest MoarVM optimizations
 07:34
[Tux] Rakudo v2024.03-99-gf0d5a9425 (v6.d) on MoarVM 2024.03-3-gf2220d93d
csv-parser1.565 - 1.568
csv-test-xs-200.141 - 0.142
test1.947 - 1.988
test-t0.419 - 0.426
test-t --race0.279 - 0.280
test-t-205.151 - 5.193
test-t-20 --race1.210 - 1.217
 07:46
gist.github.com/Tux/c783b98595f425...dcc92947f0 07:47
09:17 lizmat_ joined
lizmat_ greppable6: role_to_role 09:19
greppable6 lizmat_, Found nothing!
10:20 lizmat__ joined 10:22 lizmat_ left 10:33 ab5tract left, ab5tract joined
Geth rakudo/main: 87feb40a16 | (Elizabeth Mattijsen)++ | src/vm/moar/ModuleLoaderVMConfig.nqp
Streamline ModuleLoaderVMConfig role
 11:13
12:41 lizmat_ joined, lizmat__ left
Geth rakudo/main: 4cec36b724 | (Elizabeth Mattijsen)++ | src/Perl6/ModuleLoader.nqp
Streamline ModuleLoader (Part 1/N)

  - use nqp::atkey/pos instead of {} and []
  - change for loops to while loops
  - several other shortcuts		 12:44
13:05 lizmat_ left, lizmat_ joined 13:10 lizmat_ left 13:11 lizmat_ joined 13:51 lizmat_ left, lizmat_ joined
nine Is there an actual difference between [] and atpos in NQP? 13:57
lizmat_ [] can serve as a left-value 14:06
as can { } 14:07
afk& 14:08
14:08 lizmat_ left
ab5tract m: use nqp; say nqp::istype(${:a("B")}, Associative); say nqp::istype(${:a("B")}, nqp::gethllsym("Raku", "Associative")); #surprising 14:10
camelia 1
0
lizmat m: dd nqp::gethllsym("Raku", "Associative") 14:24
camelia ===SORRY!=== Error while compiling <tmp>
Could not find nqp::gethllsym, did you forget 'use nqp;' ?
at <tmp>:1
------> dd nqp::gethllsym("Raku", "Associative")⏏<EOL>
lizmat m: use nqp; dd nqp::gethllsym("Raku", "Associative")
camelia Mu
lizmat m: use nqp; dd nqp::gethllsym("Raku", "Foo")
camelia Mu
lizmat ab5tract ^^ 14:25
ab5tract sory, I should have been more specific about what was surprising me: I was surprised that Associative is missing in the Raku HLL 14:26
but I still have a lot to learn about the whole HLL concept, to be honest
lizmat it's simple, really: if nothing does a nqp::bindhllsym('Raku', 'Associative', Associative), then it won't be there 14:29
afk& 14:31
ab5tract I was under the impression that if it was defined in CORE setting, it was bound into the hll lookup thingy. TIL! 14:32
in retrospect the impression I had is obviously impossible, as we are bootstrapping. 14:33
Geth rakudo/is-item-redux: 840e4e16d0 | ab5tract++ | 5 files
Scaffolding for 'is item' trait on parameters
 15:35
rakudo/is-item-redux: a14563be2f | ab5tract++ | 2 files
Add dispatch disambiguation for 'is item'
rakudo/is-item-redux: 8499836dc7 | ab5tract++ | src/Perl6/bootstrap.c/BOOTSTRAP.nqp
(Legacy dispatch) disambiguate itemization with 'is item'
rakudo/is-item-redux: f95f722828 | ab5tract++ | 2 files
Add dispatch disambiguation for 'is item'

This allows for multi routines to distinguish between itemized arguments.
For the sake of simplicity, the parameter trait does not add any new ParamTypeChecks to the parameter. Instead it is only used as a marker for disambiguation in multiple dispatch: ... (6 more lines)		 16:24
rakudo/is-item-redux: 9d34483dfc | ab5tract++ | src/Perl6/bootstrap.c/BOOTSTRAP.nqp
(Legacy dispatch) disambiguate itemization with 'is item'
ab5tract lizmat: when an `is item` candidate is dispatched to, do you reckon that the itemization should remain after it is passed to the routine body? 16:26
right now I haven't implemented that, but it would be a simple enough change 16:27
Geth rakudo/is-item-redux: 4ad3b37fe2 | ab5tract++ | 2 files
Add dispatch disambiguation for 'is item'

This allows for multi routines to distinguish between itemized arguments.
For the sake of simplicity, the parameter trait does not add any new ParamTypeChecks to the parameter. Instead it is only used as a marker for disambiguation in multiple dispatch: ... (6 more lines)		 16:48
rakudo/is-item-redux: c50158bba7 | ab5tract++ | src/Perl6/bootstrap.c/BOOTSTRAP.nqp
(Legacy dispatch) disambiguate itemization with 'is item'
lizmat ab5tract: I'd say, no, as @foo doesn't imply itemization ? 16:59
Geth rakudo: ab5tract++ created pull request #5549:
Add dispatch disambiguation via 'is item' parameter trait		 17:02
rakudo/is-item-redux: 9a646a8141 | ab5tract++ | 5 files
Scaffolding for 'is item' trait on parameters
 17:05
rakudo/is-item-redux: a3758a75fb | ab5tract++ | 2 files
Add dispatch disambiguation for 'is item'

This allows for multi routines to distinguish between itemized arguments.
For the sake of simplicity, the parameter trait does not add any new ParamTypeChecks to the parameter. Instead it is only used as a marker for disambiguation in multiple dispatch: ... (6 more lines)
rakudo/is-item-redux: 1abfd6e676 | ab5tract++ | src/Perl6/bootstrap.c/BOOTSTRAP.nqp
(Legacy dispatch) disambiguate itemization with 'is item'
ab5tract ouch... I guess I will avoid developing on rakudo directly.. I don't like spamming this channel when I inevitably force push some improvements
*rakudo/rakudo 17:06
lizmat: makes sense to me too 17:07
next up: the RakuAST version. but I will avoid implementing that until the current work is discussed and merged 17:22
lizmat would a separate RakuAST version be needed ? 17:27
nine: other differences in NQP between postcircumfix [] and nqp::atpos: 17:31
$ nqp -e 'my $a := nqp::list; my $b := $a[0]; say($b.HOW.name($b))'
NQPMu
$ nqp -e 'my $a := nqp::list; my $b := nqp::atpos($a,0); say($b.HOW.name($b))'
VMNull
same for postcircumfic { } and nqp::atkey 17:32
ab5tract lizmat: yeah, but only the setting up of the trait 17:33
ie, the stuff that's currently in actions
lizmat ack 17:36
nine I think I'll just give up on t/spec/S02-types/generics.t. The code is almost impossible to comprehend. The commit messages don't explain anything and the issue referenced just says something about a 4th part of some epic saga but doesn't really explain anything.
I also don't understand why such extensive work was done on the old frontend without any accompanying work on RakuAST at all. And that in late 2023. I thought we had an agreement that that won't happen.
lizmat yeah, I think we need to revisit generics more generally 17:37
wrt the work: some people needed it *now* rather than *then* 17:38
nine Then they could have had it in their fork of Rakudo 17:39
Rakudo is a collaborative effort, not a dumping ground for people's special needs. 17:40
17:42 MasterDuke joined
lizmat well, afaik generics *were* specced 17:43
so the special need is in the timing, not in the content, I'd say 17:44
MasterDuke huh. i just profiled tools/build/raku-ast-compiler.nqp (the script that's run during the `+++ Generating  gen/moar/ast.nqp` stage) and 90% of the time is spent in run_alt 17:51
lizmat yeah, that's doing a *lot* of processing
MasterDuke 12s in NQP::src/QRegex/NFA.nqp:1044
lizmat so that we don't have to
MasterDuke ~25k lines in the files it processes 17:52
lizmat it's producing a 32K line / 1.6 MB source file 17:53
MasterDuke but i've never seen *any* nqp/rakudo code spend anywhere *near* that amount of time in run_alt 17:54
is it something about the grammar in the script?
lizmat MasterDuke: possibly 17:55
I haven't really dared looking at that yet 17:56
MasterDuke it's not a long script, only 440 lines, but i don't know grammars nearly well enough to tell if there's a slow spot
18:03 kjp left
MasterDuke well, github.com/rakudo/rakudo/blob/main...qp#L71-L87 is where in the script it spends the most time, but i don't know if that's useful information 18:10
lizmat jnthn probably knows, but that looks like a pretty involved token :-) 18:12
japhb moritz might be able to see the problem too, if he's accessible at all 18:13
Although I am kindof curious about the performance of something that combines | and || in one regex "expression" 18:17
ab5tract lizmat: actually, no RakuAST-specific changes are needed 18:20
lizmat yeah, that's what I was thinking :-)
ab5tract pretty slick! 18:21
Geth rakudo/main: c6fb210a94 | (Stefan Seifert)++ | 3 files
RakuAST: resolve generic lexicals in roles at compose time
 18:32
rakudo/main: 1d609daf40 | (Stefan Seifert)++ | src/Raku/ast/variable-declaration.rakumod
RakuAST: prohibit multiple is type traits on variables

Complains correctly about: my @a is Int is Str
japhb Stefan: What do allomorphs look like these days? 18:42
lizmat m: dd <42>.isa(Allomorph) 18:43
camelia Bool::True
lizmat so: my @a is Allomorph
or: my @a is IntStr
m: dd <42e0>.isa(Allomorph) 18:44
camelia Bool::True
japhb TIL .isa()
22:13 kjp joined
Geth rakudo/is-item-redux: 0684f1c50d | ab5tract++ | src/Raku/ast/signature.rakumod
Add sigil exception for 'is item' to RakuAST
 22:17
ab5tract so there was one small detail missing for is item in RakuAST after all 22:18
now to bed&
Regarding the question in #raku-beginner re: matches… I sometimes wish there were a “direct-to-result” option that gave me the actual thing, instead of a match object representation of the thing. But maybe we already have that and I’m just unaware? 22:54
m: dd my Str() @g = “11 22” ~~ /(\d\d)\s(\d\d)/ 23:41
camelia Str(Any) @g = Array[Str(Any)].new("11 22")
ab5tract m: dd my @g = “11 22” ~~ m/(\d\d)\s(\d\d)/
camelia Mu @g = [Match.new(:orig("11 22"), :from(0), :pos(5), :list((Match.new(:orig("11 22"), :from(0), :pos(2)), Match.new(:orig("11 22"), :from(3), :pos(5)))))]

Powered by Cro and the Raku® Programming Language.

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

Thank you!