Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-03-06

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:16 MasterDuke my branch names keep getting longer and longer
00:16 timotimo don't use the x operator for your branch names :D
00:18 MasterDuke and then i try and distill them down to a title for the commit, that takes longer than the actual coding!
00:19 timotimo yeah, naming things ... ugh
00:22 agentzh joined #moarvm
02:02 MasterDuke .tell samcv it appears using nqp::getstrfromname in Rakudo broke the JVM build: Stage jast       : Error while compiling op getstrfromname (source text: "nqp::getstrfromname(nqp::atpos(names, $i).trim)"), no registered operation handler
02:02 yoleaux2 MasterDuke: I'll pass your message to samcv.
02:03 samcv hey MasterDuke
02:03 yoleaux2 02:02Z <MasterDuke> samcv: it appears using nqp::getstrfromname in Rakudo broke the JVM build: Stage jast       : Error while compiling op getstrfromname (source text: "nqp::getstrfromname(nqp::atpos(names, $i).trim)"), no registered operation handler
02:03 samcv it compiled the last time i checked
02:03 samcv maybe something changed? i know i compiled jvm when i added that in
02:03 samcv which file is it failing the build on MasterDuke ?
02:04 MasterDuke https://gist.github.com/MasterDuke17/a2de125177163d2774d46cecf8e72d11
02:04 MasterDuke at HEAD on nom
02:06 MasterDuke did a `make realclean` and restarting the build
02:07 MasterDuke a `git grep getstrfromname` in Rakudo and NQP don't return any hits in .java files
02:13 samcv yeah cause in has a #?if moar
02:17 MasterDuke src/core/Str.pm:1368: isn't wrapped in `#?if moar`
02:19 MasterDuke commit 5c1761a6486317da6cef52bace348d3d5f350676, Author: Zoffix Znet <cpan@zoffix.com>
02:21 MasterDuke IOninja: https://github.com/rakudo/rakudo/commit/5c1761a6486317da6cef52bace348d3d5f350676 from the JVM build. nqp::getstrfromname isn't implemented for the JMV. for reference, it's wrapped in a `#?if moar` here: src/Perl6/Actions.nqp:9254:
02:21 MasterDuke *broke the JVM build
02:21 MasterDuke oops, that was supposed to be in #perl6-dev
02:27 agentzh joined #moarvm
02:48 ilbot3 joined #moarvm
02:48 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
02:48 samcv ah ok so it wasn't me then :P
06:55 domidumont joined #moarvm
07:11 brrt joined #moarvm
07:20 agentzh joined #moarvm
07:43 brrt good * #moarvm
07:43 yoleaux2 3 Mar 2017 23:07Z <MasterDuke> brrt: fyi, if you're interested in the JIT bug, there's a bunch of discussion here: https://irclog.perlgeek.de/moarvm/2017-03-03#i_14196620
07:44 samcv hey brrt
07:46 ggoebel joined #moarvm
07:47 brrt hey samcv, MasterDuke
07:47 samcv :)
07:48 samcv happy brrthday
07:48 brrt i'll take a look at it, but i think the problem is that the semantics of div had been changed
07:48 brrt thank you
07:48 brrt (how did you…?)
07:48 samcv it's not your birthday is it?
07:48 samcv i just thought it was clever wordplay
09:07 domidumont joined #moarvm
09:14 sivoais joined #moarvm
09:14 domidumont joined #moarvm
10:02 brrt well, it was my birthday just two days ago
10:02 brrt so it was recent enough that i let it ocunt
10:02 jnthn Happy belated birthday :)
10:02 brrt thanks :-)
10:02 jnthn morning #moarvm o/
10:02 brrt i'll try to take a look at the JIT div bug then..
10:03 brrt but i suppose this resolves to native int div, doesn't it?
10:09 jnthn brrt: So far as I've followed
10:10 timotimo habby birrthday, belatedly!
10:11 timotimo is that jit div bug the one where a patch to infix:<div> makes things randomly fail unless you turn off jit?
10:12 brrt well, not randomly
10:12 brrt i have a test case :-)
10:12 timotimo oh, ok, that's good, then.
10:20 dogbert17_ happy birthday brrt
10:20 * dogbert17_ suudenly remembers that he promised to write a MoarVM issue, gets to work ...
10:31 dogbert17_ tada https://github.com/MoarVM/MoarVM/issues/547
11:16 brrt joined #moarvm
11:28 brrt (because of the XOR, that is surprisingly complex in assembly language)
11:31 brrt that said, it appears it's 'always' been this way
11:32 brrt at least, before the JIT was there
11:32 brrt so it's a dumb codegen bug
11:47 samcv morning jnthn
11:48 jnthn o/ samcv
12:06 geekosaur joined #moarvm
12:29 domidumont joined #moarvm
12:47 GK__1wm___SU joined #moarvm
13:15 domidumont joined #moarvm
13:57 KDr2 joined #moarvm
14:16 El_Che joined #moarvm
14:16 El_Che https://www.eclipsecon.org/na2016/sites/default/files/slides/OMR%20Modern%20Toolkit%20for%20Building%20Language%20Runtimes.pdf <-- camelia on page 7
14:17 El_Che crossposting from #perl6
15:18 brrt joined #moarvm
16:53 domidumont joined #moarvm
17:37 Ven joined #moarvm
17:38 domidumont joined #moarvm
18:18 FROGGS joined #moarvm
18:38 Ven joined #moarvm
18:48 zakharyas joined #moarvm
19:27 dogbert17 joined #moarvm
19:37 dogbert17 my $waiter = Proc::Async.new("echo", :args<Hello World>).start; await start { await $waiter }
19:38 dogbert17 ^^^ the above piece of code has a tendency to hang, how would one go about debugging this, btw, this is RT #122709
19:38 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=122709
19:40 jnthn What happens if you stick "use v6.d.PREVIEW;" at the start of it?
19:40 dogbert17 will try
19:42 dogbert17 seems to work a lot better at first glance
19:43 dogbert17 200 runs with no problem using 'use v6.d.PREVIEW;'
19:43 jnthn Nice, figured that'd sort it out
19:44 jnthn The reason it ends up in bother at the moment is due to a scheduler bug of some sort
19:44 jnthn It doesn't start enough threads
19:44 dogbert17 mysterious
19:44 nwc10 jnthn: new! never seen before! http://paste.scsys.co.uk/557403
19:45 jnthn Our scheduler is...uh...not very smart.
19:45 nwc10 I've not even seen the error message "runtime error: member access within null pointer of type 'struct MVMSTable'" before
19:45 jnthn o.O
19:45 jnthn Wow
19:46 dogbert17 but oftentimes it does start enough threads
19:46 jnthn Too bad it doesn't have more info....
19:46 timotimo that might just be diagnostics that asan didn't know how to output before?
19:46 jnthn dogbert17: Yeah, it almost always does, I forget what was special about this case
19:47 nwc10 it's still gcc 4.9 from May 2014
19:48 El_Che left #moarvm
19:49 dogbert17 hmmgdb doesn't want to play ball either
19:54 * [Coke] wondered for a second if hmmgdb was a special build. :)
19:54 dogbert17 jnthn, FWIW strace write stuff like this when the program hangs 'futex(0xa9ab618, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable)'
19:54 dogbert17 :)
19:57 jnthn Yeah, I think I hunted that one down far enough that I realized I'd leave it until I got to giving the scheduler a larger overhaul
19:58 jnthn It just doesn't shart enough threads
19:58 jnthn *start
19:58 jnthn o.O
19:58 jnthn And there's no monitoring thing to detect lack of progress and make adjustments
20:00 dogbert17 thx for the explanation, I'll look for something more interesting then and leave the bug to the overhaul
20:01 dogbert17 btw, any ideas how to get further with the harness6 problems?
20:02 jnthn Not really, though it appears we have 3 distinct problems at this point
20:02 dogbert17 my own attempts have failed miserably :)
20:03 jnthn One in spesh that nwc10 just caught in ASAN, one involving an over-shared deocder or something that appears to be that at least (this one is likely the most tractable to solve), and then the one that shows up when we GC a corrupt P6bigint
20:04 dogbert17 I believe that you mentioned code that would stress the decoder paths. What would such code look like?
20:05 dogbert17 or might there be a specific spectest file which inadvertently stresses it
20:05 jnthn Just doing a load of Proc::Async processes concurrently in a loop should do it
20:05 jnthn Like spawn 10 procs taht will produce a bunch of output, tap them in character mode (the default), let them all exit, repeat.
20:06 dogbert17 interesting
20:07 jnthn That's basically what harness6 is doing at the end of the day ;)
20:07 jnthn Spawning 10 test files
20:07 jnthn And reading their outputs
20:08 jnthn Where 10 is actually TEST_JOBS
20:08 jnthn Which is 8 for me
20:08 dogbert17 ok, I'll see what I can do ...
20:08 jnthn Cool, thanks
20:09 Ven joined #moarvm
20:12 dogbert17 jnthn: do you mean code like this, but with more procs? https://gist.github.com/dogbert17/037f464c4da80a286f9e0895fae63ed9
20:16 jnthn Yeah :)
20:17 jnthn walk; bbiab
20:24 vendethiel joined #moarvm
21:17 Ven joined #moarvm
21:25 Ven joined #moarvm
21:27 dogbert17 jnthn, it works
21:29 jnthn Works as it reproduces the bug? :)
21:29 jnthn Or works as in doesn't reproduce the bug?
21:30 dogbert17 yes, after a while :) reproed
21:30 jnthn hah, nice!
21:30 timotimo jnthn: did you have an opinion on whether isbig_I should be used to check for specific bounds?
21:31 dogbert17 do you see anything here https://gist.github.com/dogbert17/433e0f6c901d47faccaa877c88729402
21:34 jnthn No; what's the 0xb7fdccb0 that all the rest are in? Presumably shifting concblockingqueue?
21:35 dogbert17 I can't 'bt' those
21:35 jnthn odd
21:36 dogbert17 well, at least I have some crappy code if anyone else want to give it a go :)
21:37 dogbert17 this is what I get:
21:37 dogbert17 (gdb) t 2
21:37 dogbert17 [Switching to thread 2 (Thread 0xb59a2b40 (LWP 12881))]
21:37 timotimo we might be able to figure out where those code segments are from /proc/self/maps or something?
21:37 dogbert17 #0  0xb7fdccb0 in ?? ()
21:37 dogbert17 (gdb) bt
21:37 dogbert17 Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x2903:
21:40 jnthn What if you type frame 1, frame 2, etc?
21:41 dogbert17 will try
21:42 jnthn Something very odd is going on, anyway
21:42 dogbert17 indeed, could be something with my installation which makes gdb miserable
21:43 jnthn Anyway, I'll certainly have a crack at reproducing this locally with your repro code :)
21:43 jnthn Tomorrow or Wednesday :)
21:44 dogbert17 coool
21:44 dogbert17 I'll update my gist
21:44 dogbert17 will give ASAN a go, perhaps things are horribly corrupted
21:55 Ven joined #moarvm
23:02 ggoebel joined #moarvm

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary