🦋 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.
Geth rakudo/main: 88566130ae | (Stefan Seifert)++ | 2 files
RakuAST: properly support natively typed sigilless parameters

Fixes: sub foo(int \i) { bar(i) }; sub bar(int $i) { }		 08:24
rakudo/main: 4ede82f6e1 | (Stefan Seifert)++ | src/Raku/ast/type.rakumod
RakuAST: fix method not found after failing to resolve type
rakudo/main: f20251a5ed | (Stefan Seifert)++ | src/Raku/Actions.nqp
RakuAST: fix missing $?CLASS and $?PACKAGE in augment
nine That makes it 1206 fully bootstrapped.
Btw. I love that last commit. When trying that change I wondered for which obscure problem this code was the wrong solution. Turns out, there wasn't any. Fixed things by just removing that special case. 08:25
patrickb My guess would be that this bit of code was a workaround that did help at some point in the past. 08:38
nine Yep. Probably from an early try to get augment going 08:39
Ah, there used to be a $*PACKAGE.IMPL-CHECK($*R, $*CU.context, 1); which got translated to $*PACKAGE.to-begin-time 08:40
Geth rakudo/bootstrap-rakuast: 25 commits pushed by (Stefan Seifert)++
review: github.com/rakudo/rakudo/compare/9...2a4d00d5e6		 09:25
nine 1219 now
So what will happen first? Me catching up fully bootstrapped with setting compiled with regular grammar? Or the rest of the team finishing spectests on the old setting? :D 09:26
gfldex nine: Please don't forget to set the turning light when overtaking them. You are already breaking the coding speed limit. 09:29
nine Which should not distract from the fact that it's still a ton of work and every little bit of help is greatly appreciated. 09:34
Oh boy....there's a RakuAST vs. spesh bug 09:46
nine Pushed a fix to MoarVM which brings us to 1224 10:23
The RakuAST component of the problem was that even in a method foo(|c) we declare the implicit *%_, which the old frontend doesn't.
Geth nqp/main: ccb993497d | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump MoarVM for various fixes

  - prevent stuff happening at exit (timo++, MasterDuke++)
  - avoid segfault with nqp::objectid in GC (nine++)
  - avoid mis-spec of signatures with multiple slurpies (nine++)		 10:31
