06:21 kjp left 06:22 kjp joined 06:24 kjp left, kjp joined 08:13 sena_kun joined 13:33 vrurg_ left, vrurg joined 13:34 vrurg_ joined, vrurg left 13:36 vrurg joined 13:39 vrurg_ left 13:46 vrurg left 13:48 vrurg joined 14:10 vrurg_ joined 14:13 vrurg left 14:18 vrurg joined 14:22 vrurg_ left 14:24 vrurg_ joined 14:28 vrurg left 14:37 vrurg_ left, vrurg joined 15:53 vrurg_ joined 15:55 vrurg left 15:59 vrurg_ left
Geth MoarVM/moar_gdb_jitreader: 3c63afed7d | (Timo Paulssen)++ | 2 files
Add a module for the gdb jit-reader functionality
 16:40
18:58 vrurg joined 20:30 sena_kun left 20:57 sena_kun joined 20:58 sena_kun left 21:06 sena_kun joined 21:21 sena_kun left
ab5tract Windows is going to go red soon as well github.com/rakudo/rakudo/issues/5566 22:25
ugexe i'm not sure if the situation is as serious as that issue implies 22:26
ah nevermind, that is a different windows issue than what i initially thought 22:27
a bit of a frustrating issue to parse though, due to it being a bit panic-y and not much information about what actually happened since all the logs linked to no longer exist 22:31
timo > Error: The log was not found. It may have been deleted based on retention settings. 22:32
i'm not sure if there was a "pin" or "keep" button somewhere on azure or so 22:33
yeah
do we know if "return code 0xff" refers to something like a segfault or so?
ugexe im also not sure this is general windows brokenness. my hunch is it is only *building* rakudo and only on github actions
timo do we know how much ram these runners have? 22:34
maybe it's a bit too tight?
ugexe i imagine every module using github actions to ci test is using Raku/raku-setup or whatever, which uses rakubrew and binaries (i.e. no building occurs) 22:35
timo we can just™ add another windows version to the matrix in azure-pipelines.yml and get a fresh run, then we can see what debugging options are available to us
ugexe i don't remember how much ram the runners have, although i did not that the resources available to the github runner were either the same or better than the appveyor runners
despite the resources being similar i've never been able to get CI working for zef on github actions (precomp issues that ive never been able to reproduce) when it always works on appveyor 22:37
timo oh that's frustrating 22:39
ab5tract The last time I tried to compile Rakudo on Windows I threw up my hands after quite a few hours of getting nowhere. But somehow we keep pressing releases, so I guess someone has figured it out at least? 22:42
timo the azure-pipelines.yml file links to a dev.azure.com URL that only has some runs from rba from 2020 22:47
it occurs to me that i don't know how to set up azure pipelines for my own fork of the rakudo repository 22:58
so i'll just put it in rakudo/rakudo instead and hope that a commit in a branch that changes azure-pipelines.yml will be picked up 22:59
ugexe github.com/ugexe/zef/blob/da187d34...ml#L19-L25
i've been using this windows CI workflow for years and it still works 23:00
i wonder what version of windows it is using though
timo is the windows icon on the task bar a big round globe that kind of sticks out? :P 23:01
ugexe Windows Server 2019 :grimace: 23:02
ab5tract Not as ancient as it could be 23:03
timo i think the rakudo repository is explicitly set up to only run pipelines for the main branch, could that be? i don't think i have whatever permissions are needed to see that part of the configuration
ab5tract timo: hmm.. PRs do get checked 23:05
timo i just created one
ok it looks like it picked up my changes for the matrix, i.e. the mac and linux builds aren't there because i commented them out 23:06
i could also have turned off the jvm one
great, i typoed it 23:07
ab5tract Ah, that’s cool that PRs for CI changes actually incorporate those changes. I’ve had mixed results on that front with gitlab at $work 23:09
timo gitlab cicd is a bit funky as well where it may "freeze" some things when a pipeline is first created, and then you may need to "destroy pipeline" if you want to change something and retry? not sure about the details 23:10
how on earth does it takes >2m to git clone the rakudo repository on the runners ...
never mind it was my crappy internet connection that made me think that 23:12
dev.azure.com/Rakudo/rakudo/_build...ff75bff664 is it just me or is it incredibly slow to compile moarvm on this windows runner? 23:19
ab5tract I think 20+ minutes is quite common 23:21
Though I don’t know if that includes tests or not.. 23:22
timo the rakudo windows build wasn't killed because it hit a timeout, was it?
the t_win_mvm is at 13 minutes and it's still showing me that it just compiled main.c and nothing else
main.c is tiny
ab5tract Uff 23:25
timo The following step can take a long time, please be patient. 23:27
Stage start : 0.000
NMAKE : fatal error U1077: '@"C:\Strawberry\perl\bin\perl.exe" rakudo-m-early-build --setting=NULL.c --ll-exception --optimize=3 --target=mbc --stagestats --output=blib\CORE.c.setting.moarvm "gen\moar\CORE.c.setting"' : return code '0xff'
Stop.
ab5tract Just saw that too
setting=NULL.c ? 23:28
timo yeah that's how we build the core.c setting
we can't have it try to use the core.c.setting to build the core.c setting, naturally
ab5tract Ah ok, I don’t know much about the bootstrap bits
Well, is NULL.c an actual thing that gets built or is provided? Because if not then a specific flag would be just as appropriate, no? 23:30
Anyway, I applaud you for poking at this timo 23:31
I had neither the GitHub permissions nor the patience to look into it
timo how do developers with windows even deal ... windbg and windbg's logger.exe ("more or less strace for windows") are both gui-only applications? how the fuck does that help when you're trying to debug a CI run 23:48

Powered by Cro and the Raku® Programming Language.

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

Thank you!