| IRC logs at
Set by AlexDaniel on 12 June 2018.
00:12 patrickz joined 00:17 patrickb left, lucasb left 00:49 patrickz left 01:02 sena_kun left 01:15 sena_kun joined 01:19 sena_kun left 01:51 greppable6 left 02:05 greppable6 joined 06:33 robertle left, sena_kun joined 07:01 sena_kun left 08:52 zakharyas joined 08:59 domidumont joined 10:00 domidumont left 10:08 domidumont joined 12:17 zakharyas left 12:37 lucasb joined 14:04 zakharyas joined 14:22 sena_kun joined 14:34 zakharyas left 14:36 zakharyas joined 14:41 sena_kun left 15:22 zakharyas left 15:23 zakharyas joined 16:07 squashable6 left 16:10 squashable6 joined
Kaiepi is this ok to merge now? 16:33
nine? 16:36
16:43 domidumont left 16:54 AlexDani` joined 16:55 zakharyas left 16:56 AlexDaniel left
nine Kaiepi: will have a look later on. Have to teach now 16:57
17:03 domidumont joined
Kaiepi aight, thanks 17:26
17:31 AlexDani` is now known as AlexDaniel, AlexDaniel left, AlexDaniel joined
lizmat And another Rakudo Weekly News hits the Net: 17:49
18:01 sena_kun joined
dogbert17 nine, jnthn: does this SEGV look familiar? 18:46
19:02 sena_kun left 19:19 sena_kun joined 19:54 lizmat_ joined 19:56 xiaomiao joined
nine dogbert17: no, and it's hard to imaginge how this could fail 20:01
20:02 lizmat left, releasable6 left, notable6 left, bisectable6 left, evalable6 left, DrEeevil left
dogbert17 nine: haven't been able to repro it either 20:03
nine too bad 20:04
dogbert17 that's three obscure SEGV's in the last two days 20:05
nine Only makes sense to me if the stats were free()d in the meantime
dogbert17 I hardly dare ask, but can it have anything to do with recent fixes in this area? 20:07
nine Sure. There's one by jnthn++ and a couple by me. 20:12
dogbert17 the annoying thing is that these crashes are annoyingly random and all attempts to repro fails :( 20:16
nine Kaiepi: can you please squash "Improve UNIX socket path error message, e => error" into "Clean up MVM_io_resolve_host_name and make it more portable"? 20:32
MasterDuke dogbert17: have you seen anything odd with t/spec/S03-operators/repeat.t? on random runs i get a bunch of output like `Use of uninitialized value element of type Any in string context.Methods .^name, .perl, .gist, or .say can be used to stringify it to something meaningful. in sub throws-like at /home/dan/Source/perl6/rakudo/lib/Test.pm6 (Test) 20:34
line 605WARNING: unhandled Failure detected in DESTROY. If you meant to ignore it, you can mark it as handled by calling .Bool, .so, .not, or .defined methods. The Failure was:Cannot convert NaN to Int: in block at /home/dan/Source/perl6/rakudo/lib/Test.pm6 (Test) line 614 in sub subtest at /home/dan/Source/perl6/rakudo/lib/Test.pm6 (Test) line
420 in sub throws-like at /home/dan/Source/perl6/rakudo/lib/Test.pm6 (Test) line 606 in block <unit> at t/spec/S03-operators/repeat.t line 27`
i once i had a segv in the middle of a spectest run, but i haven't been able to repro 20:35
Kaiepi nine, done 20:37
dogbert17 MasterDuke: yes, I see the same things if I run that file 20:43
MasterDuke huh 20:45
nine Also annoying: there's a segfault in an Inline::Perl5 test that only appears on a 32 bit runtime. I just managed to reproduce some segfault on 64 bit with MVM_SPESH_NODELAY and MVM_SPESH_BLOCKING, but I ony get a broken backtrace :/ 20:48
20:51 bisectable6 joined, notable6 joined 20:53 releasable6 joined 20:54 evalable6 joined
nine Nevertheless I could actually find out where it crashes by going through the spesh threads's tc: p *tc->instance->threads->>>cur_frame->static_info-> 20:59
MasterDuke anything interesting? 21:00
21:02 sena_kun left
samcv good * 21:02
Geth MoarVM: 0074094c21 | (Ben Davies)++ | src/io/syncsocket.c
Clean up the comment for MVM_io_resolve_host_name
MoarVM: cd64bf94c4 | (Ben Davies)++ | src/io/syncsocket.c
Clean up MVM_io_resolve_host_name and make it more portable

UNIX socket addresses were being handled in a way that would only work properly on Linux. Handle paths in a more portable way, and when the platform used probably doesn't support UNIX sockets, say so.
MoarVM: 34813e1813 | niner++ (committed using GitHub Web editor) | src/io/syncsocket.c
Merge pull request #1214 from Kaiepi/dns

  [IP6NS Grant] Clean up and make MVM_io_resolve_host_name more portable
nine MasterDuke: maybe. It seems to fail in a call to a different function than in the 32 bit fail. 21:05
MasterDuke vrurg: you know git submodules. what are the magic incantation i should make to create a PR updating MoarMV's 3rdparty/libtommath to the upstream recent v1.2 release? 21:08
dogbert17 I can't even run the tests, from a cloned repo, that comes with Inline::Perl5, I get this: 21:14
ype check failed in binding to parameter '$library'; expected IO::Path but got Slip (Empty) 21:15
in sub guess_library_name at /home/dogbert/.rakudobrew/versions/moar-master/install/share/perl6/core/sources/947BDAB9F96E0E5FCCB383124F923A6BF6F8D76B (NativeCall) line 214
nine huh?
dogbert17 I cloned Inline::Perl5 and ran 'perl6 -Ilib t/argv.t' 21:16
nine dogbert17: did you run configure.pl6 first?
MasterDuke: different called function but actually the same failure mode!
samcv MasterDuke, well that is MoarVM/libtommath. so you would want to cd into 3rdparty/libtommath and then `git remote add upstream $libtommath-upstream-url`. `git fetch upstream master`, then `git merge upstream/master` 21:17
then hopefully there are no merge conflicts
21:17 sena_kun joined
nine Oh, and disabling spesh makes the issue disappear on i586, giving further indication that it's indeed the same issue. Which means that I can reproduce it now in my normal dev environment :) 21:18
dogbert17 nine: nope, I was too stupid so I ignored the :(
it works now, which test is failing with a segv (have a 32 bit vm) 21:19
nine t/from.t
dogbert17 cool
ran it a few times without any problems 21:21
nine Of course now the question is: how can spesh cause this issue? 21:22
dogbert17 ha, now it failed when I built the latest version 21:29
it worked without a hitch on 'This is Rakudo version 2019.11-53-g1945b9d27 built on MoarVM version 2019.07.1-322-g8d0b50d3f'
nine Yeah, it's probably my NativeCall fix 21:32
21:34 domidumont left
dogbert17 I'm building the previous rakudo version, c16b5a204fea5b3a3bb74b0ceea1ba1b907e9365, atm to test that 21:34
and on that version the test passes 21:43
nine Well...I'll have another look tomorrow 21:49
MasterDuke samcv: i believe their new version incorporates or makes obe all our changes. i've fetched and then checked out their v1.2.0 and moarvm/nqp/rakudo all build and pass tests 22:18
22:46 lizmat_ is now known as lizmat 22:47 lucasb left
samcv MasterDuke, well then i'd check out our version, do `git merge` like i said above. then do `git diff upstream-version`. then apply that changeset on top of the merge commit 22:51
`git diff > diffs && patch -p1 diffs && git add -u && git commit` 22:52
23:02 sena_kun left
MasterDuke hm. but wouldn't it make more sense to use upstream unmodified? i.e., instead of the steps you mention, just make a clean break so we don't have different commit ids from upstream? 23:05
23:16 sena_kun joined