[00:08] *** leont left [00:09] *** leont joined [00:59] *** leont left [01:36] *** sena_kun joined [01:37] *** Altai-man_ left [03:35] *** Altai-man_ joined [03:37] *** sena_kun left [04:37] *** bloatable6 left [04:37] *** coverable6 left [04:37] *** unicodable6 left [04:37] *** sourceable6 left [04:37] *** statisfiable6 left [04:37] *** greppable6 left [04:37] *** reportable6 left [04:37] *** linkable6 left [04:37] *** notable6 left [04:37] *** bisectable6 left [04:37] *** evalable6 left [04:37] *** releasable6 left [04:37] *** shareable6 left [04:37] *** quotable6 left [04:37] *** committable6 left [04:37] *** nativecallable6 left [04:37] *** benchable6 left [04:37] *** squashable6 left [04:37] *** tellable6 left [04:38] *** coverable6 joined [04:38] *** statisfiable6 joined [04:38] *** committable6 joined [04:38] *** bisectable6 joined [04:39] *** linkable6 joined [04:39] *** bloatable6 joined [04:39] *** evalable6 joined [04:39] *** tellable6 joined [04:39] *** shareable6 joined [04:39] *** sourceable6 joined [04:39] *** nativecallable6 joined [04:39] *** greppable6 joined [04:40] *** notable6 joined [04:40] *** reportable6 joined [04:40] *** quotable6 joined [04:40] *** unicodable6 joined [04:40] *** releasable6 joined [04:40] *** squashable6 joined [04:40] *** benchable6 joined [05:36] *** sena_kun joined [05:37] *** Altai-man_ left [05:58] *** Kaiepi left [05:58] *** Kaeipi joined [07:04] timotimo: in my experience one isn't getting the flu symptoms. They're suddenly there. [07:35] *** Altai-man_ joined [07:35] *** Voldenet left [07:36] *** Voldenet joined [07:36] *** Voldenet left [07:36] *** Voldenet joined [07:37] *** sena_kun left [09:36] *** sena_kun joined [09:37] *** Altai-man_ left [10:56] *** domidumont joined [11:35] *** domidumont left [11:35] *** Altai-man_ joined [11:37] *** sena_kun left [12:27] yesterday it was just sore throat, now i'm also sneezing / have a runny nose [12:41] *** leont joined [12:45] oh noes :-) the floe! [12:45] * lizmat also has a runny nose, but no sore throat [12:52] timotimo: get well soon! [13:05] i wonder if the current flu would outcompete the covid19 in a human body [13:07] I think it will just make it harder for the body to cope [13:08] which may be one of the reasons some of the young early health professionals still died from the virus: massive repeated exposure, rather than a one time limited exposure [13:08] hoping the german perl/raku workshop will be all right [13:08] we will see... it's not like there's going to be 1000 people there... [13:12] was thinking more of "people staying home because sick" [13:12] again, we will see :-) [13:12] aye [13:36] *** sena_kun joined [13:38] *** Altai-man_ left [14:18] *** lucasb joined [15:09] ref [15:10] moarvm, would it be useful to have a record of the specific compiler used for a commit to the master branch? [15:11] from my experience long ago, i remember inconsistencies in warnings from different versions and y [15:11] "brands" [15:14] ref viruses and masks: a respected doc on tv yesterday said typical face masks aren't very useful in preventing infection, but should absolutely be used by those experiencing symptoms to prevent the spread of the virus. [15:15] ¦ MoarVM: dogbert17++ created pull request #1250: Add support for Thread Sanitizer in Configure.pl [15:15] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/1250 [15:35] *** Altai-man_ joined [15:37] *** sena_kun left [16:21] *** patrickb joined [16:55] *** MasterDuke left [16:57] *** zakharyas joined [17:01] *** Kaeipi left [17:02] *** Kaeipi joined [17:02] *** zakharyas left [17:04] *** zakharyas joined [17:04] *** leont left [17:09] tbrowder: what do you mean by "specific compiler used for a commit"? How is a compiler involved in committing? [17:13] the code is written and tested with a specific version before being commited [17:15] *** leont joined [17:24] *** leont left [17:29] *** Altai-man_ left [17:32] I can't think of a situation where knowing that would help me. [17:32] It would probably explain why someone missed a warning or compilation issue, but not what to do about it. [17:36] I'd like to get https://github.com/MoarVM/dyncall/pull/9 merged. That's a bump to the latest upstream commit. The only changes to what we currently have are two fixes, one for building on PPC64 and one for our musl build problem (and some changelog entries). Whoever has permissions is invited to merge. [17:41] patrickb: looks like we lost Geth again, but it has been merged now [17:41] lizmat: Thanks! PR to get this into MoarVM is coming soon. [17:44] *** Kaeipi left [17:45] ¦ MoarVM: e5c7cff13e | (Jan-Olof Hendig)++ | Configure.pl [17:45] ¦ MoarVM: Add support for Thread Sanitizer in Configure.pl [17:45] ¦ MoarVM: [17:45] ¦ MoarVM: Thread Sanitizer is a tool used to detect data races at [17:45] ¦ MoarVM: runtime. Enable with --tsan, e.g. [17:45] ¦ MoarVM: [17:45] ¦ MoarVM: perl Configure.pl --debug --tsan --prefix= [17:45] ¦ MoarVM: [17:45] ¦ MoarVM: for more info run [17:45] ¦ MoarVM: [17:45] ¦ MoarVM: perl Configure.pl --help [17:45] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e5c7cff13e [17:45] ¦ MoarVM: 4e1ca4edde | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | Configure.pl [17:45] ¦ MoarVM: Merge pull request #1250 from dogbert17/add-tsan-support [17:45] ¦ MoarVM: [17:45] *** Kaeipi joined [17:45] ¦ MoarVM: Add support for Thread Sanitizer in Configure.pl [17:45] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/4e1ca4edde [17:45] ah... looks like changes to MoarVM/dyncall are not reported here ? [17:47] *** Kaeipi left [17:47] *** Kaeipi joined [17:49] thx lizmat [17:49] yw :-) [17:54] ¦ MoarVM: patrickbkr++ created pull request #1251: Update dyncall to rev 357 [17:54] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/1251 [18:09] *** Kaeipi left [18:13] *** Kaiepi joined [18:14] ¦ MoarVM: d2e8418676 | (Patrick Böker)++ | 3rdparty/dyncall [18:14] ¦ MoarVM: Update dyncall to rev 357 [18:14] ¦ MoarVM: [18:14] ¦ MoarVM: Should fix #1246 [18:14] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/d2e8418676 [18:14] ¦ MoarVM: dc8a0e800c | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | 3rdparty/dyncall [18:14] ¦ MoarVM: Merge pull request #1251 from patrickbkr/dyncall-rev357 [18:14] ¦ MoarVM: [18:14] MOARVM#1246 [closed]: https://github.com/MoarVM/MoarVM/issues/1246 [BLOCKER][build] Alpine/musl rescue plan [18:14] ¦ MoarVM: Update dyncall to rev 357 [18:14] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/dc8a0e800c [18:14] dinner& [18:25] *** zakharyas left [18:28] nine: i mean the compiler used to test the commit's changes before the commit. [18:54] *** zakharyas joined [19:49] *** hankache joined [19:56] tbrowder: ok, but how would that help us? [20:14] well, it might explain why i'm seeing some warnings with my compiler, gcc x.y, when the comitter used ibm x.y, or clang x.y on mac [20:16] i mean i would generally compile with no warnings before comitting to a c repo [20:17] of course i understand some may have a different opinion about that [20:17] and i probably have done it, too [20:23] tbrowder: and what would you do with this knowledge? [20:24] first see if i couldd [20:26] try that compiler to see the results. if there were still warnings, i would consider spending some time to eliminate them and submit a PR. [20:27] Why not cut that short and go straight into trying to eliminate them? I don't see what knowing that some other compiler does or doesn't show those warnings will buy you. [20:28] probably nothing, but i'm trying to be a team player [20:29] and if there were a difference it seems like it should be worth a release note [20:41] *** leont joined [20:41] Well instead of documenting which compilers we use and what warnings they throw, I'd rather like to see us fix those warnings. [20:46] roger! [21:07] Speaking of which... [21:07] ¦ MoarVM: bc06f9630f | (Stefan Seifert)++ | src/core/interp.c [21:07] ¦ MoarVM: Fix variable might be clobbered by ‘longjmp’ or ‘vfork’ warnings in interp.c [21:07] ¦ MoarVM: [21:07] ¦ MoarVM: Moving the affected variables out of the scope of the setjmp instruction avoids [21:07] ¦ MoarVM: potential clobbering. They are only used for nested interpreters anyway, so [21:07] ¦ MoarVM: they may as well live in MVM_interp_run_nested. The important part is that we [21:07] ¦ MoarVM: don't NULL them in MVM_interp_run. [21:07] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/bc06f9630f [21:07] In hindsight, this solution seems rather obvious. [21:08] *** hankache left [21:12] .oO( it's not 2020 for nothing! ) [21:18] ¦ MoarVM: db49de050d | (Stefan Seifert)++ | src/spesh/arg_guard.c [21:18] ¦ MoarVM: Fix compiler warning about variable possibly used uninitialized [21:18] ¦ MoarVM: [21:18] ¦ MoarVM: The compiler just isn't smart enough to notice that we only access first_added [21:18] ¦ MoarVM: when it's actually initialized. When derived_only is true, then by_type[0].type [21:18] ¦ MoarVM: will be NULL, so we won't enter the if (by_type[i].type != NULL) branch, [21:18] ¦ MoarVM: as additionally by_type will only have a single element, so i will be 0. [21:18] ¦ MoarVM: Later on we will initialize first_added instead of comparing to it. [21:18] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/db49de050d [21:19] *** sena_kun joined [21:21] lizmat: it took me till now to get that joke :) [21:21] But it was well worth it! [21:22] it's not many years you can make that one :-) [21:23] bump time ? [21:23] * nine imagines lizmat sitting there since 1997, patiently waiting for the time to make that joke [21:23] in hindsight, you're probably right :-) [21:24] The warning fixes are not worth a bump [21:24] oki [21:24] fwiw, I've been sitting "there" since 1977 :-) [21:36] *** Altai-man_ joined [21:39] *** sena_kun left [23:19] *** zakharyas left [23:29] *** MasterDuke joined [23:37] *** sena_kun joined [23:39] *** Altai-man_ left