01:10 jnap joined 01:12 odc joined 02:05 benabik joined 02:21 jnap joined
tadzik :D 04:03
04:25 diakopter joined 04:39 crab2313 joined 05:00 johnny5_ joined 05:41 colomon joined 06:54 cognominal joined 07:04 FROGGS joined
FROGGS morning 07:06
#libuv++ # these guys could be Perl6ers, that friendly that they are :o) 08:04
jnthn :) 08:16
08:20 ingy1 joined
FROGGS nqp-m: my $fh := nqp::getstderr(); nqp::sayfh($fh, "test") 08:34
camelia nqp-moarvm: OUTPUT«Error while compiling op sayfh (source text: "nqp::sayfh($fh, \"test\")"): No registered operation handler for 'sayfh'␤frame_name_1108␤»
FROGGS meh, outdated moarvm
nqp-m: my $fh := nqp::getstderr(); nqp::printfh($fh, "test")
camelia nqp-moarvm: OUTPUT«test»
FROGGS why does that only fail on my box?? 08:35
but anyway, this can be considered fixed
btw, I really should learn how to use gdb properly 08:38
dalek arVM: e9b79b0 | (Tobias Leich)++ | src/ (2 files):
fix printfh/sayfh bug (segfault on linux)

This properly closes filehandles under some circumstances. Before we had a garbled req in the active_queue ov the libuv loop, which could not be uv_close'd. After malloc-ing write requests and un- referening these in the write callback, the requests in the queue are safe to be closed.		 08:45
FROGGS s/ov/of/ -.-
09:42 lizmat joined
jnthn FROGGS: I bet that fixes things up on Windows too \o/ 09:55
FROGGS++
10:20 woosley left
FROGGS jnthn: I've not seen fails on windows like I had them on linux 10:27
jnthn FROGGS: It tends to fail quieter... 11:18
FROGGS ahh, :o) 11:21
11:32 woolfy1 joined 12:05 lizmat joined 12:24 lizmat joined
jnthn diakopter: I think you could reproduce the thing FROGGS just fixed in the debugger - maybe try checkint it's gone if you have a moment. :) 12:32
13:23 lizmat joined 13:48 dalek joined 14:12 jnap joined
diakopter jnthn: I couldn't reliably reproduce it, or at least, I don't remember how 14:23
14:38 johnny5_ joined
jnthn diakopter: ah, ok 14:52
15:47 jnap joined 16:25 ingy joined 16:27 FROGGS_ joined
jnthn Awww 20:30
Something busted with Moar on Windows
Or maybe more widely
nqp-moarvm: nqp::getstderr()
camelia ( no output )
jnthn hmm 20:31
In MVM_file_get_stdstream, uv_guess_handle(type) returns soemthing that hits none of the cases... 20:32
FROGGS O.o
it worked on my boxed 20:33
jnthn Returns 0. Hmmmm. 20:34
Which is UV_UNKNOWN_HANDLE 20:36
FROGGS are piping the stdout/stderr to somewhere? 20:37
err, redirecting
jnthn Not knowingly.
Nothing's changed on this machine / in my environment since before I went on vacation. 20:38
Oh, this does happen running under the debugger 20:39
But at the command line it exits with code 1 without any output while building the Rakudo MOP
diakopter nqp-m: nqp::say(nqp::getstderr()) 20:41
camelia nqp-moarvm: OUTPUT«cannot stringify this␤frame_name_0␤»
diakopter nqp-m: nqp::say(nqp::what(nqp::getstderr()))
camelia nqp-moarvm: OUTPUT«␤»
FROGGS nqp-m my $fh := nqp::getstderr(); say($fh.HOW.name($fh)) 20:42
nqp-m: my $fh := nqp::getstderr(); say($fh.HOW.name($fh))
camelia nqp-moarvm: OUTPUT«BOOTIO␤»
FROGGS :/ 20:44
C:\nqp\install\bin\nqp-m.bat --target=mbc --output=blib/Perl6/Metamodel.moarvm --encoding=utf8 src/gen/m-Metamodel.nqp
NMAKE : fatal error U1077: 'C:\nqp\install\bin\nqp-m.bat' : return code '0x1'
jnthn Right, matches what I see then. 20:45
I have to breakpoint the exception thrower in VS to figure out where it's going wrong.
FROGGS well, must be my last commit
I've not seen any commit touching that piece of code 20:46
jnthn trying a local revert of it 20:47
FROGGS yeah, fixes it here
jnthn yeah, seems so 20:48
FROGGS now I properly get to Signature binding NYI
bind_sig
:(
jnthn samma
FROGGS: I'm wondering if we should actually create the MVM handles for stdin/stdout/stderr at startup, anchor them somewhere in instance, etc. 20:50
FROGGS I've thought about that too
jnthn FROGGS: Then we don't have to worry about them getting collected and closed...if I understand what's going on, anyway.
Or have I missed the issue?
FROGGS it seems that we have to clean up the pending requests at least 20:51
which should happen by the write callback
diakopter argh; it's what I said "we" should do months ago..
FROGGS so maybe that is enough already
diakopter ;)
FROGGS diakopter: you should have done it then :o)
because I don't know how to do that 20:52
jnthn FROGGS: Add ->stderr, ->stdin etc to MVMInstance
FROGGS: Then create the handles during startup, after 6model bootstrap 20:53
And MVM_root_add_permanent or whatever 'em.
diakopter someday, you'll also want to create global statics that enforce opening/closing them only once at the libuv level 20:54
FROGGS jnthn: this bails out on my box again: gist.github.com/FROGGS/d245bd7f983e0b5c138f 21:06
(libuv assertion)
the assertion only goes away when I close the handle in MVMOSHandle.c 21:08
Could not find Perl6::BOOTSTRAP in any of: ., blib 21:31
load_module
NMAKE :N MAfKaEt a:l f atearrlo re rrUo1r0 U5180:7 7t:e r'mCi:n\antqepd\ ibnys tuaslelr\
bSitno\pm.o
nice :o)
jnthn a tear rlos from my eye too :P 21:33
diakopter erm.
e r'm
21:44 BenGoldberg joined
FROGGS hmmm 21:54
it seems to work on both-ish when I move the uv_close to MVM_tc_destroy 21:55
(linux and windows)
ahh no, fails to build nqp 21:57
diakopter FROGGS: you can't close the standard handles on windows... just don't 22:02
it breaks stuff always
and really confuses visual studio
FROGGS then I just ifdef it out? 22:04
I'd be fine with that
diakopter yah
dalek arVM: d10b3fb | (Tobias Leich)++ | src/6model/reprs/MVMOSHandle.c:
don't close filehandles on windows, diakopter++
 22:09
22:13 colomon joined
FROGGS works on my böxes 22:15
22:15 lizmat joined 22:21 BenGoldberg joined 22:26 woolfy joined 22:39 lizmat joined 22:54 woolfy joined 23:21 lizmat joined 23:23 woolfy 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!