00:16 cognome_ joined 01:10 FROGGS_ joined 01:20 colomon_ joined 01:22 sergot joined 01:24 lizmat_ joined 01:50 colomon joined, pmichaud joined, tadzik joined
jnthn TimToady: The exception object constructed by MVM_exception_throw_adhoc does track the soruce of the exception; if something isn't printing the backtrace, then it's a problem higher up... 05:09
05:16 JimmyZ joined
JimmyZ good afternoon, jnthn :) 05:17
jnthn JimmyZ \o/ 05:20
JimmyZ: In answer to your question from a couple of days ago: I'm in Shenzhen. 05:21
JimmyZ: I think that's your part of the world too? :)
TimToady thought JimmyZ was somewhere near Beijing 05:22
JimmyZ yeah, I had been in Shenzhen for about 7 years, just leave there 4 months ago :P 05:23
jnthn Bah...when I was in Beijing you were in Shenzhen :P 05:24
JimmyZ never went to beijing 05:26
jnthn Given the air quality I encountered there, that's probaably a good thing for your life expectancy ;) 05:27
JimmyZ aye :P, my friends who went to beijing has got some cough for a long time :/ 05:28
05:48 JimmyZ_ joined 05:51 JimmyZ joined 06:56 itz joined 07:13 mj41 joined 08:13 JimmyZ_ joined
FROGGS I wonder why that happens: 08:20
Program received signal SIGBUS, Bus error.
MVM_bigint_neg at src/math/bigintops.c:382
382MVM_BIGINT_UNARY_OP(neg, { sb = -sa; })
jnthn Does it happen with JIT disabled? 08:22
jnthn wonders if that's one of the recently JITted bigint ops...
FROGGS jnthn: jit and spesh have no influence 08:23
jnthn Hm, ok. Then I've no idea. 08:24
FROGGS 386 if (MVM_BIGINT_IS_BIG(ba)) { 08:25
(gdb) p *ba
Cannot access memory at address 0x18000900000009
ahh! 08:26
it is the typo masak++ fixed (about s/-Inf/-Int/) 08:27
m: say -Int
camelia rakudo-moar d8c834: OUTPUTĀ«(signal )Ā»
jnthn oops
Missing definedness or nullness check I guess 08:28
Probably definedness
FROGGS yeah
08:35 brrt joined
brrt \o 08:35
FROGGS o/
dalek arVM: 9c670c9 | (Tobias Leich)++ | src/math/bigintops.c:
check for type object int bigint unary ops
 08:36
FROGGS m: say +Int 08:38
camelia rakudo-moar d8c834: OUTPUTĀ«use of uninitialized value of type Int in numeric context in block <unit> at /tmp/EA9LkXVy_y:1ā¤ā¤0ā¤Ā»
FROGGS that goes through .Numeric, while -Int does not
hmmm 08:39
ewww 08:42
08:42 JimmyZ_ joined 09:01 JimmyZ_ joined 09:19 FROGGS[mobile] joined
brrt curcode y u no work 09:28
oh, it has a deref 09:29
why does it have that
brrt suspices that this was copy-and-pasted somewhere 09:32
dalek arVM: b7987fa | (Bart Wiegmans)++ | src/ (4 files):
JIT getcodeobj

Was actually timotimo++'s patch, I included a fix for curcode which derefed *tc->cur_frame->code_ref, which isn't necessary.		 09:48
timotimo oops; not quite sure why i deref'd that 09:53
oh, was the incorrect jitting of curcode in the released moarvm?
ah 09:55
it wasn't
phew :)
nwc10 jnthn: paste.scsys.co.uk/420304 seems to be all that is needed to get NQP working on Power 09:58
but I'm not sure what commit message
timotimo now you're playing with power!
nwc10 other than something about it's a fix for c92d1a4cd5340d787ab5f8f42348573f99738c37
timotimo nwc10: but we use an MVM_OP_const_i64_16 in there 09:59
10:00 itz_ joined
timotimo maybe the GET_I16 macro is busted instead? 10:00
nwc10 timotimo: no, that fix is correct. Pretty confident on that. What needs to be i16 is *just* the instruction stream
the result_facts->value isn't in the instruction stream, and I'm inferring that it's still being read by other code which is unchanged 10:01
on little endian, it doesn't matter
timotimo oh!
that's a very good point
nwc10 on big endian, .i16 and .i64 are at different ends of the union 10:02
did take me a while to work it out
timotimo sorry about that :( 10:03
i was the one who introduced that
nwc10 no worries. what you did does look logical 10:05
quite possibly I would have made the same mistake
10:08 itz joined
jnthn nwc10: Thanks, will apply it in a bit. (got some other changes locally) 10:12
11:04 JimmyZ_ joined
dalek arVM: 8e5f59e | jonathan++ | / (15 files):
Add mechanism for objects to get a persistent ID.

If we move objects about over time, the object address is not a safe value to use as for ObjAt. Add a mechanism for objects to get an ID that lasts a lifetime. If the object is already in gen2, we use the memory address as before. If not, we pre-allocate a gen2 slot for it and use that.		 11:10
11:12 itz_ joined 11:15 JimmyZ_ joined 11:17 d4l3k_ joined 11:18 __rnddim__ joined 11:21 xiaomiao joined 11:22 hatsefla1s joined 11:26 gcifuent1s joined
dalek arVM: a5ae111 | jonathan++ | src/gc/ (2 files):
Ensure gen2 collect copes with ID pre-allocs.
 11:36
11:40 Juerd joined 11:42 itz joined 11:58 ilbot3 joined 12:00 moritz_ joined 12:01 ashleyde1 joined 12:02 tadzik2 joined, nebuchad` joined 12:03 gcifuent1s joined
nine Do I have to reinstall modules after recompiling MoarVM with --debug? 12:13
12:13 JimmyZ_ joined
jnthn Shouldn't 12:13
Provided you didn't also re-build NQP and Rakudo, of course.
nine jnthn: err...I probably did 12:14
12:15 JimmyZ__ joined 12:17 JimmyZ joined 12:21 JimmyZ_ joined 12:23 tadzik3 joined 12:27 JimmyZ_ joined 12:32 harrow joined 12:35 gcifuentes joined
nine I'm kind of stuck here. My tests call a method on a Perl 6 object from Perl 5 code and it works. It then calls the method again but MoarVM explodes with "Internal error: Unwound entire stack and missed handler" at the return statement in the called method. 12:41
12:42 d4l3k_ joined
timotimo callbacks and exceptions don't mix well, but exceptions also include things like returning 12:42
so if a callback registered from NativeCall ends up running an "inferior runloop" and an exception is thrown from there, it'll only unwind the "inferior runloop's" stack, or something like that 12:44
nine timotimo: but there shouldn't be any exception. I can run both calls indiviudally just fine. Only if I run both in the same test script it explodes. Order doesn't matter. 12:45
timotimo my understanding of the situation is just not-poor enough to pretend to know what goes wrong, but far too wrong to come up with a proper fix
12:45 itz_ joined
timotimo the worst thing is trying to gather/take across runloops 12:46
in that case ... not sure what's going wrong 12:47
nine The method I'm calling is just: method test(*@args) { return @args; }
The callback is: sub (Str $name, OpaquePointer $args) returns OpaquePointer { my @retvals = $value."$name"(|self!p5_array_to_p6_array($args)); return self.p6_to_p5(@retvals); CATCH { default { say $_; } } } 12:48
timotimo the optimizer will turn that into "test(*@args) { @args }" for you
hum. 12:49
masak the design of MoarVM has learned from that of Parrot, and tries really really hard not to have inferior runloops. 12:50
12:51 itz_ joined
JimmyZ_ does luajit and jvm have inferior runloops? 12:51
timotimo aye, nativecall callbacks is the only situation we apparently cannot get around
nine masak: do I see that correctly from the stack trace that MoarVM exits the runloop before calling into native code?
timotimo "the stack trace"? 12:52
nine timotimo: gist.github.com/niner/108939b4982119b146da
timotimo it looks like the stack isn't healthy 12:53
12:53 JimmyZ joined 13:08 ilbot3 joined
timotimo i'm glad to hear that! 13:10
also non-glad you've had to spend a long time hunting that down :(
nine timotimo: nothing compared to fixing all refcounting bugs in Inline::Python back then. Turned out that refcounting was handled wrongly in nearly every place. When I fixed it in one place, it broke in another. And I head to learn two slightly different refcounting systems (Python and Perl) at the same time. Compared to that this time it's trivial :) 13:12
timotimo oh 13:13
well, that's good then :)
nine That's also the reason why I'm reluctant to add any refcnt related code unless I really _know_ that it's needed and correct. 13:14
13:18 nebuchadnezzar joined 13:31 nebuchadnezzar joined 13:41 BinGOs joined 13:45 jlaire joined, nine joined, nwc10 joined 13:46 JimmyZ_ joined 13:51 masak joined 13:57 JimmyZ_ joined
nine Ok, until we have working destructors it just doesn't make sense to try having correct refcounts. So adding SvREFCNT_inc everywhere really is the way to go now. 14:16
dalek arVM: 5a0ecd6 | jimmy++ | src/ (8 files):
add const to MVMOpInfo type
 14:34
14:46 JimmyZ_ joined
dalek arVM: 5c71d91 | jimmy++ | src/core/bytecodedump.c:
slightly refactor, no functional changes
 14:46
14:49 cxreg2 joined 14:50 brother| joined 14:53 tokuhirom_ joined 14:55 oetiker joined, rurban joined 14:56 btyler joined, bcode joined 14:57 hoelzro joined 15:25 colomon joined
nwc10 jnthn: progress. Some combination of things, including possibly PEBKAC. Have yet to identify actual cause 16:10
16:11 kjs_ joined
nwc10 oh, that should be on #perl6. Re-splatting 16:12
FROGGS nine: you can make copies of P5 objects when you are not sure about refcounting 16:20
nine: because often you do not know how long something will live in P6 land
16:28 brrt joined
dalek arVM: 6542d36 | jimmy++ | / (2 files):
update update_ops.p6
 16:30
17:24 mj41 joined
FROGGS ==1925== Invalid write of size 8 17:25
==1925== at 0x4F774DD: MVM_fixed_size_alloc (fixedsizealloc.c:65)
17:35 kjs_ joined 17:46 FROGGS[mobile] joined 17:49 brrt left 17:52 colomon joined 18:13 kjs_ joined 18:29 bcode joined 18:51 zakharyas joined 19:38 dalek joined 21:22 zakharyas joined 21:41 ggoebel1111110 joined 22:35 danaj joined

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!