01:41 Pixi` joined 01:44 Pixi left 01:51 Pixi__ joined, [Coke]_ joined 01:56 lucs_ joined 02:00 Pixi` left, quotable6 left, committable6 left, evalable6 left, lucs left, notable6 left, linkable6 left, coverable6 left, greppable6 left, sourceable6 left, [Coke] left, unicodable6 left 02:03 evalable6 joined, greppable6 joined, sourceable6 joined, linkable6 joined, committable6 joined, notable6 joined, quotable6 joined 02:39 [Coke]_ is now known as [Coke] 03:51 melezhik_ left 05:43 melezhik joined
melezhik Ok. Run Rakudo::Options 0.0.3 on Rakudo 2025.11 compiled from source code , it passes the tests. So looks my theory on compile from source relation does not confirm . 07:14
Bug is still reproducible for Rakudo::Options 0.0.3 if run under Rakudo star bundle 2025.11 07:15
Rakudo::Options 0.0.4 passes tests as well, but I have not tried it with Rakudo star , will do later 07:16
Still waiting information from patrickb on his agent environment
patrickb melezhik: Literal screenshot: imgur.com/a/s2uYexT 08:00
melezhik: I did not modify the run.sh apart from s/docker/podman/ and the threads up to 19. Thus I do have the BRW_AGENT_CAP_INSTALL_FROM_SOURCE_FORCE=1 set. 08:02
I did not modify the environment. It's the vanilla debian env. 08:03
I've added a screenshot of run.sh and the env to the same URL. 08:06
My first guess as to why things don't behave identical everywhere is timing. That same behavior also sometimes shows in our CI. It fails reliably in the CI but passes on most end user machines. The reason is often: The CI is a lot slower. 08:09
melezhik Yeah. It could be timing , but Rakudo::Options error is of rather logical rather than timing nature …. Hold on )) your screen shot shows sparrow task uses default ( system Rakudo ) not whateverable one as it should , the test passes now , but just because lizmat has fixed in 0.0.4 08:20
patrickb I'm tracking down an issue in PR #5060. "Cannot find symbol GLOBAL in CORE.d". Can someone give me a primer on what GLOBAL is and how it's bootstrapped? I observe that error in code called from World.comp_unit_stage0. 08:33
It happens when trying to install zef during the "Staging" phase. 08:34
melezhik Ok, I guess this is just because you run this one before Rakudo was installed in agent 08:37
patrickb Actually I guess I'd be fine to just do it in RakuAST instead. (Where there is no World, right?) I then probably also need a few pointers. 08:54
lizmat perhaps nine could give some :-) 09:12
patrickb The CompUnit/Repository stuff is not yet supported in RakuAST, correct? (I wonder, because there is a usage of World in RepositoryRegistry.resolve-unknown-repos) 09:16
lizmat ah, indeed... ok, I guess that would need to be fixed in 6.e 09:18
which would also be a chicken/egg problem :-(
ab5tract patrickb:last I checked all mentions of $*W are actually properly accounted for 09:38
patrickb github.com/rakudo/rakudo/blob/main...kumod#L347 09:40
that's the line
ab5tract patrickb: the construction of pseudo stashes is different in 6.e, you are looking for PsuedoStash.rakumod
(One of those files for 6.e, the other for earlier versions) 09:41
patrickb: but its potential absence is accounted for here github.com/rakudo/rakudo/blob/6b47...kumod#L361
lizmat: did we ever get around to parallelizing the feed operators? 09:42
lizmat I made a gist and/or a PR for it... 09:43
ab5tract Eek
I will claim I must have been hibernating to miss it
patrickb oh interesting. the find_single_symbol in that very line is the call that fails with "GLOBAL not found in CORE.d" 09:44
So This issue might already be gone in RAST. \o/ 09:45
Am I already able to install zef and other modules with RAST? 09:47
ab5tract No
:(
There is a package name resolution problem that blocks make install
I believe it also is related to failures with zef 09:48
But please feel free to dig into the zef side of things
lizmat gist.github.com/lizmat/8652e4a403f...2b31cc6ad4 6 years ago 09:49
ab5tract Well I was born yesterday, that explains it ;) 09:56
I wonder if fully converting the feed stuff in RakuAST away from its current QAST heavy approach would allow for this solution or even an AST based approach to work 09:58
Not that this doesn’t already work, I just mean maybe we could more or less rewrite this as AST. Then the eventual optimizer might be able to do intelligent things? 10:17
patrickb ab5tract: So I compile a Rakudo as usual, then with RAKUDO_RAKUAST=1 run `raku -I. bin/zef install .` and see what breaks, correct? 10:33
lizmat probably need to make sure .precomp is empty / doesn't exist as well 10:34
11:32 melezhik left
ab5tract patrickb: that should do it :) (per lizmat’s suggestion) 11:39
11:41 librasteve_ left
patrickb paste.sr.ht/~patrickb/abaf0e890d72...0d798cfa19 13:28
Is this the known RAST install error? 13:29
lizmat that *feels* like the error that broke Hash::Ordered, are you sure you are on HEAD patrickb ? 13:36
otoh, it could be that zef has an issue with roles that RakuAST is more picky about 13:37
patrickb yes, that's head 13:41
lizmat perhaps change line 192 to: but my role :: { .... } ? 13:50
just for debugging
if that fixes it, then I assume that RakuAST has a bug for nameless roles being "our" scoped rather than "anon" scoped 13:51
or maybe: but anon role { ... } 13:52
patrickb That gives a new error. So it indeed seems to fix the issue. 14:02
New error: paste.sr.ht/~patrickb/78bf7cdc2691...3f2e32e2e6
14:02 librasteve_ joined
patrickb Let me see if I'm able to locate the place where the scope for unnamed roles is set... 14:04
lizmat fwiw, I think simply doing: RAKUDO_RAKUAST=1 raku lib/Zef.rakumod 14:05
will show the error
as it really is a compilation issue with Zef itself in RakuAST
14:09 melezhik joined
melezhik Ok. patrickb [Coke] could you please pull the latest commit and upgrade agents . I am investigating those failing tests that appear in comparison reports and seems some of them if not many are due to subtle issue which leads to usage of default Rakudo instead of whateverabke 14:48
Whateverable
This at least explains issue with Rakudo::Options and some other modules 14:49
Still dunno 🤷 how this happens 14:50
When default Rakudo star bundle zef/rakudo is used for tests
Now this should not happen by design - github.com/melezhik/brownie/blob/d...k.bash#L49 14:51
Interesting why some modules fail to test under Rakudo star bundle 14:52
Rakudo::Options 0.0.3 , Hashids 14:53
Test::Fuzz 14:57
They all do not pass tests under Rakudo Star 2025.10
[Coke] git pull, rebuild, hard restart. 15:31
melezhik Ahhh, forgot to numb agent Version, but if you pull the latest , this should be fine 16:45
Bump 16:47
lizmat
.oO( are we sure the agents are agenting on their own free will ? :-)
 16:48
