github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
timotimo MasterDuke: so your feedback so far is: 1) customizable sorting, 2) link to user script, 3) a file picker would be cool, but there's a slight problem with that ... 00:08
timotimo the problem is: the file picker will submit the file as an upload 00:09
which the app will then either feed directly into the stdin of sqlite3 to throw it into /tmp as a sqlite3 file, or cat it into a file in /tmp and build the sqlite3 file from that
though there are in-memory databases
MasterDuke can you just get the path from the file picker? 00:11
timotimo that's not a thing that html+js allows, i don't think 00:12
MasterDuke also, i could see wanting to sort by time per entry
oh, huh
timotimo my grant proposal has "Sortable by every sensible column 00:13
" as one of the deliverables
MasterDuke cool
in the call graph, what does the darker blue mean? 00:14
timotimo the smaller one is exclusive time, the bigger one is exclusive time
i'll hopefully find colors for those that aren't extremely terrible 00:15
MasterDuke or maybe a hover-over?
timotimo you mean like tooltip text? 00:16
MasterDuke yeah 00:17
timotimo quite possible. though i'd love to have little questionmark icons that you could click to get big-but-friendly explanations for everything
MasterDuke yep
timotimo i imagine in the GC tab you'd have one next to the first row if it isn't 0 or 1 that tells you why the gc numbers would not start at 0 (because the compiler does stuff before the profiler turns on) 00:18
Geth MoarVM/master: 4 commits pushed by (Timo Paulssen)++ 00:50
timotimo for some reason there's nothing in jit/graph.c for sp_guardsfouter
i wonder if that's a problem at all; does it ever show up in BAIL messages?
MasterDuke think it's fine to merge github.com/MoarVM/MoarVM/pull/935 ? i get pastel warnings every time i compile moarvm 00:53
timotimo oh, we don't actually know if the other compilers are fine with this though? 00:55
because the build bots don't have --with-telemeh or --enable-telemeh or what it is in their configs?
MasterDuke hm. pretty sure i tried with clang, but i'll double check 00:59
timotimo can you also try on appveyor?
MasterDuke hm, the macro causes clang to warn 01:00
timotimo that sucks :( :( 01:01
MasterDuke but come only on stuff i added, it's used another place also
github.com/MoarVM/MoarVM/blob/mast...reprs.c#L5 01:02
i guess clang knows about the "return-type" warning group 01:03
this is what clang warns: `src/profiler/telemeh.c:206:1: warning: unknown warning group '-Wstringop-overflow', ignored [-Wunknown-warning-option]` 01:04
timotimo :\
MasterDuke `src/gcc_diag.h:15:27: note: expanded from macro 'GCC_DIAG_ON'`
timotimo temporarily turn unknown warning option off for that line :D
MasterDuke heh, i had the same thought
timotimo that'll b0rk on gcc :P
and who knows what will happen on msvc
travis-ci MoarVM build errored. Timo Paulssen 'silence compiler warning' 01:10
travis-ci.org/MoarVM/MoarVM/builds/414750946 github.com/MoarVM/MoarVM/compare/5...fc6c254f62
MasterDuke some people online are suggesting just adding -Wno-unknown-warning-option to the default clang compiler flags 01:12
travis-ci MoarVM build failed. Timo Paulssen 'silence compiler warning' 01:16
travis-ci.org/MoarVM/MoarVM/builds/414750946 github.com/MoarVM/MoarVM/compare/5...fc6c254f62
Geth MoarVM: b7ffccfa34 | (Timo Paulssen)++ | src/6model/containers.c
ensure returning NULL from these.
 01:20
timotimo if only C had optional arguments ... %) 01:35
timotimo goes sleep 01:52
timotimo writes some code to remove redundant guards 11:45
timotimo hum. of course it causes trouble 11:53
the flags in the source register are good for what it's telling me it's trying to do
but:
===SORRY!===
Parameter '$CWD' of routine 'new' must be an object instance of type 'Str', not a type object of type 'Str'. Did you forget a '.new'?
Geth MoarVM/eliminate_redundant_guards: e6e5be860a | (Timo Paulssen)++ | src/spesh/optimize.c
turn redundant sp_guard ops into set

unfortunately, this causes misbehaviour.
when correctness is fixed, the code can also turn guardconc into guardjustconc and guardtype into guardjusttype. that's just a SMOP		 12:06
timotimo don't have the brain right now to investigate, but here's the code so you can try it yourself
could just be that the facts are from logging, but aren't marked as such, or something.
i.e. the "from_log_guard" flag isn't set 12:07
nine What the? I've been trying for hours to get to the grounds on github.com/rakudo/rakudo/issues/2036 but it does get more mysterious all the time. 12:59
On the good side, I've managed to make it consistently work right until it gets speshed and more importantly JIT compiled and fail consistently afterwards running it with MVM_JIT_EXPR_DISABLE=1 MVM_SPESH_OSR_DISABLE=1 MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 MVM_SPESH_INLINE_DISABLE=1 13:00
That's with all actual spesh optimizations disabled, so it really looks like it's JIT compilation itself. 13:01
On the bad side, it still fails, even if I change it so the JIT compilation will generate the same code as run before optimization. 13:02
Oh, that could just be because the code would no longer be valid and accesses the wrong register which just leads to a similar looking failure. 13:03
diakopter dang, I should've followed my (mentioned) hunch about the lexical registry being accessed incorrectly 13:05
nine diakopter: better late than never ;) 13:15
diakopter nine: well I mean, jnthn fixed it, it seems 13:17
nine OMG I think I have it! 13:38
Geth MoarVM: 30781708ec | (Stefan Seifert)++ | src/jit/x64/emit.dasc
Fix JIT compiled getarg_* reading the wrong register

