[Coke] looks like the blin run not only died but took my tmux session with it. wtf 00:50
01:55 sjn left 02:07 sjn joined
[Coke] it happened again - got partway through the blin run (in a tmux session), come back later to see tmux a 05:36
[exited]
the last output was đŸ„žđŸ„žđŸ„ž Testing LibXML (new)
jdv: let me know if your run completed successfully. 05:37
only thing in the output/ folder is overview, which is just names of packages.
(well, it has some OK, some AlwaysFail, but 675 Unkown that it didn't get to) 05:39
If yours dies, then I assume we have some badly behaving package. 05:42
(otherwise I still need to flesh out this blin setup)
patrickb [Coke]: re *.bak in .gitignore. Yes, I agree that having things that only matter for individuals should go into .git/config/exclude. But ignoring typical editor temporary files will make working on our stuff more pleasant for everyone using that editor. 07:57
(I'm not strongly opinionated on that one. If people want this out, then I'll gladly remove that commit.) 07:58
sjn agrees with patrickb. any files that are generated automatically during normal work within a repo, and that are not intended to be committed, should be ignored at the repo level (as a QOL matter, but also to avoid clutter, and help detect unexpected behaviour on the filesystem) 08:40
08:50 sena_kun joined 10:01 sena_kun left
Geth nqp/main: dbf4bb8282 | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump MoarVM to get debugserver fix
 10:32
rakudo/main: 9bf3be4d2e | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP to get MoarVM debugserver fixes
 10:42
lizmat notable6: weekly 11:39
notable6 lizmat, 8 notes: gist.github.com/5144db6d8f8eb47ecb...73905d9371
lizmat notable6: weekly reset 12:22
notable6 lizmat, Moved existing notes to “weekly_2024-12-09T12:22:57Z”
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2024/12/09/2024-...kduckcool/ 12:54
jdv [Coke]: my run produced a failures.md file that i'm curating shortly 14:39
it was not a happy ending run (blin hung) but its not the first time
19 raw fails:( 14:44
[Coke] I wonder if I hung and it got killed by the OS? 14:45
Did you also run at 0911eca22 ?
linkable6 (2024-12-05) github.com/rakudo/rakudo/commit/0911eca222 Hopefully address $*USER / $*GROUP on Windows
[Coke] I do at least have an azure config that'll let it complete in under a day now. :) 14:46
jdv Blin results between 2024.10 (44bc9df) and HEAD (4082d2c): 14:47
its always been a fragile thing...
github.com/rakudo/rakudo/issues/5726 15:54
lizmat: looks like mostly from your work ^
ab5tract: looks like your repl change upset Jupyter::Chatbook ^ 15:55
a bunch of them, maybe half are deps breaking (Digest/JSON::Tiny)... 15:56
[Coke]: so if you look at the difference between the orig and the one that's directly in the ticket, that's what basically has to be done post blin run 15:57
[Coke] was c81d9cf just after the 2024.10? 15:58
jdv i didn't look tbh
[Coke] that breaking commit was from Oct, wasn't a recent one. 15:59
jdv iirc that might be the one where an older attempt broke the last release and it had to be backed out
but ok:) 16:00
[Coke] if we get an UnhandledException, are there any more details? (tried to get a single module run) gist.github.com/coke/13e4248ebe582...5841c96581 16:02
jdv i don't think i've ever looked into it, probably cause i've never seen anything there unexpectedly 16:03
maybe in the output dir? but i already threw mine away:(
[Coke] output has the data.json but that just says UnhandledException with an empty errors attribute 16:04
how much memory do you have on your box? do you know how much the blin run consumes by the end? 16:05
jdv i have 16G ram and 16G swap:) 16:07
i added the swap because a few releases ago something leaked and i could catch it before it oom'd cause i checked in every hour or so...
[Coke]: ah, i only know we have the output for "failure"s and maybe the dist dir or someting in output too 16:08
iirc it used maybe 10G last night but i wasn't watching too closely 16:09
i run with --nproc=12
[Coke] with how many CPUS? 16:13
jdv "16" 16:15
gist.github.com/jdv/035fadfa59e9e0...571e34e2e5 16:16
[Coke] ok, added some swap here as well 16:24
.. why is this VM running lorea automatically on startup... 16:26
jdv ideally the jobs would get automatically killed and "failed" on using too much mem
but never got around to looking into it as its pretty rare and only comes up once a month:) 16:27
but it is pretty annoying when the run is mostly done and then the box ooms:| 16:31
[Coke] apparently the suggested settings for the docker container in raku.land cause it to restart... even after a reboot. whee. 16:44
2024-12-09T00:29:01.430885+00:00 raku-blin systemd[1]: user@1000.service: A process of this unit has been killed by the OOM killer. - ah, that *was* it. 16:54
added 4G of swap, will try again.
timo could be it took the whole cgroup with it and that extended to your tmux if you were unlucky? or did it just exit because the thing in it closed? for the latter case i believe there is a setting that keeps tabs around after the process in it exits
[Coke] I mean, the process should have been bash, no? I'd expect the blin.p6 to die and be sitting at the bash prompt again 16:57
[Coke] has also killed off the copy of raku.land that was running in the background, somehow having survived after 2 months and 4 different VM upgrades. :) 16:58
f/win 11 17:15
lizmat bisectable6: old=2024.10 dd dir(".").head(2)' 17:39
bisectable6 lizmat, Bisecting by output (old=2024.10 new=0911eca) because on both starting points the exit code is 1
lizmat, bisect log: gist.github.com/cd3f3e4ff0bc9eae40...4d0eed1504
lizmat, (2024-11-22) github.com/rakudo/rakudo/commit/a9...b4dced35bc
lizmat bisectable6: old=2024.10 dd dir(".").head(2)
bisectable6 lizmat, On both starting points (old=2024.10 new=0911eca) the exit code is 0 and the output is identical as well
lizmat, Output on both points: «(IO::Path.new("sandbox", :SPEC(IO::Spec::Unix), :CWD("/srv")), IO::Path.new("data", :SPEC(IO::Spec::Unix), :CWD("/srv"))).Seq␀»
lizmat bisectable6: old=2024.10 use nqp; dd nqp::nextfiledir(nqp::opendir(".")) 18:02
bisectable6 lizmat, Bisecting by output (old=2024.10 new=0911eca) because on both starting points the exit code is 0
lizmat, bisect log: gist.github.com/004906331f7855de47...e3c918835e
lizmat, (2024-11-28) github.com/rakudo/rakudo/commit/c6...85c11737ee
lizmat bisectable6: old=2024.10 use nqp; my $h := nqp::opendir("."); dd nqp::nextfiledir($h), nqp::nextfiledir($h) 18:04
bisectable6 lizmat, Bisecting by output (old=2024.10 new=0911eca) because on both starting points the exit code is 0
lizmat, bisect log: gist.github.com/1b15edbac0a5916d17...d5b40f774f
lizmat, (2024-11-28) github.com/rakudo/rakudo/commit/c6...85c11737ee
18:08 sena_kun joined 18:11 gfldex joined
releasable6 Next release in ≈4 days and ≈23 hours. 1 blocker. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 19:00
19:10 japhb left 19:11 japhb joined
lizmat bisectable6: old=2024.10 my uint32 @a[3] = 1,2,3; dd @a[1..*] 19:59
bisectable6 lizmat, On both starting points (old=2024.10 new=0911eca) the exit code is 1 and the output is identical as well
lizmat, Output on both points: «Index 3 for dimension 1 out of range (must be 0..2)␀ in block <unit> at /tmp/GLCsxvInBM line 1␀␀»
lizmat I wonder whether we should look at the Range in a slice, and if endpoint is Inf, assume the invocant's .end instead ? 20:00
20:10 japhb left 20:29 japhb joined 20:50 japhb left
lizmat jdv [Coke] fixed first blin issue, looking at 2nd but too gnarly for my current state of mind 21:10
will look again tomorrow
Geth roast: 3822c39451 | (Christian BartolomÀus)++ | integration/man-or-boy.t
[JVM] Cut down test that often fails

Very often the tenth test fails with a StackOverflowError. Hopefully this can be fixed at some point, but for cutting down the test makes spotting other problems or regressions easier.		 21:23
21:25 sena_kun left 23:03 sena_kun joined 23:33 sena_kun left

Powered by Cro and the RakuÂź Programming Language.

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

Thank you!