šŸ¦‹ 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.
00:28 AlexDaniel joined
AlexDaniel buildable6: info 00:45
buildable6 AlexDaniel, (ā³ Buildingā€¦) 25163 rakudo-moar builds, 7969 archives (49.7 GB); 0 moarvm builds, 0 archives (0 GB)
AlexDaniel niice
02:27 jgaz left
buildable6 AlexDaniel, Done building! 02:48
03:50 AlexDaniel left 05:05 sivoais left 05:14 sivoais joined
bartolin bisectable6: role A[::T $] { also is T }; class B {}; class C does A[B] {}; say C ~~ B ## github.com/Raku/old-issue-tracker/issues/2679 07:11
bisectable6 bartolin, Will bisect the whole range automagically because no endpoints were provided, hang tight
bartolin, Output on all releases: gist.github.com/276bbddda84f53411b...3070f5ab01
bartolin, Bisecting by exit code (old=2021.05 new=2021.06). Old exit code: 1
bartolin, bisect log: gist.github.com/e07aabd2129fa9e663...388b97b956 07:12
bartolin, (2021-06-17) github.com/rakudo/rakudo/commit/4b...109a1f362d
bartolin, Output on all releases and bisected commits: gist.github.com/d181190cbcadb8bcbb...4b9c368500
Geth roast: usev6++ created pull request #841:
Fix tests for arrays that aren't shaped		 08:31
08:40 sena_kun joined 09:51 finanalyst joined
ab5tract_ nine, vrurg: any thoughts on using nqp::dispatch to allow extops like `p6setfirstflag` in RakuAST? 09:55
bartolin bisectable6: role R { method foo () handles <bar> {} } ## github.com/Raku/old-issue-tracker/issues/3721 09:58
bisectable6 bartolin, Will bisect the whole range automagically because no endpoints were provided, hang tight
bartolin, Output on all releases: gist.github.com/b9bcba8df6f001af9f...c937e296b0 09:59
bartolin, More than 3 changes to bisect, please try a narrower range like old=2022.06 new=HEAD
ab5tract_ Right now I have to rig it up as a QAST op. The base compiler massages blocks annotated with `loop-already-block-first-phaser` in `wanted` back into bare blocks, without the FIRST phaser setup code 10:00
we don't have any equivalent hooks in RakuAST that I'm aware of
bartolin bisectable6: old=2022.06 new=HEAD role R { method foo () handles <bar> {} } ## github.com/Raku/old-issue-tracker/issues/3721 10:02
bisectable6 bartolin, Bisecting by exit code (old=2022.06 new=1eaaded). Old exit code: 1
bartolin, and I oop! Backtrace: gist.github.com/6254b3086a5790296d...8e223e357c 10:03
ab5tract_ so I'm trying to implement FIRST phasers through `p6stateinit` but running into other problems. If I could call `nqp::setfirstflag` directly, it might solve my problems.
bartolin: maybe it doesn't actually have head built yet? though I think it should... 10:04
bartolin ab5tract_: good point :) 10:05
ab5tract_ *`nqp::p6setfirstflag`
bartolin bisectable6: old=2022.06 new=2023.09 role R { method foo () handles <bar> {} } ## github.com/Raku/old-issue-tracker/issues/3721
bisectable6 bartolin, Bisecting by exit code (old=2022.06 new=2023.09). Old exit code: 1
bartolin, and I oop! Backtrace: gist.github.com/7b18b714ce53381cb3...27c7192401
ab5tract_ and it probable doesn't have 2022.06 either :.
:/ 10:06
probably more likely to have head, actually.
buildable6: status
buildable6 ab5tract_, (ā³ Buildingā€¦) 25257 rakudo-moar builds, 8063 archives (50.7 GB); 0 moarvm builds, 0 archives (0 GB)
bartolin Strange. It mentioned 2022.06 when I did my first request: gist.github.com/Whateverable/b9bcb...c937e296b0
ab5tract_ okay, then color me confused 10:07
it also seems to have correctly run against HEAD in that report 10:08
bartolin yeah. Maybe it has some temporary problem. I'll re-run the first query to see if that fails now as well.
bisectable6: role R { method foo () handles <bar> {} } ## github.com/Raku/old-issue-tracker/issues/3721
bisectable6 bartolin, Will bisect the whole range automagically because no endpoints were provided, hang tight
bartolin, Output on all releases: gist.github.com/87c34c182fc4423c26...d0a4acb567 10:09
bartolin, More than 3 changes to bisect, please try a narrower range like old=2022.06 new=HEAD
bartolin ok, at least that's the same result
commit: 2022.06,2023.09 role R { method foo () handles <bar> {} } 10:10
committable6 bartolin, Ā¦2022.06: Ā«4===SORRY!4=== Error while compiling /tmp/FmOMPmOdZzā¤No such method 'add_method' for invocant of typeā¤'Perl6::Metamodel::GenericHOW'ā¤at /tmp/FmOMPmOdZz:1ā¤ Ā«exit code = 1Ā»Ā» Ā¦2023.09: Ā«Ā»
bartolin ok, so it seems to be something else 10:11
10:13 committable6 left, committable6 joined
ab5tract_ these bots sure can be finnicky 10:32
GAR! one of these bugs where I can't reproduce via CLI invocation 10:37
buildable6 ab5tract_, Done building! 11:10
ab5tract_ buildable6: dubious :)
buildable6 ab5tract_, I cannot recognize this command. See wiki for some examples: github.com/Raku/whateverable/wiki/Buildable
11:22 finanalyst left
nine ab5tract_: nqp::dispatch would certainly be what would be used today instead of adding ops. 11:49
The more interesting question however is whether we actually need explicit VM support for this feature?
ab5tract_ does nqp::dispatch actually exist? I don't see it in the ops docu
oh, that is an interesting question. I just sort of assumed that it would 11:50
nine We have wanted to get rid of extops for a long time. We could have just moved their implementation into MoarVM proper at any point, but all of them were of rather questionable design. Most of them have already been replaced by better mechanisms. 11:51
ab5tract_ Ah, I guess that's part of why lizmat said "go ahead!" when I asked whether it made sense to try to implement `FIRST` using an implicit state var and `p6stateinit` 11:54
nine Well it does feel like it should be a trivial feature, doesn't it? 11:57
ab5tract_ it does. certainly the wrangling of `p6setfirstflag` seems less compact 12:03
and it works fine for non-map based loops, at least as far as I can tell 12:04
but there is also the problem of `p6stateinit` not being universally applied when used at the compunit level, which I brought up a while ago 12:06
that's an issue in base as well... should have filed a bug report, since now I've forgotten the exact invocation 12:08
FWIW, the issue that I've been facing is that `p6setfirstflag` works fine when used in a single iteration `while` loop using this code: github.com/ab5tract/rakudo/blob/66...umod#L1129 12:12
but when there is more than a single iteration, I get an error from MoarVM: `p6setfirstflag requires a bytecode handle` 12:13
nine Without having gone into the details of the current implementation, if FIRST phasers didn't exist and I had a use for them I'd implemented something like: my $is-first = True; loop { if $is-first { $is-first = False; ... } ... }. Couldn't we just generate code exactly like that without any special ops at all? 12:15
I.e. declare a lexical in the loop's outer scope and just check that. 12:16
ab5tract_ now you're talking :)
nine Are there any crazy edge cases where the naive approach just wouldn't work correctly? 12:19
ab5tract_ well, you need to account for multiple FIRSTs
so you can't wrap it quite so simply as what you have there 12:20
nine You'd need to create a unique name for that lexical anyway, so that should also cover multiple FIRST phasers
ab5tract_ ah, good point
let me see where I can get with that approach 12:21
12:21 sena_kun left
nine That's often the easiest approach to finding the spec tests that show you those edge cases :) 12:22
ab5tract_ one thing that makes switching to your proposal awkward is just how QAST oriented the ScopePhaser code is 12:28
and I also can't pull in implicit lookups there without clashing with inherited classes 12:29
nine Yeah, that ImplicitLookups thing really could do with an API overhaul. E.g. instead of a PRODUCE-IMPLICIT-LOOKUPS method, have an add-implicit-lookup method taking one RakuAST::Lookup and returning the index that can be used to look up the result of the lookup. 12:46
ab5tract_ that would be... amazing
plus just `implicit-lookups` vs `get-implicit-lookups` would match more how we do things in RakuAST 12:48
vrurg Using a lexical might brake inlining at some edge cases, if I'm not mistaken. 13:23
*break
ab5tract_ hmm
is that something which could be fixed? 13:28
because this really does seem like a much cleaner option 13:30
vrurg I don't think so as it's about critical size of a frame for inlining.
ab5tract_ ah
vrurg But MoarVM experts could tell more. Perhaps the influence would be so minor that it could be ignored. 13:31
BTW, it's just crossed my mind that I have no idea how referencing an outer lexical would impact inlining of looping frames. And if it ever would. 13:33
ab5tract_ well, it's not "outer" in the sense that I define it on the loop block 13:37
its outer to the FIRST blorsts though
13:44 AlexDaniel joined
AlexDaniel buildable6: status 13:44
buildable6 AlexDaniel, (ā³ Buildingā€¦) 25293 rakudo-moar builds, 8099 archives (51.1 GB); 0 moarvm builds, 0 archives (0 GB)
vrurg I mean in { my $is-first; for {...} } ā€“ the looping block is the one attached to `for`. It has to reference the $is-first. 13:46
ab5tract_ right 13:49
as long as the declaration is not part of the statement list for the loop block, I think it is safe to attach lexical declarations to it. but we shall soon see 13:51
vrurg So, the question is: where now `for {}` would be inlined, would it still be if it adds a reference to the outer frame? Intuitively I'd say "yes", but not sure about it.
ab5tract_ it could very well be that I need the outer scope indeed 13:52
vrurg Another thing I don't like is the pollution of namespace.
ab5tract_ yeah, but we kind of do that in a lot of places 13:54
vrurg Long ago, before newdisp was invented, I was rising a question of adding a storage space to frames, so we could keep some free form technical details in it. 13:55
Even doing it in many places doesn't make the polluting a good thing. :)
ab5tract_ yeah, I hear you. 14:01
but without `nqp::dispatch`, we would need to implement something like Perl6/Actions.wanted 14:04
I don't think anyone wants that
14:24 lucs left, lucs joined
nine vrurg: If inlining was a problem it would also be one for the manual FIRST implementation I posted above. Luckily MoarVM is too smart for that 14:59
That's actually the charme of this solution: it's using only very high level constructs, so we know that the VM will treat it correctly. Even more so: it allows for the VM to optimize better as it doesn't have to deal with any special cases. It's just plain normal lexical lookup. 15:00
vrurg nine: No frame size, no extra links from one frame to another wouldn't prevent some edge-cases from optimization? My only worry (aside of the namespace pollution) is that when it's 50/50 for inlinling an extra lexical would make it 55/45 against. 15:05
nine Point in case for possible VM optimizations: That loop block may be called a lot. The VM will see just 1 call where the if's condition is True and on all other runs it'll be false. So it will specialize the loop block for the assumption that the condition will be False and replace the whole if $is-first { $is-first = False; ... } block with a cheap guard. This means that the specialized loop block may be a 15:06
lot smaller and get under the max-inline-size.
These are optimizations that we actually do even today. I'm pretty sure the VM doesn't optimize p6setfirstflag in the same way. 15:07
vrurg There is also the outer frame where the lexical is installed. What about that one?' 15:08
nine Lexicals don't increase bytecode size
Btw. the other optimization-friendly implementation of FIRST would be via a special dispatcher. After all dispatchers are how the compiler can teach the VM about optimization opportunities. 15:11
vrurg OK, very good. Then I'd chose some undeclarable name for the symbol, like '!first' so it would clash with absolutely nothing declarable. 15:12
But the dispatcher would need to keep the state somewhere and have the state guarded. 15:13
Perhaps, that'd still be a job for the lexical.
buildable6 AlexDaniel, Done building! 15:22
ab5tract_ a lot of assumptions in `Statement::IfWith` that `$!then` will be a block, not an expression 15:24
getting closer, though
15:36 Util left 15:38 Util joined
Geth rakudo: ab5tract++ created pull request #5406:
DRAFT: RakudoAST: Implement `FIRST` using only AST		 15:41
ab5tract_ well, I've got the AST generating what I *think* we want, but the wrapped blorst (well, so far only looking at blocks) does not actually run: github.com/rakudo/rakudo/pull/5406...2b8a1238a7 15:42
nine: if you can take a look and let me know if I'm at least on track with what you were thinking, I'd really appreciate it :) 15:46
nine Going in the right direction, yes 15:53
16:00 guifa left 16:01 guifa joined 16:08 committable6_ joined 16:10 committable6_ left
AlexDaniel buildable6: status 16:20
buildable6 AlexDaniel, (ā³ Buildingā€¦) 31734 rakudo-moar builds, 8015 archives (51.1 GB); 0 moarvm builds, 0 archives (0 GB)
ab5tract_ did it go backwards? I thought there were more archives than that
AlexDaniel it actually jumped up by 6000 16:21
ab5tract_ oh :O
AlexDaniel it's a funny story, I found that some builds were misnamed
hahahaha
so I fixed that and I think that's how it got to see them now
ab5tract_ I was remembering the less significant numbers, I guess
AlexDaniel I mean, rakudo has 38k commits, so it should be approaching that 16:22
there's a cutoff there at some point
c: all say 42
committable6 AlexDaniel, gist.github.com/0d68f4b96459833034...c7cbb45be9
AlexDaniel c: 2014.01 say 42 ** 5 16:23
committable6 AlexDaniel, Ā¦2014.01: Ā«130691232ā¤Ā»
AlexDaniel yeah, that's as early as you can go, but I think Rakudo has a bunch of commits before that
that's almost 10 years ago actually, can you imagine :)
ab5tract_: to be clear, an ā€œarchiveā€ here means an actual file on the disk, and a ā€œbuildā€ is a usable rakudo sha that you can run code on 16:26
ab5tract_: to achieve 100+ compression ratio whateverable puts multiple builds into a single archive, compressed in a long-range mode 16:27
ab5tract_ ok, interesting
AlexDaniel because rakudo doesn't change that much with every commit, it makes storaging the builds so efficient :) 16:28
the only downside is slower decompression speed
so whateverable stores tagged commits and new commits as plain archives, but anything else is put into these ā€œlong-term storageā€ archives 16:29
all that was developed back in the day when zstd didn't have a long range mode, so lrzip is used for that
I wonder if things can be improved dramatically by switching to zstd fullyā€¦ 16:30
though that being said, everything is already pretty good and there's no real need to change anything :)
s/storaging/storing/ hahaha
ab5tract_ I'll have to take a closer look some time, it sounds interesting 16:36
Geth roast: usev6++ created pull request #842:
Add test for issue 6176 in old issue tracker		 16:37
ab5tract_ why... isn't... this... codepath... running...
this is going to be one of those things that was actually super easy to fix but which stymies me for hours or days 16:39
`QAST::Block with cuid 1 has not appeared` <--- why am I getting cuid 4-6 instead of 1-3? how can the QAST get called twice? 17:13
17:16 sena_kun joined
Geth roast: usev6++ created pull request #843:
Add test for issue 3721 in old issue tracker		 17:26
buildable6 AlexDaniel, Done building! 17:31
AlexDaniel okay, so 17:50
buildable6: status 17:51
buildable6 AlexDaniel, (ā³ Buildingā€¦) 31749 rakudo-moar builds, 8030 archives (51.3 GB); 0 moarvm builds, 0 archives (0 GB)
AlexDaniel now I'll remove 1992 builds
or so I think
buildable6: status 17:53
buildable6 AlexDaniel, (ā³ Buildingā€¦) 30703 rakudo-moar builds, 7896 archives (49.4 GB); 0 moarvm builds, 0 archives (0 GB)
AlexDaniel šŸ¤” 17:54
buildable6: status 18:04
buildable6 AlexDaniel, (ā³ Buildingā€¦) 29852 rakudo-moar builds, 7898 archives (49.4 GB); 0 moarvm builds, 0 archives (0 GB)
AlexDaniel okay, that is now correct, I expected that difference there 18:05
and that concludes my fixups for whateverable
the rest gets fixed with just time 18:06
bartolin AlexDaniel++ 18:08
18:09 linkable6 left 18:10 linkable6 joined
buildable6 AlexDaniel, Done building! 19:38
[Coke] buildable6: status 19:40
buildable6 [Coke], (ā³ Buildingā€¦) 29868 rakudo-moar builds, 7914 archives (49.6 GB); 0 moarvm builds, 0 archives (0 GB)
AlexDaniel it says ā€œDone buildingā€ for a batch of 20 :) Technically that's lying 19:43
but it's designed for the use case when you push something new to the main branch and then wait for it to be built 19:44
[Coke] so it won't wait for 20, but will report on that one? 19:50
19:52 AlexDaniel left
buildable6 [Coke], Done building! 21:42
21:51 AlexDaniel joined
AlexDaniel [Coke]: it will report after it finishes the current batch of 20 21:52
right now that behavior might sound confusing, but it's just because it has a backlog of 3000 commits or so. Usually the bot is idle :) 21:54
22:21 sena_kun left
Geth Ā¦ rakudo: coke assigned to lizmat Issue rakuast pod handling change github.com/rakudo/rakudo/issues/5407 22:41
AlexDaniel c: all say 42 23:47
committable6 AlexDaniel, Ā¦all (94 commits): Ā«42ā¤Ā» 23:48
AlexDaniel yaaay

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!