github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:59 linkable6 left, evalable6 left 01:01 linkable6 joined 01:02 evalable6 joined 01:22 vrurg left 01:23 vrurg joined 03:10 klapperl left 03:15 klapperl joined 03:41 squashable6 left, squashable6 joined 03:43 squashable6 left 03:44 squashable6 joined 04:44 linkable6 left, evalable6 left 04:46 evalable6 joined, linkable6 joined 05:23 squashable6 left 05:26 squashable6 joined 06:14 Altai-man joined
nwc10 good *, #moarvm 07:12
nine Good fog! 07:41
nwc10 certainly not as sunny as yesterday here
Geth MoarVM: patrickbkr++ created pull request #1385:
Add a test configuration for MinGW on Windows		 07:58
08:07 domidumont joined 08:11 sena_kun joined 08:12 Altai-man left
nine LOL...I just tried to ack for 'SC not yet resolved' in MoarVM sources but fat fingered that closing single quote into ;' 08:28
The funny part: it found the message anyway as the full message is "SC not yet resolved; lookup failed"
08:55 zakharyas joined 09:14 MasterDuke joined
MasterDuke libuv 1.40.0 is already out, looks like a 1.41.0 or 1.40.1 might be out soon. we should bump after the release 09:33
jnthn nine: Convenient :) 10:31
MasterDuke ok, i'm back with some time to try to debug that segv i'd captured in rr 11:16
but where was i?
13:51 nine I'd say you want to know where it entered the worklist13:52 nine You already know where and how sc_idx gets overwritten. That didn't help because it's obviously not the writer's fault. It's the fault of whoever holds a pointer to an object and lets it get out-dated 11:17
hm. guess i want to set a breakpoint on MVM_gc_worklist_add where `item` is the same `item` that causes the panic in MVM_gc_mark_collectable? 11:26
11:40 vrurg left 11:59 MasterDuke left 12:10 Altai-man joined 12:12 sena_kun left 12:21 Geth_ joined 12:26 Kaiepi left, Kaeipi joined 12:30 Geth_ left, Geth_ joined 12:31 Geth__ joined, Geth__ left 12:40 MasterDuke joined 12:45 Geth__ joined, raku-bridge joined 12:53 Geth_ left 12:54 raku-bridge left, Geth__ left 12:57 Geth___ joined 12:58 raku-bridge joined, raku-bridge left, Geth_ joined, raku-bridge joined, raku-bridge left, raku-bridge joined, Geth___ left 13:02 raku-bridge left, raku-bridge joined, raku-bridge left, raku-bridge joined 13:04 raku-bridge left 13:06 raku-bridge joined, raku-bridge left, raku-bridge joined 13:13 raku-bridge left, raku-bridge joined, raku-bridge left, raku-bridge joined 13:33 raku-bridge left 13:34 raku-bridge joined 13:35 raku-bridge1 joined 13:36 Geth__ joined 13:41 raku-bridge left 13:42 Geth__ left 13:43 raku-bridge1 left, Geth___ joined 13:44 raku-bridge joined, raku-bridge left, raku-bridge joined 13:47 raku-bridge1 joined, raku-bridge1 left, raku-bridge1 joined 13:48 Geth___ left 13:49 raku-bridge left 13:50 raku-bridge1 left, raku-bridge joined, raku-bridge left, raku-bridge joined 13:53 Geth_ left 13:54 raku-bridge left, Geth__ joined, raku-bridge joined, raku-bridge left, raku-bridge joined 13:56 raku-bridge left 13:57 raku-bridge joined, raku-bridge left, raku-bridge joined
MasterDuke but i'm not quite sure how to make sure they're the same assuming the object gets moved around by the gc 14:00
14:01 zakharyas left
MasterDuke see the address in MVM_gc_mark_collectable when the panic happens, set a watchpoint on it, reverse-cont, see when that address gets written, see what the previous address was, set a watchpoint on MVM_gc_watchlist_add when the address of it's argument is the same, reverse-cont again, when that hits see where we are? 14:02
14:03 raku-bridge left, Geth__ left 14:10 raku-bridge joined, raku-bridge left, raku-bridge joined, Geth_ joined 14:14 Geth_ left 14:15 raku-bridge left, vrurg joined 14:16 Geth__ joined 14:23 raku-bridge joined, raku-bridge left, raku-bridge joined 14:25 raku-bridge left 14:26 raku-bridge joined, raku-bridge left, raku-bridge joined 14:32 raku-bridge left, raku-bridge joined, raku-bridge left, raku-bridge joined 14:34 raku-bridge left, raku-bridge joined, raku-bridge left, raku-bridge joined 14:36 raku-bridge left, raku-bridge joined, raku-bridge left, raku-bridge joined 14:48 Geth__ left 14:50 raku-bridge left
MasterDuke timotimo: we can't use the appimage to run files? it just works with -e? 14:56
oh, i guess it just can't read the local filesystem at all 15:06
15:09 Geth___ joined
Kaeipi what versions of windows does moarvm support? 15:12
nine I thought there were no more versions of windows? 15:13
15:14 zakharyas joined
nwc10 10.00000 recurring :-) 15:16
I don't know the answer, but I assume that the MoarVM code is portable enough (along with all the *other* 3rd party stuff) that the limiting factor will be libuv. So the answer likely is "the same as UV supports" 15:17
Kaeipi ah 15:18
if none prior to 10 are supported, no worries then
15:18 raku-bridge joined, raku-bridge left, raku-bridge joined
nwc10 I really don't know - and I'm not personalyl in a posisiton to try it out 15:19
I think that jnthn was developing partly on Windows 7 until relatively recently, so it's possible that Windows 7 still builds too
jnthn Yeah, 7 is what I still have here 15:21
nine Windows 8.1 fell out of mainstream support in 2018 and will fall out of extended support in January 2023
jnthn Though I don't develop on it much (pretty much only if I'm asked to go after a bug)
nwc10 here's an answer: github.com/libuv/libuv/blob/master...ATFORMS.md 15:23
jnthn nine: What's supported and what's used are different questions, alas :)
nwc10 the door system at the old office was still running on Windows 2000 until a couple of years ago. 15:26
The system that replaced it was on Windows 7, IIRC
"thanks dudes. This product you're installing will itself go out of support in 2 years"
I suppose they're just gettings us ready for the IoS, er IoT 15:27
15:27 raku-bridge2 joined, raku-bridge2 left, raku-bridge2 joined, Geth__ joined
nwc10 "to say thank you for buying our product last year, we've turned the servers off and now you have a very expensive brick" 15:27
(with a high carbon footprint and quite a few non ethically sourced rare metals) 15:28
15:32 Geth__ left, raku-bridge2 left, raku-bridge left
MasterDuke given the warning in this comment github.com/MoarVM/MoarVM/blame/mas...2482-L2489 has the serialization format changed at all recently? 15:32
nine February 2020 15:33
15:33 raku-bridge joined 15:34 raku-bridge left
MasterDuke github.com/MoarVM/MoarVM/commit/97...597c75ffcb ? 15:35
[Coke] I do very occassional builds on win 10, haven't had any issues when tried. 15:37
MasterDuke i really don't know serialization well enough to know if that commit changes the sizes referenced in the comment
15:38 Geth__ joined
MasterDuke jnthn: ping re above question/comment 15:42
15:42 raku-bridge joined, raku-bridge left, raku-bridge joined
jnthn MasterDuke: I don't think the function the warning relates to deserializes closures 15:46
So I don't think it could have any impact 15:47
MasterDuke hm, the comment says "...if you change other parts of the serialization format..."
nwc10: pinging also since you wrote the warning 15:48
nine MasterDuke: actually, why do you ask? 16:07
MasterDuke i've seen some functions from that file in backtraces during my flailing about in rr 16:09
and then the comments here github.com/MoarVM/MoarVM/blame/mas...2544-L2545 gave me pause
interestingly, i added a print if either of those calculate_int_bytes values was > 1_000_000 and it doesn't hit 16:10
16:11 raku-bridge left, sena_kun joined
MasterDuke oops, ha 16:11
16:11 Geth__ left 16:12 Altai-man left
MasterDuke waves hand "pay no attention to the previous comment" 16:13
16:20 Geth_ joined 16:24 Geth_ left
nwc10 MasterDuke: It's been five years. I roughly remember what I was doing, but we've moved house twice in that time, and a lot of other stuff, so I don't remember much else 16:30
well, that IIRC the lazy function was trying to figure out if all the things "inside" something else where of the shapes that it expected, and if it was 100% confident about what was inside, it was lazy (ie cheated), else it was eager 16:32
but please don't ask me to expand anything in that sentance, because I can't remember any more than that, and my head is currently full of many many other things. 16:33
timotimo imagine if we all consistently wrote very good commit messages 16:36
(tbh nwc10 is light years ahead of me already)
nine word! 16:48
17:02 Geth left
[Coke] just did a win10 build, seems fine 17:13
sena_kun github.com/MoarVM/MoarVM/pull/1385...-730222698 17:21
17:22 Geth___ left 17:23 Geth joined, raku-bridge joined, raku-bridge left, raku-bridge joined 17:26 raku-bridge left 17:27 raku-bridge joined, raku-bridge left, raku-bridge joined 17:30 raku-bridge left, Geth left 17:32 Geth joined 17:33 raku-bridge joined, raku-bridge left, raku-bridge joined 17:41 raku-bridge left 17:43 Geth_ joined, Geth left, raku-bridge joined, raku-bridge left, raku-bridge joined 17:44 Geth joined 17:45 Geth left 18:01 rypervenche left 18:11 rypervenche joined 18:56 zakharyas left
Geth_ MoarVM/bigint_div_num-IEEE-rounding: 70cefcfffc | (Nicholas Clark)++ | src/math/bigintops.c
Minimally exact bigint/bigint => num conversion, including rounding.

Given that Rakudo parses decimal constants such as 0.01 as `Rat`s (ie represents them internally as (1 / 100), and persists with this exact representation as long as possible), this effectively means that the MoarVM operator that converts `Rat`s to `Num`s implements Rakudo's decimal => binary floating point conversion. ... (161 more lines)		 19:20
nwc10 Unlike that Pascal quote apologising for writing a long letter, in this case, I don't think that I could write a shorter explanation of the problem, and the not-a-solutions. 19:25
lizmat: is there a (booby) prize for the longest commit message? 19:41
lizmat good question :-)
20:00 domidumont left
nine And is there also a price for longest commit message per actual character changed? I may be a contestant for that :) 20:06
nwc10 I sometimes do quite well on those. 20:07
on that metric, that is
you can make a 1 character change
and then a long explanation of why
(justified explanation)
meanwhile I must berate the beer fridge operative, as he (it is known to be a he) failed to put in the beer that I actually wanted
I have fixed this, and taken a different one (for now) 20:08
20:10 Altai-man joined
MasterDuke nwc10: could there possibly be a missing MVMROOT in (or around) github.com/MoarVM/MoarVM/blame/mas...c#L97-L119 ? 20:12
20:13 sena_kun left
nwc10 I didn't think that anything that it calls down to can cause the GC to run, because nothing (I thought) does any object allocation 20:20
that's not "no" just "if there is one missing, I can't see why" 20:21
MasterDuke ok, that's kind of where i ended up too, but wanted a second opinion
nwc10 "it got past code review - it must be perfect" 20:22
or
"it got past code review - it's SEP now :-)"
aargh, I'm getting flashbacks to pow(2, 32) being an odd number on Irix 20:24
MasterDuke gist.github.com/MasterDuke17/a175c...bef9671069 does this look like i've done something wrong with the breakpoint? or is it correct and the idx is really that crazy number? 20:25
nwc10 I hope that that other beer is cold (enough)
MasterDuke i recently got two christmas beers, one st bernardus and one delirium tremens. looking forward to the end of lockdown to try with with a friend of mine 20:27
nine MasterDuke: that's 2^32-1 which is MVM_DIRECT_SC_IDX_SENTINEL
MasterDuke ah
gist updated. is this where the problem object gets added to the worklist? 20:33
nine what did you set the watchpoint on? 20:34
MasterDuke iirc, i first went forward to the panic, then found the address of new_addr in MVM_gc_mark_collectable, then went back to the beginning and set the read watchpoint on that 20:36
nine Oh a read watchpoint. Not a bad idea. I'd have watched the slot in the worklist. But yes, I'd say you're in the right place 20:38
now you can trace that pointer's origin further back
MasterDuke heh, well it wasn't the hash bind...
nine And somewhere along the line there's the spot where it should be rooted but isn't. But only reading the code will tell you which one 20:39
MasterDuke and it wasn't the clone
nine It's unlikely to be some very common operation like hash binds. We'd be crashing all over the place
MasterDuke seems unlikely to be in decont either 20:40
nine I'm a bit confused why GC_DEBUG=3 didn't make it easier to spot, since that includes poisoning which would trip up every of those ops. But maybe the frequent GC runs would promote it to gen2 too quickly 20:41
MasterDuke or find_meth... 20:43
21:16 zakharyas joined
MasterDuke if something calls MVM_gc_allocate_gen2_default_set(tc), then we don't need to worry about MVMROOTing? 21:31
jnthn Correct, because it can't trigger GC 21:39
MasterDuke thanks 21:40
re "But maybe the frequent GC runs would promote it to gen2 too quickly", is there a way to disable the gen2 promotion? 21:44
21:48 zakharyas left
jnthn Make the nursery bigger 21:56
That won't disable it, but it'll put it off much longer
Well, how much depending how big you make it
22:01 MasterDuke left 22:38 raku-bridge left, raku-bridge joined, raku-bridge left, raku-bridge joined 22:49 Altai-man left
timotimo doesn't the gc debug mode 3 also turn the time it takes to gen2 things a whole lot? 23:47

Powered by Cro and the Raku® Programming Language.

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

Thank you!