github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
MasterDuke anyone have an idea why the patch in gist.github.com/MasterDuke17/56cc2...3a0ee3458f would cause the error i get when compiling the core.d setting? 00:52
timotimo 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
it even outputs that error
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:55
MasterDuke hm, maybe it doesn't like $strict as a hash key if it hasn't been set 00:56
timotimo which of the green lines is line 39 inside Encoding/Builtin.pm6?
aye, give it False as a default value
MasterDuke `%!encoders{$!name}{$buf-type}{$strict} = $encoder;`
timotimo same for translate-nl perhaps
MasterDuke i don't use that as a key (yet) 00:57
timotimo OK 00:59
MasterDuke timotimo++ 01:00
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:02
timotimo no line number, eh? 01:04
MasterDuke nope, --ll-exception doesn't give a single extra line of info
timotimo can you catch it with CONTROL outside of your code? 01:05
MasterDuke 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 <unit> at -e line 1 MoarVM panic: Trying to unwind over wrong handler 01:06
whoops, that didn't paste nicely
timotimo you should be able to get at a stacktrace via that object
MasterDuke `if %!encoders{$!name}{$buf-type}{$strict}:exists {` 01:08
01:08 patrickb joined 01:27 lucasb left
MasterDuke 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:05
02:09 patrickb left
timotimo curious; that's without profiler turned on, right? so that's not giving overhead? 02:10
i wouldn't expect jitting from being prevented; what about inlining? could be the bigger encoder method makes inlining impossible? 02:11
MasterDuke without profiling correct. though i saw a similar slow down when profiling before/after 02:12
timotimo right
MasterDuke didn't look at a spesh log, will do that next 02:13
timotimo it's possible that in the future partial escape analysis might make the encoder objects not actually appear
that needs inlining to go a few levels deep, though
i'm going to bed RSN
i wish you the best of luck :)
MasterDuke also trying a smaller patch, it got as big and explicit as it was because i was trying to find that error
thanks, later... 02:14
timotimo the number of inlining-eliminated frames vs regularly used frames could be interesting for before/after 02:15
MasterDuke before: Inlining eliminated the need to create 2859271 call frames (that's 71.48%). 02:17
after: Inlining eliminated the need to create 3258326 call frames (that's 74.05%). 02:18
a smaller patch does seem less slower
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` 02:38
04:07 klapperl joined 07:19 domidumont joined
nine MasterDuke: why not really patch the module to use the Encoder API as intended? That did wonders for Inline::Perl5 07:54
07:59 robertle joined 10:01 brrt joined
brrt ohai #moarvm 10:01
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
MasterDuke nine: i don't know the Encoder API at all, but github.com/retupmoca/P6-Compress-Z...42e1b5dfff makes things faster 12:23
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, robertle joined 14:35 robertle left 15:49 robertle joined 16:05 robertle left 16:24 domidumont left
timotimo 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
MasterDuke timotimo: you think the binary format isn't being read properly? 21:38
timotimo that was one of my hypothesises 22:31
22:44 chansen__ joined 22:47 hoelzro_ joined 22:52 chansen_ left, chansen__ is now known as chansen_ 23:00 patrickz joined 23:03 patrickb left
timotimo oh my lord 23:24
i've made a rather silly mistake
in the binary format reader code 23:25
anyway, there remains a discrepancy that i can now hopefully figure out 23:27
a-ha! it was meaningless! 23:29
MasterDuke so there was a real problem? 23:32
timotimo yes, indeed 23:34
i was dropping entries on the ground
in the middle of the data
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
MasterDuke that does indeed sound like a problem
timotimo and sometimes errors of the "object with index foobar doesn't exist"
kind
nice. the refs file is also correct 23:39
i should have built this the first time around already 23:40
but no, i like living on the edge
MasterDuke easy fix? 23:42
timotimo yeah 23:43
absolutely
MasterDuke that's good
timotimo this entire time it was so easy :| 23:56
jnthn Hurrah, I get to set off to a workshop with all of my presentations prepared. :) 23:58
timotimo heck yeah :) :)
did you read, jnthn, i fixed the heap analyzer
it was a trivial problem
jnthn I always aim to do this. This is one of the times I was organized enough to pull it off. :) 23:59
timotimo because of course
well done, jnthn :)
jnthn timotimo: Trivial to solve, or trivial to find? :)
timotimo to solve
jnthn Ah...well, numerous bugs are like that... :)
timotimo it would have been trivial to find if i had just looked at the right lines of code for a little
as it is so often
jnthn hah, too right

Powered by Cro and the Raku® Programming Language.

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

Thank you!