[00:59] *** linkable6 left [00:59] *** 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 [03:41] *** squashable6 joined [03:43] *** squashable6 left [03:44] *** squashable6 joined [04:44] *** linkable6 left [04:44] *** evalable6 left [04:46] *** evalable6 joined [04:46] *** linkable6 joined [05:23] *** squashable6 left [05:26] *** squashable6 joined [06:14] *** Altai-man joined [07:12] good *, #moarvm [07:41] Good fog! [07:41] certainly not as sunny as yesterday here [07:58] ¦ MoarVM: patrickbkr++ created pull request #1385: Add a test configuration for MinGW on Windows [07:58] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/1385 [08:07] *** domidumont joined [08:11] *** sena_kun joined [08:12] *** Altai-man left [08:28] 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 [09:33] 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 [10:31] nine: Convenient :) [11:16] ok, i'm back with some time to try to debug that segv i'd captured in rr [11:16] but where was i? [11:17] 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:26] 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: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 [12:26] *** Kaeipi joined [12:30] *** Geth_ left [12:30] *** Geth_ joined [12:31] *** Geth__ joined [12:31] *** Geth__ left [12:40] *** MasterDuke joined [12:45] *** Geth__ joined [12:45] *** raku-bridge joined [12:53] *** Geth_ left [12:54] *** raku-bridge left [12:54] *** Geth__ left [12:57] *** Geth___ joined [12:58] *** raku-bridge joined [12:58] *** raku-bridge left [12:58] *** Geth_ joined [12:58] *** raku-bridge joined [12:58] *** raku-bridge left [12:58] *** raku-bridge joined [12:58] *** Geth___ left [13:02] *** raku-bridge left [13:02] *** raku-bridge joined [13:02] *** raku-bridge left [13:02] *** raku-bridge joined [13:04] *** raku-bridge left [13:06] *** raku-bridge joined [13:06] *** raku-bridge left [13:06] *** raku-bridge joined [13:13] *** raku-bridge left [13:13] *** raku-bridge joined [13:13] *** raku-bridge left [13:13] *** 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 [13:43] *** Geth___ joined [13:44] *** raku-bridge joined [13:44] *** raku-bridge left [13:44] *** raku-bridge joined [13:47] *** raku-bridge1 joined [13:47] *** raku-bridge1 left [13:47] *** raku-bridge1 joined [13:48] *** Geth___ left [13:49] *** raku-bridge left [13:50] *** raku-bridge1 left [13:50] *** raku-bridge joined [13:50] *** raku-bridge left [13:50] *** raku-bridge joined [13:53] *** Geth_ left [13:54] *** raku-bridge left [13:54] *** Geth__ joined [13:54] *** raku-bridge joined [13:54] *** raku-bridge left [13:54] *** raku-bridge joined [13:56] *** raku-bridge left [13:57] *** raku-bridge joined [13:57] *** raku-bridge left [13:57] *** raku-bridge joined [14:00] but i'm not quite sure how to make sure they're the same assuming the object gets moved around by the gc [14:01] *** zakharyas left [14:02] 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:03] *** raku-bridge left [14:03] *** Geth__ left [14:10] *** raku-bridge joined [14:10] *** raku-bridge left [14:10] *** raku-bridge joined [14:10] *** Geth_ joined [14:14] *** Geth_ left [14:15] *** raku-bridge left [14:15] *** vrurg joined [14:16] *** Geth__ joined [14:23] *** raku-bridge joined [14:23] *** raku-bridge left [14:23] *** raku-bridge joined [14:25] *** raku-bridge left [14:26] *** raku-bridge joined [14:26] *** raku-bridge left [14:26] *** raku-bridge joined [14:32] *** raku-bridge left [14:32] *** raku-bridge joined [14:32] *** raku-bridge left [14:32] *** raku-bridge joined [14:34] *** raku-bridge left [14:34] *** raku-bridge joined [14:34] *** raku-bridge left [14:34] *** raku-bridge joined [14:36] *** raku-bridge left [14:36] *** raku-bridge joined [14:36] *** raku-bridge left [14:36] *** raku-bridge joined [14:48] *** Geth__ left [14:50] *** raku-bridge left [14:56] timotimo: we can't use the appimage to run files? it just works with -e? [15:06] oh, i guess it just can't read the local filesystem at all [15:09] *** Geth___ joined [15:12] what versions of windows does moarvm support? [15:13] I thought there were no more versions of windows? [15:14] *** zakharyas joined [15:16] 10.00000 recurring :-) [15:17] 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:18] ah [15:18] if none prior to 10 are supported, no worries then [15:18] *** raku-bridge joined [15:18] *** raku-bridge left [15:18] *** raku-bridge joined [15:19] 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 [15:21] Yeah, 7 is what I still have here [15:21] Windows 8.1 fell out of mainstream support in 2018 and will fall out of extended support in January 2023 [15:21] Though I don't develop on it much (pretty much only if I'm asked to go after a bug) [15:23] here's an answer: https://github.com/libuv/libuv/blob/master/SUPPORTED_PLATFORMS.md [15:23] nine: What's supported and what's used are different questions, alas :) [15:26] 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 [15:26] "thanks dudes. This product you're installing will itself go out of support in 2 years" [15:27] I suppose they're just gettings us ready for the IoS, er IoT [15:27] *** raku-bridge2 joined [15:27] *** raku-bridge2 left [15:27] *** raku-bridge2 joined [15:27] *** Geth__ joined [15:27] "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:28] (with a high carbon footprint and quite a few non ethically sourced rare metals) [15:32] *** Geth__ left [15:32] *** raku-bridge2 left [15:32] *** raku-bridge left [15:32] given the warning in this comment https://github.com/MoarVM/MoarVM/blame/master/src/6model/serialization.c#L2482-L2489 has the serialization format changed at all recently? [15:33] February 2020 [15:33] *** raku-bridge joined [15:34] *** raku-bridge left [15:35] https://github.com/MoarVM/MoarVM/commit/9709537d90d61529e519bb05a273680675bdbcaf#diff-dfe73d9a4d2ab1ec317d032b9c74220219869ea9f6352bbc850ebb597c75ffcb ? [15:37] <[Coke]> I do very occassional builds on win 10, haven't had any issues when tried. [15:37] i really don't know serialization well enough to know if that commit changes the sizes referenced in the comment [15:38] *** Geth__ joined [15:42] jnthn: ping re above question/comment [15:42] *** raku-bridge joined [15:42] *** raku-bridge left [15:42] *** raku-bridge joined [15:46] MasterDuke: I don't think the function the warning relates to deserializes closures [15:47] So I don't think it could have any impact [15:47] hm, the comment says "...if you change other parts of the serialization format..." [15:48] nwc10: pinging also since you wrote the warning [16:07] MasterDuke: actually, why do you ask? [16:09] i've seen some functions from that file in backtraces during my flailing about in rr [16:09] and then the comments here https://github.com/MoarVM/MoarVM/blame/master/src/6model/serialization.c#L2544-L2545 gave me pause [16:10] interestingly, i added a print if either of those calculate_int_bytes values was > 1_000_000 and it doesn't hit [16:11] *** raku-bridge left [16:11] *** sena_kun joined [16:11] oops, ha [16:11] *** Geth__ left [16:12] *** Altai-man left [16:13] * MasterDuke waves hand "pay no attention to the previous comment" [16:20] *** Geth_ joined [16:24] *** Geth_ left [16:30] 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:32] 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:33] 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:36] imagine if we all consistently wrote very good commit messages [16:36] (tbh nwc10 is light years ahead of me already) [16:48] word! [17:02] *** Geth left [17:13] <[Coke]> just did a win10 build, seems fine [17:21] https://github.com/MoarVM/MoarVM/pull/1385#issuecomment-730222698 [17:22] *** Geth___ left [17:23] *** Geth joined [17:23] *** raku-bridge joined [17:23] *** raku-bridge left [17:23] *** raku-bridge joined [17:26] *** raku-bridge left [17:27] *** raku-bridge joined [17:27] *** raku-bridge left [17:27] *** raku-bridge joined [17:30] *** raku-bridge left [17:30] *** Geth left [17:32] *** Geth joined [17:33] *** raku-bridge joined [17:33] *** raku-bridge left [17:33] *** raku-bridge joined [17:41] *** raku-bridge left [17:43] *** Geth_ joined [17:43] *** Geth left [17:43] *** raku-bridge joined [17:43] *** raku-bridge left [17:43] *** raku-bridge joined [17:44] *** Geth joined [17:45] *** Geth left [18:01] *** rypervenche left [18:11] *** rypervenche joined [18:56] *** zakharyas left [19:20] ¦ MoarVM/bigint_div_num-IEEE-rounding: 70cefcfffc | (Nicholas Clark)++ | src/math/bigintops.c [19:20] ¦ MoarVM/bigint_div_num-IEEE-rounding: Minimally exact bigint/bigint => num conversion, including rounding. [19:20] ¦ MoarVM/bigint_div_num-IEEE-rounding: [19:20] ¦ MoarVM/bigint_div_num-IEEE-rounding: Given that Rakudo parses decimal constants such as 0.01 as `Rat`s (ie [19:20] ¦ MoarVM/bigint_div_num-IEEE-rounding: represents them internally as (1 / 100), and persists with this exact [19:20] ¦ MoarVM/bigint_div_num-IEEE-rounding: representation as long as possible), this effectively means that the MoarVM [19:20] ¦ MoarVM/bigint_div_num-IEEE-rounding: operator that converts `Rat`s to `Num`s implements Rakudo's decimal => [19:20] ¦ MoarVM/bigint_div_num-IEEE-rounding: binary floating point conversion. [19:20] ¦ MoarVM/bigint_div_num-IEEE-rounding: <…commit message has 161 more lines…> [19:20] ¦ MoarVM/bigint_div_num-IEEE-rounding: review: https://github.com/MoarVM/MoarVM/commit/70cefcfffc [19:25] 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:41] lizmat: is there a (booby) prize for the longest commit message? [19:41] good question :-) [20:00] *** domidumont left [20:06] And is there also a price for longest commit message per actual character changed? I may be a contestant for that :) [20:07] I sometimes do quite well on those. [20:07] on that metric, that is [20:07] you can make a 1 character change [20:07] and then a long explanation of why [20:07] (justified explanation) [20:07] 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 [20:08] I have fixed this, and taken a different one (for now) [20:10] *** Altai-man joined [20:12] nwc10: could there possibly be a missing MVMROOT in (or around) https://github.com/MoarVM/MoarVM/blame/master/src/6model/reprs/MVMHash.c#L97-L119 ? [20:13] *** sena_kun left [20:20] 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:21] that's not "no" just "if there is one missing, I can't see why" [20:21] ok, that's kind of where i ended up too, but wanted a second opinion [20:22] "it got past code review - it must be perfect" [20:22] or [20:22] "it got past code review - it's SEP now :-)" [20:24] aargh, I'm getting flashbacks to pow(2, 32) being an odd number on Irix [20:25] https://gist.github.com/MasterDuke17/a175cb379647619b1ac9c2bef9671069 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] I hope that that other beer is cold (enough) [20:27] 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] MasterDuke: that's 2^32-1 which is MVM_DIRECT_SC_IDX_SENTINEL [20:27] ah [20:33] gist updated. is this where the problem object gets added to the worklist? [20:34] what did you set the watchpoint on? [20:36] 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:38] 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 [20:38] heh, well it wasn't the hash bind... [20:39] 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] and it wasn't the clone [20:39] It's unlikely to be some very common operation like hash binds. We'd be crashing all over the place [20:40] seems unlikely to be in decont either [20:41] 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:43] or find_meth... [21:16] *** zakharyas joined [21:31] if something calls MVM_gc_allocate_gen2_default_set(tc), then we don't need to worry about MVMROOTing? [21:39] Correct, because it can't trigger GC [21:40] thanks [21:44] re "But maybe the frequent GC runs would promote it to gen2 too quickly", is there a way to disable the gen2 promotion? [21:48] *** zakharyas left [21:56] Make the nursery bigger [21:56] That won't disable it, but it'll put it off much longer [21:56] Well, how much depending how big you make it [22:01] *** MasterDuke left [22:38] *** raku-bridge left [22:38] *** raku-bridge joined [22:38] *** raku-bridge left [22:38] *** raku-bridge joined [22:49] *** Altai-man left [23:47] doesn't the gc debug mode 3 also turn the time it takes to gen2 things a whole lot?