Code started out as a copy of sp_getarg_* but those get a literal as the number of the argument to read, not a register as getarg_* are supposed to do.
Fixes github.com/rakudo/rakudo/issues/2036		 13:58
jnthn nine++ # fixing stuff :) 14:15
timotimo oh, good catch 14:16
nine Would have been a lot easier to catch if my first test results would not have been so misleading 14:18
timotimo yeah, that happens when the jitted code misuses registers 14:18
travis-ci MoarVM build errored. Stefan Seifert 'Fix JIT compiled getarg_* reading the wrong register
travis-ci.org/MoarVM/MoarVM/builds/414872753 github.com/MoarVM/MoarVM/compare/b...781708ece1
Geth MoarVM: 62a99bcf44 | (Stefan Seifert)++ | 4 files
Fix segfaults in GC caused by sharing of jitcode in NativeCall repr

jitcode is a pointer to an MVMJitCode structure. When copying a NativeCall object, we may not just copy the pointer but have to make a copy of the whole structure. Otherwise GC'd free the same structure multiple times.
Many thanks to dogbert17++ for providing the ASAN printout that gave the essential hint!
Fixes GH #862		 14:47
travis-ci MoarVM build errored. Stefan Seifert 'Fix segfaults in GC caused by sharing of jitcode in NativeCall repr 15:06
travis-ci.org/MoarVM/MoarVM/builds/414882980 github.com/MoarVM/MoarVM/compare/3...a99bcf44d7
dogbert17 nine++, I wonder how many other reported nativecall issues you fixed there :) 15:10
dogbert17 also jnthn++, seems to have been on a bug fixing spree 15:10
dogbert17 I wonder if that latest commit managed to fix the pesky RT #131003 15:18
synopsebot RT#131003 [open]: rt.perl.org/Ticket/Display.html?id=131003 [SEVERE][SEGV] Heap corruption when using Gumbo
nine dogbert17: unfortunately not: MoarVM panic: Heap corruption detected: pointer 0x7f6d151f00f8 to past fromspace 16:03
timotimo i wonder what other ops could benefit from devirtualization in the jit ??? 16:09
MasterDuke timotimo: where did you find that env variable that might let valgrind run with my broken glibc? 16:23
timotimo i just searched for the error message 16:28
timotimo so, how do we build a tool that checks if memory regions deemed "exploitably constant" are accessed over and over and over 17:12
i.e. pointing out that perhaps the jit should have put something into the bytecode
MasterDuke huh, `MoarVM panic: Heap corruption detected: pointer 0x12008840 to past fromspace` when running under valgrind, but it didn't have anything to say about it 18:12
MasterDuke now this might be interesting. the same code after recompiling with --valgrind give this gist.github.com/MasterDuke17/b8e7e...585be64ac2 18:25
==31403== Process terminating with default action of signal 11 (SIGSEGV) ==31403== General Protection Fault 18:27
timotimo i mean, managed_size would be fine to replace with just "return 0" 19:08
it's non-essential
MasterDuke timotimo: you mean unmanaged_size? 19:20
AlexDaniel nine++ 19:53
timotimo yes 20:00
MasterDuke timotimo: so "calculating the non-GC-managed memory we hold on to" isn't important when compiled with --valgrind ? 21:13
timotimo well, it's certainly not a problem to just cut it out if it causes crashes 22:01
Geth MoarVM: 1e4b2c84d6 | (Jonathan Worthington)++ | src/core/interp.c
Correct first argument to MVM_panic
 22:15
