Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-09-21

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:48 ilbot3 joined #moarvm
01:48 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
05:09 cxreg joined #moarvm
05:09 cxreg just saw this https://github.com/indutny/uv_link_t
05:16 konobi oh... nice
05:24 domidumont joined #moarvm
05:29 domidumont joined #moarvm
05:50 domidumont joined #moarvm
06:07 brrt joined #moarvm
06:42 brrt joined #moarvm
07:22 dalek MoarVM/even-moar-jit: e6d1b14 | brrt++ | src/jit/ (5 files):
07:22 dalek MoarVM/even-moar-jit: Remove MVM_JIT_FRAME and MVM_JIT_VMNULL nodes
07:22 dalek MoarVM/even-moar-jit:
07:22 dalek MoarVM/even-moar-jit: These have been complex memory access constructs for some time,
07:22 dalek MoarVM/even-moar-jit: and should not be singular nodes.
07:22 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/e6d1b149ce
07:23 brrt … that's just cleanup, though
07:27 dalek MoarVM/line_based_coverage_4: 8238b2b | (Zoffix Znet)++ | tools/parse_coverage_report.p6:
07:27 dalek MoarVM/line_based_coverage_4: Avoid 2 irrelevant lines and add line number IDs
07:27 dalek MoarVM/line_based_coverage_4:
07:27 dalek MoarVM/line_based_coverage_4: This makes the line numbers reported in the report match those in the actual
07:27 dalek MoarVM/line_based_coverage_4: individual source files and allows to map output of &some-code-sub.line to the
07:27 dalek MoarVM/line_based_coverage_4: coverage report. Added line numbers in id="" attribute allow to link people
07:27 dalek MoarVM/line_based_coverage_4: to individual lines in the coverage report.
07:27 dalek MoarVM/line_based_coverage_4: review: https://github.com/MoarVM/MoarVM/commit/8238b2b3e2
07:27 dalek MoarVM/line_based_coverage_4: c07f650 | lizmat++ | tools/parse_coverage_report.p6:
07:27 dalek MoarVM/line_based_coverage_4: Merge pull request #409 from zoffixznet/line_based_coverage_4--line-num
07:27 dalek MoarVM/line_based_coverage_4:
07:27 dalek MoarVM/line_based_coverage_4: Avoid 2 irrelevant lines and add line number IDs
07:30 brrt doesn't Zoffix have a commit bit yet for MoarVM?
07:34 zakharyas joined #moarvm
07:38 brrt next thing: integrate the new register spec thingy, so that we don't have to specialcase TC,CU, etc.
07:39 brrt other architectures, after all, may not have dedicated callee-saved registers in which to store them
08:35 zakharyas1 joined #moarvm
09:00 lizmat joined #moarvm
09:08 jnthn morning, #moarvm
09:11 lizmat moan, jnthn
09:14 jnthn ohhhh :(((((
09:16 brrt uh oh
09:18 jnthn .oO( wait, was "moan" not to be parsed as an instruction? )
09:18 brrt damn von neumann architectures...
09:20 jnthn First task of the day (which I'm on with) is hunting down https://rt.perl.org/Ticket/Display.html?id=129291
09:26 lizmat jnthn: that feels like that could help TEST_HARNESS=6 as well
09:26 nwc10 task count starts at zero I hope?
09:26 nwc10 else no coffee
09:27 jnthn 0th task (already completed) was "make coffee"
09:27 jnthn lizmat: I thought it uses Proc::Async, and this is about Proc
09:27 nwc10 this is a Monty Python Bruces variant?
09:27 nwc10 Task 0 - make coffee
09:28 nwc10 Task 1,                https://rt.perl.org/Ticket/Display.html?id=129291
09:28 nwc10 Task 2 - make coffee
09:28 nwc10 etc
09:28 nwc10 ?
09:28 nwc10 actually, there's a danger here, isn't there? Task 1 can block task 2, with fatal consequences
09:28 jnthn Indeed, need preemptive scheduling or something
09:54 domidumont joined #moarvm
10:00 domidumont1 joined #moarvm
10:02 jnthn Damn this is a confusing bug.
10:05 brrt joined #moarvm
10:05 nwc10 use more 'coffee'?
10:05 nwc10 or just lunch
10:14 domidumont joined #moarvm
10:22 jnthn I suspect it's a case of "confused implementation"
10:23 jnthn Though I'm not entirely sure
10:23 jnthn If you are spawning process 2, and binding its stdin to a handle captured from process 1, then we end of sticking process 2 in the ->process slot of the handle obtained from process 1
10:24 jnthn Thus replacing, I presume, the process object that was already there
10:25 jnthn Well, process handle rather than process object
10:25 jnthn That *feels* bogus, but maybe spectest will tell me otherwise
10:31 jnthn Well, they pass
10:33 TimToady joined #moarvm
10:40 jnthn I was a tad worried it might break:
10:40 jnthn for ^10 {my $proc = run(:out, :bin, "lsd"); say so run(:in($proc.out), :bin, "false");}
10:40 jnthn But it seems not
10:50 dalek MoarVM: debb859 | jnthn++ | src/io/syncpipe.c:
10:50 dalek MoarVM: Don't set inheriting process on inherited pipe.
10:50 dalek MoarVM:
10:50 dalek MoarVM: If we spawned process 2, and set its input to a pipe with output from
10:50 dalek MoarVM: an already-spawned process 1, then we ended up setting ->process on
10:50 dalek MoarVM: the pipe - which formally pointed at process 1 - to point at process
10:50 dalek MoarVM: 2. This seems somewhat bogus. It ends up with us trying to write to
10:50 dalek MoarVM: the C stack because the latter process has no captured I/O and so
10:50 dalek MoarVM: plans to store its result there. This in turn leads to the invalid
10:50 dalek MoarVM: free - we try to free a pointer pointing into the stack. Removing
10:50 dalek MoarVM: this ->process assignment makes the problem go away, and breaks no
10:50 dalek MoarVM: spectests. I also can't find any case where it affects previous
10:50 dalek MoarVM: behavior on conveynace of exit codes.
10:50 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/debb859d8d
11:41 domidumont joined #moarvm
15:00 brrt joined #moarvm
15:03 brrt joined #moarvm
15:54 * TimToady wonders if somehow that's the bug he ran into when trying to flatten 'unit' lexical scopes, which manifested some kind of bogus subprocess handshaking
15:55 timotimo actually, that could be
15:56 TimToady maybe later today I'll fire up that branch again and see if it's any better
15:56 mst jnthn: damnit, dude, 'formally' is not 'formerly'
15:56 TimToady but for now, have to go get my eyes checked, or maybe paisleyed
15:57 japhb TimToady: tartaned?
15:57 TimToady don't think I have enough of the right genetics
15:58 TimToady though my wife is really a biggar, part of the murray clan
15:59 mst one of the people who runs the UK mirrors commissioned a debian tartan
16:03 jnthn mst: hah, wow
16:10 Ven_ joined #moarvm
16:11 jnthn oh, wtf...somehow "space" ends up with two entries in the ucd2c property names table
16:11 jnthn One pointing to something totally bogus
16:12 nwc10 that's a neat trick.
16:13 jnthn m: use nqp; say nqp::unipropcode("Space"); say nqp::unipropcode("space")
16:13 camelia rakudo-moar 77a2ff: OUTPUT«21␤21␤»
16:13 jnthn Comes out as 23 and 92 here
16:14 jnthn The correct entry actually appears earlier
16:17 nwc10 "in parallel universes in constant time" - this is not a feature
16:24 domidumont joined #moarvm
16:28 Ven_ joined #moarvm
16:29 dalek MoarVM/unicode9: 24742b1 | jnthn++ | / (2 files):
16:29 dalek MoarVM/unicode9: Explicitly handle ZWJ in grapheme break.
16:29 dalek MoarVM/unicode9:
16:29 dalek MoarVM/unicode9: This is in preparation for updating to the Unicode 9 UCD, which takes
16:29 dalek MoarVM/unicode9: the Grapheme_Extend property away from Zero Width Joiner.
16:29 dalek MoarVM/unicode9: review: https://github.com/MoarVM/MoarVM/commit/24742b1024
16:29 dalek MoarVM/unicode9: 917f868 | jnthn++ | src/strings/unicode_ (2 files):
16:29 dalek MoarVM/unicode9: Update to the Unicode 9 character database.
16:29 dalek MoarVM/unicode9:
16:29 dalek MoarVM/unicode9: This is not all the work needed to support Unicode 9; we'll still need
16:29 dalek MoarVM/unicode9: to modify our NFG algorithm to cope with the new Emoji rules, for
16:29 dalek MoarVM/unicode9: example.
16:29 dalek MoarVM/unicode9: review: https://github.com/MoarVM/MoarVM/commit/917f868984
16:43 stmuk I've some gdb backtraces of moar coredumps .. can I report via github or is RT best?
16:45 jnthn github is fine, if it's a SEGV and nativecall ain't involved then it's a clear Moar bug
16:47 jnthn *sigh* If I get rid of the dubious entry by hand, the test that failed passes.
16:47 jnthn But I can't figure out where on earth it's coming from
16:47 timotimo it's a generated c file, right?
16:48 jnthn Yes!
16:48 timotimo i'd write a different "say" or whatever method/sub
16:48 jnthn Generated by ucd2c.pl
16:48 jnthn Thus why I want to figure out where it's coming from :)
16:48 timotimo that inspects its caller and grabs the line number
16:48 timotimo then puts a comment with the source lineno into the result
16:48 jnthn ...are we talking about the same thing? :)
16:49 timotimo maybe not? :\
16:49 timotimo you want to know what puts the bogus entry into the .c file?
16:49 jnthn Yeah. In the unicode_db.c.
16:49 jnthn I mean, I'm looking at the sub that generates the line
16:50 jnthn It doesn't help that the script is sensitive to hash ordering
16:50 jnthn Well, changes its output based on hash ordering
16:51 timotimo ugh
16:51 timotimo and that it's a perl5 script :)
16:54 timotimo well, that makes it harder for *me*
17:00 jnthn Yeah. Anyway, getting tired, not sure I'm going to find it Right Now
17:01 jnthn I don't see a singificant change between 8 and 9 in the versions of the files to make a difference
17:01 jnthn (PropertyAliases and PropertyValueAliases, that is)
17:02 nwc10 use more 'curry';
17:02 jnthn Indeed :)
17:02 jnthn It is dinner time
17:03 jnthn timotimo: fwiw, the trouble happens in emit_unicode_property_keypairs
17:04 stmuk https://github.com/MoarVM/MoarVM/issues/410
17:05 timotimo could you put ``` before and after the pasted text?
17:05 timotimo also, can you try with MVM_DISABLE_JIT=yes in the environment?
17:06 timotimo that makes backtraces less broken
17:06 stmuk ok
17:07 timotimo potentially makes it harder to crash the thing, though
17:14 stmuk updated
17:16 timotimo um, changing the environment variable when you load a core isn't going to make a difference :(
17:18 timotimo could that problem be the "unlocking an unlocked mutex explodes on some platforms but not on others" thing?
17:20 stmuk d'uh
17:20 stmuk I wondered why there was still a reference to a jit function :)
17:31 stmuk fixed
17:31 stmuk it still says MVM_jit_enter_code
17:33 timotimo i wonder if panda clears the environment or something before invoking a sub-moar, or ... no clue :\
17:49 jnthn That's one confused backtrace...
17:51 jnthn (And yes, I suspect JIT too)
17:52 jnthn I can't see a codepath where we'd try to relesae that lock without having acquired it, fwiw
17:54 Ven_ joined #moarvm
18:01 stmuk I have some partly golfed ways of triggering the core dump I'll experiment further
18:02 timotimo well, the jit makes the stack trace bogus, but it's not necessarily the cause of the crash
18:02 jnthn Oh, I rather doubt the JIT is to blame
18:03 jnthn I meant it's likely to blame for the dodgy stack trace
18:03 timotimo right
18:03 jnthn stmuk: Left a couple of extra things that might give me more clues on the github issue also
18:06 stmuk updated with a clearer (?) version
18:11 stmuk jnthn: I can try with valgrind also if that helps
18:11 stmuk I tried turning off jit and spesh and it still breaks
18:14 jnthn Please could you try a MoarVM build with --no-jit also? I think it's still somehow managing to JIT stuff.
18:15 stmuk ok I've also now seen further comments .. eating so will comment further on ticket later
18:16 jnthn np, time for me to do cooking momentarily also :)
18:17 edehont joined #moarvm
19:08 Ven_ joined #moarvm
19:08 Ven_ joined #moarvm
19:25 Ven__ joined #moarvm
19:40 stmuk jnthn: ticket updated
19:48 Ven_ joined #moarvm
19:52 timotimo stmuk: can you move the ``` below the pasted code? it ended up abve it it seem slike
19:52 timotimo at least in the very first comment in the ticket
19:52 timotimo i mean the original description
19:53 stmuk fixed
19:53 timotimo huh, it seems like i'm allowed to edit comments, too
20:20 Ven_ joined #moarvm
20:25 Ven_ joined #moarvm
20:56 Ven_ joined #moarvm
21:00 hoelzro joined #moarvm
21:22 zakharyas joined #moarvm
21:45 camelia joined #moarvm

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary