|
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 | ||