01:10 TimToady joined 01:48 ilbot3 joined 02:02 MasterDuke joined
MasterDuke how do i get printf statements in moarvm code to show up when running nqp-m? 02:05
07:15 cognominal joined 08:10 domidumont joined 08:12 rurban_ joined 08:15 domidumont joined 09:01 cognominal joined 09:21 camelia joined 10:01 FROGGS joined
jnthn MasterDuke: Shouldn't have to do anything special, except make sure you're doing "make install" and that it's installing over the MoarVM NQP was built against. 10:15
FROGGS o/ 10:17
jnthn hi FROGGS :) 10:22
Nice to see you about again :)
FROGGS aye :o)
nice to have some time to be here again :o)
jnthn :-)
FROGGS I even wrote some perl 6 the other day *g* 10:23
jnthn Lucky. My current Perl 6 related tasks need me to write C and Java :P 10:25
FROGGS eww
well, C is fun at least 10:26
jnthn Yeah, I don't mind C :)
FROGGS at work I often port php stuff to p5 these days...
making me wonder how some parts of the old code could have actually worked 10:27
I mean, I wrote that php code about ten years ago :o)
nwc10 poor FROGGS - might have to do a talk about Perl 5 soon :-)
FROGGS hehe
jnthn When I look at code I wrote long ago, I at least take comfort I learned something since writing it. :-) 10:34
FROGGS ohh yes
would be odd to look at a decade old code and being happy with it 10:35
dalek arVM: ef3a804 | jnthn++ | src/core/ (5 files):
Allow HLL handler for unhandled lexical exception.
 11:06
MasterDuke jnthn: i see the print output when "make install"ing nqp, but then not when i actually run nqp-m 11:08
jnthn Then it's not being hit or you're running the wrong thing I guess... 11:09
MasterDuke if i stick in a MVM_exception_throw_adhoc i get output, but that's an unwieldy debug method
jnthn Or the output is being redirected somewhere
I guess it's also possible that there's some weird things going on because all actual program output goes via libuv. Could try adding a flush 11:10
Though it'd be odd in that I've not run into issues like that and I use logging printfs plenty while debugging
MasterDuke i thought about a flush, but haven't seriously written C in a while and was under the impression that having "\n" in my output would trigger that (and also the program exiting) 11:12
FROGGS I usually do fprintf(stderr, ...)
because stdout might be redirected into precomp files 11:13
(sorry if I talk rubbish, I didnt catch the entire discussion)
MasterDuke yeah, tried that too, think it had the same behavior 11:14
jnthn Yeah, stderr is safter if you're doing a build
Argh, what... Some tests I thought I'd fixed up involving lexical handlers for return are failing again due to inlining :/ 11:16
Ah, phew, I busted it in a silly way 11:17
MasterDuke what's odd is that a printf in ascii.c works all the time, but the printf in coerce.c only during the build 11:19
dalek arVM: 4a40a01 | jnthn++ | src/core/exceptions.c:
Fix lexical inlined handler regression.

We used to tweak the mode; now we just fall through, so pass the mode we really want.
jnthn spectests again :) 11:20
But fingers crossed the return improvements will be clean on MoarVM now
lizmat hopes jnthn will see a TODO pass :) 11:22
jnthn Oh?
We'll see
lizmat github.com/perl6/roast/commit/834afc7a26 11:23
jnthn Ah, yeah 11:24
Hopefully :)
jnthn runs it manually 11:25
Fails 11:26
expected 948, got 984
11:26 cognominal joined
jnthn Curious. 11:26
Huh, and if I take the test out of the larger test file it doesn't fail 11:30
lizmat yeah, I also found that if you put that code in a block, it doesn't fail either 11:31
jnthn Ah, I can make it fail by upping the iteration count 11:32
lizmat m: sub bar() { foo; return 6 }; sub foo() { return 42 }; my $a; for ^158 { $a += bar }; say $a
camelia rakudo-moar 926f1d: OUTPUT«984␤»
lizmat m: { sub bar() { foo; return 6 }; sub foo() { return 42 }; my $a; for ^158 { $a += bar }; say $a } 11:33
camelia rakudo-moar 926f1d: OUTPUT«948␤»
jnthn Oh, duh... 11:36
Inlining `return` by rewriting throwpayloadlexcaller into throwpayloadlex ain't going to work...'cus it'll run straight into the inlined handler 11:37
FROGGS MasterDuke: when you see output during build and not during runtime, then maybe that code path is not taken at runtime? 11:41
MasterDuke except when i replace the print with MVM_exception_throw_adhoc (and add a conditional so it doesn't hit the exception during build) the exception gets thrown 11:44
FROGGS .oO( Boy look straight! You're about to run into the inlined handler! )
weird 11:45
jnthn Guess I'll ponder the best way to fix this over lunch... :) bbl 11:46
MasterDuke yeah, it's been interesting trying to figure out what's going on 11:47
i like Perl[5,6] much better than C 11:48
11:49 travis-ci joined
travis-ci MoarVM build errored. Jonathan Worthington 'Fix lexical inlined handler regression. 11:49
travis-ci.org/MoarVM/MoarVM/builds/136905575 github.com/MoarVM/MoarVM/compare/e...40a0107b19
11:49 travis-ci left
MasterDuke actually, another question, how do i print a MVMString? '%s' in *printf doesn't seem to do it 11:50
nm, MVM_string_utf8_encode_C_string seems to do the trick 12:00
jnthn That's th eone 12:29
*the one
I've pondered the inlining thing enough over lunch to realize it's a bit tricky, and more tricky than I'll find time for today, given it's competing with making momos and chilli sauce, and crashing on the sofa with a beer to watch the euro footy :) 12:30
lizmat :-) 12:31
lizmat is glad the underlying cause has been found :-)
jnthn Well, it raises the more general interesting question of inlining and lexical-y things.
Which we've sorta dodged so far. 12:32
12:55 cognominal joined 13:44 rurban_ joined
timotimo invoke_lexical_handler_hll_erorr - tee hee 13:55
16:58 domidumont joined 17:58 cognominal joined 18:58 cognominal joined 18:59 rurban_ joined 19:06 edehont 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!