00:02 librasteve_ left
timo2 joins the fez 00:19
wow, what does `fez list` do that it takes so long to give me ">>= No results"? :D 00:20
Geth rakudo/main: 95c56c2fa9 | (Will Coleda)++ | 2 files
Split -errata akefile target into 6c/6d

Also reset the branch to master when done.
Fixes #5827 Fixes #5829		 00:30
rakudo/main: bebd4a0f45 | (Will Coleda)++ (committed using GitHub Web editor) | 2 files
Merge pull request #5992 from rakudo/coke/errata-split

Split -errata akefile target into 6c/6d		 00:31
rakudo/main: ffeb426021 | (Will Coleda)++ | tools/releasable/Akefile
Only check flappers 2 times.

Good enough, Fixes #5828
rakudo/main: e1b3f9277e | (Will Coleda)++ (committed using GitHub Web editor) | tools/releasable/Akefile
Merge pull request #5993 from rakudo/coke/antiflap

Only check flappers 2 times.
[Coke] c: e1b3f9277e 3.put 00:48
committable6 [Coke], ¦e1b3f92: «3␤»
07:20 [Tux] left 07:25 [Tux] joined 07:54 librasteve_ joined 10:22 melezhik_ joined
melezhik_ I've created this simple project on sparky to test preselected modules zef install against fresh Rakudo version, here is an report example - sparky.sparrowhub.io/report/r100/25879 10:23
failure is not relevant to Rakudo itself, please see artifacts tab and DSL::English::RecommenderWorkflows.install.log
however just demonstrate UX 10:24
maybe somehow could be useful to test future Rakudo release, I know that blin does that, I am just not sure how, and maybe this flow bit different 10:25
10:32 melezhik_ left
[Coke] .ask melezhik - is there a way to see the code driving the report? 12:01
tellable6 [Coke], I'll pass your message to melezhik_
13:24 melezhik_ joined
melezhik_ . 13:24
tellable6 2025-10-21T12:01:18Z #raku-dev <[Coke]> melezhik - is there a way to see the code driving the report?
melezhik_ [Coke]: sure - github.com/melezhik/ci.sparrowhub/...jects/r100
this is Sparky scenario 13:25
github.com/melezhik/ci.sparrowhub/...onfig.raku has list of modules
and this is a scenario - github.com/melezhik/ci.sparrowhub/...parrowfile
this thing should be even shipped as self-contained docker container, so you can run it from your laptop and get results in 127.0.0.1:4000 browser 13:26
we can add rakudo installation into current scenario, so that any rakudo version could be tested 13:27
let me know if you are interested , and btw the similar approach we take for rak-infra tasks
parallelization is also possible 13:30
timo2 the magical feature in Blin is that it can refer back to a previous blin run of the same dist with an older rakudo version and differentiate between "has failed last time, is still failing" in other words "new rakudo changes probably didn't cause this failure" and "was working last time, is failing now" in other words "new rakudo changes probably caused this failure" 13:35
melezhik_ makes a sense ... I guess to build stat for this sparky job is not that hard , so we can have this insight 13:42
14:01 melezhik_ left, melezhik_ joined 14:06 melezhik_ left, melezhik_ joined 14:18 melezhik_ left, melezhik_ joined 14:25 shareable6 left 14:27 shareable6 joined
[Coke] "previous blin run"... technically not true. 14:28
It's all one blin run with two endpoints.
My goal for the next iteration is to split this into two steps: 1) Run a version of rakudo. 2) run a report comparing that version to the previous version. 14:29
Right now that's all one job
I had some notes I threw into a readme that I just invited you to, melezhik_ 14:31
It may also be tricky to split it up, as right now the "one big job" lets us not worry about prereqs - they'll be tested on their own before we see them as a prereq. 14:33
timo2: You were also invited.
It's literally just a README - feel free to throw more .md files in there with notes or open issues or whatever. 14:34
melezhik_ [Coke]: ++ 14:50
[Coke] did some updates 14:56
melezhik_ I guess now blin now runs on some VM, right ? 14:57
[Coke] added a note about that - I run it on an azure VM - jdv runs it in a docker container on his laptop
I probably pay like 30 bucks on the months I run blin between that and doing the release from that box. 14:58
(which is fine, but not something I would expect another contributor to have to do)
jdv's docker container is outdated at this point, and I think mine required installing whateverable directly from git instead of a release. 14:59
(but I set it up originally over a year ago, and didn't make an arm template for it)
melezhik_ ok, does blin test all raku.land modules or some preset ? 15:00
15:09 melezhik_ left, melezhik_ joined
ugexe i think ideally it would be able to test all or any subset of all 15:12
like it would be cool if people could queue of a blin run of their module or something 15:13
that is a feature request though... currently i think it does all of them except for anything on its ignore list
ab5tract especially if they can do that queue locally. 15:14
melezhik_ distributed tests will benefit IF the whole dependency tree is well balanced which I am not is the case for the eco system ... 15:26
15:52 melezhik_ left 15:53 melezhik_ joined, melezhik_ left
[Coke] blin tests everything zef can install with a small skiplist. (and some known failures because of JSON::Class) 15:58
... so basically raku.land, yes
We use zef (don't think anyone has tried to use pakku for this in ages, and I won't bother building any support for it into blin2), ‘Zef::Repository::Ecosystems’; 16:01
so it gets the source list for all three, and tests (only the latest, looking at name & version). Some cleanup to be done there so it considers auth as well so we can avoid the JSON::Class issue. 16:02
ab5tract The input list of modules feels like a nice place to accept user input. 17:59
lizmat m: dd 44 minmax 666 18:00
camelia 44..666
lizmat m: dd 44 ^minmax 666
camelia one(44, 666..666)
lizmat :-) 18:01
ab5tract [Coke]: does blin use a database for storing run results? 18:02
18:15 melezhik joined
melezhik . 18:15
I have been reading the blin code, try to understand what’s going on, it’s heard tbh , structure abit complex for me 18:16
If we decide to refactor blin so it run only against single Rakudo version , will it be difficult ? 18:17
lizmat clickbaits raku.land/zef:lizmat/Ecosystem::Cache 18:19
melezhik I still think maybe we need to go by CPAN testers way and allow users to run tests against release candidates and push reports back to our system ? And the handle all the logic there - like comprising results with previous versions , etc …
lizmat: what about Ecosystem::Cache;? I wonder how this module could be helpful ? 18:21
To build dependencies tree ?
lizmat no, to run blin off of
no need to fetch anything anymore inside blin: just run the update-ecosystem-cache script 18:22
jdv since when is it "my" docker container? 18:23
i didn't set it up. i just try to maintain it because it how i run blin:)
someday it'll work again!
melezhik )) 18:24
ab5tract melezhik: I have a branch that is probably out of date that I patched to do a single commit in rakudo.git 18:26
github.com/Raku/Blin/commit/d9bc2d...3627458a4b 18:29
19:18 Geth left, Geth joined
ugexe the problem with the cpan testers model is it isn't good at maintaining a similar environment to make comparisons with 19:21
we actually did used to have that implemented though. testers.p6c.org or some such that zef used to report test results to 19:22
github.com/ugexe/zef/blob/040a9ac7...er.pm6#L62 19:23
(that code has long since been deleted though)
20:45 melezhik left
[Coke] ab5tract: no, current blin just dumps markdown output 20:54
(release candidates) we are doing that, we're just not tagging/releasing the candidate.
(because we release every month and that would at least double the already annoying amount of time to cut a release) 20:55
jdv: I meant your laptop more than your container.

Powered by Cro and the Raku® Programming Language.

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

Thank you!