| 6 Mar 2026 | |||
| timo | there used to be no way to get an object's WHO, but I created a command for this purpose last year or so | 23:12 | |
| oh, hm, did i not merge that to main maybe? | 23:30 | ||
| 7 Mar 2026 | |||
| patrickb | Just to make sure: WHO won't give me access to the full list of lexicaly available packages, correct? | 07:45 | |
| Geth | MoarVM: MasterDuke17++ created pull request #1993: Bump mimalloc to v2.2.7 |
17:53 | |
| 8 Mar 2026 | |||
| MoarVM/main: 4 commits pushed by (Daniel Green)++, MasterDuke17++ | 18:25 | ||
| lizmat | MasterDuke++ | 18:36 | |
| MasterDuke: I can't get rakudo to build anymore after the NQP bump | 23:55 | ||
| tellable6 | lizmat, I'll pass your message to MasterDuke | ||
| lizmat | compiling src/core/index_hash_table.o | ||
| ^Cmake: *** [src/core/index_hash_table.o] Interrupt: 2 | |||
| ===SORRY!=== | |||
| No moar executable found in /Users/liz/Github/rakudo/install at /Users/liz/Github/rakudo/nqp/3rdparty/nqp-configure/lib/NQP/Config.pm line 192. | |||
| 9 Mar 2026 | |||
| timo | lizmat: the "sorry! no moar executable found" is surely from the part that had just called the "compile me a moarvm" for --gen-moar and didn't check the return value? | 00:03 | |
| i don't know what "Interrupt: 2" means, but i'm guessing you didn't send a signal to the process by hand | |||
| i think you will have to paste more than just the last line of make | 00:04 | ||
| surely your make is compiling moar in multiple processes at the same time so after the error that aborted the compilation you'll see lines for all the other compilations that were going on at the same time too | 00:05 | ||
| Fetching submodule 3rdparty/libtommath | 00:06 | ||
| fatal: remote error: upload-pack: not our ref 84ad9c0bc3d13e83db87f1aa1b0d7f94bf8cf741 | |||
| Errors during submodule fetch: | |||
| 3rdparty/libtommath | |||
| but yeah it looks like the commit set for the libtommath submodule isn't in the repo | 00:07 | ||
| unclear how the CI was able to check out and build moarvm if that's the case though | 00:10 | ||
| github.com/MoarVM/libtommath/compa...9cf2b5165b - in the "changed files" github shows these changes, where does the 84ad9c0bc commit come from? | 00:12 | ||
| maybe when there's no tag or branch that points at it it won't be fetched and appear to be missing? | |||
| weird, after a `git submodule update` it works now? | 00:15 | ||
| i'm not sure why that would be necessary. but doesn't our Configure.pl script do that always anyway? do we need something in --gen-moar (which i don't like too much anyway) to be resilient against this issue? | 00:17 | ||
| ShimmerFairy | timo: As another data point, I just encountered the same issue. First 'git pull' aborts partway through, because libtommath doesn't have commit 84ad9c..., then second 'git pull' finishes the job, but now libtommath is listed in 'git status' as having unstaged commits. Running the configure script updates the submodules, now libtommath is considered up-to-date at commit 87c5876... | 09:16 | |
| Unfortunately, I didn't think to check libtommath when it was in that "unstaged commits" stage, but there's definitely something funky going on here. | |||
| Another weird thing: grepping for '84ad9c' in my current pull of main reveals absolutely nothing. Strange. | 09:19 | ||
| patrickb | When traversing the outer context chain and going beyond the context that contains the !UNIT_MARKER lexical, what lies there? The setting? | 09:40 | |
| The next outer one contains a single lexical "RakuAST" being a Failure object, the next outer has a hand full of lexicals, including $?LANGUAGE_REVISION and CORE_SETTING_REV, then the next outer is entirely empty, the next outer contains hundreds (maybe thousands) of lexicals (the setting?), lastly there is another empty context. | 09:45 | ||
| What's a good place to look / investigate / read up on what those are? | 09:46 | ||
| timo | some of our settings are just a layer on top of another setting that only has the changed things in it | 12:07 | |
| patrickb | ah, 6.e, 6.f and so forth | 12:20 | |
| timo | it's not a rule, or a fixed requirement, but stacking settings is something we can do and we do it for at least some of the settings | 12:33 | |
| if you have --no-silent-build in your rakudo Configure.pl you should be able to see which core is created with what other core as its --setting= | |||
| 10 Mar 2026 | |||
| librasteve_ | rakudoweekly.blog/2026/03/10/2026-...g-cragcli/ | 14:50 | |
| [Coke] | Let's make sure that the release isn't going to be bitten by this submodule issue. | 14:51 | |
| lizmat | librasteve_++ | 14:55 | |
| [Coke] | (though it does sound like it will only bite folks who build from git in the same checkout all the time, right?0 | 14:57 | |
| lizmat | yeah, looks like | ||
| timo | d'oh the weekly shows "[removed by moderator]" already in the preview :( | 15:16 | |
| > Removed due to being low quality. | |||
| huh. | |||
| you might have much more success if you create CrgCL (that is CragCLI without the a and I) | 15:23 | ||
| [Coke] | ... scraggly | 16:03 | |
| [Coke] hides | |||
| librasteve | oh dear - seems to have survided at www.reddit.com/r/CLI/comments/1rpz...are_button for now | 16:20 | |
| I have updated the weekly to not point to a dead link | 16:24 | ||