Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-12-14

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

All times shown according to UTC.

Time Nick Message
01:08 Ven joined #moarvm
03:28 pyrimidine joined #moarvm
04:13 leedo_ joined #moarvm
05:21 leego joined #moarvm
05:50 geekosaur joined #moarvm
05:53 pyrimidi_ joined #moarvm
05:58 geekosaur joined #moarvm
06:16 domidumont joined #moarvm
06:36 TimToady joined #moarvm
06:53 geekosaur joined #moarvm
07:09 nwc10 good \o, o/
07:32 domidumont joined #moarvm
07:38 domidumont joined #moarvm
07:40 geekosaur joined #moarvm
08:12 pyrimidine joined #moarvm
08:51 zakharyas joined #moarvm
08:53 pyrimidine joined #moarvm
08:58 brrt joined #moarvm
08:58 brrt \o nwc10
08:58 yoleaux2 13 Dec 2016 19:20Z <nine> brrt: nice advent calendar post! Though I have to admit that I do not yet fully understand the tile syntax. There are many "reg"s and in the explanation I'm not sure to which ones you refer. Also "the expression" is quite ambiguous.
08:58 brrt thanks nine :-)
08:59 brrt .tell nine: I see.... I can elucidate it a bit more if you want.
08:59 yoleaux2 brrt: What kind of a name is "nine:"?!
08:59 brrt .tell nine I see.... I can elucidate it a bit more if you want
08:59 yoleaux2 brrt: I'll pass your message to nine.
09:01 jnthn moarning o/
09:01 yoleaux2 03:08Z <MasterDuke> jnthn: explicitly putting a QAST::Op with a say in the while body prints (what i gave the say) for every line of the input file. but 'say "hi"' in the -ne doesn't ever print (not does .say)
09:01 yoleaux2 04:44Z <MasterDuke> jnthn: and -p doesn't print the file contents
09:14 dalek MoarVM: 8c6d4c5 | jnthn++ | src/gc/debug.h:
09:14 dalek MoarVM: Only do MVM_ASSERT_NOT_FROMSPACE in GC debug mode.
09:14 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/8c6d4c59dc
09:39 pyrimidine joined #moarvm
09:53 jnthn Today's unfortunate "fun": two optimizations interact to screw up the "no GC during spesh" invariant
09:54 jnthn Well, spesh is of course optimizing, that's its job
09:54 jnthn Lazy deserialization is the other one
09:54 jnthn Turns out that in a couple of places spesh looks at method caches or resolves wvals
09:54 jnthn Those can both trigger lazy deserialization
09:54 jnthn That in turn leads to trying to acquire a reentrant mutex
09:55 nwc10 er erk
09:55 nwc10 you have a plan for this now?
09:55 nwc10 "moar coffee"?
09:55 jnthn The reentrant mutex then marks the thread blocked, but finds itself to have been GC interrupted, so goes ahead and GCs
09:56 jnthn Breaking the inaviant
09:56 jnthn *invariant
09:56 jnthn A plan? Well, the obvious one for the method cache is "don't bother if we didn't deserialize the thing"
09:57 jnthn Since in that case we're trying to optimize a codepath that was never taken anyway (we'll fail)
09:57 jnthn The inlining wval issue is far less clear cut
09:58 jnthn Oh...actually, we can just treat it as a reason to rule out inlining
09:59 jnthn So yeah, we can fix the two cases that crop up
09:59 jnthn And I can see if there's any others liable to cause such trouble
09:59 jnthn This doesn't strike me as entirely robust however
09:59 nwc10 is it viable to add enough flags to spot the general problem?
09:59 jnthn Yes
10:00 nwc10 but at that point can it do anything other than panic/abort?
10:00 jnthn Detecting the situation robustly isn't too difficult.
10:00 nwc10 (which at least gives a bug report)
10:00 jnthn But....right, that's all we can do if we detect it.
10:02 jnthn But given if we're in that position we'll currently likely end up reaching SEGV or other corruption, it's probably an improvement.
10:03 pyrimidine joined #moarvm
10:04 jnthn MVM_6model_get_how is a third such vulnerable path
10:17 pyrimidine joined #moarvm
10:29 Ven joined #moarvm
10:47 nine ~~
10:47 yoleaux2 08:59Z <brrt> nine: I see.... I can elucidate it a bit more if you want
10:47 nine brrt: yes, that would be nice :)
11:05 brrt okay, here goes
11:08 brrt so the actual 'tile' that is matched against the tree is (xor reg (load (index reg reg $stride) $size))
11:08 brrt the symbolic return value of that tile is a 'reg'
11:08 brrt which means that this tile can be selected to stand in for a tree wherever an 'upper' tile needs a 'reg'
11:10 brrt so for instance: if you'd have (add (const 4 4) (xor (load ...) (load ..))); then the tiler could select the: (add reg reg) tile by replacing (const 4 4) with the a 'reg' segment, and the first (load ...) with something that yields a reg; and then the (xor ... (load ..)) with our template
11:10 brrt does that make sense
11:10 brrt it's a excessively complex sentence, so it might not :-)
11:10 brrt the point is that these 'reg' thingies are /symbols/ that allow the tiler to connect and select the correct tiles
11:11 brrt they are also overloaded as /values/ by the register allocator, in that the register allocator tries to a allocate a register for every 'reg' thing that is alive
11:12 brrt so three things come into play here:
11:12 brrt - the tiler uses them as symbols, the same way it could use 'flag' or 'void' as a symbol
11:13 brrt - the tile template generator uses them to distinguish 'valuelike' tree nodes from 'constant' tree nodes, and generates a 'path', which is a string of indexes into the tree
11:14 brrt - the register allocator uses the generated path (along with a bitmap) to find out how the tiles' values are used; they are the 'virtual registers' in the 'three-address-code' that is the tile list
11:15 brrt and finally, the register allocator assigns real registers to these virtual registers
11:16 brrt so that the tile implementation (the little C + asm code bit) can use them to generate the correct machine code
11:19 brrt (i apologise for terrorizing you with detail)
11:27 dalek MoarVM: 85cac62 | jnthn++ | src/gc/finalize.c:
11:27 dalek MoarVM: Add an fromspace assertion in finalize.
11:27 dalek MoarVM:
11:27 dalek MoarVM: To try and detect a maybe-bug in there.
11:27 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/85cac62642
11:27 dalek MoarVM: 1c06af2 | jnthn++ | / (5 files):
11:27 dalek MoarVM: Avoid a number of spesh GC invariant violations.
11:27 dalek MoarVM:
11:27 dalek MoarVM: In some cases, we could end up triggering lazy deserialization during
11:27 dalek MoarVM: spesh. This is undesirable, and can break the "no GC during spesh"
11:27 dalek MoarVM: invariant by acquiring a reentrant mutex, which along the way will
11:27 dalek MoarVM: block for GC and so may also enter the GC. (It also means we're
11:29 dalek MoarVM: 5214212 | jnthn++ | src/ (3 files):
11:29 dalek MoarVM: Panic if we try to GC when speshing/JITing.
11:29 dalek MoarVM:
11:29 dalek MoarVM: Enabled by MVM_GC_DEBUG being non-zero.
11:29 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/5214212dc1
11:31 nine brrt: hey I asked for the details :)
11:33 dogbert17 jnthn: although I'm hiding at $work, let me know if I can help somewhat by running spectests in the background
11:35 pyrimidine joined #moarvm
11:46 dalek MoarVM: 5a96721 | jnthn++ | src/6model/sc.c:
11:46 dalek MoarVM: Ensure we don't leak partially deserialized objs.
11:46 dalek MoarVM:
11:46 dalek MoarVM: This (perhaps a tad over-zealous) check makes sure that, in the case
11:46 dalek MoarVM: we are in the middle of deserializing something, we don't hand it
11:46 dalek MoarVM: back from the SC when doing a "try to get this" style lookup.
11:46 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/5a967215b0
11:46 dalek MoarVM: cb118d7 | jnthn++ | src/spesh/ (2 files):
11:46 dalek MoarVM: Avoid two more GC triggers inside of spesh.
11:46 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/cb118d7e95
11:55 dalek MoarVM: b94d9cf | jnthn++ | src/core/frame.c:
11:55 dalek MoarVM: Fix unrooted frame around SC object lookup.
11:55 dalek MoarVM:
11:55 dalek MoarVM: While these only ever cause gen2 allocation, they can still trigger
11:55 dalek MoarVM: GC due to mutex acquisition needing to enter the GC, and lazy
11:55 dalek MoarVM: deserialization can trigger that.
11:55 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/b94d9cf237
12:12 * brrt chuckles at the 'eventually static' pun
12:12 dalek MoarVM: 2edb721 | jnthn++ | src/core/interp.c:
12:12 dalek MoarVM: Remove some GC debug code.
12:12 dalek MoarVM:
12:12 dalek MoarVM: This was put in before MVM_GC_DEBUG level 2. It's now subsumed by it.
12:12 dalek MoarVM: Worse, one of these had a nasty bug; better leave it to the more
12:12 dalek MoarVM: general mechanism.
12:12 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/2edb7212c0
12:12 dalek MoarVM: ccafaa4 | jnthn++ | src/spesh/args.c:
12:12 dalek MoarVM: Avoid reading nativerefs in spesh.
12:12 dalek MoarVM:
12:12 dalek MoarVM: Reading them triggers a boxing, which in turn triggers GC, which
12:12 dalek MoarVM: violates the spesh no-GC invariant.
12:12 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/ccafaa4cf8
12:13 jnthn brrt: Where'd you see that one? :)
12:13 jnthn I'm not sure whether or not I coined it. :P
12:14 dogbert17 jnthn: looks like you opened a can of worms
12:15 jnthn Well, it was already open, I'm just trying to make sure the worms aren't escaping all over our users :)
12:15 brrt in the 2014 advent calendar
12:15 brrt your post, in fact
12:15 jnthn That S15-nfg/many-threads.t test was very good at shaking them out
12:15 brrt damn, is it end of 2016 already?
12:16 dogbert17 cool, I'm running make spectest with your latest fixes (1 meg nursery for speed), should I holler if I see any fails or should I wait for more fixes?
12:17 jnthn brrt: Yeah, I was looking for a way to talk about the way that dynamic code tends to have a static execution profile in many cases, and at the same time at $dayjob stuff was having various discussions of eventual consistency, so the term "eventually static" kinda fell out of the intersection of them :-)
12:17 jnthn dogbert17: Plesae do :)
12:17 jnthn dogbert17: I'm about to have lunch
12:17 jnthn But have S15-nfg/many-threads.t running in a loop inside of gdb
12:17 jnthn (Stops looping if it panics or SEGVs)
12:17 dogbert17 me too :-) so the tests can run while eating
12:18 jnthn :)
12:18 jnthn bbi30 :)
12:19 brrt it's a good pun imho :-)
12:19 * brrt wonders if/when we can revive the 'trace spesh' effort
12:57 * jnthn back
12:58 * timotimo wonders about escape analysis, as well as allocation-site measurements
13:03 dogbert17 for me, t/spec/S15-nfg/many-threads.t still fails (MoarVM commit ccafaa4cf8e0b0e1)
13:03 jnthn dogbert17: I'm trying a slightly smaller nursery size now, just to see if I can squeeze anything more out of S15-nfg/threads.t but given it ran over lunch I suspect probably not
13:03 jnthn Oh :/
13:03 dogbert17 let me gdb
13:04 nwc10 use more 'lunch' ?
13:04 dogbert17 17 spectests failed during lunch (1 Meg nursery)
13:07 dogbert17 as usual I might have made some kind of mistake, I get: Missing or wrong version of dependency 'gen/moar/Metamodel.nqp' (from 'gen/moar/BOOTSTRAP.nqp')
13:07 jnthn Sounds like something didn't get rebuilt
13:07 nine dogbert17: it's not you, it's our build system...
13:10 dogbert17 what do I need to do; I only dir a 'perl Configure ...' followed my 'make install' from the nqp/MoarVM dir
13:10 dogbert17 s/dir/did/
13:11 * dogbert17 tries again
13:12 timotimo might want a make clean in rakudo if not a Configure.pl
13:13 dogbert17 timotimo: thx, will try
13:25 dogbert17 timotimo: you were 100% correct, rerunning spectests now with 64k nursery
13:25 dalek MoarVM: 42655a7 | jnthn++ | src/6model/sc.h:
13:25 dalek MoarVM: Remove well-meaning but bogus assertions.
13:25 dalek MoarVM:
13:25 dalek MoarVM: Our GC is partially concurrent: while the mark phase is certainly
13:25 dalek MoarVM: done with the world stopped, we sweep afterwards. This means that
13:25 dalek MoarVM: we may encounter objects whose headers are still marked with the
13:25 dalek MoarVM: GEN2_LIVE flag, which is cleared after the stop-the-world phase,
13:25 dalek MoarVM: and that this can happen legitimately.
13:25 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/42655a7598
13:27 timotimo i'm glad
13:27 dogbert17 and we can now safely ignore my earlier comment about 17 failed spectests :-)
13:28 dalek MoarVM: e4784c9 | jnthn++ | src/core/interp.c:
13:28 dalek MoarVM: Cope with push being used on concurrent queues.
13:28 dalek MoarVM:
13:28 dalek MoarVM: We should probably not have re-purposed push for sending on a
13:28 dalek MoarVM: concurrent queue. But, with that being done, it's possible the
13:28 dalek MoarVM: push will trigger GC and so `obj` is out-dated when we come to
13:28 dalek MoarVM: consider the object write barrier.
13:28 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e4784c92cc
13:29 jnthn dogbert17: How's it looking now? Or still waiting for results? :)
13:30 jnthn dogbert17: btw, managed to reproduce something close to https://github.com/MoarVM/MoarVM/issues/449
13:44 dogbert17 I'm only at the S06* test so far. Only one fail, i.e. t/spec/S17-supply/syntax.t, but we had a separete issue for that if I remember correctly
13:45 dogbert17 ha, that's the one you're looking at :-)
13:51 jnthn Yeah, I'm pretty far into figuring it out too
13:54 brrt timotimo: any idea why the throwlexpayload thingy broke?
13:54 brrt i mean, it looked good
14:07 timotimo no clue :(
14:07 timotimo it might have caused a frame to be jitted that has some other op in it that's not right
14:12 dogbert17 jnthn: have run spectest to completion with 128k nursery only t/spec/S17-supply/syntax.t failed
14:14 dalek MoarVM: c45cb0e | jnthn++ | src/io/ (6 files):
14:14 dalek MoarVM: MVMROOT around putting work on concurrent queue.
14:14 dalek MoarVM:
14:14 dalek MoarVM: It was missing in this set of places (will audit for further ones; the
14:14 dalek MoarVM: timer case was a cause of problems for S17-supply/syntax.t).
14:14 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/c45cb0ecfd
14:15 dogbert17 cool, I wonder have many RT's your fixes will close
14:22 dalek MoarVM: 81c5d27 | jnthn++ | src/io/eventloop.c:
14:22 dalek MoarVM: MVMROOT eventloop queue when polling it.
14:22 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/81c5d27ebb
14:27 * jnthn wonders how so much worked before these fixes :P
14:28 nwc10 "because it hates you"?
14:28 ilmari the wrong kind of luck?
14:28 nwc10 the wrong kind of lunch?
14:28 ilmari yeh, the late kind
14:28 ilmari have been dealing with an outage at work
14:29 nwc10 :-(
14:29 nwc10 expense pizza delivery?
14:29 jnthn It's "wrong kind of luck" pretty much.
14:30 jnthn With normal GC intervals you're fairly unlikely to run into many of these.
14:30 nwc10 as long as lunch is ultimately "better late than never" that's probably OK
14:31 timotimo oh, those fixes are in time for the release, too
14:31 jnthn All fixes are in time for the next release. :P
14:32 jnthn MVM_GC_DEBUG is really not bad at catching stuff these days, especially at level 2
14:33 jnthn It gets stuff that we used to get away with even in small nursery size tests.
14:34 brrt timotimo: i wonder if we can add jit bisecting for those kind of things, too
14:36 jnthn Darnit. S17-supply/syntax.t has a test near the end that runs for ages. I thought it was going to make it through with the above fix. But no...there's still something.
14:37 jnthn And I forgot to stick the breakpoint on MVM_panic...
14:37 jnthn So, here we go again...
14:38 timotimo should be possible
14:42 * brrt thinks about it for a bit
14:45 dogbert17 now all spectests passed for me with a 64k nursery
14:46 dogbert17 I meant 128k nursery
14:46 jnthn dogbert17: Still having trouble with syntax.t on a 28KB one
14:46 dogbert17 ok, i'll try that as well
14:47 jnthn I did 32KB then went for 28KB to try and catch things that get lucky on power-of-2 boundaries :)
14:47 jnthn Guess we could pick prime sizes... :)
14:49 dogbert17 got it with 32k
14:49 jnthn In syntax.t?
14:49 dogbert17 yes
14:49 * jnthn is trying another tweak he's done locally
14:49 jnthn Found a very sneaky way that the inter-generational invariant mighta been violated
14:50 jnthn (The "gen2 must not point to nursery unless it's in the inter-gens list" one)
14:51 dogbert17 here's a gist, does it confirm your suspicions? https://gist.github.com/dogbert17/93a8ce5f6cbb9cc016cb668c30b7d42c
14:52 jnthn That one actually looks fairly different
14:52 jnthn Mine is whlie it's working on test 68
14:52 dogbert17 aha, here it must have been test 54
14:53 jnthn yeah, I've not had it fail there
14:53 jnthn In quite a lot of runs
14:53 jnthn (all the ones where looking for 68)
14:53 jnthn But I'm on 28000 bytes of nursery
14:53 jnthn I'll try 32768 after
14:53 jnthn (Once I've nailed the current issue)
14:54 * jnthn wonders if any of these match up with the docs build issue
14:56 jnthn dogbert17: I've run https://github.com/MoarVM/MoarVM/issues/450 quite a few times on HEAD (well, and one more local fix) and can't reproduce it
14:57 jnthn (So if you can I'm interested :))
14:58 dogbert17 will try
15:02 dogbert17 jnthn: https://gist.github.com/dogbert17/d0de6163af8ae7b85f51991266c0a640
15:07 dogbert17 I', on 81c5d27ebbb99,i.e. 'MVMROOT eventloop queue when polling it.' 32k nursery
15:10 dalek MoarVM: 1bbd82f | jnthn++ | src/6model/reprs/ConcBlockingQueue.c:
15:10 dalek MoarVM: Do MVM_ASSIGN_REF after block/unblock.
15:10 dalek MoarVM:
15:10 dalek MoarVM: Suppose that we do it before, and the target of the assignment is in
15:10 dalek MoarVM: the nursery and has already been seen there once. Thus we don't put
15:10 dalek MoarVM: the target into the inter-generational set because it's not in gen2.
15:10 dalek MoarVM: Then, when we block/unblock around the lock acquisition, GC triggers
15:10 dalek MoarVM: and the target is promoted. At this point the node to add into the
15:10 dalek MoarVM: linked list may point to a nursery object, but since we didn't
15:10 dalek MoarVM: actually chain the new item into the linked list representing the
15:10 dalek MoarVM: queue yet, the GC could never spot it at the point of promotion,
15:10 dalek MoarVM: so it would not place the target into the inter-gen set at this
15:13 jnthn 68 in S17-supply/syntax.t survives with that one
15:13 jnthn Checking it another time or two to try and be sure
15:14 dogbert17 you're quickly working towards another blogpost :-)
15:14 jnthn :P
15:15 jnthn Well, I've gotta write my advent post
15:15 jnthn So suspect that'll eat the bloggingz time this week
15:15 jnthn I did at least start writing the code I need for my advent post last night :)
15:16 dogbert17 did you see my socket gist above?
15:18 jnthn Yes, *also* in finish_store
15:21 jnthn Really want to try and recreate that locally
15:21 dogbert17 32k nursery does it for me
15:22 jnthn Yeah, will try after this latest run of syntax.t completes, provided it comes out OK
15:23 dogbert17 the syntax test which fails for me is: is $order, '123', 'multiple channels in whenever blocks work';
15:23 jnthn Yeah, my 28k nursery gets through that fine every time...
15:24 jnthn Hopefully 32K will catch it
15:30 jnthn Oh, I just realized...
15:31 jnthn The code explodes inside of the Rakduo C extensions to the VM
15:31 jnthn But I didn't re-compile those
15:32 dogbert17 oO
15:32 jnthn So MVM_ASSIGN_REF won't have got the GC-debug version of itself
15:32 jnthn Which would explain why I don't see the issue ;)
15:32 jnthn Anyway, compiling with that to see
15:33 dogbert17 would be nice if you manage to reproduce the errors
15:33 jnthn Indeed
15:36 jnthn Need a quick break; bbi15
16:10 jnthn dogbert17: Hmm, still no luck
16:15 jnthn ooh, but with an 8KB nursery I provoke something
16:17 jnthn And yes, it's in the place you got it.
16:20 dogbert17 jnthn: I did a make clean on both moar and rakudo and now the problems are gone ?!?
16:22 dogbert17 I think we're good :)
16:22 jnthn No, it's certainly still busted
16:22 jnthn Well, it was :)
16:22 dogbert17 syntax.t?
16:22 jnthn Yeah
16:22 dogbert17 :)
16:22 jnthn With the error you got in finish_store
16:22 jnthn But I think I've patched it :)
16:23 dogbert17 cooool
16:25 dogbert17 must go afk, bbl
16:25 Ven joined #moarvm
16:36 TimToady joined #moarvm
16:54 jnthn Pushed that fix (in Rakudo repo).
16:56 pyrimidine joined #moarvm
17:04 jnthn Turns out with a really tiny nursery you can sqeeze even more out of that socket read vs recv test
17:06 jnthn Which, bizzarely, makes it look like when the nursery is small enough it doesn't get properly zeroed o.O
17:11 JimmyZ jnthn: https://github.com/MoarVM/MoarVM/blob/b94d9cf237fe6f74cbe7dfa83d94b3cd77c61a15/src/core/frame.c#L1017 looks like mssing a MVMROOT the 'code' Object?
17:12 jnthn JimmyZ: Yes, and will need pulling apart into two lines
17:13 jnthn (I didn't do a full audit of those yet)
17:13 JimmyZ the missing MVMROOT part is hard,, haha, it [will] is/be always here and there
17:16 jnthn Yeah...need to write less of this stuff in C :)
17:17 jnthn OK, think I've not the concentration for hunting down more stuff today
17:17 jnthn And should save some energy to start preparing my advent post
17:46 lizmat jnthn++
17:47 lizmat jnthn: just as a datapoint: the last fix in rakudo did not take away the problem with HARNESS_TYPE=6 make spectest
17:48 lizmat Unhandled exception in code scheduled on thread 13
17:48 lizmat No such method 'end-entries' for invocant of type 'Match'
17:48 lizmat although I needed 4 runs this time before it happened, so maybe some stability was added by that fix after all
17:58 dalek MoarVM: 21abc2a | (Jimmy Zhuo)++ | src/core/frame.c:
17:58 dalek MoarVM: Fix more unrooted frame around SC object lookup.
17:58 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/21abc2a113
18:28 japhb joined #moarvm
18:30 domidumont joined #moarvm
18:33 domidumont joined #moarvm
18:45 pyrimidine joined #moarvm
18:45 jnthn lizmat: I'd say there's an 90% chance that one will boil down to a code-gen bug rather than a VM bug, fwiw :)
18:46 lizmat jnthn: after the MoarVM bump I haven't been able to get HARNESS_TYPE=6 to crash
18:46 lizmat 4 runs so far
18:47 jnthn Hmm :)
18:47 jnthn Interesting.
18:47 jnthn 5th time's a charm :P
18:48 jnthn Or maybe it really was one of today's fixes, though if so I'm very curious which :)
18:49 jnthn BTW, bumping MOAR_REVISION was fine :)
18:49 jnthn It's hard to imagine anything I did today making things worse rather than better :-)
18:49 timotimo i thought worse is better
18:50 lizmat no, less is moar  :-)
18:50 jnthn moar or less...
18:50 lizmat $ 6 ''
18:50 lizmat real0m0.099s
18:50 lizmat wow, been a long time I've seen that below 100 msecs
18:50 jnthn :)
18:51 jnthn Wonder if that was because I turned off the accidentally enabled GC sanity checks in a few ops...
18:51 japhb Yay!  \o/
18:51 jnthn oh no, japhb /o\
18:51 jnthn I accidentally the whole day fixing GC bugs and didn't yet get to the OO::Monitors thing
18:51 japhb I STRIKE FEAR INTO MORTALS
18:51 jnthn Though I did think about it some
18:51 japhb Fair enough.
18:52 lizmat jnthn: 5th run ok
18:54 pyrimidine joined #moarvm
18:54 jnthn lizmat: Not bad. :)
18:55 lizmat testing Zoffix's last fix now
18:57 jnthn japhb: Gotta be afk for a bit now, but I pushed my idea that may help to the branch maybe-fix-exception-stuff in the OO::Monitors repo
18:58 jnthn japhb: Didn't have chance to turn the report into a proper test case and try if it helps yet
18:59 * jnthn bbiab
19:07 FROGGS joined #moarvm
19:08 lizmat jnthn: the 6th was the charm  :-(
19:08 lizmat ===Unhandled exception in code scheduled on thread 10
19:08 lizmat No such method 'end-entries' for invocant of type 'Match'
19:10 moritz end-entries is a Tap method, not Match, right?
19:11 lizmat yup
19:11 lizmat it gets confused
19:11 lizmat actually, not sure it's a Tap
19:12 lizmat it's a method from Entry::Handler in lib/TAP.pm6
19:13 lizmat or from class State
19:14 lizmat which does TAP::Entry::Handler
19:14 lizmat so it gets confused about a method that is also provided by a role that  it does
19:17 moritz I've seen such confusion with parameterized roles, in single-threaded code
19:18 lizmat so perhaps it's JIT / SPESH / related
19:19 moritz RT#130183
19:19 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=130183
19:21 domidumont joined #moarvm
19:21 moritz that one doesn't seem to SPESH-related though
19:21 moritz maybe they are separate issues after all
19:30 pyrimidine joined #moarvm
19:58 Ven joined #moarvm
20:09 dalek MoarVM/missing_mvmroot: ee6b817 | (Jimmy Zhuo)++ | src/ (2 files):
20:09 dalek MoarVM/missing_mvmroot: add more missing mvmroot
20:09 dalek MoarVM/missing_mvmroot: review: https://github.com/MoarVM/MoarVM/commit/ee6b81707e
20:10 JimmyZ jnthn: ^^ please review, thanks :)
20:38 jnthn JimmyZ: I will, but probably only makes sense to do it when I'm rested :)
20:38 jnthn So will look tomorrow :)
20:44 japhb jnthn: Sadly, doesn't look like maybe-fix-exception-stuff fixed the problem.  :-(
20:48 jnthn japhb: Aww :( I thought that would nail the exception getting turned into cannot invoke...
20:48 * japhb is sad also
20:48 domidumont joined #moarvm
20:49 jnthn I figured it was because of the EXCEPTION(...) call that takes place inside of a CATCH block
20:49 jnthn A LEAVE is the same code path for success and exceptions
21:54 timotimo mumroot sounds vaguely edible
21:55 timotimo maybe you can brew a tea with mumroot. maybe it has some medicinal properties
22:01 geekosaur "enhances memory" :p
22:04 timotimo %)

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