[00:38] *** nativecallable6 left [00:38] *** statisfiable6 left [00:38] *** quotable6 left [00:38] *** tellable6 left [00:38] *** greppable6 left [00:38] *** bloatable6 left [00:38] *** releasable6 left [00:38] *** squashable6 left [00:38] *** benchable6 left [00:38] *** committable6 left [00:38] *** evalable6 left [00:38] *** sourceable6 left [00:38] *** linkable6 left [00:38] *** unicodable6 left [00:38] *** notable6 left [00:38] *** coverable6 left [00:38] *** reportable6 left [00:38] *** bisectable6 left [00:38] *** shareable6 left [00:38] *** shareable6 joined [00:39] *** benchable6 joined [00:39] *** statisfiable6 joined [00:39] *** greppable6 joined [00:39] *** nativecallable6 joined [00:40] *** sourceable6 joined [00:40] *** squashable6 joined [00:40] *** bisectable6 joined [00:40] *** bloatable6 joined [00:40] *** coverable6 joined [00:40] *** reportable6 joined [00:40] *** linkable6 joined [00:40] *** committable6 joined [00:40] *** unicodable6 joined [00:41] *** releasable6 joined [00:41] *** notable6 joined [00:41] *** tellable6 joined [00:41] *** evalable6 joined [00:41] *** quotable6 joined [02:35] *** releasable6 left [02:35] *** bloatable6 left [02:35] *** unicodable6 left [02:35] *** tellable6 left [02:35] *** nativecallable6 left [02:35] *** benchable6 left [02:35] *** evalable6 left [02:35] *** bisectable6 left [02:35] *** notable6 left [02:35] *** coverable6 left [02:35] *** statisfiable6 left [02:35] *** quotable6 left [02:35] *** sourceable6 left [02:35] *** linkable6 left [02:35] *** reportable6 left [02:35] *** committable6 left [02:35] *** shareable6 left [02:35] *** greppable6 left [02:35] *** squashable6 left [02:35] *** greppable6 joined [02:35] *** nativecallable6 joined [02:35] *** releasable6 joined [02:36] *** shareable6 joined [02:36] *** bisectable6 joined [02:36] *** notable6 joined [02:36] *** coverable6 joined [02:36] *** evalable6 joined [02:36] *** tellable6 joined [02:36] *** quotable6 joined [02:36] *** sourceable6 joined [02:37] *** committable6 joined [02:37] *** benchable6 joined [02:37] *** bloatable6 joined [02:37] *** reportable6 joined [02:37] *** statisfiable6 joined [02:37] *** squashable6 joined [02:38] *** unicodable6 joined [02:38] *** linkable6 joined [04:09] *** notable6 left [04:09] *** benchable6 left [04:09] *** linkable6 left [04:09] *** sourceable6 left [04:09] *** greppable6 left [04:09] *** quotable6 left [04:09] *** committable6 left [04:09] *** evalable6 left [04:09] *** shareable6 left [04:09] *** bisectable6 left [04:09] *** tellable6 left [04:09] *** bloatable6 left [04:09] *** unicodable6 left [04:09] *** reportable6 left [04:09] *** statisfiable6 left [04:09] *** nativecallable6 left [04:09] *** greppable6 joined [04:09] *** reportable6 joined [04:10] *** evalable6 joined [04:10] *** quotable6 joined [04:10] *** bisectable6 joined [04:11] *** shareable6 joined [04:11] *** nativecallable6 joined [04:11] *** statisfiable6 joined [04:11] *** sourceable6 joined [04:11] *** bloatable6 joined [04:11] *** notable6 joined [04:12] *** committable6 joined [04:12] *** linkable6 joined [04:12] *** tellable6 joined [04:12] *** benchable6 joined [04:12] *** unicodable6 joined [04:43] *** MasterDuke left [06:32] good *, #moarvm [06:33] good #moarvm, * [06:34] children dispatched to schools(s) [06:34] I wonder how many super-spreader events we get this morning... :-( [07:03] *** Altai-man joined [07:19] *** sena_kun joined [07:21] *** Altai-man left [07:34] *** zakharyas joined [08:33] *** brrt joined [08:40] good *, brrt [08:46] good * nwc10 [09:05] morning o/ [09:19] \o [09:19] *** Kaiepi left [09:21] *** Kaeipi joined [09:28] *** Kaeipi left [09:29] *** Kaiepi joined [10:06] *** Kaeipi joined [10:07] *** Kaiepi left [10:10] *** Kaeipi left [10:20] *** MasterDuke joined [11:06] *** brrt left [11:09] *** zakharyas left [11:18] *** Altai-man joined [11:20] *** sena_kun left [11:21] *** brrt joined [11:36] *** brrt left [12:16] *** domidumont joined [12:19] *** zakharyas joined [12:30] *** Kaeipi joined [12:59] nwc10: ugexe just posted on #raku-dev [12:59] m: say $*KERNEL.arch [12:59] rakudo-moar 85847d2f1: OUTPUT: «x86_64␤» [12:59] could that be of help? Should probably live in the config as well, I guess :-) [13:03] that shows up in the -V output. Seems that it can be more reliable than the value of $*VM.config.. (But still doesn't distinguish between 32 and 64 bit ABIs) [13:56] *** domidumont left [13:56] *** domidumont joined [14:01] *** domidumont left [14:20] ¦ MoarVM/sparc: 0772199939 | (Nicholas Clark)++ | src/6model/reprs/P6opaque.c [14:20] ¦ MoarVM/sparc: Correctly align object references (ie pointers) in P6opaque object bodies. [14:20] ¦ MoarVM/sparc: [14:20] ¦ MoarVM/sparc: Previously these were written at whatever offset the composer happened to be [14:20] ¦ MoarVM/sparc: at, which meant that some were only 4-byte aligned. On systems with 8-byte [14:20] ¦ MoarVM/sparc: pointers which care strictly about alignment, these leads to SIGBUS. [14:20] ¦ MoarVM/sparc: [14:20] ¦ MoarVM/sparc: This is sufficient to get MoarVM, NQP and most Rakudo tests working on [14:20] ¦ MoarVM/sparc: sparc64. [14:20] ¦ MoarVM/sparc: review: https://github.com/MoarVM/MoarVM/commit/0772199939 [14:20] With that we build on "4.19.0" [14:21] "4.9.0" is what my Raspberry Pi reports. Sometimes $*VM.config. is pretty much useless. [14:22] isn't that simply the kernel version? [14:23] mmm yes, possibly it is. And I guess that Fedora name their kernels as advertisments: 3.10.0-957.27.2.el7.ppc64 [14:26] My guess: that's kernel 3.10.0 with 957 distro patches, spec file version 27, build number 2, build target el7 and architecture ppc64 [14:26] 957 distro patches -- you're paying for something.... [14:27] Sounds realistic for security updates since the ancient version 3.10.0 [14:42] ¦ MoarVM: nwc10++ created pull request #1343: sparc64 support [14:42] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/1343 [14:42] hey, github auto-suggested you. I have no idea why :-) [15:19] *** sena_kun joined [15:20] *** Altai-man left [15:43] *** domidumont joined [15:49] Maybe because I've looked at the sparc32 commit before [15:49] it's stalking you [16:04] *** domidumont left [16:06] *** domidumont joined [16:14] <[Coke]> Reminder: Voting for RSC is open. [16:48] *** lizmat left [16:49] *** lizmat joined [16:50] *** zakharyas left [17:12] nwc10: I guess at least some of your test failures are due to an outdated rakudo [17:12] nwc10: remember that make spectest will do a git pull in t/spec before running those tests [17:17] yes but they only have the duration of the build, because usually I pull the lot just before I start [17:17] # Failed test 'sorting method list does not segfault' [17:18] There was a PR I merged over the weekend that changed our behavior here and we adapted the spec tests to it [17:27] The segfault in rakudo's build on P6opaque-debug boils down to: don't try to mix into a Scalar [17:28] *** brrt joined [18:01] Ok, this is definitely a bug: MVM_p6opaque_get_bigint_offset needs to bail if st->is_mixin_type [18:12] *** zakharyas joined [18:18] good * [18:39] *** domidumont left [19:18] *** Altai-man joined [19:20] *** sena_kun left [19:26] i'm getting errors because of `create_stub_boot_type(tc, MVM_REPR_ID_MVMSpeshCandidate, SpeshCandidate, 0, MVM_BOOL_MODE_NOT_TYPE_OBJECT);` and `meta_objectifier(tc, SpeshCandidate, "SpeshCandidate");`, but i just copied what had been done for MVMSpeshPluginState [19:26] 'error: ‘MVMInstance’ has no member named ‘SpeshCandidate’' [19:27] nine: shouldn't setting st->is_mixin_type = 1 in type_object_for in src/6model/reprs/P6opaque.c be enough to "force" the correct invariants that spesh and the JIT "know" about - that if body->replaced is non-NULL that flag also must be non-zero [19:27] meanwhile I am resting sparc64 and ppc64 with to-be-sure to-be-sure master [19:27] I think I am guilty of PEBKAC [19:40] if i comment out the create_stub_boot_type and meta_objectifier i added, instead i get `src/6model/reprs.c: In function ‘MVM_repr_initialize_registry’:src/6model/reprs.c:229:34: warning: implicit declaration of function ‘MVMSpeshCandidate_initialize’; did you mean ‘MVMSpeshPluginState_initialize’? [-Wimplicit-function-declaration] 229 [19:40] | const MVMREPROps *repr = MVM##name##_initialize(tc); \ | ^~~src/6model/reprs.c:291:5: note: in expansion of macro ‘register_core_repr’ 291 | register_core_repr(SpeshCandidate);` [19:41] ugh, that looked pretty when pasted [19:41] but i do have an `MVMSpeshCandidate_initialize` [19:43] nwc10: well that in MVM_p6opaque_get_bigint_offset is definitely a bug. sp_bool_I would blindly take that offset and add it to the object pointer, not caring about a replaced body. The easy solution is to not spesh a bool_I to sp_bool_I on mixins [19:44] my current diff https://gist.github.com/MasterDuke17/5541873da1f7ebfd201652d7a6d1ddda ... [19:45] oh yes. I see [19:45] return sizeof(MVMObject) + repr_data->attribute_offsets[slot]; [20:07] setting this flag (https://github.com/MoarVM/MoarVM/blob/master/src/core/frame.c#L7) to 1 and trying to build rakudo outputs a massive amount of messages like this: [20:07] Inconsistent spesh preselection of '!cursor_fail' (90): got 1, not 2 [20:07] at :1 (:) [20:07] from gen/moar/stage2/QRegex.nqp:2258 (/home/dogbert/repos/rakudo/install/share/nqp/lib/QRegex.moarvm:parse) [20:08] is it something to worry about? [20:11] MasterDuke: I don't see a change to instance.h; did you add a field there? [20:11] Or am I just missing that addition? [20:11] If not, that could be the issue [20:12] no. but i thought i looked and some other reprs didn't have a field [20:14] and i don't see why an instance would need a speshcandidate? [20:15] i may have just copied too much from the commit nine++ gave as inspiration https://github.com/MoarVM/MoarVM/commit/c61236f96e [20:15] ¦ MoarVM/P6opaque-debug: 45c1341aae | (Stefan Seifert)++ | src/6model/reprs/P6opaque.c [20:15] ¦ MoarVM/P6opaque-debug: Fix potential outdated reads and segfaults on mixed into bigints [20:15] ¦ MoarVM/P6opaque-debug: [20:15] ¦ MoarVM/P6opaque-debug: For mixin types the P6opaque's body is replaced, so we must not just take an [20:15] ¦ MoarVM/P6opaque-debug: offset and add it to the objects base address (like sp_bool_I does). Better [20:15] ¦ MoarVM/P6opaque-debug: leave those ops unspeshed. [20:15] ¦ MoarVM/P6opaque-debug: review: https://github.com/MoarVM/MoarVM/commit/45c1341aae [20:18] MasterDuke: It's to hold the type object, which you need in order to create an instance of it [20:18] ah ha! type objects [20:18] oh, jinx [20:19] i was looking at https://github.com/MoarVM/MoarVM/blob/master/src/core/instance.h#L290 and didn't think i needed something like that, not at something like https://github.com/MoarVM/MoarVM/blob/master/src/core/instance.h#L438 [20:23] nice. i still get the `warning: implicit declaration of function ‘MVMSpeshCandidate_initialize’`, but moarvm builds now [20:23] nqp does not [20:27] well, the warning was just because i forgot to add it to the .h [20:32] hm, is this still allowed now that i've made it a repr? https://github.com/MoarVM/MoarVM/blob/master/src/spesh/candidate.c#L167-L179 [20:45] Think it's OK; it looks like its a list of pointers to spesh candidates [20:46] And "all" that's changed is that the pointers are to GC-managed objects now [20:46] However, the second gen check/barrier below may become redundant [20:48] yeah, really wasn't sure about those. and i do create the new candidate that's added to the list via MVM_repr_alloc_init instead of calloc, so hopefully good there [20:48] the segfault in nqp is in the new gc_mark [20:49] *** Altai-man left [20:49] Well, if you're getting to the new GC mark that's at least something :) [20:50] `MVM_gc_worklist_add(tc, worklist, &(candidate->inlines[i]));` how do i know that the `void *data` passed to gc_mark is the/a MVMSpeshCandidateBody instead of a/the MVMSpeshCandidate? [20:51] Well, not sure you can by inspection, but that's what the gc_mark always gets passed [20:52] That line looks dubious to me, though [20:52] oh? [20:52] I think that points to an MVMSpeshInline [20:52] Which includes some GC-able things to mark, but is not itself a GC-able thing [20:52] (And doesn't need to be) [20:53] ha. i adapted it from https://gist.github.com/MasterDuke17/5541873da1f7ebfd201652d7a6d1ddda#file-mvmspeshcandidate-patch-L133 but it looks like i lost the trailing `.sf` [20:54] It should be...yes, exactly :-) [20:54] I was just finding that to point you at :) [20:55] new segv in unmanaged_size. how accurate does that have to be? [20:56] oh, guess there won't always be a jitcode, can't just blindly dereference its size [21:00] *** zakharyas left [21:02] heh. `Try to enter NULL jitcode`, yeah that might cause a problem [21:15] how did that happen [21:15] and another Rakudo Weekly News hits the Net: https://rakudoweekly.blog/2020/09/07/2020-36-election-time-again/ [21:16] brrt: i think i've missed a few places where i need to change `spesh_candidate->jitcode` to `spesh_candidate->body.jitcode` [21:21] *** Kaeipi left [21:22] ah [21:22] lizmat++ [21:28] *** Kaiepi joined [21:29] *** brrt left [21:56] *** pamplemousse joined [22:07] *** pamplemousse left [22:10] *** pamplemousse joined [22:24] *** pamplemousse left [22:28] would this still be correct after my change? https://github.com/MoarVM/MoarVM/blob/master/src/jit/x64/emit.dasc#L3560-L3567 [22:50] ¦ MoarVM: MasterDuke17++ created pull request #1344: WIP convert MVMSpeshCandidate to a REPR [22:50] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/1344 [23:00] *** leont left [23:00] ^^^ so people can easily see the current diff [23:00] off to sleep [23:23] *** lizmat left [23:23] *** lizmat joined