MasterDuke think it might be fixed by nine's attempt to get precomp to happen in a single process? 01:38
02:51 agentzh joined 08:34 agentzh joined 08:36 brrt joined
IOninja Hi. How to unbust line coverage branch 11:27
timotimo let me have a look-see
IOninja ?. There's a conflict in ops when I merge master: gist.github.com/zoffixznet/84166c2...7926d20805
I'll really need it this weekend :(
Geth MoarVM/line_based_coverage_pr: 22 commits pushed by (Timo Paulssen)++, (Daniel Green)++, (Zoffix Znet)++
review: github.com/MoarVM/MoarVM/compare/a...6fd4ded176		 11:31
timotimo forcepushed over the pr branch
IOninja \o/
timotimo++
brrt git push —force or, in other words, git push —f_ck_you :-P 11:55
timotimo: you've skipped my blog post in the weekly… 😟 11:56
timotimo NO! DAMN! 11:59
:(
i even read it ;_;
next monday is already drawing close
maybe i'll do a weekly again, actually
dogbert11 why is valgrind so slooooooow :( 12:19
timotimo miracles don't happen according to *your* schedule :) 12:20
dogbert11 looking into the strange bug from yesterday evening. Did one valgrind run during the night, the program completed and the panicked with the comment "Tried to garbage-collect a locked mutex" 12:25
12:36 agentzh joined
jnthn dogbert11: Was it during final cleanup? 12:45
yoleaux2 03:58Z <lizmat> jnthn: 62bd30b3d7953ea9b did not fix segfaults on HARNESS_TYPE=6 :-(
jnthn That woulda been nice :P
brrt no worries :-) although I won't be able to write another one before monday i think 12:52
timotimo that's fine, next monday i'll link to your post from this week 12:54
just have to ... remember that :S
dogbert11 jnthn: now that you say it I believe that you're right 12:57
jnthn Ah, if it's during full cleanup it's less worrying 12:58
At some point we'll need to change the way we handle locking
In order to get more control over these things 12:59
Though when we do so we'll need to be *really* careful not to introduce new problems.
dogbert11 jnthn: trying with ASAN again (don't have the patience right now to wait for valgrind) 13:15
dogbert11 is convinced there's something fishy going on ... 13:16
13:43 lizmat joined 15:04 zakharyas joined 15:08 Ven joined 15:12 mst joined
timotimo jnthn: wouldn't it be a good idea to move the "started GCing" recording to before the gc waits for others to clear their flags? 15:58
jnthn timotimo: Where are you looking exactly? 16:01
timotimo orchestrate.c enter_from_allocator
jnthn Hmm
timotimo ah
it wants to know if we have a full collection, so that decision would have to move up, too 16:02
jnthn Yeah, and I dunno if that'll work out too well
timotimo though i imagine the API could be changed such that it logs whether it's major or minor at the end rather than at the start
just the profiler_end_gc call i mean, it'd get the parameter instead of begin_gc
jnthn Yeah, that'd be the better way
timotimo i'll make it so
jnthn I don't like the idea of changing gc_full_collect underneath other possibly still-finalizing threads 16:03
timotimo then we'll also measure when there's some kind of delay from coordination
jnthn I'm doubting this happens much in reality
*nod*
timotimo this is exactly the kind of thing that'll bite us in the butt after about 1 year of people using that version, and then everybody will be like WTF, but also the satellite will be like "i'll go visit the sun!"
16:08 brrt joined 16:37 hoelzro joined
Geth MoarVM/vmhealth: 4 commits pushed by (Timo Paulssen)++ 16:38
brrt unfortunately, clang will not let me get away with compile-time splitting of ((uintpr_t)&foo)>>32 16:48
doesn't think it's a constant
17:14 zakharyas joined 17:43 agentzh joined 18:01 lizmat_ joined 19:44 agentzh joined
timotimo it's supposed to be 0, right? 20:15
because uint is 32bit big?
20:33 agentzh joined 22:12 pyrimidine joined 22:50 pyrimidine joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!