🦋 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: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm
Set by lizmat on 8 June 2022.
MasterDuke lizmat: yeah, i knew you weren't working in core.d stuff, but the code is calling `is_array_type`, which was recently changed in 039dbe495be5eb9a211c9e596f4e91e7aa1f3089 00:58
linkable6 (2024-04-02) github.com/rakudo/rakudo/commit/039dbe495b Streamline Metamodel::ArrayType
tellable6 2024-04-03T09:20:54Z #raku-dev <lizmat> MasterDuke: no idea, the error location file I haven't touched yet
MasterDuke i added some more info in the gist and i'll keep investigating
nine: huh, thanks for fixing that. the odd thing is i did in fact run a test and a spectest on the branch with `RAKUDO_RAKUAST=1` and compared the results with running on main and they were the same, but obviously i did something wrong... 00:59
Geth rakudo/main: 555f4b0049 | (Daniel Green)++ | src/Perl6/Metamodel/ArrayType.nqp
Revert 039dbe4 for the JVM backend

This unbreaks its build. I think the JVM backend doesn't support TEAK this early in the build, but I'm not 100% certain.		 01:53
nqp/main: 30 commits pushed by (Daniel Green)++, MasterDuke17++
review: github.com/Raku/nqp/compare/196708...906e170584		 02:07
rakudo: MasterDuke17++ created pull request #5548:
Adapt Rakudo to using fastutil for the JVM backend		 02:35
rakudo/main: 5 commits pushed by (Daniel Green)++, MasterDuke17++ 04:10
07:23 MasterDuke left
nine "The .literalize method attempts to create literal HLL objects for the given RakuAST::Node object, and returns Nil if for some reason it is impossible to do so." 07:30
Except that it doesn't: literalize on RakuAST::WhateverCode::Argument NYI at SETTING::src/core.c/RakuAST/Literalize.rakumod:154
Geth rakudo/main: fe279b0516 | (Stefan Seifert)++ | src/Raku/ast/expressions.rakumod
RakuAST: implement interpretation of postfix operations
 08:25
rakudo/main: 65f349a5cb | (Stefan Seifert)++ | src/Raku/ast/expressions.rakumod
RakuAST: throw the appropriate error for negative array index literals
08:55 sena_kun joined
ab5tract Plot twist: in the base compiler, target=ast output does not include optimization 09:10
This is probably mostly a benefit, but when looking into a situation where optimize=off makes your changes work as expected, it is certainly an important detail to know 09:11
Related conclusion: Lexicals lowered by the optimizer do not respond equivalently to ParamTypeCheck calls 09:13
lizmat MasterDuke: if reverting 039dbe495be5eb9a211c would fix the JVM build, then there's something really weird going on 10:17
tellable6 lizmat, I'll pass your message to MasterDuke
linkable6 (2024-04-02) github.com/rakudo/rakudo/commit/039dbe495b Streamline Metamodel::ArrayType
lizmat MasterDuke: because basically the only thing that that changed, was how is_array_type is implemented, and if nqp::not_i(nqp::isnull(...)) doesn't work on JVM, we have a bigger issue? 10:19
tellable6 lizmat, I'll pass your message to MasterDuke
10:50 [Tux] left 10:55 [Tux] joined
Geth rakudo/main: ea0aa21d7f | (Stefan Seifert)++ | 3 files
RakuAST: support .&{...} method calls
 11:10
rakudo/main: ca0d17087d | (Stefan Seifert)++ | src/Raku/ast/expressions.rakumod
RakuAST: Support hypering of hash indexing
lizmat ab5tract: FWIW TIL :-) 11:11
re target=ast
nine: 1003! 11:38
[Tux] ............This type (NQPRoutine) does not support positional operations 11:47
in method require at /pro/3gl/CPAN/rakudo/install/share/perl6/site/sources/FE0EA2E16CD0CD31716830FEE610E9B4116A2281 (Inline::Perl5) line 1057
in method use at /pro/3gl/CPAN/rakudo/install/share/perl6/site/sources/FE0EA2E16CD0CD31716830FEE610E9B4116A2281 (Inline::Perl5) line 1163
in block <unit> at csv-ip5pp.pl line 8
Rakudo v2024.03-86-gca0d17087 (v6.d) on MoarVM 2024.03-1-g69a06919c
csv-ip5xs0.253 - 0.263
csv-ip5xs-201.119 - 1.136
csv-parser1.567 - 1.607
csv-test-xs-200.141 - 0.143
test1.930 - 1.942
test-t0.419 - 0.434
test-t --race0.272 - 0.294
test-t-205.150 - 5.280
test-t-20 --race1.220 - 1.229
 11:48
