[04:45] *** hurufu joined
[04:47] *** hurufu left
[04:48] *** hurufu joined
[07:38] *** hurufu left
[07:53] *** hurufu joined
[09:03] *** hurufu left
[10:07] *** rnddim is now known as ShimmerFairy

[12:45] *** hurufu joined
[12:53] *** donaldh left
[14:44] *** hurufu left
[17:13] *** El_Che joined
[17:14] <El_Che> 19:11 < El_Che> is redhat 8 still a target for redhat 8 (supported until 2029)? The new moar breaks there, was ok on last release: ./libmoar.so: undefined reference to `gettid'

[17:15] <Geth> ¦ nqp/main: ca2e391a07 | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION

[17:15] <Geth> ¦ nqp/main: Bump MoarVM to get gettid fix

[17:15] <Geth> ¦ nqp/main: review: https://github.com/Raku/nqp/commit/ca2e391a07

[17:22] <Geth> ¦ rakudo/main: 5fae814f6f | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION

[17:22] <Geth> ¦ rakudo/main: Bump NQP to get gettid fix

[17:22] <Geth> ¦ rakudo/main: review: https://github.com/rakudo/rakudo/commit/5fae814f6f

[17:22] <lizmat> El_Che: ^ should be ok after this 

[17:24] <El_Che> does it bump a vesion?

[17:24] <El_Che> version

[17:28] <lizmat> you mean, will we do a Rakudo point release for this ?

[17:28] <El_Che> or a moarvm dot release, I can set the version for each component separately

[17:29] <[Coke]> I can probably do a moarvm dot release to get that one thing.

[17:29] <[Coke]> probably not until saturday

[17:29] <El_Che> it's cleaning than patching for 1 OS

[17:30] <El_Che> I'll release the packages saturday then

[17:32] <[Coke]> ok. will mention here if I can get to it sooner.

[17:32] <El_Che> [Coke]++

[17:32] <[Coke]> is there any way we can catch this stuff sooner?

[17:33] <[Coke]> our process should have caught this on the original PR.

[17:34] <El_Che> I had a dev build on rakudo-pkg where you could build any commit on the matrix of distros+versions but I removed it because no one used it

[17:36] <El_Che> I guess you get get an idea by forking rakudo-pkg, and change config/setup.sh with your commits, push it and the action would build the matrix

[17:40] <[Coke]> where is rakudo-pkg?

[17:41] <[Coke]> ah, under nxadm

[17:41] <El_Che> https://github.com/nxadm/rakudo-pkg

[17:41] <El_Che> Here is what's built: https://github.com/nxadm/rakudo-pkg/blob/bc7d54031096351dcf8d629a0ad243f4cc964491/.github/workflows/package.yml#L28

[17:42] <[Coke]> can that test just that moarvm doesn't build? Does it need to have a full rakudo?

[17:42] <El_Che> config/setup.sh has the version it checks out and builds

[17:43] <El_Che> as is, it is not granular, no

[17:49] <[Coke]> moarvm is doing 22 compilation checks - why doesn't it include all the OSes on your list?

[17:55] <[Coke]> added MoarVM/issue/2011

[18:04] <[Coke]> https://github.com/MoarVM/MoarVM/pull/2010/checks

[18:05] <[Coke]> that's the fix PR that was just merged. it is failing more than hald the CI checks.

[18:05] <[Coke]> half

[18:05] <[Coke]> nearly 2/3

[18:07] <[Coke]> Shouldn't that be 100% green, especially if we're trying to fix a compiler issue on one OS without breaking others?

[18:12] <[Coke]> I'm not going to do the point release until I'm sure we're not making things even worse. :)

[18:13] <lizmat> [Coke]++

[18:17] <[Coke]> guessing part of the failure was that the merge happened before they finished? some of them are git failures that it couldn't fetch that branch

[18:19] <[Coke]> ok, looking better on main, down to 5ish failures, first one I checked is actually failing in rakudo native call?

[18:20] <[Coke]> https://dev.azure.com/MoarVM/MoarVM/_build/results?buildId=2093&view=logs&jobId=c4cc608e-e7c1-51dc-c1de-b4e400f2515c&j=c4cc608e-e7c1-51dc-c1de-b4e400f2515c&t=207e95a6-d18e-5fbe-1828-1df1d64735f6

[18:22] <[Coke]> Moarvm builds are being tested against Rakudo main

[18:23] <[Coke]> I guess that's better than rakudo-latest-release, but i imagine we could get some false negatives there.

[18:24] <[Coke]> the moarvm failures are with MVM_clang, 

[18:24] <El_Che> flipping tests are pretty common

[18:24] <El_Che> (flapping?)

[18:24] <[Coke]> the moarvm failures are with MVM_clang, MVM_clang_malloc, MVM_clang_njit, MVM_clang_no_c11_atomics

[18:25] <[Coke]> also: if we have any flappers, fix them. we shouldn't have tests written in a way that flap at this point.

[18:26] <[Coke]> (just found one this release that was depending on hash key order in roast)

[18:27] <[Coke]> oof. just did "rerun failed checks" on the last commit in moarvm and it's rerunning *everything*?

[18:34] <El_Che> the fails I saw, but disappeared after 1  retry: t/04-nativecall/09-nativecast.t, t/09-moar/Line_Break__LineBreak.t, t/12-rakuast/xx-fixed-in-rakuast.rakutest, t/02-rakudo/rakuast-code-assuming.t, t/04-nativecall/19-function-pointers.t,  t/04-nativecall/00-misc.t , t/12-rakuast/origins.rakutest 

[18:38] <[Coke]> I'm rerunning the CI tests.

[18:38] <[Coke]> looks like the original 4 that died still died.

[18:39] <[Coke]> failing on t/04-nativecall/02-simple-args.t   consistently

[18:42] <timo> yeah, that's the thing with clang and gcc disagreeing and we're getting caught in the middle

[18:42] <timo> the simple-args one

[20:39] *** hurufu joined
[21:44] <Geth> ¦ rakudo/lizmat-8: ca0d8d6e95 | (Elizabeth Mattijsen)++ | src/Raku/ast/package.rakumod

[21:44] <Geth> ¦ rakudo/lizmat-8: RakuAST: step one for codegenning POPULATE in every class

[21:44] <Geth> ¦ rakudo/lizmat-8: 

[21:44] <Geth> ¦ rakudo/lizmat-8: This actually compiles and works as expected (as far as I have been

[21:44] <Geth> ¦ rakudo/lizmat-8: able to test in a simulated environment.

[21:44] <Geth> ¦ rakudo/lizmat-8: 

[21:44] <Geth> ¦ rakudo/lizmat-8: The next step will be to actually convert the created AST for the

[21:44] <Geth> ¦ rakudo/lizmat-8: POPULATE method into an actual Method object, and add it to the

[21:44] <Geth> ¦ rakudo/lizmat-8: <…commit message has 5 more lines…>

[21:44] <Geth> ¦ rakudo/lizmat-8: review: https://github.com/rakudo/rakudo/commit/ca0d8d6e95

[21:44] <Geth> ¦ rakudo: lizmat++ created pull request #6211: RakuAST: step one for codegenning POPULATE in every class

[21:44] <Geth> ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/6211

[21:53] *** hurufu left
[22:12] <lizmat> ugexe: re POPULATE, I think  PRODUCE-META-ATTACHABLES is the wrong place for it, as it is also being called for roles

[22:13] <lizmat> I think that the POPULATE codegenning logic needs to live in RakuAST::Class.PRODUCE-META-OBJECT

[22:13] <lizmat> or be called from there

[22:14] <ugexe> yeah sounds good to me. only thing i might add is having a PRODUCE-POPULATE method or some such that is called from PRODUCE-META-OBJECT

[22:14] <tellable6> 2026-05-28T22:11:50Z #moarvm <lizmat> ugexe: re POPULATE, I think  PRODUCE-META-ATTACHABLES is the wrong place for it, as it is also being called for roles

[22:15] <lizmat> ok, I'll go that way tomorrow...  :-)

[22:15] <lizmat> sleep&

[22:59] *** apogee_ntv left
[23:00] *** apogee_ntv joined