00:01 MasterDuke joined 01:57 ilbot3 joined
Geth MoarVM: ef4e6fe945 | (Samantha McVey)++ | Configure.pl
Tell user to delete folder if submodule dir already exists

Should help with issue #839 The message shows at the very bottom of the ./Configure.pl run for best visibility. Tested with rakudobrew:
ERROR: Cannot update submodule because directory exists and is not empty.
  >>> Please delete the following folder and try again:
  /home/perl/.rakudobrew/moar-blead-master/nqp/MoarVM/3rdparty/libatomic_ops		 04:05
05:32 AlexDaniel joined 05:40 domidumont joined 05:46 domidumont joined 05:49 brrt joined 06:27 domidumont joined, robertle joined
AlexDaniel any thoughts on github.com/rakudo/rakudo/issues/1711 ? 07:07
what could be causing it? Or what can we request to move forward? 07:08
nwc10 Are all the failing architectures big endian? 07:09
AlexDaniel yes
nwc10 (At a guess, the "intermittent" is because spesh doesn't always kick in
OK. "yes" is useful. Bytecode is little endian. There's a bunch of hacks to fix it up 07:10
(at the same time as validating it)
AlexDaniel so I'm thinking, can we just declare spesh broken at the moment on these archs and recommend to build without it?
nwc10 this implies that there's a second fix needed rather like the one timotimo and jnthn found at the GPW
that would be a work around 07:11
nine AlexDaniel: can you test with MVM_SPESH_BLOCKING=1 MVM_SPESH_NODELAY=1
nwc10 that's the one. thanks
was about to say, I can't remember the variables
if you can get a test case repeatedly failing by running with those two variables
that's useful info
AlexDaniel robertle: ping 07:12
nwc10 aha, you are not the reporter :-)
clearly the empty coffee cup near me is an illusion
(or it hasn't kicked in yet)
AlexDaniel nwc10: by the way, the fix was found 1 month before GPW :) 07:13
not sure what was going on there!
nwc10 ah OK.
So, why did it end up with both of them staring at a terminal and (re) figuring it out 07:14
robertle AlexDaniel: o/
nwc10 (not meant as a silly question - how come the fix didn't get committed earlier)
AlexDaniel I don't know… timo committed a fix into a branch, we asked debian maints to test it, they confirmed it resolved the problem
nwc10 ah OK 07:15
AlexDaniel I pinged timo asking to commit it to master, this didn't happen
one month later everyone was trying to fix it again :D
nwc10 oops.
that's LTA 07:16
saboteurs? eg dilbert.com/strip/2003-06-19
AlexDaniel robertle: so if I get it right, tests should pass reliably with MVM_SPESH_DISABLE=1
robertle right, I wasn't paying attention. so regarding 1711 you are suggesting to run with MVM_SPESH_BLOCKING=1 MVM_SPESH_NODELAY=1? should that make the problem go away, or shed mor light on it?
nwc10 shed more light on it
should fail every time, not intermettently
AlexDaniel yes
robertle ok, and MVM_SPESH_DISABLE=1 might make them go away? does disabling spesh make rakudo practically useless in terms of performance? 07:17
nwc10 I don't know about the "practically useless" but it will hurt performance
AlexDaniel definitely not useless, you can try it on any machine actually
it's pretty ok
robertle ok, will do these tests and update the ticker, thanks for the input!
nwc10 thanks
AlexDaniel robertle: ♥ 07:18
nwc10 should get back to the messy/big/ugly work ticket
timotimo huh, i don't remember having had a working fix for that bug 07:57
robertle timotimo: that's a mixup, there are a couple of vauely similar problems: 1711, 1257, 1663. your fix github.com/MoarVM/MoarVM/commit/c8...2740d73310 seems to sort out 1257... 08:06
timotimo huh, yeah, that looks like it's the same fix
not entirely, though 08:07
the fix we ended up committing put the value validation in between the two validation calls 08:08
shouldn't make a noticable difference.
it looks like i (or AlexDaniel) committed that based on the commit that initially introduced the validation code? 08:10
08:11 brrt joined
AlexDaniel timotimo: well, your commit was on top of HEAD (which didn't work well because we were trying to test some old revision), so I made a branch and committed it on top of the required revision… 08:12
timotimo oh, ok 08:13
AlexDaniel so we had github.com/MoarVM/MoarVM/tree/mayb...big_endian and github.com/MoarVM/MoarVM/tree/mayb...an_oldmoar
I'll delete these branches now
brrt good * 08:17
AlexDaniel o/
08:23 zakharyas joined 08:33 dalek joined, Geth joined, p6lert joined, synopsebot joined 08:34 SourceBaby joined
brrt i am still tracing the CSV segv 08:37
AlexDaniel brrt: sounds promising :) 09:03
09:18 domidumont1 joined
brrt it happens in MVM_frame_vivify_lexical 09:35
timotimo do we have an rr recording? 09:43
09:50 zakharyas joined
brrt no, but it is very repeatable 09:56
10:59 brrt joined 11:32 lizmat joined 11:38 FROGGS joined
brrt ohai. i think i have traced our issue with the spesh of CSV 12:06
sp_getlex_o r19(4), lex(idx=10,outers=0,<out of bounds>)
well, i agree with that, that *is* out of bounds 12:07
12:15 domidumont joined 12:31 zakharyas joined 12:42 Util joined
robertle I just got my mips "bytecode validation error" even with MVM_SPESH_DISABLE=1 :( 12:49
any ideas on what to do next?
lizmat robertle: /me has no idea... and jnthn is having a well-deserved vacation atm so don't expect much from him for the rest of the week, I believe 12:50
AlexDaniel timotimo: ↑ ? 13:50
14:20 FROGGS_ joined 14:48 FROGGS|m joined 15:17 brrt joined
brrt . 15:17
so the question is, during inlining we end up with a lexical reference that is out of bounds for the actual frame, even though we are not using OSR
so i'm confused
oh, it should have 21 lexicals 15:18
hmm, nm that
15:18 domidumont1 joined 16:18 FROGGS joined 17:02 robertle joined 17:37 geekosaur joined
FROGGS halp 18:27
==11083== Invalid read of size 1
==11083== at 0x5062EEC: gc_mark (P6opaque.c:112)
==11083== Address 0xd6967a0000c is not stack'd, malloc'd or (recently) free'd
how can I get behind this one?
I'm calling into a C++ library here 18:28
18:28 domidumont joined
FROGGS at least it is reproducable... 18:34
in that code repr_data->gc_obj_mark_offsets_count is 17
and it crashes when i is 15 18:35
lizmat nine timotimo ^^^
FROGGS uhh, nice 18:44
the stable_debug_name states it is about a Method+{Callable[b2Body]}+{NativeCall::Native[Method+{Callable[b2Body]},Str]}+{NativeCall::NativeCallMangled[Bool]} 18:45
which is exactly the C++ method I am calling
hmm, no, actually it is not 18:46
the object is the resulting object after the 'is native' trait was applied I think 18:50
19:18 brrt joined
brrt . 19:29
timotimo .
brrt ohai timotimo 19:30
timotimo hi there 19:31
brrt any idea why sp_getlex_o would be trying to clone a null object 19:32
hmm.. 19:37
i'm getting to be supsicious about lazy loading here
20:31 ilmari[m] joined 20:32 evalable6 joined, coverable6 joined 20:33 bisectable6 joined, bloatable6 joined
MasterDuke would blog.llvm.org/2018/03/dragonffi-ffi...using.html have any potential use for MoarVM? 21:34
timotimo tirania.org/blog/archive/2018/Apr-11.html - mono was using 64bit floats for all calculations even if the variables used were 32bit, and they got a rather big performance win for float32-using applications by changing that, it seems like 22:34
Nowadays, Games, 3D applications image processing, VR, AR and machine learning have made floating point operations a more common data type in modern applications. When it rains, it pours, and this is no exception. Floats are no longer your friendly data type that you sprinkle in a few places in your code, here and there. They come in an avalanche and there is no place to hide. There are so many of them, and 22:35
they won’t stop coming at you.
Geth MoarVM: samcv++ created pull request #840:
Move libatomic_ops module to a different directory		 22:44

Powered by Cro and the Raku® Programming Language.

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

Thank you!