00:16 pyrimidine joined 00:39 pyrimidine joined 00:51 lizmat joined 01:14 pyrimidine joined 01:26 pyrimidine joined 01:39 pyrimidine joined 01:55 pyrimidine joined 02:22 pyrimidine joined 02:32 pyrimidine joined 02:37 colomon joined 02:48 ilbot3 joined 02:57 pyrimidine joined 03:37 colomon joined 07:01 geekosaur joined 07:16 pyrimidine joined 07:26 pyrimidine joined 07:48 domidumont joined 07:53 domidumont joined 08:16 pyrimidi_ joined 08:25 zakharyas joined 10:20 domidumont joined 11:27 geekosaur joined 11:38 pyrimidine joined 11:56 pyrimidine joined 12:06 pyrimidine joined 12:08 domidumont joined
dogbert17_ jnthn: regarding the discussion yesterday about "Must not GC when in the specializer/JIT": the MoarVM issue no is #458 12:14
12:18 domidumont joined
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
12:24 pyrimidine joined 12:34 pyrimidine joined 12:43 pyrimidine joined
jnthn dogbert17_: print_exception is invoked from somewhere in NQP, which in turn is just a normal exception handler, iirc 12:45
dogbert17_ jnthn, thx I guess it's not possible to set gdb breakpoints in NQP code ... 12:48
was trying to take a look at [Coke]'s problems with htmlify 12:50
12:52 pyrimidine joined 13:02 pyrimidine joined
jnthn OK, I've Perl 6 / MoarVM tuits :) 13:09
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
dogbert17_ jnthn, I believe you solved the syntax.t and many-threads ones 13:12
jnthn Pretty sure github.com/MoarVM/MoarVM/issues/449 and github.com/MoarVM/MoarVM/issues/450 and github.com/MoarVM/MoarVM/issues/452 I fixed
dogbert17_ yup
jnthn I thought S32-io/socket-recv-vs-read.t too
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...
Ah, right
Oh, and hyper.t was a newly reported one since We
*Wed
dogbert17_ wrt 450, when I run it, it does no longer panic but one test fails with truncated data
hyper is new
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
jnthn Yes, I wasn't able to be sure whether it was a timing issue
Or memory issue 13:15
(for the lost data)
Though it shouldn't really happen either way
dogbert17_ agreed, where will you start?
jnthn Think with hyper.t
As it looks the most easily huntable
dogbert17_ here's hoping :) 13:16
jnthn Especially since I'm pretty sure there's just one thread involved
dogbert17_ sounds good, didn't you want to work on race and hyper anyways 13:17
jnthn True :) 13:18
jnthn has so many things he wants to work on... :)
dogbert17_ holler if there's anything I can do except apat from closing the two fixed issues 13:20
nwc10 hopefully including lunch
dogbert17_ my spelling totally sucks today :(
13:20 pyrimidine joined
jnthn Already did lunch :) 13:21
nwc10 jnthn++
jnthn My lunchtime reminder service is back home, so reliable lunches are back for the foreseeable future :)
nwc10 \o/ 13:22
dogbert17_ how about coffee then?
jnthn Did that this morning. Already on to tea. 13:23
A slice of stollen in an hour or so would be nice, though...
nwc10 you have that sorted, or you're just popping out to Germany to get some? 13:25
jnthn No, already have some :) 13:28
There was a kilo of it
But its disappearing fast 13:29
jnthn fails to reproduce the hyper.t bug
13:30 pyrimidine joined
jnthn Can try with some nursery size variations 13:31
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 :)
JimmyZ jnthn: thanks
[Coke] yawns. 13:36
lizmat too
jnthn three
Sleep deprevation all around 13:37
mst forth
*deprivation
trout.me.uk/ocd.png
< El_Che> mst: Megalomanic Spelling Troll
[Coke] mst: *twitch*
jnthn
.oO( depravation :P )
lizmat
.oO( OCD should be spelled CDO )
 13:38
13:39 pyrimidine joined
jnthn dogbert17_: Don't suppose you could check the hyper.t one again locally? I'm have zero luck reproducing it... 13:44
dogbert17_ jnthn: will try 13:45
jnthn has tried a dozen nursery sizes by this point 13:47
dogbert17_ gah 13:48
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
It's possible it was covered by another fix 13:55
dogbert17_ maybe there's somthing more reproducible in your list of bugs to fix 13:57
13:57 pyrimidine joined
jnthn Yeah, think I'll have to give up on this one for now 13:58
jnthn reviews JimmyZ++'s pull requests before further hutning 13:59
JimmyZ: Left some comments. :) 14:09
14:10 pyrimidine joined
jnthn And merged the Rakudo one, which is ifne 14:10
*fine
dogbert17_: Better news: reproduced rt.perl.org/Ticket/Display.html?id=130294 :) 14:14
14:16 pyrimidine joined
nwc10 this is sort of 14:16
bad news: it's not fixed
good news: we know that it's not fixed
dogbert17_ yay :-) 14:20
hope it's a simple one 14:22
jnthn Confusing one so far 14:24
Though maybe wonky debug symbols
14:24 pyrimidine joined
jnthn is now compiling with optimization off 14:25
Aha. Goes away under MVM_SPESH_INLINE_DISABLE 14:26
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:27
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:56
jnthn: cause more two push 14:57
jnthn JimmyZ: I think I'd prefer the code clarity 15:00
dalek arVM/missing_mvmroot: 9d2a4e5 | (Jimmy Zhuo)++ | src/6model/6model.c:
change MVM_gc_root_temp_push to MVMROOT
 15:08
arVM/missing_mvmroot: 7b89473 | (Jimmy Zhuo)++ | src/core/frame.c:
add a missing MVMROOT
15:09 colomon joined
JimmyZ jnthn: should I change all temp_push to MVMROOT? though this will cause a bit more push times 15:11
dalek arVM: 0e4652c | jnthn++ | src/core/interp.c:
Check lexical access in GC debug mode 2 also.

Might catch a few more things. Sadly, not the bug I'm currently on the hunt for.		 15:12
jnthn JimmyZ: I don't think we need to change existing code
JimmyZ: Just would prefer MVMROOT going forward 15:13
JimmyZ jnthn: I meant in my PR
dogbert17_ jnthn: has rt.perl.org/Ticket/Display.html?id=130294 turned out to be a can of worms?
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
jnthn JimmyZ: It can, though I think --debug=3 makes it OK again in GCC at least :) 15:15
dogbert17_: Yes, somewhat
dogbert17_: Well, not so much can of worms
JimmyZ jnthn: ah, don't know about it
jnthn dogbert17_: At least, not yet. It's just rather hard to work out what's going on.
JimmyZ: When you configure MoarVM pass --debug=3
dogbert17_ perhaps time for some stoller 15:16
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 ;)
JimmyZ well , since it is in find_method, it may be in hot path 15:19
jnthn Maybe, but isn't this code in the case we missed the cache? 15:20
If so we're already on the slow path...
JimmyZ yeah
jnthn Then spesh bypasses it all also in many cases
JimmyZ jnthn: BTW, github.com/MoarVM/MoarVM/issues/412 #don't know if it is a gc but or not 15:21
*bug
jnthn Think I've spent time on that one before without success... 15:22
There was a similar RT a couple of days ago also
JimmyZ jnthn:yeah, I tried too ,haha
dalek arVM/missing_mvmroot: d7fdb71 | (Jimmy Zhuo)++ | src/6model/6model.c:
change MVM_gc_root_temp_push to MVMROOT
 15:32
arVM/missing_mvmroot: c0a7588 | (Jimmy Zhuo)++ | src/6model/6model.c:
change MVM_gc_root_temp_push to MVMROOT
 15:35
JimmyZ jnthn: updated my PR
jnthn ooh, valgrind barfage 15:38
(On the SEGV I'm hunting)
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
.oO( Who is president of valgrind? :P )
dalek arVM/missing_mvmroot: 9cfedef | (Jimmy Zhuo)++ | src/6model/6model.c:
fixed wrong MVMROOT
 15:40
jnthn Think I found the darn thing 15:53
Wasn't anything to do with spesh or GC at all
timotimo oh?
i wish there was some way to automatically expand only MVMROOT macros 15:54
before building
because it confuses the heck out of multiple debugging/analysis tools i've tried
dalek arVM: 4722cfc | jnthn++ | src/spesh/optimize.c:
Add a #define to turn on inline logging.

Quicker that commenting/uncommenting it.		 15:55
dogbert17_ interesting 15:59
jnthn Here it comes... 16:02
dalek arVM: 65acd55 | jnthn++ | src/core/callstack.c:
Fix callstack reset.

In cases where we have recursed heavily, we may end up needing to flush the entire stack onto the heap. In that case, we need to set
  *all* regions to have their ->alloc pointers back to the start of
the region. Otherwise, it can create a situation where we flip into that region again in the future, and assume that we're at the start of it - only to end up with memory off the end of it. The resulting corruption can be highly confusing, looking very much like a GC bug or an inlining bug (since inlining changes the number of stack frames allocated, thus hiding the bug).
jnthn Will stick a test in for it shortly. bbi10 16:05
dogbert17_ jnthn++ 16:07
timotimo ah! 16:10
so that's how that happens!
jnthn abh, bit longer than 10 mins...another errand to do 16:13
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 ... :-(
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:35
japhb jnthn: A worthy choice. :-) 17:48
jnthn Darn, the SEGV is good at hiding itself
timotimo sneaky thief
JimmyZ jnthn: I think I can merge my PR now, just wait for your opinion
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
Which means the test isn't so valuable :S
JimmyZ thinks fixing segv in the VM is the hardest work 17:50
jnthn ah, if I jack up the recursion count then it blows reliably even with use Test :) 17:51
JimmyZ: That's largely because there aren't many easy ones left :)
nwc10 \o/ 17:52
timotimo seems like that's your only recurse.
jnthn *groan*
18:01 domidumont joined
dogbert17 jnthn: have now closed 449 and 452 18:13
jnthn \o/ 18:18
And I've just resolved RT #130294 18:19
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=130294
dogbert17 jnthn++, from your comment I gather this is not blog material :-) 18:20
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:23
In the end it was something far more boring. 18:24
JimmyZ: Taking another look at your PR now 18:25
dalek arVM: ee6b817 | (Jimmy Zhuo)++ | src/ (2 files):
add more missing mvmroot
 18:28
