[00:55] *** Kaeipi joined [00:56] *** Kaeipi left [01:38] *** lucasb left [01:44] *** leont_ left [04:26] *** Kaiepi joined [06:33] *** sena_kun joined [08:11] *** Altai-man joined [08:13] *** sena_kun left [09:39] ¦ MoarVM: b8653caec1 | (Stefan Seifert)++ | 3 files [09:39] ¦ MoarVM: Turn gen2 default allocation off on (de)serialization failures [09:39] ¦ MoarVM: [09:39] ¦ MoarVM: This allows for a more graceful recovery of serialization errors. [09:39] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/b8653caec1 [09:41] ¦ MoarVM: a6118ff229 | (Stefan Seifert)++ | src/strings/utf8.c [09:41] ¦ MoarVM: New debug helper: MVM_dump_string [09:41] ¦ MoarVM: [09:41] ¦ MoarVM: A debug build now contains the MVM_dump_string(tc, string) function which [09:41] ¦ MoarVM: prints the given MVMString to STDERR. Useful e.g. in gdb sessions. [09:41] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/a6118ff229 [09:42] * nine got fed up of typing MVM_string_utf8_maybe_encode_C_string [09:46] ¦ MoarVM/precomp-singleprocess-endgame: f530a56aba | (Stefan Seifert)++ | 14 files [09:46] ¦ MoarVM/precomp-singleprocess-endgame: WIP [09:46] ¦ MoarVM/precomp-singleprocess-endgame: review: https://github.com/MoarVM/MoarVM/commit/f530a56aba [09:47] *** MasterDuke joined [09:50] . [09:50] 2020-11-27T22:14:22Z #moarvm MasterDuke But you can defer the alignment and just make it work at all first; it won't be a big change [09:50] hey MasterDuke, you have a message: https://gist.github.com/fb91d1189e9f326227111bea3cfdee7d [09:52] hm, it seems to work for a trivial example https://godbolt.org/z/Ys7168 [10:13] oh, but a slightly better example segvs https://godbolt.org/z/aYeGE6 [10:48] MasterDuke: as it must [10:49] sa->d is uninitialized, yet you dereference it in sa->d.s[0] = ... [10:51] yeah. so i'm not sure how to alloc this construct (struct of members plus dynamic array at end) as one piece [10:51] but afk for a bit& [10:51] the allocation is correct, usage is not [10:57] Anyway I think what jnthn meant was more in the lines of: struct h { int b; int c }; struct a { struct h h; union { char *s; int i; } d; }; struct a *sa = malloc(sizeof(struct h) + 2 * sizeof(char *)); [11:05] *** domidumont joined [11:16] *** domidumont1 joined [11:18] *** domidumont left [12:12] *** sena_kun joined [12:14] *** Altai-man left [12:25] *** raku-bridge joined [12:25] *** raku-bridge left [12:25] *** raku-bridge joined [12:41] *** leont_ joined [12:58] nine: did that too, same result [13:03] https://godbolt.org/z/v17qhY [13:04] ah, thanks [13:05] nine++ oO(he hasn't evolved to a ten yet?) [13:07] .oO(Forever nine! I want to be, forever nine) [13:19] he's just a nine out of nine [13:34] any benefit to putting the metadata (three MVMuint64s) in a struct vs leaving them as is? [13:41] makes code to access it a little less annoying? [13:46] *** lucasb joined [13:49] there's another level then. `body->ssize` vs `body->meta.ssize`, right? [14:02] isn't there a syntax in one of the newer C standards that lets you put a variable-size array at the end of a struct? [14:05] i think just `foo[]` for the member [14:05] but i wasn't sure how to do that with our union [14:06] ¦ MoarVM/master: 20 commits pushed by (Nicholas Clark)++ [14:06] ¦ MoarVM/master: review: https://github.com/MoarVM/MoarVM/compare/a6118ff229c8...1c7358004301 [14:06] i would assume you can array the union, perhaps array each entry [14:07] ¦ MoarVM/hash-bits-in-metadata: 24 commits pushed by (Nicholas Clark)++ [14:07] ¦ MoarVM/hash-bits-in-metadata: review: https://github.com/MoarVM/MoarVM/compare/0641ce8402f2...fecfad19173a [14:52] *** leont_ is now known as leont [15:00] *** domidumont joined [15:03] *** domidumont1 left [15:16] *** domidumont1 joined [15:16] *** domidumont left [15:37] *** leont left [15:39] *** leont joined [15:49] *** leont left [15:52] *** leont joined [16:00] *** leont left [16:03] *** leont joined [16:11] *** Altai-man joined [16:13] *** sena_kun left [16:48] *** leont left [17:05] *** leont joined [17:22] *** leont left [17:32] *** leont joined [17:40] *** leont left [17:40] *** leont joined [18:21] *** leont left [18:21] *** leont_ joined [18:46] *** zakharyas joined [18:49] *** domidumont1 left [19:01] *** leont_ left [19:02] *** leont_ joined [19:05] *** leont_ left [19:05] *** leont_ joined [19:49] why is `value->i64 = (MVMint64)*(&(body->slots.i8) + body->start + real_index);` ok, but `value->n64 = (MVMnum64)*(&(body->slots.n64) + body->start + real_index);` gives 'error: pointer value used where a floating-point was expected'? [19:51] I think that the first one is compiling without warning because you are actually casting from a pointer to an integer [19:51] and the seond one is casting from a pointer to floating point [19:51] and I think that you have missed a * in each [19:52] I think you wanted something more like [19:52] value->i64 = *(MVMint64 *)(&(body->slots.i8) + body->start + real_index); [19:52] value->n64 = *(MVMnum64 *)(&(body->slots.n64) + body->start + real_index); [19:53] but I question why the firstis slots.i8 [19:53] but the secnod slots.n64 [19:53] when you're deferencing as something different in the first [19:54] that bit (*->64 = *.i8) is unchanged from the original code [19:55] but thanks, you've fixed it for me [20:12] *** sena_kun joined [20:14] *** Altai-man left [20:45] *** patrickb joined [22:44] *** zakharyas left [22:55] *** ChanServ left [23:01] *** ChanServ joined [23:01] *** tepper.freenode.net sets mode: +o ChanServ [23:32] *** patrickb left [23:54] *** sena_kun left [23:54] *** sena_kun joined [23:58] *** sena_kun left