Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-12-20

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

All times shown according to UTC.

Time Nick Message
00:16 pyrimidine joined #moarvm
00:39 pyrimidine joined #moarvm
00:51 lizmat joined #moarvm
01:14 pyrimidine joined #moarvm
01:26 pyrimidine joined #moarvm
01:39 pyrimidine joined #moarvm
01:55 pyrimidine joined #moarvm
02:22 pyrimidine joined #moarvm
02:32 pyrimidine joined #moarvm
02:37 colomon 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:57 pyrimidine joined #moarvm
03:37 colomon joined #moarvm
07:01 geekosaur joined #moarvm
07:16 pyrimidine joined #moarvm
07:26 pyrimidine joined #moarvm
07:48 domidumont joined #moarvm
07:53 domidumont joined #moarvm
08:16 pyrimidi_ joined #moarvm
08:25 zakharyas joined #moarvm
10:20 domidumont joined #moarvm
11:27 geekosaur joined #moarvm
11:38 pyrimidine joined #moarvm
11:56 pyrimidine joined #moarvm
12:06 pyrimidine joined #moarvm
12:08 domidumont joined #moarvm
12:14 dogbert17_ jnthn: regarding the discussion yesterday about "Must not GC when in the specializer/JIT": the MoarVM issue no is #458
12:18 domidumont joined #moarvm
12:24 dogbert17_ question: in Exception.pm there's a sub print_exception which seems to be the one printing out the rather sad ==SORRY!== messages when something goes horribly wrong. Is there a function in MoarVM which is called just before that, i.e. I wan't to break the program in gdb just before this happens if possible?
12:24 pyrimidine joined #moarvm
12:34 pyrimidine joined #moarvm
12:43 pyrimidine joined #moarvm
12:45 jnthn dogbert17_: print_exception is invoked from somewhere in NQP, which in turn is just a normal exception handler, iirc
12:48 dogbert17_ jnthn, thx I guess it's not possible to set gdb breakpoints in NQP code ...
12:50 dogbert17_ was trying to take a look at [Coke]'s problems with htmlify
12:52 pyrimidine joined #moarvm
13:02 pyrimidine joined #moarvm
13:09 jnthn OK, I've Perl 6 / MoarVM tuits :)
13:10 * lizmat hopes for some love for the HARNESS_TYPE=6 issue
13:10 jnthn Grr, I should probably have closed some of the MoarVM issues last week when I solved them
13:12 dogbert17_ jnthn, I believe you solved the syntax.t and many-threads ones
13:12 jnthn Pretty sure https://github.com/MoarVM/MoarVM/issues/449 and https://github.com/MoarVM/MoarVM/issues/450 and https://github.com/MoarVM/MoarVM/issues/452 I fixed
13:12 dogbert17_ yup
13:12 jnthn I thought S32-io/socket-recv-vs-read.t too
13:13 dogbert17_ you wrote that you still had some problem with an ultra small nursery and 450
13:13 jnthn If you're time and fancy verifying/closing those...
13:13 jnthn Ah, right
13:13 jnthn Oh, and hyper.t was a newly reported one since We
13:13 jnthn *Wed
13:13 dogbert17_ wrt 450, when I run it, it does no longer panic but one test fails with truncated data
13:13 dogbert17_ hyper is new
13:14 jnthn Yeah, I think 450 still has that tiny nursery explosion issue though
13:14 dogbert17_ 450, again the test fail is ofc with a small nursery
13:14 jnthn Yes, I wasn't able to be sure whether it was a timing issue
13:15 jnthn Or memory issue
13:15 jnthn (for the lost data)
13:15 jnthn Though it shouldn't really happen either way
13:15 dogbert17_ agreed, where will you start?
13:15 jnthn Think with hyper.t
13:15 jnthn As it looks the most easily huntable
13:16 dogbert17_ here's hoping :)
13:16 jnthn Especially since I'm pretty sure there's just one thread involved
13:17 dogbert17_ sounds good, didn't you want to work on race and hyper anyways
13:18 jnthn True :)
13:18 * jnthn has so many things he wants to work on... :)
13:20 dogbert17_ holler if there's anything I can do except apat from closing the two fixed issues
13:20 nwc10 hopefully including lunch
13:20 * dogbert17_ my spelling totally sucks today :(
13:20 pyrimidine joined #moarvm
13:21 jnthn Already did lunch :)
13:21 nwc10 jnthn++
13:21 jnthn My lunchtime reminder service is back home, so reliable lunches are back for the foreseeable future :)
13:22 nwc10 \o/
13:22 dogbert17_ how about coffee then?
13:23 jnthn Did that this morning. Already on to tea.
13:23 jnthn A slice of stollen in an hour or so would be nice, though...
13:25 nwc10 you have that sorted, or you're just popping out to Germany to get some?
13:28 jnthn No, already have some :)
13:28 jnthn There was a kilo of it
13:29 jnthn But its disappearing fast
13:29 * jnthn fails to reproduce the hyper.t bug
13:30 pyrimidine joined #moarvm
13:31 jnthn Can try with some nursery size variations
13:32 JimmyZ jnthn: any chance review my pr for moarvm and rakudo?
13:32 jnthn JimmyZ: Ah, thanks for reminder. Will look after this bug hunt :)
13:32 JimmyZ jnthn: thanks
13:36 * [Coke] yawns.
13:36 * lizmat too
13:36 * jnthn three
13:37 jnthn Sleep deprevation all around
13:37 * mst forth
13:37 mst *deprivation
13:37 mst http://trout.me.uk/ocd.png
13:37 mst < El_Che> mst: Megalomanic Spelling Troll
13:37 [Coke] mst: *twitch*
13:37 jnthn .oO( depravation :P )
13:38 lizmat .oO( OCD should be spelled CDO )
13:39 pyrimidine joined #moarvm
13:44 jnthn dogbert17_: Don't suppose you could check the hyper.t one again locally? I'm have zero luck reproducing it...
13:45 dogbert17_ jnthn: will try
13:47 * jnthn has tried a dozen nursery sizes by this point
13:48 dogbert17_ gah
13:54 dogbert17_ grr , it doesn't want to rear its ugly face, suggest we pretend it never happened unless there's something obvious in the report itself :-)
13:54 jnthn No, sadly not
13:55 jnthn It's possible it was covered by another fix
13:57 dogbert17_ maybe there's somthing more reproducible in your list of bugs to fix
13:57 pyrimidine joined #moarvm
13:58 jnthn Yeah, think I'll have to give up on this one for now
13:59 * jnthn reviews JimmyZ++'s pull requests before further hutning
14:09 jnthn JimmyZ: Left some comments. :)
14:10 pyrimidine joined #moarvm
14:10 jnthn And merged the Rakudo one, which is ifne
14:10 jnthn *fine
14:14 jnthn dogbert17_: Better news: reproduced https://rt.perl.org/Ticket/Display.html?id=130294 :)
14:16 pyrimidine joined #moarvm
14:16 nwc10 this is sort of
14:16 nwc10 bad news: it's not fixed
14:16 nwc10 good news: we know that it's not fixed
14:20 dogbert17_ yay :-)
14:22 dogbert17_ hope it's a simple one
14:24 jnthn Confusing one so far
14:24 jnthn Though maybe wonky debug symbols
14:24 pyrimidine joined #moarvm
14:25 * jnthn is now compiling with optimization off
14:26 jnthn Aha. Goes away under MVM_SPESH_INLINE_DISABLE
14:27 * dogbert17_ is trying to reproduce #458 with mixed results, I can't get the "spesh/GC" error message but I can get it to SEGV every 10-15 times
14:56 JimmyZ jnthn: re: I'd much rather use MVMROOT instead.   because it will be a big MVMROOT since line 114 may triger a gc and line 103 may return
14:57 JimmyZ jnthn: cause more two push
15:00 jnthn JimmyZ: I think I'd prefer the code clarity
15:08 dalek MoarVM/missing_mvmroot: 9d2a4e5 | (Jimmy Zhuo)++ | src/6model/6model.c:
15:08 dalek MoarVM/missing_mvmroot: change MVM_gc_root_temp_push to MVMROOT
15:08 dalek MoarVM/missing_mvmroot: review: https://github.com/MoarVM/MoarVM/commit/9d2a4e5729
15:08 dalek MoarVM/missing_mvmroot: 7b89473 | (Jimmy Zhuo)++ | src/core/frame.c:
15:08 dalek MoarVM/missing_mvmroot: add a missing MVMROOT
15:08 dalek MoarVM/missing_mvmroot: review: https://github.com/MoarVM/MoarVM/commit/7b89473a96
15:09 colomon joined #moarvm
15:11 JimmyZ jnthn: should I change all temp_push to MVMROOT? though this will cause a bit more push times
15:12 dalek MoarVM: 0e4652c | jnthn++ | src/core/interp.c:
15:12 dalek MoarVM: Check lexical access in GC debug mode 2 also.
15:12 dalek MoarVM:
15:12 dalek MoarVM: Might catch a few more things. Sadly, not the bug I'm currently on
15:12 dalek MoarVM: the hunt for.
15:12 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/0e4652ce58
15:12 jnthn JimmyZ: I don't think we need to change existing code
15:13 jnthn JimmyZ: Just would prefer MVMROOT going forward
15:13 JimmyZ jnthn: I meant in my PR
15:13 dogbert17_ jnthn: has https://rt.perl.org/Ticket/Display.html?id=130294 turned out to be a can of worms?
15:14 jnthn JimmyZ: Oh, in your PR, yes, unless there's really good resons not to
15:14 JimmyZ I remember MVMROOT cause a problem to see the real line no when debug, haha
15:15 jnthn JimmyZ: It can, though I think --debug=3 makes it OK again in GCC at least :)
15:15 jnthn dogbert17_: Yes, somewhat
15:15 jnthn dogbert17_: Well, not so much can of worms
15:15 JimmyZ jnthn: ah, don't know about it
15:15 jnthn dogbert17_: At least, not yet. It's just rather hard to work out what's going on.
15:15 jnthn JimmyZ: When you configure MoarVM pass --debug=3
15:16 dogbert17_ perhaps time for some stoller
15:18 JimmyZ jnthn: there is a reason that is it will cause two more temp_push, but don't know whether it is good or not :P
15:18 jnthn If it's just two more I think we can live wiht it ;)
15:19 JimmyZ well , since it is in find_method, it may be in hot path
15:20 jnthn Maybe, but isn't this code in the case we missed the cache?
15:20 jnthn If so we're already on the slow path...
15:20 JimmyZ yeah
15:20 jnthn Then spesh bypasses it all also in many cases
15:21 JimmyZ jnthn: BTW, https://github.com/MoarVM/MoarVM/issues/412 #don't know if it is a  gc but or not
15:21 JimmyZ *bug
15:22 jnthn Think I've spent time on that one before without success...
15:22 jnthn There was a similar RT a couple of days ago also
15:22 JimmyZ jnthn:yeah, I tried too ,haha
15:32 dalek MoarVM/missing_mvmroot: d7fdb71 | (Jimmy Zhuo)++ | src/6model/6model.c:
15:32 dalek MoarVM/missing_mvmroot: change MVM_gc_root_temp_push to MVMROOT
15:32 dalek MoarVM/missing_mvmroot: review: https://github.com/MoarVM/MoarVM/commit/d7fdb71b70
15:35 dalek MoarVM/missing_mvmroot: c0a7588 | (Jimmy Zhuo)++ | src/6model/6model.c:
15:35 dalek MoarVM/missing_mvmroot: change MVM_gc_root_temp_push to MVMROOT
15:35 dalek MoarVM/missing_mvmroot: review: https://github.com/MoarVM/MoarVM/commit/c0a7588647
15:35 JimmyZ jnthn: updated my PR
15:38 jnthn ooh, valgrind barfage
15:38 jnthn (On the SEGV I'm hunting)
15:39 moritz valgrind says "your memory is more corrupt than my president, I won't debug this for you"?
15:39 jnthn Funnily enough, things do actually go wrong enough to corrupt valgrind's own state, yes. :P
15:39 jnthn .oO( Who is president of valgrind? :P )
15:40 dalek MoarVM/missing_mvmroot: 9cfedef | (Jimmy Zhuo)++ | src/6model/6model.c:
15:40 dalek MoarVM/missing_mvmroot: fixed wrong MVMROOT
15:40 dalek MoarVM/missing_mvmroot: review: https://github.com/MoarVM/MoarVM/commit/9cfedef847
15:53 jnthn Think I found the darn thing
15:53 jnthn Wasn't anything to do with spesh or GC at all
15:53 timotimo oh?
15:54 timotimo i wish there was some way to automatically expand only MVMROOT macros
15:54 timotimo before building
15:54 timotimo because it confuses the heck out of multiple debugging/analysis tools i've tried
15:55 dalek MoarVM: 4722cfc | jnthn++ | src/spesh/optimize.c:
15:55 dalek MoarVM: Add a #define to turn on inline logging.
15:55 dalek MoarVM:
15:55 dalek MoarVM: Quicker that commenting/uncommenting it.
15:55 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/4722cfc038
15:59 dogbert17_ interesting
16:02 jnthn Here it comes...
16:02 dalek MoarVM: 65acd55 | jnthn++ | src/core/callstack.c:
16:02 dalek MoarVM: Fix callstack reset.
16:02 dalek MoarVM:
16:02 dalek MoarVM: In cases where we have recursed heavily, we may end up needing to
16:02 dalek MoarVM: flush the entire stack onto the heap. In that case, we need to set
16:02 dalek MoarVM: *all* regions to have their ->alloc pointers back to the start of
16:02 dalek MoarVM: the region. Otherwise, it can create a situation where we flip into
16:02 dalek MoarVM: that region again in the future, and assume that we're at the start
16:02 dalek MoarVM: of it - only to end up with memory off the end of it. The resulting
16:02 dalek MoarVM: corruption can be highly confusing, looking very much like a GC bug
16:02 dalek MoarVM: or an inlining bug (since inlining changes the number of stack frames
16:02 dalek MoarVM: allocated, thus hiding the bug).
16:02 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/65acd55574
16:05 jnthn Will stick a test in for it shortly. bbi10
16:07 dogbert17_ jnthn++
16:10 timotimo ah!
16:10 timotimo so that's how that happens!
16:13 jnthn abh, bit longer than 10 mins...another errand to do
16:20 japhb jnthn: If it's a Perl 6 day too (as opposed to pure MoarVM work), any chance of oo-monitors making it in this week?
16:20 * japhb feels like he's nagging, which is not a fun feeling ...  :-(
17:35 jnthn japhb: Actually, tomorrow is the Perl 6 day. Just that I ran out of loose ends to tie up in $other-project, and since I'm taking vacation from Thursday there's no point starting anything new, so I decided to hunt a bug or two here instead. :)
17:48 japhb jnthn: A worthy choice.  :-)
17:48 jnthn Darn, the SEGV is good at hiding itself
17:48 timotimo sneaky thief
17:48 JimmyZ jnthn: I think I can merge my PR now, just wait for your opinion
17:49 jnthn The most I put `use Test` in the test case I wrote the cover the thing I fixed an hour or so ago, it won't SEGV
17:49 jnthn Which means the test isn't so valuable :S
17:50 * JimmyZ thinks fixing segv in the VM is the hardest work
17:51 jnthn ah, if I jack up the recursion count then it blows reliably even with use Test :)
17:51 jnthn JimmyZ: That's largely because there aren't many easy ones left :)
17:52 nwc10 \o/
17:52 timotimo seems like that's your only recurse.
17:52 jnthn *groan*
18:01 domidumont joined #moarvm
18:13 dogbert17 jnthn: have now closed 449 and 452
18:18 jnthn \o/
18:19 jnthn And I've just resolved RT #130294
18:19 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=130294
18:20 dogbert17 jnthn++, from your comment I gather this is not blog material :-)
18:23 jnthn If anything it's a lesson in biases. Having fixed GC and inlining-triggered things recently, when this one was sensitive to both it was easy to chase it with the expectation it would be one of the two.
18:24 jnthn In the end it was something far more boring.
18:25 jnthn JimmyZ: Taking another look at your PR now
18:28 dalek MoarVM: ee6b817 | (Jimmy Zhuo)++ | src/ (2 files):
18:28 dalek MoarVM: add more missing mvmroot
18:28 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/ee6b81707e
18:28 dalek MoarVM: 97d288c | (Jimmy Zhuo)++ | src/core/args.c:
18:28 dalek MoarVM: fixed arg_flags allocation
18:28 jnthn JimmyZ: Thanks, it was incredibly easier to be comfortable it was correct when done that way :)
18:29 dalek joined #moarvm
18:31 jnthn JimmyZ: Shall I clean up the branch?
18:34 FROGGS joined #moarvm
18:43 travis-ci joined #moarvm
18:43 travis-ci MoarVM build failed. Jonathan Worthington 'Add a #define to turn on inline logging.
18:43 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/185499926 https://github.com/MoarVM/MoarVM/compare/0e4652ce589f...4722cfc03847
18:43 travis-ci left #moarvm
18:55 JimmyZ jnthn: yes please
18:57 jnthn Done
18:59 JimmyZ thanks
19:17 nine jnthn: I'm not sure you still have a right to groan at bad puns ;)
19:18 japhb He earns the right to groan by dishing out so many groaners.  :-)
19:24 JimmyZ ah ,find another wrong MVMROOT from my commit
19:42 JimmyZ jnthn: I found that MVM_gc_allocate_frame() may triger a GC but allocate_frame() not , so no need MVMROOT around allocate_frame()?
19:43 JimmyZ jnthn: and when use the triger the GC one?
19:51 JimmyZ found it about heap vs callstack
19:52 dalek MoarVM/needless_mvmroot: 86dc577 | (Jimmy Zhuo)++ | src/core/frame.c:
19:52 dalek MoarVM/needless_mvmroot: remove unused MVMROOT
19:52 dalek MoarVM/needless_mvmroot: review: https://github.com/MoarVM/MoarVM/commit/86dc577f46
20:34 zakharyas joined #moarvm
20:41 notviki Do we use a "generational GC"?
20:42 japhb notviki: yes.
20:42 notviki cool
20:43 * notviki is reading https://medium.com/@octskyward/modern-garbage-collection-911ef4f8bd8e
20:51 japhb notviki: I believe jnthn used http://gchandbook.org/ as a reference.
20:52 japhb (I can confirm it's really quite good, as was it's predecessor https://www.cs.kent.ac.uk/people/staff/rej/gcbook/ )
21:00 pyrimidine joined #moarvm
21:07 jnthn Oh, I was gonna post that article notviki is reading here
21:07 yoleaux2 20:10Z <notviki> jnthn: should stuff like class { method ^name ($) { "elems" } }; be spectested or is it a Rakudo-only detail? Like overriding the metamodel methods like that?
21:07 jnthn (I'm about 75% of the way through it :))
21:09 jnthn Our GC is generational, parallel, and at a stretch you could label it concurrent.
21:09 pyrimidine joined #moarvm
21:09 jnthn (Though I don't tend to include it in the last of those camps as while it's semi-true, it's semier-false :))
21:11 japhb .oO( Simian-false )
21:12 jnthn :)
21:12 jnthn The claim is that we let threads go their own way during the sweep/finalization phase, so that one thread may be doing that while another is already getting on with work.
21:13 jnthn And "does an amount of GC-related work at the same time as non-GC related work is running" is pretty much what concurrent means in a GC context
21:13 jnthn But most people understand it to mean doing a bit more than the amount we do in that way ;)
21:15 jnthn .tell notviki I believe method ^name() {} is in S12 as being a way to override a MOP method; STD parsed it also. So that's standard. What is less standardized is the exact set of methods on the MOP, though a number of them appear in the spectest and so we are committed on that part of the API.
21:15 yoleaux2 jnthn: I'll pass your message to notviki.
21:19 jnthn .tell lizmat Can you show me some code on the floor thing? :)
21:19 yoleaux2 jnthn: I'll pass your message to lizmat.
21:19 jnthn oh, mis-channel, but I think yoleaux2 is everywhere :)
21:20 japhb Why do we run our own yoleaux?
21:23 * jnthn has no idea :)
21:24 stmuk joined #moarvm
21:26 pyrimidine joined #moarvm
21:37 pyrimidine joined #moarvm
21:55 pyrimidine joined #moarvm
22:04 pyrimidine joined #moarvm
22:18 notviki japhb: what do you mean our own?
22:18 yoleaux2 21:14Z <jnthn> notviki: I believe method ^name() {} is in S12 as being a way to override a MOP method; STD parsed it also. So that's standard. What is less standardized is the exact set of methods on the MOP, though a number of them appear in the spectest and so we are committed on that part of the API.
22:18 notviki yoleaux2: is not in #perl6
22:19 japhb notviki: Why is there a second yoleaux?
22:20 notviki japhb: because we can't find who owns yoleaux to make it join #perl6-dev and #moar
22:20 japhb :-P
22:20 japhb Fair enough.
22:22 pyrimidine joined #moarvm
22:41 pyrimidine joined #moarvm
22:43 colomon_ joined #moarvm
22:50 pyrimidine joined #moarvm
22:55 colomon joined #moarvm
23:24 colomon joined #moarvm
23:26 colomon joined #moarvm
23:28 pyrimidine joined #moarvm
23:37 pyrimidine joined #moarvm
23:45 colomon joined #moarvm
23:55 pyrimidine joined #moarvm

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