[00:52] anyone have an idea why the patch in https://gist.github.com/MasterDuke17/56cc26586f0bb3aa5070ed3a0ee3458f would cause the error i get when compiling the core.d setting? [00:54] looks like you're hoping to $output-thing.say(something), but instead of $output-thing you're getting a failure, perhaps from looking up a dynamic variable that doesn't exist? [00:54] oh [00:54] it even outputs that error [00:55] OK, so it's trying to bind a key and that's causing a warning, and it looks like it's trying to .Str a Mu perhaps or an undefined value in general [00:56] hm, maybe it doesn't like $strict as a hash key if it hasn't been set [00:56] which of the green lines is line 39 inside Encoding/Builtin.pm6? [00:56] aye, give it False as a default value [00:56] `%!encoders{$!name}{$buf-type}{$strict} = $encoder;` [00:56] same for translate-nl perhaps [00:57] i don't use that as a key (yet) [00:59] OK [01:00] timotimo++ [01:02] huh. now it builds, but i get two `Use of uninitialized value of type Any in string context. Methods .^name, .perl, .gist, or .say can be used to stringify it to something meaningful.` when running `perl6 -e 'my $b = "foobar".encode; say $b'` [01:04] no line number, eh? [01:04] nope, --ll-exception doesn't give a single extra line of info [01:05] can you catch it with CONTROL outside of your code? [01:06] CX::Warn.new(message => "Use of uninitialized value of type Any in string context.\nMethods .^name, .perl, .gist, or .say can be used to stringify it to something meaningful.") Use of uninitialized value of type Any in string context. Methods .^name, .perl, .gist, or .say can be used to stringify it to something meaningful. in block at -e line 1 MoarVM panic: Trying to unwind over wrong handler [01:06] whoops, that didn't paste nicely [01:06] you should be able to get at a stacktrace via that object [01:08] `if %!encoders{$!name}{$buf-type}{$strict}:exists {` [01:08] *** patrickb joined [01:27] *** lucasb left [02:05] hm, for `my $a; for ^100_000 { my $b = "foobar".encode; $a = $b.decode; }; say $a; say now - INIT now`, my patch removes those 100k Encoding::Encoder::Builtin allocations, but it's time increases from ~0.75s to ~0.95s [02:09] *** patrickb left [02:10] curious; that's without profiler turned on, right? so that's not giving overhead? [02:11] i wouldn't expect jitting from being prevented; what about inlining? could be the bigger encoder method makes inlining impossible? [02:12] without profiling correct. though i saw a similar slow down when profiling before/after [02:12] right [02:13] didn't look at a spesh log, will do that next [02:13] it's possible that in the future partial escape analysis might make the encoder objects not actually appear [02:13] that needs inlining to go a few levels deep, though [02:13] i'm going to bed RSN [02:13] i wish you the best of luck :) [02:13] also trying a smaller patch, it got as big and explicit as it was because i was trying to find that error [02:14] thanks, later... [02:15] the number of inlining-eliminated frames vs regularly used frames could be interesting for before/after [02:17] before: Inlining eliminated the need to create 2859271 call frames (that's 71.48%). [02:18] after: Inlining eliminated the need to create 3258326 call frames (that's 74.05%). [02:18] a smaller patch does seem less slower [02:38] timotimo: i'm terrible at reading spesh logs, but a relevant piece of info is that both say `sp_fastinvoke_o r14(10), r22(5), liti16(0) # could not inline 'encoder' (4018) candidate 0: bytecode is too large to inline` [04:07] *** klapperl joined [07:19] *** domidumont joined [07:54] MasterDuke: why not really patch the module to use the Encoder API as intended? That did wonders for Inline::Perl5 [07:59] *** robertle joined [10:01] *** brrt joined [10:01] ohai #moarvm [10:03] I'm thinking again about reducing all variants of conditionals to COND [10:03] that's nicely LISPY, and more importantly, it's easy to analyze [10:32] *** robertle left [10:48] *** brrt left [11:16] *** domidumont left [11:44] *** robertle joined [12:23] nine: i don't know the Encoder API at all, but https://github.com/retupmoca/P6-Compress-Zlib/pull/19/commits/a1ed2e572d4937f1d02cb4007c7e7a42e1b5dfff makes things faster [13:00] *** domidumont joined [13:14] *** domidumont left [13:16] *** domidumont joined [13:19] *** lucasb joined [13:30] *** robertle left [13:32] *** robertle joined [13:45] *** robertle left [14:01] *** robertle joined [14:20] *** robertle left [14:20] *** robertle joined [14:35] *** robertle left [15:49] *** robertle joined [16:05] *** robertle left [16:24] *** domidumont left [18:52] i've taken the first step towards being able to verify whether or not my binary format for the heap snapshot analyzer is being read properly: writing out the data in a super-simple format from moar, then writing the same format after parsing and comparing the files [18:52] i've only got the "moar writes the simple format" part done, but it shouldn't be that hard to get the next step done [19:15] *** patrickb joined [21:38] timotimo: you think the binary format isn't being read properly? [22:31] that was one of my hypothesises [22:44] *** chansen__ joined [22:47] *** hoelzro_ joined [22:52] *** chansen_ left [22:52] *** chansen__ is now known as chansen_ [23:00] *** patrickz joined [23:03] *** patrickb left [23:24] oh my lord [23:24] i've made a rather silly mistake [23:25] in the binary format reader code [23:27] anyway, there remains a discrepancy that i can now hopefully figure out [23:29] a-ha! it was meaningless! [23:32] so there was a real problem? [23:34] yes, indeed [23:34] i was dropping entries on the ground [23:34] in the middle of the data [23:35] that caused about half of all collectables to be rather bogus [23:35] so you'd have connections between objects that just made no sense at all [23:35] that does indeed sound like a problem [23:35] and sometimes errors of the "object with index foobar doesn't exist" [23:35] kind [23:39] nice. the refs file is also correct [23:40] i should have built this the first time around already [23:40] but no, i like living on the edge [23:42] easy fix? [23:43] yeah [23:43] absolutely [23:43] that's good [23:56] this entire time it was so easy :| [23:58] Hurrah, I get to set off to a workshop with all of my presentations prepared. :) [23:58] heck yeah :) :) [23:58] did you read, jnthn, i fixed the heap analyzer [23:58] it was a trivial problem [23:59] I always aim to do this. This is one of the times I was organized enough to pull it off. :) [23:59] because of course [23:59] well done, jnthn :) [23:59] timotimo: Trivial to solve, or trivial to find? :) [23:59] to solve [23:59] Ah...well, numerous bugs are like that... :) [23:59] it would have been trivial to find if i had just looked at the right lines of code for a little [23:59] as it is so often [23:59] hah, too right