MoarVM: 97d288c | (Jimmy Zhuo)++ | src/core/args.c:
MoarVM: fixed arg_flags allocation
jnthn JimmyZ: Thanks, it was incredibly easier to be comfortable it was correct when done that way :)
18:29 dalek joined
jnthn JimmyZ: Shall I clean up the branch? 18:31
18:34 FROGGS joined 18:43 travis-ci joined
travis-ci MoarVM build failed. Jonathan Worthington 'Add a #define to turn on inline logging. 18:43
travis-ci.org/MoarVM/MoarVM/builds/185499926 github.com/MoarVM/MoarVM/compare/0...22cfc03847
18:43 travis-ci left
JimmyZ jnthn: yes please 18:55
jnthn Done 18:57
JimmyZ thanks 18:59
nine jnthn: I'm not sure you still have a right to groan at bad puns ;) 19:17
japhb He earns the right to groan by dishing out so many groaners. :-) 19:18
JimmyZ ah ,find another wrong MVMROOT from my commit 19:24
jnthn: I found that MVM_gc_allocate_frame() may triger a GC but allocate_frame() not , so no need MVMROOT around allocate_frame()? 19:42
jnthn: and when use the triger the GC one? 19:43
found it about heap vs callstack 19:51
dalek arVM/needless_mvmroot: 86dc577 | (Jimmy Zhuo)++ | src/core/frame.c:
remove unused MVMROOT
 19:52
20:34 zakharyas joined
notviki Do we use a "generational GC"? 20:41
japhb notviki: yes. 20:42
notviki cool
notviki is reading medium.com/@octskyward/modern-garb...1ef4f8bd8e 20:43
japhb notviki: I believe jnthn used gchandbook.org/ as a reference. 20:51
(I can confirm it's really quite good, as was it's predecessor www.cs.kent.ac.uk/people/staff/rej/gcbook/ ) 20:52
21:00 pyrimidine joined
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?
jnthn (I'm about 75% of the way through it :))
Our GC is generational, parallel, and at a stretch you could label it concurrent. 21:09
21:09 pyrimidine joined
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:09
japhb
.oO( Simian-false )
 21:11
jnthn :) 21:12
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.
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
But most people understand it to mean doing a bit more than the amount we do in that way ;)
.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.
jnthn .tell lizmat Can you show me some code on the floor thing? :) 21:19
yoleaux2 jnthn: I'll pass your message to lizmat.
jnthn oh, mis-channel, but I think yoleaux2 is everywhere :)
japhb Why do we run our own yoleaux? 21:20
jnthn has no idea :) 21:23
21:24 stmuk joined 21:26 pyrimidine joined 21:37 pyrimidine joined 21:55 pyrimidine joined 22:04 pyrimidine joined
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.
notviki yoleaux2: is not in #perl6
japhb notviki: Why is there a second yoleaux? 22:19
notviki japhb: because we can't find who owns yoleaux to make it join #perl6-dev and #moar 22:20
japhb :-P
Fair enough.
22:22 pyrimidine joined 22:41 pyrimidine joined 22:43 colomon_ joined 22:50 pyrimidine joined 22:55 colomon joined 23:24 colomon joined 23:26 colomon joined 23:28 pyrimidine joined 23:37 pyrimidine joined 23:45 colomon joined 23:55 pyrimidine joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!