🦋 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.
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
03:53 codesections joined 03:57 codesections left 04:23 codesections joined 04:28 codesections left, codesections joined 04:32 codesections left 04:55 codesections joined 05:00 codesections left 08:34 finanalyst joined
Geth rakudo/main: 03372894d3 | (Elizabeth Mattijsen)++ | t/12-rakuast/xx-fixed-in-rakuast.rakutest
Skip multislice array test for now
 09:36
10:00 sena_kun joined
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
11:06 finanalyst left
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
11:37 Geth joined
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.
11:53 JimmyZhuo joined
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&
13:20 JimmyZhuo left 14:36 librasteve_ left 18:34 [Coke] left 19:43 rakkable left, rakkable joined 19:59 finanalyst joined 20:01 finanalyst left 20:30 [Coke] joined 21:09 vrurg joined, vrurg_ left 23:34 sena_kun left 23:40 sena_kun joined 23:47 sena_kun 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!