lizmat nine: maybe the new frontend shouldn't either 10:33
nine It definitely shouldn't. But apart from bugs like that in spesh it also shouldn't make any semantic difference, so it's just a missing optimization. 10:34
timo makes me wonder if there's any sensible way to make an automatic fuzzer for spesh 10:35
lizmat hmm... got 3 new make test failures after bumping NQP 10:38
not sure whether they are caused by the bump or not :-(
lizmat re-conpiles without the bump 10:39
t/02-rakudo/07-implementation-detail-6.c.t # ditto 6.d.t and 6.e.t
it wasn't the bump 10:43
nine: got spectest failure now *without* RakuAST: t/spec/S06-signature/arity.t 10:56
Slurpy named parameters with type constraints are not supported
since this looks related to .assuming, I'll have a look
Geth rakudo/main: 024827436a | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP for various MoarVM fixes

  - prevent stuff happening at exit (timo++, MasterDuke++)
  - avoid segfault with nqp::objectid in GC (nine++)
  - avoid mis-spec of signatures with multiple slurpies (nine++)		 10:57
lizmat bisectable6: old=2025.02 sub a($a, Mu *%_) { } 11:05
bisectable6 lizmat, On both starting points (old=2025.02 new=f20251a) the exit code is 1 and the output is identical as well
lizmat, Output on both points: «===SORRY!=== Error while compiling /tmp/eF9hJABYjP␤Slurpy named parameters with type constraints are not supported␤at /tmp/eF9hJABYjP:1␤------> sub a($a, Mu *%_<HERE>) { }␤ expecting any of:␤ constraint␤»
lizmat aha
so somehow now the Mu constraint is being added 11:07
lizmat bisectable6: old=2025.02 class A { our method a() { } }; dd &A::a.signature.params[1].type 11:17
bisectable6 lizmat, On both starting points (old=2025.02 new=f20251a) the exit code is 0 and the output is identical as well
lizmat, Output on both points: «Mu␤»
nine Seems like there's at least one case where the generated BUILDALL differs from the interpreting POPULATE 11:39
The latter hllizes bound values while the former doesn't.
lizmat BUILDALL is no longer generated. POPULATE is generated 11:40
BUILDALL is a shim
nine # Attempt to auto-generate a BUILDALL method. 11:41
unless self.declares_method($target, 'BUILDALL')
"Basically a flattened version of Mu.BUILDALL"
nqp::die('Invalid ' ~ $object.HOW.name($object) ~ '.BUILDALL plan: ' ~ $code); 11:42
So forgive me when I use the name that occurs in many more places
Still doesn't change anything about there being a difference
AFAICT it's not actually possible for a routine to receive an NQP hash as argument. It will always be hllized. The only exception seems to be that generated constructor. Thus I would say hllize is just missing from that. 11:53
Geth rakudo/main: 0adcacd4f0 | (Elizabeth Mattijsen)++ | 4 files
Hopefully reduce BUILDALL -> POPULATE confusion

Only comment changes.		 11:54
lizmat nine: what is this affecting? 11:55
the reason I'm asking is that I'm close to getting rid of all compiler services / BUILDPLAN etc. logic in RakuAST
so RakuAST will generate the POPULATE method itself, and the accessor where applicable 11:56
nine github.com/rakudo/rakudo/blob/main...kumod#L331 relies on $lexpad (which may be an nqp::hash) getting bound un-hllized
lizmat so we can get rid of the generate_BUILDPLAN / BUILDPLAN interpreting logic altogether as soon as the Raku bootstrap is merged
nine: it also works the other way around: 12:00
m: use nqp; my %h = :42a; dd nqp::atkey(%h,"a")
camelia element of %h = 42
lizmat so I don't think that's the issue ? 12:01
nine It is: 12:05
m: use nqp; my %h; nqp::iterator(%h)
camelia Cannot iterate object with P6opaque representation (Hash)
in block <unit> at <tmp> line 1
lizmat I guess nqp::atkey is special like that 12:12
Geth rakudo/bootstrap-rakuast: 18106bf302 | (Stefan Seifert)++ | src/core.e/PseudoStash.rakumod
RakuAST: fix reliance on missing hllize in generated POPULATE

Arguments are supposed to be hllized. Apparently this is missing from the generated POPULATE methods, so it wasn't obvious that binding an NQP hash to an attribute via constructor call cannot work as expected.
nine 1225
timo right, a few things can go to the positional or associative delegate slot by default. i think we allow an object to have both a positional and an associative delegate slot, in that case it wouldn't be clear what you would want to iterate? 12:16
nine Sadly t/spec/S02-names/SETTING-6e.t still fails, because it's expecting every comp unit to have a <unit> wrapped in a <unit-outer> scope. The latter fulfils no purpose though and is absent in RakuAST 12:17
I may be biased, but I find SETTING::OUTER::OUTER to get from v6.e to v6.c to be much clearer than SETTING::OUTER::OUTER::OUTER::OUTER 12:18
lizmat agree... and we can fix that on the merge 12:20
anyways, it's not a roast test, so why not adapt that test in the bootstrap-rakuast branch ? 12:21
nine It *is* a roast test 12:24
[Coke] lizmat: did you see the blin run I did a few days ago? 12:28
I only posted the .md in a gist, I didn't open a ticket (yet)
lizmat nine: ah,, yes :-(
missed it
been focused on issues lately :-) 12:29
[Coke] gist.githubusercontent.com/coke/9d...failure.md
there's an issue with .assuming
lizmat ok, looks like there are some .assuming regressions in there 12:31
ok, getting a bit swamped now: will do the weekly first, then look at blin, then look at spectest regression 12:32
nine: then I wonder, should it be a roast test? feels to me that's pretty implementation dependent 12:45
nine I don't know. 12:56
I wish vrurg would explain what issues his fixes actually solve. But as with the generic stuff all commit messages, comments, GitHub issues and PRs basically just give you a wordy "re-wrote a bunch of code to fix some issues" 12:57
Commit message says "Tests to cover fixed CORE loading and pseudo-packages [...] In support of rakudo/rakudo#3055" 12:58
linkable6 RAKUDO#3055 [closed]: github.com/rakudo/rakudo/pull/3055 Re-implement CORE loading sequence
nine That issue says "PR #3040 wasn't a complete fix to the new symbols issue." without further explaining what the "new symbols issues" was 12:59
The referenced PR says "Because loading of all CORE settings caused some tests to fail due to the way SETTING and CORE pseudo-packages behaved, this fix also includes improvements to PseudoStash class"
"some tests to fail" yeah, that is helpful
[Coke] lizmat: I'll plan on one more blin run before this weekend. 13:03
(this weekend) - I am going to do the release on Sunday 13:04
lizmat [Coke]: ok
ok
[Coke] (unless jdv gets really excited about it. :)
nine m: my $a will init { say 'init!' }; 13:07
camelia ( no output )
lizmat that used to work ?
bisectable6: old=2023.01 my $a will init { say "innit" } 13:08
bisectable6 lizmat, Cannot find revision “2023.01” (did you mean “2025.01”?)
lizmat bisectable6: old=2023.02 my $a will init { say "innit" }
bisectable6 lizmat, On both starting points (old=2023.02 new=0adcacd) the exit code is 0 and the output is identical as well
lizmat, Output on both points: «»
lizmat hmmm.. I guess not
Geth rakudo/main: 085953b822 | (Stefan Seifert)++ | src/core.c/Variable.rakumod
Fix accidental execution of stub code when trying to report will phaser NYI
nine No, that was never implemented 13:09
lizmat heh, indeed
nine It's just that the error reporting code was never tested 13:10
lizmat well, it feels a bit weird to test for a NYI in roast ? 13:13
nine Even a single manual test would have uncovered this immediately 13:14
lizmat true 13:17
I guess I didn't :-(
bisectable6: old=2025.02 class A { our method a() { } }; &A::a.assuming(A) 13:21
bisectable6 lizmat, Bisecting by exit code (old=2025.02 new=085953b). Old exit code: 0
lizmat, bisect log: gist.github.com/fb1d471a4e114dd272...03dbbe2de8
lizmat, (2025-03-16) github.com/rakudo/rakudo/commit/51...f688d09d51
[Coke] I agree that NYIs should probably either not be in roast, or either explicitly or implicitly be preventative. 13:22
(because NYI at this point doesn't necessarily mean "we are really going to I this") 13:23
timo would probably make sense to have NYIs as fudged tests?
[Coke] (but if they come out, you'd still need to run those tests somewhere.... rakudo t/?)
still want to make sure that nine's case is covered. 13:24
if they're fudged, we'd miss it, yah?
timo well, they can be fudged to generate a todo that's expected to fail, right?
and i think we can also use fudge to output specific different code per backend? 13:25
lizmat but it's not supposed to fail
timo instead of just marking a single test, or a series of tests as to be skipped
vrurg nine: It was unrealistic to mention all the details anyway. So, github.com/Raku/roast/pull/557 summarizes the changed tests. :) The whole thing started, as I now remember, with the SETTINGS pseudo not doing right. 13:32
nine vrurg: that's again a PR that just says that something is fixed. And it refers to the Rakudo PR that says that "some tests failed" 13:33
JimmyZhuo nine: for 'role E { method e { $!e = 1 }};class F does E { };' , my $package := $!package.meta-object; $package.HOW.has_attribute($package, $!name); can't find $!e. How can I find it/ 13:35
tellable6 2025-03-17T07:55:14Z #raku <patrickb> JimmyZhuo: Ok. Then I understand why you had so much trouble. As not all back ends use a C toolchain and provide respective $CC, ... make variables
JimmyZhuo ah, I am wrong
vrurg nine: Well, no reviewer mentioned that problem back then. My only excuse is that there are even worse commit messages in the log. Event worse it was when they were accompanying incorrect changes to the roast. 13:38
nine It's the same reason why I have given up on generics. Tests expect "instantiated". Commit message just says "Add test for instantiation of a generic class 13:42
In support of rakudo/rakudo#5493"
linkable6 RAKUDO#5493 [closed]: github.com/rakudo/rakudo/pull/5493 Complete generic instantiation 4
nine That issue tells me "The epic saga continues with the fourth episode" 13:43
The probably relevant commit from that PR just says "Add support for nominalizables on generic classes" 13:44
But what does that mean?!
vrurg Unfortunately, true. Due to the absolute lack of time back then I was happy to get that working and fix a real problem in my JSON::Class implementation. 13:52
nine And yes, I'm smart and I have by now written most of the compiler frontend for Raku which gave me a pretty intimate understanding of the language and I if I invest a few hours digging through those tests and commits I could figure out what it's all supposed to mean.
But why should I? Why should I spend hours on something that wasn't worth the minutes to you that it would have taken to include a few code examples and bits of background information? 13:53
vrurg nine: Cool down, please. I was digging hours and hours too. I was pissed off of many commits and absolutely non-explaining messages of one person. Nobody even knows who that person was. Like you don't know what was my personal state when I was submitting these PRs. 13:59
But mainly, the problem is that there must be review process working in first place. We didn't have it with this respect. So, everybody is prone to errors of some kind. But somebody needs to be around to help fix these errors. 14:00
jdv [Coke]: why would i be excited? 14:02
lizmat I'd say: let us all try to create better commit messages
in the future 14:03
JimmyZhuo the roast has a little test about compiling time type check test
Geth rakudo/main: 2e82abc353 | (Elizabeth Mattijsen)++ | src/Raku/ast/signature.rakumod
Revert "throw X::Parameter::TypedSlurpy exception, pass two test in t/spec/S06-signature/slurpy-params.t (#5818)"

This reverts commit 518596b47ee659a85f949081955971f688d09d51.
The added test was breaking .assuming on methods. Further research is needed as to why this was the case.		 14:05
nine Wouldn't it be quite surprising if commit 518596b47ee659a85f949081955971f688d09d51 was wrong? As checks go it doesn't seem much more straight forward than that 14:07
timo the .rakumod files in the ast folder go through some special kind of extra compilation step, right? 14:09
Geth roast: 101b02e8db | (Elizabeth Mattijsen)++ | S04-declarations/will.t
Make sure will init tests are skipped

As they will throw X::NYI at compilation now. Also remove test for "will compose" as that will most likely never get implemented.
Also commented out "will post" code, as that also broke compilation now with X::NYI (although it looks like the test was really being able to compile at this time).		 14:11
lizmat that should make spectest clean again
nine timo: yes, tools/build/raku-ast-compiler.nqp 14:13
timo ah, it leaves bodies of subs and stuff completely alone, doesn't it? 14:14
nine timo: src/Raku/ast/README.md might also be worth a look
yes
timo OK, that can't be the culprit then
it does "kind of tokenize" the source at a very basic level, but that should be simple enough not to get confused by that code, i'm just assuming. though it's probably easier to just look at the output 14:16
lizmat afk for a few hours& 14:17
nine timo: how's it breaking? 14:18
timo i have yet to actually run the code to see 14:30
[Coke] jdv: that is ... a fair question. :) 15:12
timo the slurpy signature tests have a bunch of "dies-ok" which don't test for a specific type of exception. i wonder if that's wise 15:26
ah, we get an X::AdHoc for these cases 15:29
feels like we should be able to do better than that 15:31
nine Wow, that's a subtle bug... multi method candidates get sorted into the wrong order if a parameter type is just a stub at the time the class gets composed 15:38
timo eep 15:41
[Coke] wow 15:52
nine But for some reason I see this only in the setting 15:53
timo could it be particularly bootstrappy? 15:54
uhhh on current rakudo/main i fail 4 tests in t/spec/S06-signature/slurpy-params.t but on the commit right before it, i.e. without the revert, i fail only 2 tests in that file? 15:57
timo oh, i was looking at the wrong spot, the trouble isn't in slurpy-params.t at all 15:59
uhhh i actually have no idea where the failing code lives that has to do with that commit. presumably one of the failures from the blin run log? 16:02
> Serialization Error: missing static code ref for closure 'assumed.great-circle-waypoint' (:1) 16:19
this is the real error behind Astro-Utils's "SORRY" with "chars requires a concrete string, but got null" 16:21
moar has a commit for that now 16:23
timo got a shorter reproduction case 16:36
nine Same here: 16:43
m: 'class Simple { ... }; class Foo { multi method foo(Simple \x, \y, :$a) { say "Simple Any" }; multi method foo(\x, Whatever \y, :$a) { say "Any Whatever" }; multi method foo(\x, \y, :$a) { } }; BEGIN Foo.foo(Any, Any); class Simple { }; Foo.foo(Simple, Whatever);'.AST.EVAL 16:44
camelia ===SORRY!===
Unknown compilation input 'qast'
timo github.com/rakudo/rakudo/issues/5819
nine (would print "Any Whatever" instead of the expected "Simple Any")
timo [Coke]: when you create an issue for the blin run, you can put this as the source of the problem of Astro::Utils, but the problem is caused by `use Math::Trig;` 16:45
nine It's because of that BEGIN time call to the multi
timo begin time call, eh? in our company we just say "daily standup" 16:47
[Coke] scruuuuuum 16:58
nine Plot twist! 17:07
m: class Simple { ... }; class Foo { multi method foo(Simple \x, \y, :$a) { say "Simple Any" }; multi method foo(\x, Whatever \y, :$a) { say "Any Whatever" }; multi method foo(\x, \y, :$a) { } }; BEGIN Foo.foo(Any, Any); class Simple { }; Foo.foo(Simple, Whatever);
camelia Any Whatever
nine The exact same problem actually exists on the old frontend. It's just some coincidence that it's hidden 17:08
Geth nqp/main: db1c963b24 | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump MoarVM to handle unnamed CU serialization, timo++
 17:39
timo i also realize that this is with assuming but not related to methods, so probably not what liz was actually hunting down
lizmat I think somewhere a RakuAST::Type::Simple.new("Mu") is added to the Parameter, but I haven't looked yet exactly 17:41
that makes the RakuAST::Parameter.type concrete, and that triggers the error
it probably shouldn't trigger when the type is Mu either 17:42
m: sub a(Mu *@a) { }
camelia ===SORRY!=== Error while compiling <tmp>
Slurpy positional parameters with type constraints are not supported
at <tmp>:1
------> sub a(Mu *@a<HERE>) { }
expecting any of:
constraint
lizmat I wonder why that is actually an error, you can't get more non-typy in Raku 17:43
Geth rakudo/main: e633a64c95 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP to handle unnamed CU serialization, timo++
 17:51
timo m: dd :$!; # a random fun "Confused" if anyone is into that kinda thing 17:52
camelia ===SORRY!=== Error while compiling <tmp>
Confused
at <tmp>:1
------> dd :$<HERE>!; # a random fun "Confused" if anyone i
expecting any of:
colon pair
Geth rakudo/main: cbccee08a4 | (Stefan Seifert)++ | 2 files
RakuAST: sort multi candidates at check time

If aa multi candidate's parameter is typed with a stub and we call that proto at BEGIN time, we may produce a wrong dispatch order. The reason is that the type stub will not yet have any parents and so it won't even beat an Any typed canidate in terms of specificity. Thus we need to re-sort those dispatch canidates at CHECK time, i.e. when we've fully ... (12 more lines)		 17:57
nine 1228 17:58
lizmat and 1279 non-bootstrapped, right?
asking for the weekly editor
nine correct 17:59
I still don't see why the perfectly fine commit 518596b47ee659a85f949081955971f688d09d51 was reverted 18:00
This of course now causes a rebase conflict in bootstrap-rakuast
lizmat nine: because it caused a roast regression 18:07
it just added / removed 4 lines ?
you mean you changed something in those 4 lines in the bootstrapped branch? 18:08
otherwise I don't see how that could create conflicts ?
nine Yes the branch changes a line there 18:09
lizmat maybe that change needs to be ported to main then ?
lizmat is getting curious now
nine So there are 2 changes: one is that 2 line super easy and straight forward commit that's quite obviously correct. The other is the massive rewrite of assuming. Now something using assuming breaks and the immediate conclusion is that the tiny commit is to blame? 18:10
Isn't it just as massively more likely that there's a few kinks in the new assuming implementation? 18:11
lizmat I'm not saying the .assuming implementation is without kinks
I'm just saying that it broke roast
nine I say assuming broke roast 18:12
Wanna bet?
lizmat no, not particularly
I'm just saying roast was fine for a week with the new assuming implementation 18:13
and that addition in rakuast broke roast
and we're a few days away from a release 18:14
nine And then a new error check actually showed that the new assuming implementation has a flaw. And as far as I understood from what you wrote here, you already confirmed that - the parameter gets a type set when it shouldn't. So the check was totally correct in throwing the error. 18:15
If its a problem for the release, then assuming should be reverted, not the innocent check that showed that assuming is not ready for prime time. 18:16
lizmat ok, but that's the thing: I verified that the new assuming implementation does **not** add a type to the parameter
nine Yet there is one there, isn't there? 18:17
lizmat I haven't look at it in depth yet, but the test is:
if $was-slurpy && nqp::isconcrete($!type) {
so I can only assume that $!type is getting set somewhere
lizmat triple checks 18:18
hmmm... and indeed it shows a type was added 18:20
meh 18:21
Geth rakudo/main: fa7697e212 | (Elizabeth Mattijsen)++ | src/Raku/ast/signature.rakumod
Revert "Revert "throw X::Parameter::TypedSlurpy exception, pass two test in t/spec/S06-signature/slurpy-params.t (#5818)""

This reverts commit 2e82abc35389110abb915306926977b4fb16c82b.
By popular demand		 18:22
Geth rakudo/main: 729d26ea61 | (Elizabeth Mattijsen)++ | src/core.c/core_epilogue.rakumod
Preliminary fix for .assuming producing typed slurpies

Problem became apparent after 518596b47ee659a8 but did not appear to create any problems in roast before that.
There is still a kind of tangled mess in RakuAST land handling typed @ and % sigilled parameters, because internally this is handled as Positional[type] / Associative[type], but in other places the sigil appears to be leading, causing stacked types such as Positional[Positional[type]] in certain situations.		 18:53
releasable6 Next release in ≈4 days and ≈23 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 19:00
lizmat notable6: weekly 19:09
notable6 lizmat, 6 notes: gist.github.com/6ffed0c2c6fb0a86ba...5c7ea1453d
lizmat notable6: weekly reset
notable6 lizmat, Moved existing notes to “weekly_2025-03-17T19:09:43Z”
nine WTF 19:26
m: my int @a = 1, 2; @a.first = 3
camelia ( no output )
nine > rakudo -e 'my int @a = 1, 2; say @a.first = 2' 19:27
Cannot modify an immutable Int (1)
lizmat that's with the bootstrapped version ? 19:29
nine No, my plain normal rakudo from openSUSE package 19:32
But also with a locally compiled one 19:33
lizmat looks like I fixed that on 9 Feb: de08b4c67d
nine Oooh...and my locally compiled one was compiled with --optimize=off instead of --optimize=3 from earlier debugging. 19:34
And both using a too old rakudo and one compiled without optimization lead to the exact same error
Geth rakudo/main: 26a9c1a702 | (Stefan Seifert)++ | src/Raku/ast/signature.rakumod
RakuAST: fix wrong flags on natively typed array parameters

Fixes: sub foo(int @a) { }; my int $i = 1; foo($i)		 19:45
nine 1229
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2025/03/17/2025-...-for-sale/
nine rakudo (bootstrap-rakuast *<>)> ./rakudo-m --ll-exception -e 'my @a = map &sprintf.assuming("%x"), 9..12;' 20:06
This element has not been resolved. Type: RakuAST::Term::Name
lizmat looks 20:07
bisectable6: old=2025.02 my @a = (9..12).map(&sprintf.assuming("%x")); dd @a 20:08
bisectable6 lizmat, On both starting points (old=2025.02 new=26a9c1a) the exit code is 0 and the output is identical as well
lizmat, Output on both points: «["9", "a", "b", "c"]␤»
lizmat bisectable6: old=2023.02 my @a = (9..12).map(&sprintf.assuming("%x")); dd @a 20:09
bisectable6 lizmat, Bisecting by output (old=2023.02 new=26a9c1a) because on both starting points the exit code is 0
lizmat m: my @a = (9..12).map(&sprintf.assuming("%x")); dd @a 20:14
camelia ["9", "a", "b", "c"]
lizmat I wonder where the a b c come from ?
nine those numbers in hex
lizmat aaaahhh ... "%x" :- 20:15
)
nine: RakuAST::Term::Name.new(RakuAST::Name.from-identifier("param.2")) 20:16
bisectable6 lizmat, There are 10 candidates for the first “new” revision. See the log for more details 20:18
lizmat eh... :-)
bisectable6: old=2024.08 my @a = (9..12).map(&sprintf.assuming("%x")); dd @a
bisectable6 lizmat, On both starting points (old=2024.08 new=26a9c1a) the exit code is 0 and the output is identical as well
lizmat, Output on both points: «["9", "a", "b", "c"]␤»
lizmat bisectable6: old=2024.08 my @a = (9..12).map(&sprintf.assuming("%x")); dd @a 20:19
bisectable6 lizmat, On both starting points (old=2024.08 new=26a9c1a) the exit code is 0 and the output is identical as well
lizmat, Output on both points: «["9", "a", "b", "c"]␤»
lizmat bisectable6: old=2024.01 my @a = (9..12).map(&sprintf.assuming("%x")); dd @a
bisectable6 lizmat, Bisecting by output (old=2024.01 new=26a9c1a) because on both starting points the exit code is 0
lizmat, bisect log: gist.github.com/f65affb2045f1c85e8...5af5601528
lizmat, (2024-05-18) github.com/rakudo/rakudo/commit/0a...0683b6afac
lizmat nine: the param.2 is a generated name to be able to refer to the nameless capture in the proto of sprintf 20:20
the deparsed code is: proto sub assumed.sprintf (|param.2) { self("\%x", |param.2) 20:21
where self refers to the invocant of .assuming
the RakuAST::Term::Name thing was inspired by: 20:25
m: say Q/sub a(|c) { a |c }/.AST.statements.head.expression.body.statement-list.statements.head.expression.args 20:26
camelia RakuAST::ArgList.new(
RakuAST::ApplyPrefix.new(
prefix => RakuAST::Prefix.new("|"),
operand => RakuAST::Term::Name.new(
RakuAST::Name.from-identifier("c")
)
)
)
lizmat nine: if the use of RakuAST::Term::Name is wrong there, please advise what it should be :-) 20:28
nine looks legit 20:30
Though "param.2" is not exactly a valid identifier, I don't think that matters
lizmat I specifically chose to create an invalid identifier to prevent collisions with actual identifiers 20:38
and within the context of that sub, it shouldn't matter, I think ?
nine As I said, I don't think it matters 20:41
lizmat right
lizmat afk& 20:49

Powered by Cro and the Raku® Programming Language.

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

Thank you!