github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
nine timotimo: in my experience one isn't getting the flu symptoms. They're suddenly there. 07:04
timotimo yesterday it was just sore throat, now i'm also sneezing / have a runny nose 12:27
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
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
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
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.
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
lizmat ah... looks like changes to MoarVM/dyncall are not reported here ?
dogbert17 thx lizmat 17:49
lizmat yw :-)
Geth MoarVM: patrickbkr++ created pull request #1251:
Update dyncall to rev 357		 17:54
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&
tbrowder nine: i mean the compiler used to test the commit's changes before the commit. 18:28
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
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.
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
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 :-)

Powered by Cro and the Raku® Programming Language.

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

Thank you!