00:20 itaipu left 00:46 itaipu joined 01:26 itaipu left
disbot11 <.landyacht.> Hm, Rakudo is sucking memory and CPU on startup and not even printing a statement I put in a BEGIN phaser... any tricks for diagnosing this? I almost suspect something with precompilation, but I don't know how one disables that 01:47
<.landyacht.> yeah, even running with -c flag does this 01:49
01:49 itaipu joined 02:15 kylese left 02:16 kylese joined 02:20 sibl joined
Voldenet Probably some compilation issue 02:36
the only way to debug it would be probably using gdb
breaking and printing stack at some point :\ 02:37
I'm betting infinite recursion because that's the easiest way to get this
since you don't need to even run the code, consider golfing 02:38
03:05 annamalai joined 03:15 kylese left, kylese joined 03:21 vasko4535586 left 03:22 vasko4535586 joined
disbot11 <.landyacht.> yeah I'm working on a pretty large application and given the vague nature of the problem idk where to start with tracking down a golf :/ 03:44
<.landyacht.> I'll give gdb a try, haven't used that in ages
04:15 sibl left 04:35 lichtkind__ joined 04:38 lichtkind_ left 05:06 stanrifkin joined
Voldenet Hm, maybe there's a way of getting a stack from rakudo itself 05:24
if the app is truly large but modular then maybe RAKUDO_MODULE_DEBUG=1 would help somehow 05:29
so, you may need to use `call (void)MVM_dump_backtrace(tc)` in gdb 05:37
06:13 johnjay joined 06:55 stanrifkin left 07:01 Aedil joined 07:30 stanrifkin joined 07:59 sibl joined 08:10 atcroft left 08:25 atcroft joined 08:55 sibl left 09:13 Aedil left 09:17 Sgeo left
librasteve_ weekly: raku -e 'flat (1,3,2).rotor: 3 => -2 andthen say ( * < * > * )(|$_) ;' 09:55
notable6 librasteve_, Noted! (weekly)
wayland76 If `rakubrew build jvm` fails, where do I report it? 10:14
11:03 merp joined
timo unfortunately, we know that the jvm version of rakudo doesn't build at the moment 11:55
12:05 maskd left
lizmat weekly: my @a = 1,2,3,4,5; sub foo($a, @b) { }; foo(@a.head, @a.skip) is about 13x as fast as: foo(@a[0], @a[1..*]) 12:47
notable6 lizmat, Noted! (weekly)
13:31 Aedil joined 13:34 itaipu left 13:50 itaipu joined
tbrowder lizmat we need the raku fire dept for Spreadsheet::XLMS. it's ver 0.3.4 shows on Raku.land but not on the repo. [Coke] talked me through releasing from my fork of main but i got a failure when i ran mi6 release for 0.3.4. 14:01
hopefull the raku fire chief can fix it šŸ„² 14:03
timo i can take a look 14:04
do you have your own fork of the repository on github, or were you working directly against the upstream one? is that in the raku-community-modules org? 14:05
tbrowder duh Spreadsheet::XLXS
lizmat XLSX you mean?
timo ok, you do have a fork of your own, which doesn't have the tag for 0.3.4 either 14:06
when you "git tags" in your local checkout, does 0.3.4 show up? if so, all you have to do is probably `git push --tags`
tbrowder i was using my fork of the raku-community-modules/Spreadsheet-XLXS.git 14:07
lizmat well, I guess we need a way to find out from zef *who* uploaded a version of a module at what time 14:08
timo could be you don't have permissions to push a tag to that repo
lizmat tonyo ugexe ^^ could the logs tell us who uploaded 0.3.4 of Spreadsheet::XLSX ? 14:09
tbrowder that's what i suspect.
timo oh, i might have misread your initial message
lizmat I wonder if that's the case? anyways, I guess we shouldn't allow uploads from non-default branches 14:10
tbrowder and i really don't want it
timo you didn't get a successful "mi6 release" even after coke helped?
tbrowder no
lizmat well, I could release a 0.3.5 now just in case
should I ?
as the current release on raku.land is essentially roague 14:11
*rogue
lizmat hates the fez CLI help (or lack of) 14:16
0.3.5 released 14:23
tbrowder cool, water on the fire, thanks! 14:24
i don't see it on raku.land yet, but the repo looks good! 14:38
[Coke] .... I did not talk you through release from "your fork of main", but instead suggested you should release from the rcm primary repo! 15:03
15:10 snonux left 15:11 snonux joined
ugexe releasing from non-default branches is the probably the appropriate way to do releases, i.e. having release branches is more proper than releasing from main 15:54
so disallowing uploads from non-default branches would not be a good thing
tbh i still dont understand what the actual problem is 15:57
without looking at code just because mi6 didnt complete successfully doesn't mean it didnt publish a release 16:03
http calls aren't like database transactions that roll back
if im imagining a way to avoid user error in these type of situations, the thing that comes to mind would be emailing authors when they make a new release to let them know the distribution was uploaded and separately let them know the distribution was validated/indexed. if a user makes a release they did not expect it should become clear to them once they get one of these emails 16:19
that being said, if you're using mi6 it seems like it should be trivial to write your own plug/step thing for your dist.ini to make sure you are on some arbitrary branch 16:27
it shouldn't be a default thing though
lizmat ugexe: the weird thing is that raku.land reported version 0.3.4, whereas the repo was still at 0.3.3 17:02
ugexe why is that weird
lizmat in the META6.json
ugexe or in other words: what makes you think releasing a distribution to the ecosystem and pushing to git are atomic or even guaranteed to always happen together 17:03
lizmat I guess it all boils down to being stricter on who can upload Raku Community Modules 17:08
and in that light: how does one remove a member from a fez organization 17:09
?
fez org mod ... and then?
the help doesn't make that clear
timo so is the problem that tbrowder accidentally released from a commit that never made it into the main repository? 17:10
lizmat yes, it looks like 17:35
ugexe: re branches: maybe somewhere (META6.json) it should say from which branch a release should be done (and fail if the branch is incorrect ??) 17:37
ugexe that type of information doesn't belong in a meta6.json 17:38
as i said earlier, a mi6 plugin/config or some such is the appropriate place to do something like that
18:09 wayland76 left, wayland joined
disbot11 <librasteve> fwiw, the fez success message ā€œyou did itā€ it echoed by mi6 release ā€¦ pretty sure that has the version number 18:53
18:54 Sgeo joined 18:56 librasteve_ left
timo do we have the actual output from the `mi6 release` attempt? 18:56
19:16 silug left 19:33 silug joined 19:35 silug left 19:41 silug joined 19:43 silug left 19:44 silug joined 19:49 silug left
disbot11 <.landyacht.> a-ha, I found the compilation issue 20:12
<.landyacht.> using a role type parameter as a type constraint for a hash...
<.landyacht.> let's see if this reproduces in a single-file example
<.landyacht.> oh boy, no, it's obviously more complicated - I can pull out the offending role and its one dependency, along with the test file, and it works... 20:43
<.landyacht.> but it doesn't work when I'm in the project, even after deleting all the precomps
<.landyacht.> however I now know it does get as far as creating the local .precomp dir 20:44
<.landyacht.> the only difference I can think is there's a META6.json 20:45
timo do you know if the problem happens only after you load precompiled code? 20:46
disbot11 <.landyacht.> that I'm not 100% sure of, I don't know how to disable that though 20:47
<.landyacht.> hiding META6.json also did not change the behavior so that's not it
timo you can put `no precompilation;` into a file
disbot11 <.landyacht.> ahh
timo that prevents a file from getting precompiled
it will not prevent loading of precompiled modules
disbot11 <.landyacht.> okay, disabling precomp and deleting all the precomp folders (local and in ~/.raku) does not change the outcome :( 20:53
<.landyacht.> this is so bizarre 20:54
<.landyacht.> oh well, I'm enforcing the type constraint on the methods that allow access to that hash anyway, so I'll just untype it 20:55
<.landyacht.> that one change does fix the issue
<.landyacht.> I have no idea what else to look for so I'm going to leave it this way, maybe try again to add the constraint in a year, and hope it magically got fixed lol
tbrowder timo: sorry, i do not 21:25
Voldenet something like this? 21:27
m: role X[::V] { has V %!x; }; X[Int].new
camelia MoarVM panic: Memory allocation failed; could not allocate 131072 bytes
Voldenet (regarding the typed hassh) 21:28
I've seen `from src/Perl6/Metamodel/GenericHOW.nqp:42 (/opt/rakudo/share/perl6/lib/Perl6/Metamodel.moarvm:instantiate_generic)` already 21:30
disbot11 <.landyacht.> yeah that's the general idea 21:48
<.landyacht.> there's something with the interaction with the rest of the code, which is weird because it happens even when I run the test of that role in isolation, but not if I copy all the files out to a different place... I don't know, I'm tired of messing with it at this point :P 21:49
wayland timo: OK, thanks! :) 21:51
disbot11 <.landyacht.> I will note, the type parameter is also constrained (that's the one other file I have to pull in) 21:57
21:57 wayland left 22:02 Aedil left
Voldenet it might be that the type is instantiated in compile time for something 22:16
22:59 annamalai left
tonyo lizmat: i can take a look - do you know about when that happened? 23:24
tellable6 2026-01-09T23:08:53Z #raku <[Coke]> tonyo - I uploaded a module with fez about 40 minutes ago - I am unable to fez remove 'Math::Zeckendorf:ver<0.0.1>:auth<zef:coke>'
tonyo [Coke]: i can mark it deleted, you might have to bump to next version to upload. what is the output of trying to delete? 23:30
lizmat: found it but that user has no other modules and one other failed attempt to upload. it is possible they've uploaded something prior to my logging being set up the way it is but the only user i can't find a dist for is antonocube 23:36

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!