github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
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, coverable6 left, unicodable6 left, sourceable6 left, statisfiable6 left, greppable6 left, reportable6 left, linkable6 left, notable6 left, bisectable6 left, evalable6 left, releasable6 left, shareable6 left, quotable6 left, committable6 left, nativecallable6 left, benchable6 left, squashable6 left, tellable6 left 04:38 coverable6 joined, statisfiable6 joined, committable6 joined, bisectable6 joined 04:39 linkable6 joined, bloatable6 joined, evalable6 joined, tellable6 joined, shareable6 joined, sourceable6 joined, nativecallable6 joined, greppable6 joined 04:40 notable6 joined, reportable6 joined, quotable6 joined, unicodable6 joined, releasable6 joined, squashable6 joined, benchable6 joined 05:36 sena_kun joined 05:37 Altai-man_ left 05:58 Kaiepi left, Kaeipi joined
nine timotimo: in my experience one isn't getting the flu symptoms. They're suddenly there. 07:04
07:35 Altai-man_ joined, Voldenet left 07:36 Voldenet joined, Voldenet left, 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, Altai-man_ joined 11:37 sena_kun left
timotimo yesterday it was just sore throat, now i'm also sneezing / have a runny nose 12:27
12:41 leont joined
lizmat oh noes :-) the floe! 12:45
lizmat also has a runny nose, but no sore throat
moritz timotimo: get well soon! 12:52
timotimo i wonder if the current flu would outcompete the covid19 in a human body 13:05
lizmat I think it will just make it harder for the body to cope 13:07
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
timotimo hoping the german perl/raku workshop will be all right
lizmat we will see... it's not like there's going to be 1000 people there...
timotimo was thinking more of "people staying home because sick" 13:12
lizmat again, we will see :-)
timotimo aye
13:36 sena_kun joined 13:38 Altai-man_ left 14:18 lucasb joined
tbrowder ref 15:09
moarvm, would it be useful to have a record of the specific compiler used for a commit to the master branch? 15:10
from my experience long ago, i remember inconsistencies in warnings from different versions and y 15:11
"brands"
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:14
Geth MoarVM: dogbert17++ created pull request #1250:
Add support for Thread Sanitizer in Configure.pl
15:15
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, zakharyas left 17:04 zakharyas joined, leont left
nine tbrowder: what do you mean by "specific compiler used for a commit"? How is a compiler involved in committing? 17:09
Voldenet the code is written and tested with a specific version before being commited 17:13
17:15 leont joined 17:24 leont left 17:29 Altai-man_ left
nine 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.
patrickb I'd like to get 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:36
lizmat patrickb: looks like we lost Geth again, but it has been merged now 17:41
patrickb lizmat: Thanks! PR to get this into MoarVM is coming soon.
17:44 Kaeipi left
Geth MoarVM: e5c7cff13e | (Jan-Olof Hendig)++ | Configure.pl
Add support for Thread Sanitizer in Configure.pl

Thread Sanitizer is a tool used to detect data races at runtime. Enable with --tsan, e.g.
   perl Configure.pl --debug --tsan --prefix=<install dir>
for more info run
   perl Configure.pl --help
17:45
MoarVM: 4e1ca4edde | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | Configure.pl
Merge pull request #1250 from dogbert17/add-tsan-support

Add support for Thread Sanitizer in Configure.pl
17:45 Kaeipi joined
lizmat ah... looks like changes to MoarVM/dyncall are not reported here ?
17:47 Kaeipi left, Kaeipi joined
dogbert17 thx lizmat 17:49
lizmat yw :-)
Geth MoarVM: patrickbkr++ created pull request #1251:
Update dyncall to rev 357
17:54
18:09 Kaeipi left 18:13 Kaiepi joined
Geth MoarVM: d2e8418676 | (Patrick Böker)++ | 3rdparty/dyncall
Update dyncall to rev 357

Should fix #1246
18:14
MoarVM: dc8a0e800c | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | 3rdparty/dyncall
Merge pull request #1251 from patrickbkr/dyncall-rev357

Update dyncall to rev 357
linkable6 MOARVM#1246 [closed]: github.com/MoarVM/MoarVM/issues/1246 [BLOCKER][build] Alpine/musl rescue plan
lizmat dinner&
18:25 zakharyas left
tbrowder nine: i mean the compiler used to test the commit's changes before the commit. 18:28
18:54 zakharyas joined 19:49 hankache joined
nine tbrowder: ok, but how would that help us? 19:56
tbrowder 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:14
i mean i would generally compile with no warnings before comitting to a c repo 20:16
of course i understand some may have a different opinion about that 20:17
and i probably have done it, too
nine tbrowder: and what would you do with this knowledge? 20:23
tbrowder first see if i couldd 20:24
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:26
nine 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:27
tbrowder probably nothing, but i'm trying to be a team player 20:28
and if there were a difference it seems like it should be worth a release note 20:29
20:41 leont joined
nine Well instead of documenting which compilers we use and what warnings they throw, I'd rather like to see us fix those warnings. 20:41
tbrowder roger! 20:46
nine Speaking of which... 21:07
Geth MoarVM: bc06f9630f | (Stefan Seifert)++ | src/core/interp.c
Fix variable might be clobbered by ‘longjmp’ or ‘vfork’ warnings in interp.c

Moving the affected variables out of the scope of the setjmp instruction avoids potential clobbering. They are only used for nested interpreters anyway, so they may as well live in MVM_interp_run_nested. The important part is that we don't NULL them in MVM_interp_run.
nine In hindsight, this solution seems rather obvious.
21:08 hankache left
lizmat
.oO( it's not 2020 for nothing! )
21:12
Geth MoarVM: db49de050d | (Stefan Seifert)++ | src/spesh/arg_guard.c
Fix compiler warning about variable possibly used uninitialized

The compiler just isn't smart enough to notice that we only access first_added when it's actually initialized. When derived_only is true, then by_type[0].type will be NULL, so we won't enter the if (by_type[i].type != NULL) branch, as additionally by_type will only have a single element, so i will be 0. Later on we will initialize first_added instead of comparing to it.
21:18
21:19 sena_kun joined
nine lizmat: it took me till now to get that joke :) 21:21
But it was well worth it!
lizmat it's not many years you can make that one :-) 21:22
bump time ? 21:23
nine imagines lizmat sitting there since 1997, patiently waiting for the time to make that joke
lizmat in hindsight, you're probably right :-)
nine The warning fixes are not worth a bump 21:24
lizmat oki
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