0.419 is in the top-5, but all top 5 is now 0.419 or 0.420 :) 11:49
lizmat greppable: $!composed_repr 12:37
greppable6 lizmat, Found nothing!
lizmat greppable: composed_repr
greppable6 lizmat, 1 line, 1 module: gist.github.com/45362187e5b6c67cf3...00fdf2e88c
lizmat funny that greppable doesn't spot $!composed_repr, but does find composed_repr 12:39
and naughty Inline::Perl5 :-)
Geth rakudo/main: 406ad16bb9 | (Elizabeth Mattijsen)++ | src/Perl6/Metamodel/REPRComposeProtocol.nqp
Streamline Metamodel::REPRComposeProtocol

  - replace for loops by while loops
  - centralize composing
Sadly, it was not possible to make the $!composed_repr an int attribute, as that broke Inline::Perl5		 12:51
lizmat greppable: is_array_type 13:01
greppable6 lizmat, Found nothing!
lizmat greppable: array_type
greppable6 lizmat, 40 lines, 5 modules: gist.github.com/4f4e9d11904f97db80...fd1004e2d2
nine class Bar is ::Foo # What does the double-colon here mean? 13:14
lizmat GLOBAL::Foo ?? 13:15
m: class A { }; dd A =:= ::A
camelia Bool::True
lizmat m: class A { }; {dd A =:= GLOBAL::A 13:16
camelia ===SORRY!=== Error while compiling <tmp>
Missing block
at <tmp>:1
------> class A { }; {dd A =:= GLOBAL::A⏏<EOL>
expecting any of:
postfix
statement end
statement modifier
statement mo…
lizmat m: class A { }; dd A =:= GLOBAL::A
camelia Bool::True
lizmat actually, looks like it's UNIT:: 13:17
m: my class A { }; { dd A =:= UNIT::A }
camelia Bool::True
lizmat m: my class A { }; { dd A =:= GLOBAL::A }
camelia Bool::False
lizmat m: my class A { }; { dd A =:= ::A }
camelia Bool::True
nine m: my ::T $i; dd $i 13:27
camelia Method T.raku not found
in block <unit> at <tmp> line 1
lizmat m: my ::T $i; say $i 13:28
camelia Method T.gist not found
in block <unit> at <tmp> line 1
nine Looks like we're accepting type captures in places where this syntax can only mean global type lookup
lizmat m: my ::T $i; dd $i.^methods>>.name
camelia No such method 'methods' for invocant of type
'Perl6::Metamodel::GenericHOW'
in block <unit> at <tmp> line 1
lizmat yeah, GenericHOW's find_method always returns nqp::nnull
Geth rakudo/main: e64145d284 | (Stefan Seifert)++ | 4 files
RakuAST: fix "is" trait with parameterized type

in my @a is Array[Int] we treated the brackets as array constructor and were quite confused about that.		 13:29
rakudo/main: a4b6c4019b | (Stefan Seifert)++ | src/Raku/Grammar.nqp
RakuAST: disambiguate global lookup vs type capture in "is" traits

In class Bar is ::Foo { } we parsed ::Foo as a type capture leading to a confusing error message. Instead it should be parsed as a global lookup
  (i.e. short for GLOBAL::Foo) which just looks the same.
nine 1005
lizmat nine++
Geth rakudo/main: 392213dd80 | (Elizabeth Mattijsen)++ | src/Perl6/Metamodel/GenericHOW.nqp
Streamline Metamodel::GenericHOW

  - don't bother with BUILDALL, since the only attributes that need
   to be set, are set with set_name already
  - some re-arranging of ifs to ternaries		 13:48
lizmat afk for a few hours&
14:08 vrurg_ joined, vrurg left
Geth rakudo/is-item: b547b75bb0 | ab5tract++ | src/Perl6/Actions.nqp
'is item' works fine with --optimize=off
 14:23
ab5tract This part is kind of blowing my mind to be honest
the feature works as expected as long as you are not using the optimizer 14:24
it also works in the signature of pointy blocks: -> @a is item { dd @a }($[1,2]) 14:25
I've done all sorts of tryouts in the optimizer, skipping the lowering of lexicals (no effect), skipping the visiting of the sub based on name, and about a bazillion debug states of my own.. nothing has really cleared anything up yet 14:28
If someone with more QAST knowledge could take a look at the before/after of optimization for `sub q(@a is item) { dd @a }; q $[5,6];`, I'd _really_ appreciate it: gist.githubusercontent.com/ab5trac....qast.dump 14:36
nine ab5tract: Inconsistent bind result is the result of QAST not agreeing with the information in the meta-object. 14:37
ab5tract the main thing that I've noticed (aside from the changes to lexical `@a` / `__lowered_lex__1`) is the conversion of `call` to callstatic`
nine I.e. QAST checks fail on something that according the the signature's flags should pass
ab5tract nine: right, I haven't bothered to fix the bind
*binder code 14:38
the notable thing here is that the first, unoptimized QAST succeeds. the second QAST fails
nine So what's the failure you get from the optimizer? 14:39
So binder is fine with unoptimized but fails on optimized?
ab5tract the binder is only interacted with when the call fails 14:40
it's really only there to give a sensible exception
another way to put it is that the unoptimized QAST computes fine by the VM, but the optimized QAST doesn't 14:41
nine Not entirely true. There are also situations where we need the full binder
ab5tract well, let's just say for this instance
it would be weird that the optimized path hits the fulle binder when the unoptimized doesn't, right? 14:42
again, for this case
From the code that dies with the inconsistent bind result: '# Run full binder to produce an error.' 14:47
I spent a lot of time chasing my tail through the binder code trying to understand why it was irrelevant for the case I was trying to dispatch :) 14:48
nine: does anything else jump out at you? could it be related to the conversion of `QAST::Op(call &q)` to `QAST::Op(callstatic &q)` ? 14:51
nine And that is the result of an assertparamcheck failing but the binder thinking it should have been successful.
No, that should only affect finding the routine to call 14:52
ab5tract FWIW I'm adding the proper check to the binder now 14:59
nine Worst case it'll at least tell you why the call got rejected 15:02
Maybe the problem in your test is actually at the caller's side 15:03
ab5tract it could be... but the how of that is beyond me. it works in signatures attached to pointy blocks, for example 15:04
maybe if I follow this down the road a bit: 15:05
m: use nqp; sub s(@a is raw where { nqp::iscont($_) }) { say nqp::iscont(@a) }; s $[1,2];
camelia 1
Geth rakudo/is-item: f9ff6a11b1 | ab5tract++ | src/Perl6/bootstrap.c/BOOTSTRAP.nqp
Add error checking to Binder to remove inconsistent bind result ambiguity
 15:13
ab5tract nine: it looks like the only inconsistency in the bind is indeed the fact that the ParamTypeCheck added by the `is item` check fails with optimized QAST. but it was a good to remove the ambiguity in any case 15:15
nine So what does it say now why it fails? 15:20
ab5tract `Parameter '@a' only accepts an itemized argument` 15:21
this is what I set the error to when it encounters this failure in the binder 15:23
it looks perfect now without the optimizer: gist.github.com/ab5tract/972c29df4...nt-5012274 15:27
(note that it was already working before, just without a targetted error message) 15:28
in case it helps readability, I've split the before and after optimization QASTs into two separate files in the gist 15:32
nine: I'm a bit surprised why you would expect fixing the binder to return something other than said fix to the binder. am I holding something wrong here? 15:46
nine I expected that to give you a better idea of why the call fails in the first place. After all you do expect the call to succeed, don't you? Since it's not succeeding, it would be interesting to know why. 15:49
According to that message you just don't get an itemized argument which makes it reasonable for the call to fail. Now the question is, why don't you get one? 15:50
ab5tract One answer to that question: because of changes made by the optimizer 15:54
When I change ParamTypeCheck to include a QAST chain that calls `say __lowered_param__1.VAR.WHAT`, I get `Array` with optimization and `Scalar` without (for `$[]` 15:55
there's a `.raku` in that `VAR.WHAT` method chain, for good measure. 15:58
nine Which is consistent with you not getting an itemized argument 16:01
Geth rakudo/main: 54854d9304 | (Stefan Seifert)++ | src/Raku/ast/expressions.rakumod
RakuAST: fix .= calls on non-Scalar containers

Fixes "Cannot assign to an immutable value" on my @a = 1, 2; @a .= sort;		 16:04
nine 1015 16:05
ab5tract oh snap!
nice one :D
lizmat cool! 16:06
greppable: instantiate_generic
greppable6 lizmat, 1 line, 1 module: gist.github.com/6351b48a48f122f964...0bf2b861b6
ab5tract Re: the consistency of not getting an itemized argument.. yes, it is indeed consistent with that. But I wasn't surprised about not getting an itemized argument, that's been clear for a few days now. What I'm struggling with is understanding what the optimizer is doing and how I can fix it :) 16:07
lizmat greppable6: is_default_generic 16:13
greppable6 lizmat, Found nothing!
ab5tract it's the conversion of `call` to `callstatic` 16:50
the former's documentation says "this documentation is missing" and the latter's documentation is conspicuosly absent 17:04
nine Huh....how? 17:08
ab5tract also, TIL that the "soft" pragma exists
nine: I was hoping you might know! 17:09
Geth rakudo/main: 3a70c5034a | (Stefan Seifert)++ | 2 files
RakuAST: Fix block topic not being raw enough

In $_ = 1 for @a we want to be able to write to $_. For this we added the "is raw" trait to the generated signature for the expression thunk. However this trait was ineffective as it never got applied. The signature gets generated after BEGIN time effects have already happened. Fixing this is not easy as to run BEGIN we need a resolver and context ... (5 more lines)		 17:11
nine 1019 17:13
ab5tract on a roll! 17:14
I can't seem to find the implementation of `callstatic` in MoarVM 17:16
nine Because there is none. github.com/Raku/nqp/blob/main/src/....nqp#L1757 17:17
ab5tract :O 17:18
maybe it's this.. github.com/Raku/nqp/blob/b9906e170....nqp#L1553 17:19
nine But that's about the callee, i.e. the sub itself 17:20
ab5tract good point.. just checked with MVM_SPESH_DISABLE, just in case, and that doesn't fix anything 17:38
yeah, this is super confusing.. the lines nine linked to basically show that call and callstatic dispatch to the same exact sub 19:12
but `$call.op('callstatic') unless nqp::getenvhash<WTF> eq '3';` in Optimize.nqp definitely makes the whole thing succeed 19:15
evidence: gist.githubusercontent.com/ab5trac....%2520diff 19:19
lizmat vrurg_: re generics, perhaps a crazy idea: 19:20
1. each "instantiate_generic" method should be able to handle the null-case (as in, no instantiation needed)
2. change all "is_generic" checks to nqp::can(..., 'instantiate_generic') and call it when it can 19:21
why? because I feel that the current check whether something is generic through the archetypes, is potentially much more expensive than an nqp::can() 19:22
and a null-return can actually quickly be handled in dispatch (perhaps with a dedicated dispatch handler)
this should also reduce bytecode footprint significantly and thus allow for more progressive inlining 19:23
vrurg_ But this is why the dispatcher for ClassHOW archetype. It is supposed to take care of the check.
19:23 vrurg_ is now known as vrurg
vrurg Another thing, what if someone needs to know if something is generic or not? 19:24
The instantiation process itself can avoid asking for is_generic result the way you propose. That's gonna be beneficial. But for introspection purposes it'd be for worse. 19:26
lizmat hmmm ok, good point... but other than that, is there something essentially wrong with my idea?
Question: why would one need to know whether a type is generic or not ? 19:27
vrurg No, I rather like it. As you noticed, it would even be easier for dispatchers to optimize it. Inlining? I doubt a bit, but a couple of methods, perhaps, would get small enough. 19:28
lizmat ok, I'm pretty tired right now, will look into the feasibility tomorrow 19:29
vrurg Have a good rest! It's so easy to burn out... 19:31
ab5tract the only difference between the `call` and `callstatic` that I can find is here: github.com/Raku/nqp/blob/b9906e170....nqp#L1615 20:05
but that just seems to be about looking up the routine in question, so how does it end up affecting an argument passed to that routine? 20:15
erm, sorry: I meant that the dfifference lies here: github.com/Raku/nqp/blob/b9906e170....nqp#L1542 20:32
21:12 MasterDuke joined
MasterDuke lizmat: i don't think it was is_array_type was implemented, but that $!array_type wasn't getting set in the TWEAK 21:15
tellable6 2024-04-04T10:17:23Z #raku-dev <lizmat> MasterDuke: if reverting 039dbe495be5eb9a211c would fix the JVM build, then there's something really weird going on
2024-04-04T10:19:17Z #raku-dev <lizmat> MasterDuke: because basically the only thing that that changed, was how is_array_type is implemented, and if nqp::not_i(nqp::isnull(...)) doesn't work on JVM, we have a bigger issue?
linkable6 (2024-04-02) github.com/rakudo/rakudo/commit/039dbe495b Streamline Metamodel::ArrayType
MasterDuke btw nine++, jdv++, lizmat++, lots-of-people++, cool to see the progress being made 21:16
[Tux]: could you make a page with graphs for test-t-20? might be easier to see changes with that one now that test-t has gotten so much faster 21:18
Geth rakudo/main: 037fab6c95 | (Daniel Green)++ | src/Perl6/Metamodel/GenericHOW.nqp
Fix typo in JVM part of 392213d
 21:46
lizmat MasterDuke++ 21:54
MasterDuke: irclogs.raku.org/raku-dev/search.h...=test-t-20 21:58
22:02 sena_kun left 23:27 MasterDuke 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!