00:55 AlexDaniel joined 01:58 ilbot3 joined 03:26 AlexDaniel joined 04:10 releasable6 joined, undersightable6 joined, shareable6 joined 04:12 lizmat joined 04:38 Kaiepi joined 05:25 AlexDaniel joined 06:00 domidumont joined 06:07 domidumont joined 06:34 robertle joined 06:51 domidumont joined 06:59 brrt joined 07:11 live_the_dream joined 07:13 lizmat joined 07:26 lizmat joined
brrt good * 07:53
08:11 zakharyas joined 08:23 zakharyas joined
timotimo hey brrt 08:52
brrt hey timotimo 08:53
jnthn o/ all
timotimo ohai jnthn
i was a bit late today, but liz spoke a bit longer so i got to see wendy's "the changing image of perl" talk, which i enjoyed 08:54
jnthn ah, cool
We made breakfast and I'm currently hiding away ahead of my talk :)
I actually slept ok last night so feel a tad better today
timotimo and i'm considering just giving a second lightning talk today, this time showing off a program that attaches to itself via the debugger
that's good! 08:55
brrt ohai jnthn
jnthn hi brrt 08:56
timotimo i don't yet have an idea what the program should actually do with the debugging interface 08:58
i mean, i can't come up with a sensible use for this, but this is really more of a "it's possible so why not do it" kind of thing 08:59
brrt what debuggging interface is that? 09:00
timotimo the one jnthn just recently unveiled on his blog :)
brrt If i have time somewhere today, I want to introduce the patches to limit spesh log noisyness to a frame-of-interest
timotimo you attach to moarvm with a tcp socket that speaks a simple messagepack based protocol
brrt oh, that one :-) 09:01
okay, which program then :-)
(y'know what we ought to have, a source language server for perl6)
timotimo i think i'll start by attaching the debugger to another debugger session
and then in the next step forego the debugger itself and just attach a program to itself using the library 09:03
jnthn timotimo: One other thing you could do is show how to build some other tool using the library
Like a "count how many times X is called" or something
timotimo oh 09:04
yeah, that'd be simple
jnthn Well, it's nice in that it shows people that we have an API for doing such things. :) 09:05
And you could then as a joke at the end show how that debugger-using tool can itself be debugged :)
jnthn wanders to the venue 09:32
09:41 lizmat joined 10:05 lizmat joined 10:09 zakharyas joined 10:21 AlexDaniel joined 10:50 lizmat joined 12:02 lizmat joined 12:48 zakharyas joined 12:59 zakharyas joined 13:04 domidumont joined
Geth MoarVM: d44fa8941e | gerd++ (committed by Timo Paulssen) | src/core/validation.c
Fix loading bytecode on big endian systems

