japhb Welp, looks like I need to rebuild all. Managed to crash rak trying to see if I'm using wait-condition/need-condition anywhere. 00:11
FWIW, I think those are *far* more likely to be used in bespoke code in the wild than in the ecosystem anyway.
Is it expected that as of rakudo/main HEAD (f3ae9c3876) that it would fail `make test` 00:43
?
ugexe Tests_Lin Lin_MVM_normal started failing on Feb 23, 2025 and hasn't been green since 01:31
which seems kind of odd, since I doubt rakudo would have been broken that long without anyone noticing
dev.azure.com/Rakudo/rakudo/_build...esults-tab 01:32
that shows the tests that are failing in CI, not sure if it correlates to the failures you're seeing though 01:33
i wonder if those tests pass in rakuast or something. that could explain how the failures are being missed during active development 01:35
japhb ugexe: Yeah, those look related. I wasn't too surprised about the t/12-rakuast/ failures, figuring that was a "committed on wrong branch" sort of issue. I was a bit more surprised by the t/02-rakudo/07-implementation-detail-* tests failing, indicating visible new "global lowercase CORE::/SETTING:: subs added" -- not because of the chance of that happening, but because the expected/got pair is 01:43
`Set.new()` versus `Set.new("")`. Which seems like an actual bug.
I mean, we still need to fix the t/12-rakuast/ failures in the `main` branch before release, but that's probably trivial. 01:44
Geth rakudo/main: 03372894d3 | (Elizabeth Mattijsen)++ | t/12-rakuast/xx-fixed-in-rakuast.rakutest
Skip multislice array test for now
 09:36
Geth rakudo/main: 8475b1d607 | (Elizabeth Mattijsen)++ | t/12-rakuast/signature.rakutest
Mark failing test as todo for now

Apparently creating a sub programmatically with RakuAST does **not** set the parameter type correctly. Creating a sub in the full grammar
  *does* work correctly.		 10:14
lizmat bisectable6: old=2025.02 use v6.*; say RakuAST::Var::Attribute::Public.new("foo") 10:40
bisectable6 lizmat, Bisecting by exit code (old=2025.02 new=8475b1d). Old exit code: 0
lizmat, bisect log: gist.github.com/ad8e5dc96c996853ac...a203071e4d 10:41
lizmat, (2025-03-21) github.com/rakudo/rakudo/commit/f7...18c30c19f8
Geth rakudo/main: b801bb5b98 | (Elizabeth Mattijsen)++ | 2 files
RakuAST: fix testing / .raku of ::Var::Attribute::Public

Commit f7f670f changed the intreface of RakuAST::Var::Attribute::Public from one positional to two nameds, with the second named being optional and apparently used for internal purposes only.
This commit adapts to this changed interface, although I doubt it should have. At least it is clean for the 2025.03 release now.		 10:44
lizmat bisectable6: old=2025.02 use v6.*; say Q|s/o/x/|.AST 10:49
bisectable6 lizmat, On both starting points (old=2025.02 new=8475b1d) the exit code is 0 and the output is identical as well
lizmat, gist.github.com/446fe263750ac1be46...156c4625d1
Geth rakudo/main: c7cfbfca3a | (Elizabeth Mattijsen)++ | t/12-rakuast/regex-substitution.rakutest
RakuAST: mark broken tests as todo for now
 10:53
Geth rakudo/main: 7826a7672f | (Elizabeth Mattijsen)++ | t/12-rakuast/role.rakutest
RakuAST: skip role tests for now

Programmatically built roles are severely broken at the moment		 11:24
nine lizmat: actually I added that second parameter for Var::Attribute::Public explicitly for synthetic ASTs. Would have been slightly less effort to just call replace-args from the Actions :) 11:44
Otherwise how would you create an AST for $.foo: 1, 2? 11:45
lizmat well, if you change the API, you need to change the tests that test the API :-)
Geth rakudo/main: 69d4fcb4ee | (Elizabeth Mattijsen)++ | 3 files
Remove special casing in implementation-detail test

Apparently an empty "" would be created before, but no longer. No idea what changed this, but this simplifies the test, so it is probably good		 11:47
nine Yes, I probably should. Still I cannot overstate how overstressed I am with this whole thing, so I take every little shady excuse to trim down the amount of work necessary to get to the minimal goal for the grant.
lizmat at least "make test" is clean now 12:05
nine: I'm not understanding why $.a: 1,2 would need special handling ? 12:09
could have generated that as self.a.item: 1,2 12:10
also: shouldn't $!a: 1,2 need to work as well then ? 12:11
anyways, post 2025.03 release :-) 12:12
going to be mostly afk& for most of the day
nine $!a translates direclty nqp::attribute. There's no way this can refer to a private method 12:18
And yes, that's one of the inconsistencies that $.foo syntax brought with it. 12:19
Just like $.^name could have also meant "give me the type name of the value in the anonymous scalar variable"
And $.name could have meant "call method `name` on the value in $" for that matter
In fact with my commit $.a: 1, 2 no longer has special handling. It generates exactly the same way as $.a(1, 2) 12:20
$.a(1, 2) previously had special handling in EXPR-POSTFIX which my commit removed. That was the one case where supporting a dubious feature actually made the code better :) 12:21
lizmat ok, I see your point now 12:22
afk&

Powered by Cro and the Raku® Programming Language.

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

Thank you!