| 14 Dec 2025 | |||
| melezhik2 | as a suggestion it'd be good imho to gave some sort of flag of env var that only increases verbosity of TAP report, not other details for zef | 17:50 | |
| for me as a someone who tests thousands of Raku modules this would be very helpful in troubleshooting why modules fail | 17:51 | ||
| but current workaround is ok too ) | |||
| patrickb: I am again have this phantom of "your agent does not work correctly" ))) I dunno but when I rerun failed modules on my agent ( the same Rakudo version ) they pass, as on [Coke]: agent too ), once you've got an access to your agent please run `env|grep BRW` inside id, brownie reports show that you probably have Rakudo version installed | 17:54 | ||
| from source code, not downloaded from whateverable, I am not 100% sure though , thanks | |||
| As an example - gist.github.com/melezhik/c800b01dd...7bf2935d41 | 17:57 | ||
| cc patrickb: | |||
| [Coke] | ⏳ 1113 out of 2389 modules processed (46.58%) | 18:05 | |
| ugexe | that example is proof of why you should just always use --debug | 18:06 | |
| on the output where --debug was used there is `[Hashids] Testing with plugin: Zef::Service::Shell::Test` | |||
| for the other output no such line exists, but based on the output of a test summary it presumably uses Zef::Service::TAP | 18:07 | ||
| i think you need to decide if you want to use TAP::Harness during testing. if yes it needs to always be installed. then you need to ensure that is the only way tests are run by disabling the other testers in config or via `--/raku-test`. Or if you want to test everything without using TAP::Harness then force that by passing `--/tap-harness`. Currently zef will prefer TAP::Harness if it is | 18:10 | ||
| installed, otherwise it uses Zef::Service::Shell::Test | |||
| melezhik | Ok. I get it. But main question why is patrickb agent has different setup for zef then mine and [Coke] agent . The only (?) possible question for that would be it installs Rakudo and zef from source code instead of using whateverable distro | 18:19 | |
| [Coke] | "if installed" - maybe he has more modules installed on his setup? | 18:24 | |
| melezhik | Yeah … [Coke] could you please pull the latest commit and restart agent ? I added —debug on ugexe suggestion . Some modules keep failing on your agent too , debug will gives up more details in TAP report | 18:57 | |
| brw.sparrowhub.io/report/job.1.report/1770 | 18:59 | ||
| Again those TAP related errors | |||
| [Coke] | done | 19:00 | |
| patrickb | melezhik: imgur.com/a/fEhx2WJ | 20:35 | |
| releasable6 | Next release in ≈5 days and ≈19 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft | 23:00 | |
| 15 Dec 2025 | |||
| MasterDuke | timo, lizmat, et al.: that leibniz benchmark is interesting. i made some modifications (github.com/niklas-heer/speed-compa...bniz.raku) that sped it up, but across some of the different languages i get surprising results on x86 vs apple silicon | 02:57 | |
| on my laptop (apple silicon), raku takes twice as long as on my desktop (amd x86). but the python version reversed, it takes twice as long on the laptop | 03:00 | ||
| and just changing `$pi = $pi + $x / (2 * $i - 1).Num;` to `$pi = $pi + nqp::div_n($x, (2 * $i - 1));` speeds it up by at least 5x on both laptop and desktop | 03:03 | ||
| and a bunch of the savings is that now there are 0 GCs, where before there were ~8k (doing only 100000000 rounds instead of the default 1000000000, just to get results quicker) | 03:06 | ||
| it'd be great it spesh could figure out that it doesn't need to allocate a new Num each iteration, but can just reuse one | 03:08 | ||
| (oops, typoed the bit about python. it's twice as long on the *desktop*) | 03:09 | ||
| off to bed & | 03:11 | ||
| melezhik | I am going to post summary of fundings. But right now diff head vs 2025.11 does not show much | 05:48 | |
| brw.sparrowhub.io/report/brw-reporter/2957 | 05:49 | ||
| ab5tract | MasterDuke: so wuold spesh essentially install a state variable in the scope and reference that? That also sounds like the kind of thing I would expect a RakuAST based optimizer to be able to do as well | 07:32 | |
| melezhik_ | update on yesterday run on Rakudo head to test PTY merge. I again have seen quite a few TAP related failures , which are pretty meaningless to me - gist.github.com/melezhik/599e7282c...b6359792cf | 09:29 | |
| many times those failures happen on patrickb: agent (happy-herschel-****) | 09:30 | ||
| maybe such a failures happen on other agents, I don't know, but what puzzles me more, if I rerun those tests one more time ( and sometimes not on happy-herschel-**** agent ) they all pass | 09:31 | ||
| what's so special about happy-herschel-**** agent ? I don't know , the only thing first come to my mind it runs 19 parallels jobs, in comparison with [Coke]: (4 parallel jobs ) and mine (1 parallel job), which makes me think maybe this is sort of high concurrency related issue ? I dunno 🤷 | 09:33 | ||
| but the issue by itself is quite annoying as it cause some modules fails falsely and requires modules rerun ( and sometimes not on happy-herschel-*** agent ) | 09:34 | ||
| the latest commit to the agent gave added --debug flag for test runner, so hopefully it will get more details next time we encounter the issues, nevertheless it's still weird to have a such unpredictable behavior given we test the same rakudo version on the same container environment | 09:36 | ||
| ok, other different between happy-herschel-*** and other agents - mine one at least on docker, [Coke]: which one do you have ? happy-herschel-*** is on podman ... | 09:38 | ||
| other different -> other difference | 09:39 | ||
| patrickb | easy test: I set the parallel jobs to 1 on the next run. Then we'll see if it's the parallelity or something else. | 09:46 | |
| librasteve_ | lizmat: hi i saw your ping - just heading out to get a tree | 11:34 | |
| lizmat | ack | ||
| librasteve_ | i’ll pong when im back | 11:35 | |
| lizmat | ok | ||
| Geth | rakudo/andthen-orelse: 11 commits pushed by ab5tract++ review: github.com/rakudo/rakudo/compare/e...d9987d7680 |
11:57 | |
| melezhik | [Coke]: would be interesting to compare results with blin if you have them | 13:26 | |
| [Coke] | * [ ] [Unicode::Security](raku.land/zef:jjmerelo/Unicode::Security) – Fail, Bisected: [1e66a50](github.com/rakudo/rakudo/commit/1e...5809c85f2) | 13:38 | |
| * [ ] [Inline::Perl5](raku.land/cpan:NINE/Inline::Perl5) – Fail, Bisected: [63bc8b8](github.com/rakudo/rakudo/commit/63...08207b510) | |||
| So just the one new issue, with Inline::Perl5 | |||
| ... and that bisected to the pty support merge | 13:39 | ||
| lizmat | Unicode::Security failure could be attributed to the move to Unicode 17 perahaps ? | 13:42 | |
| patrickb | Is there a link pointing to the error log? | 13:45 | |