We used to check the value before it got endian-switched by validate_operand. Move the check after the switch and fix the offset to match.		 14:19
timotimo gerd++ a couple of times
robertle timotimo: do you think the symptoms of the bug that fixes would be consistent, or would that only manifest every now and then? 14:30
14:34 lizmat joined 14:38 live_the_dream joined, travis-ci joined
travis-ci MoarVM build passed. gerd 'Fix loading bytecode on big endian systems 14:38
travis-ci.org/MoarVM/MoarVM/builds/363132005 github.com/MoarVM/MoarVM/compare/d...4fa8941e62
14:38 travis-ci left 15:22 zakharyas joined 15:23 zakharyas joined 15:56 brrt joined
timotimo .tell robertle do you mean the endian swap bug? that pretty much manifests as a crash very early in the nqp build and 100% consistent 16:05
yoleaux timotimo: I'll pass your message to robertle.
16:12 zakharyas joined 16:16 zakharyas joined 16:17 robertle joined
timotimo jnthn: ping? :) 16:25
16:56 AlexDaniel joined 17:05 zakharyas joined
dogbert17 brrt: you there? 17:24
.tell brrt please take a look at github.com/MoarVM/MoarVM/issues/837 if you have a minute 17:26
yoleaux dogbert17: I'll pass your message to brrt.
nwc10 good *, #moarvm 17:30
I've not built with the FSA debug enabled for a while
turns out that it's making ASAN quite exited: paste.scsys.co.uk/576714
I have no idea if this is a bug in the DEBUG, or a real bug that it's exposing 17:31
and don't have time to dig further as the flight will start boarding "RSN"
17:35 domidumont joined 19:35 brrt joined, zakharyas joined
brrt . 19:37
yoleaux 17:26Z <dogbert17> brrt: please take a look at github.com/MoarVM/MoarVM/issues/837 if you have a minute
19:38 zakharyas joined
brrt yeah, seen it, not able to replicate it yet 19:39
there's also the CSV issue 19:40
it's odd, and flappy 19:52
the CSV issue is not, fortunatley
.ask samcv if that issue is more frequent with larger files 19:55
yoleaux brrt: I'll pass your message to samcv.
samcv brrt: what system are you on?
yoleaux 19:55Z <brrt> samcv: if that issue is more frequent with larger files
brrt fedora linux, recent everything, x86-64 19:56
samcv i can get it to happen about 1/3 tries
brrt hmm, 1/20 for me, at best 19:58
samcv maybe 1/5
brrt are you using clang?
samcv putting the code in a loop doesn't make it happen faster
brrt hmmpf
samcv uh i think i'm using clang. but i tried with gcc and it happens too
brrt that's the worst case scenario really 19:59
samcv though removing code from it causes it to happen much less often
i tried to golf it
though actually let me try it again maybe 20:00
brrt it would be very helpful 20:03
samcv it seems the split and join are important
even if there's nothing actually in the array, if i take the split out or the join out it stops the error 20:04
will work on it a bit and let you know what i find
brrt tux's CSV segv has been with us for some time at least
... bisecting moarvm is fruitless 20:06
samcv $file.IO.lines does it about 8x more often than $file.IO.slurp.lines 20:07
brrt ok, that leaves us with analyzing the thing from first principles
hmmm
oh, that's the variant i have
samcv dunno if this means anything, but if instead sc_find_object (i think is the name) returns NULL instead of throwing, the script works fine 20:09
brrt oh 20:10
hmmm
shit
if you only set MVM_JIT_DISABLE=1, how does it fare then? 20:11
and with only MVM_SPESH_INLINE_DISABLE=1
samcv jit disable it doesn't throw
inline disable it's fine
if i use nqp::split instead of split it doesn't throw 20:15
though i mean the problem is in resolving something in CORE.setting so i guess that makes sense 20:16
brrt so, i can't parse the above completely accurately; 20:18
MVM_JIT_DISABLE - works, or breaks?
samcv MVM_JIT_DISABLE causes it to work fine 20:19
brrt MVM_SPESH_INLINE_DISABLE=1, works, or breaks?
damn
samcv works
brrt hmmm
samcv but without any flags it breaks
brrt yeah
i know enough, i think
well, i know more
samcv dunno if relevant but if running with asan, it has no leaks most of the time. but then will have a leak in spesh 20:20
about as often as it normally fails
that could be important?
brrt no, that's not important 20:35
if the spesh worker thread is running, it will be shutdown, and whatever it was holding on to will be considered a leak by asan 20:36
it's a known issue
anyway, i'm off to bed now 20:38
20:41 Kaiepi joined
timotimo .tell brrt don't worry about the "potential version skew detected" bug, it's entirely my fault and there'll be a fantastic patch that'll make everything nicer tomorrow or so 22:05
yoleaux timotimo: I'll pass your message to brrt.
samcv timotimo: you figured it out? 22:06
timotimo no, jnthn came up with a way that lets us get rid fo the whole situation entirely 22:08
while at the same time keeping more stuff unserialized
samcv oh nice!
timotimo i.e. not only wvals, but also strings, callsites, and code refs 22:10
not sure how often this will actually trigger, but it's also cleaner in general

Powered by Cro and the Raku® Programming Language.

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

Thank you!