timotimo i've made that mistake in the past 22:16
timotimo jnthn: there's a few times in this super random speshlog where two fastcreates are in a row, and some times where by just shuffling one or two instructions around, there could be three; do you think it'd be good to have "ensurenursery" and "sp_superfastcreate" ops for cases like that? 22:18
or maybe just an sp_fastcreate2 22:19
jnthn Maybe
I say the odd SEGV in make test at MoarVM HEAD :/ 22:20
jnthn And I'm quite sure they weren't there yesterday 22:20
timotimo make test, yeah?
jnthn Yeah
timotimo let's see 22:21
perhaps i made a bad thing
jnthn Did you test/spectest the spesh changes last night?
timotimo i ran spectests a bunch while i was doing the devirt change at least 22:21
jnthn spectest is a mess :S
timotimo i only had two flappers, both were stress.t files
at least i thought they were regular flappers, they didn't fail consistently 22:22
jnthn Building a commit from yesterday
jnthn make test is happy at 554fe425da5a6571 22:23
jnthn spectest running now 22:24
timotimo are you running with nodelay or spesh blocking or something? 22:30
i'm on master/master/master, 35k tests in and everything's green 22:31
jnthn I wsa just running `make spectest`, no flags or anything
timotimo t/spec/S17-supply/syntax.t ........................................ Dubious, test returned 1 (wstat 256, 0x100)
that's bad, yeah 22:32
jnthn I was getting failures all over the place
2 in make test, a bunch in make spectest
It's in my VM, which is slow and under some pressure
But otherwise unremarkable (Ubuntu 16.04) 22:33
timotimo even though the spectest is still running in the background, i can't get S17-supply/syntax.t to crash inside gdb-m 22:33
Unhandled exception in code scheduled on thread 9 22:34
Not enough positional arguments; needed at least 2
# Looks like you planned 83 tests, but ran 74
not a crash, OK
jnthn Yeah, I've seen that occasionally 22:35
timotimo but that was the only file that failed on my end
jnthn Hm, odd
Mine was a real mess
timotimo very odd indeed
jnthn The commit I mentioned looks pretty fine though
timotimo i don't feel so bad any more about having pushed those commits 22:37
but please feel free to revert my changes if they make it better on your end
travis-ci MoarVM build errored. Jonathan Worthington 'Correct first argument to MVM_panic' 22:37
travis-ci.org/MoarVM/MoarVM/builds/414975262 github.com/MoarVM/MoarVM/compare/6...4b2c84d619
timotimo BBL 22:43
lizmat wonders whether timotimo would have to say anything about www.reddit.com/r/perl6/comments/96...s/e3zvt9w/ 22:58
specifically to the "To my knowledge, perl6 doesn't have a debugger yet" bit :-) 22:59
dogbert17 spectest looks pretty good on my end as long as one avoids MVM_SPESH_BLOCKING and MVM_SPESH_NODELAY 23:29
if the flags are one there are plenty of fails, some being directly connected to github.com/MoarVM/MoarVM/issues/913 23:33
other are a bit more bizarre, e.g. MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 ./perl6 -c t/spec/S14-roles/attributes.t which doesn't even compile ! 23:34

Powered by Cro and the Raku® Programming Language.

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

Thank you!