[Coke] restarted 17:14
melezhik [Coke]: ++ 18:08
lizmat: )) 18:09
patrickb: please update your agent when you can , thanks 🙏 18:10
[Coke] cro.raku.org/training-support - this is out of date, yes? 18:48
melezhik Hm , Coke-agent jobs are sort of stuck - gist.github.com/melezhik/dab288f13...11042417ad 18:53
Though I set timeouts … hm 18:54
ps aux | grep timeout 18:55
[Coke] shows one timeout 20m one timeout 10m job. 18:57
er, 2-3 depending. 18:58
melezhik Ok, then timeout should do their jobs soon or later 19:02
Ok. Report has arrived 19:03
New jobs have started , looks good
Fixed timeout abit 10m -> 20m 19:08
[Coke] github.com/croservices/cro/ - is this the right repo for cro these days? 19:23
If so, can someone add me as a ticket admin or something?
melezhik, for example has github.com/croservices/cro/issues/144 which is old and not a cro issue. 19:24
(actually, just add me to the org, if possible) 19:29
(rather than one repo)
Also, someone please re-open github.com/croservices/cro/issues/158, I misclicked close. :( 19:36
19:39 melezhik_ joined
melezhik_ lizmat: here is an example of failing Rakudo::Options:ver<0.0.3> on Rakudo Star 2025.10 and passing on Rakudo 2025.10 whateverable. Seems strange to me - gist.github.com/melezhik/ae37a0134...7fb4c451fa 19:41
19:48 melezhik_ left 19:49 linkable6 left, notable6 left, notable6 joined, linkable6 joined 19:50 quotable6 left, quotable6 joined
[Coke] do cro tickets get announced anywhere? 20:10
20:14 Geth__ joined
lizmat kicks Geth just to be on the safe side 20:14
20:18 Geth left 20:21 Geth__ left, Geth joined
lizmat I don't think we actually announce issue creation? 20:26
20:28 rakkable left 20:29 rakkable joined
[Coke] at all? OK. 20:35
21:12 melezhik left
[Coke] had to restart docker here, melezhik. 22:03
(reboot the laptop, actually)
Geth rakudo: patrickbkr++ created pull request #6038:
Default unnamed packages to `my` scope instead of `our`		 22:25
patrickb lizmat: I've created a minimal patch to default unnamed packages to `my`. That fixes this issue. But trying to set it to `anon` instead (which I find more logical) gives "Cannot use 'anon' with role declaration". 22:26
github.com/rakudo/rakudo/pull/6038
Next up: No such method 'meta-object' for invocant of type 22:36
'RakuAST::Declaration::Import'
I'm off for today. o/ 22:37

Powered by Cro and the Raku® Programming Language.

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

Thank you!