01:48 ilbot3 joined 05:09 cxreg joined
cxreg just saw this github.com/indutny/uv_link_t 05:09
konobi oh... nice 05:16
05:24 domidumont joined 05:29 domidumont joined 05:50 domidumont joined 06:07 brrt joined 06:42 brrt joined
dalek arVM/even-moar-jit: e6d1b14 | brrt++ | src/jit/ (5 files):
Remove MVM_JIT_FRAME and MVM_JIT_VMNULL nodes

These have been complex memory access constructs for some time, and should not be singular nodes.		 07:22
brrt … that's just cleanup, though 07:23
dalek arVM/line_based_coverage_4: 8238b2b | (Zoffix Znet)++ | tools/parse_coverage_report.p6:
Avoid 2 irrelevant lines and add line number IDs

This makes the line numbers reported in the report match those in the actual individual source files and allows to map output of &some-code-sub.line to the coverage report. Added line numbers in id="" attribute allow to link people to individual lines in the coverage report.		 07:27
MoarVM/line_based_coverage_4: c07f650 | lizmat++ | tools/parse_coverage_report.p6:
MoarVM/line_based_coverage_4: Merge pull request #409 from zoffixznet/line_based_coverage_4--line-num
MoarVM/line_based_coverage_4:
MoarVM/line_based_coverage_4: Avoid 2 irrelevant lines and add line number IDs
brrt doesn't Zoffix have a commit bit yet for MoarVM? 07:30
07:34 zakharyas joined
brrt next thing: integrate the new register spec thingy, so that we don't have to specialcase TC,CU, etc. 07:38
other architectures, after all, may not have dedicated callee-saved registers in which to store them 07:39
08:35 zakharyas1 joined 09:00 lizmat joined
jnthn morning, #moarvm 09:08
lizmat moan, jnthn 09:11
jnthn ohhhh :((((( 09:14
brrt uh oh 09:16
jnthn
.oO( wait, was "moan" not to be parsed as an instruction? )
 09:18
brrt damn von neumann architectures...
jnthn First task of the day (which I'm on with) is hunting down rt.perl.org/Ticket/Display.html?id=129291 09:20
lizmat jnthn: that feels like that could help TEST_HARNESS=6 as well 09:26
nwc10 task count starts at zero I hope?
else no coffee
jnthn 0th task (already completed) was "make coffee" 09:27
lizmat: I thought it uses Proc::Async, and this is about Proc
nwc10 this is a Monty Python Bruces variant?
Task 0 - make coffee
Task 1, rt.perl.org/Ticket/Display.html?id=129291 09:28
Task 2 - make coffee
etc
?
actually, there's a danger here, isn't there? Task 1 can block task 2, with fatal consequences
jnthn Indeed, need preemptive scheduling or something
09:54 domidumont joined 10:00 domidumont1 joined
jnthn Damn this is a confusing bug. 10:02
10:05 brrt joined
nwc10 use more 'coffee'? 10:05
or just lunch
10:14 domidumont joined
jnthn I suspect it's a case of "confused implementation" 10:22
Though I'm not entirely sure 10:23
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
Thus replacing, I presume, the process object that was already there 10:24
Well, process handle rather than process object 10:25
That *feels* bogus, but maybe spectest will tell me otherwise
Well, they pass 10:31
10:33 TimToady joined
jnthn I was a tad worried it might break: 10:40
for ^10 {my $proc = run(:out, :bin, "lsd"); say so run(:in($proc.out), :bin, "false");}
But it seems not
dalek arVM: debb859 | jnthn++ | src/io/syncpipe.c:
Don't set inheriting process on inherited pipe.

If we spawned process 2, and set its input to a pipe with output from an already-spawned process 1, then we ended up setting ->process on the pipe - which formally pointed at process 1 - to point at process 2. This seems somewhat bogus. It ends up with us trying to write to the C stack because the latter process has no captured I/O and so plans to store its result there. This in turn leads to the invalid free - we try to free a pointer pointing into the stack. Removing this ->process assignment makes the problem go away, and breaks no spectests. I also can't find any case where it affects previous behavior on conveynace of exit codes.		 10:50
11:41 domidumont joined 15:00 brrt joined 15:03 brrt joined
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:54
timotimo actually, that could be 15:55
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'
TimToady but for now, have to go get my eyes checked, or maybe paisleyed
japhb TimToady: tartaned? 15:57
TimToady don't think I have enough of the right genetics
though my wife is really a biggar, part of the murray clan 15:58
mst one of the people who runs the UK mirrors commissioned a debian tartan 15:59
jnthn mst: hah, wow 16:03
16:10 Ven_ joined
jnthn oh, wtf...somehow "space" ends up with two entries in the ucd2c property names table 16:11
One pointing to something totally bogus
nwc10 that's a neat trick. 16:12
jnthn m: use nqp; say nqp::unipropcode("Space"); say nqp::unipropcode("space") 16:13
camelia rakudo-moar 77a2ff: OUTPUT«21␤21␤»
jnthn Comes out as 23 and 92 here
The correct entry actually appears earlier 16:14
nwc10 "in parallel universes in constant time" - this is not a feature 16:17
16:24 domidumont joined 16:28 Ven_ joined
dalek arVM/unicode9: 24742b1 | jnthn++ | / (2 files):
Explicitly handle ZWJ in grapheme break.

This is in preparation for updating to the Unicode 9 UCD, which takes the Grapheme_Extend property away from Zero Width Joiner.		 16:29
arVM/unicode9: 917f868 | jnthn++ | src/strings/unicode_ (2 files):
Update to the Unicode 9 character database.

This is not all the work needed to support Unicode 9; we'll still need to modify our NFG algorithm to cope with the new Emoji rules, for example.
stmuk I've some gdb backtraces of moar coredumps .. can I report via github or is RT best? 16:43
jnthn github is fine, if it's a SEGV and nativecall ain't involved then it's a clear Moar bug 16:45
*sigh* If I get rid of the dubious entry by hand, the test that failed passes. 16:47
But I can't figure out where on earth it's coming from
timotimo it's a generated c file, right?
jnthn Yes! 16:48
timotimo i'd write a different "say" or whatever method/sub
jnthn Generated by ucd2c.pl
Thus why I want to figure out where it's coming from :)
timotimo that inspects its caller and grabs the line number
then puts a comment with the source lineno into the result
jnthn ...are we talking about the same thing? :)
timotimo maybe not? :\ 16:49
you want to know what puts the bogus entry into the .c file?
jnthn Yeah. In the unicode_db.c.
I mean, I'm looking at the sub that generates the line
It doesn't help that the script is sensitive to hash ordering 16:50
Well, changes its output based on hash ordering
timotimo ugh 16:51
and that it's a perl5 script :)
well, that makes it harder for *me* 16:54
jnthn Yeah. Anyway, getting tired, not sure I'm going to find it Right Now 17:00
I don't see a singificant change between 8 and 9 in the versions of the files to make a difference 17:01
(PropertyAliases and PropertyValueAliases, that is)
nwc10 use more 'curry'; 17:02
jnthn Indeed :)
It is dinner time
timotimo: fwiw, the trouble happens in emit_unicode_property_keypairs 17:03
stmuk github.com/MoarVM/MoarVM/issues/410 17:04
timotimo could you put ``` before and after the pasted text? 17:05
also, can you try with MVM_DISABLE_JIT=yes in the environment?
that makes backtraces less broken 17:06
stmuk ok
timotimo potentially makes it harder to crash the thing, though 17:07
stmuk updated 17:14
timotimo um, changing the environment variable when you load a core isn't going to make a difference :( 17:16
could that problem be the "unlocking an unlocked mutex explodes on some platforms but not on others" thing? 17:18
stmuk d'uh 17:20
I wondered why there was still a reference to a jit function :)
fixed 17:31
it still says MVM_jit_enter_code
timotimo i wonder if panda clears the environment or something before invoking a sub-moar, or ... no clue :\ 17:33
jnthn That's one confused backtrace... 17:49
(And yes, I suspect JIT too) 17:51
I can't see a codepath where we'd try to relesae that lock without having acquired it, fwiw 17:52
17:54 Ven_ joined
stmuk I have some partly golfed ways of triggering the core dump I'll experiment further 18:01
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
I meant it's likely to blame for the dodgy stack trace 18:03
timotimo right
jnthn stmuk: Left a couple of extra things that might give me more clues on the github issue also
stmuk updated with a clearer (?) version 18:06
jnthn: I can try with valgrind also if that helps 18:11
I tried turning off jit and spesh and it still breaks
jnthn Please could you try a MoarVM build with --no-jit also? I think it's still somehow managing to JIT stuff. 18:14
stmuk ok I've also now seen further comments .. eating so will comment further on ticket later 18:15
jnthn np, time for me to do cooking momentarily also :) 18:16
18:17 edehont joined 19:08 Ven_ joined 19:25 Ven__ joined
stmuk jnthn: ticket updated 19:40
19:48 Ven_ joined
timotimo stmuk: can you move the ``` below the pasted code? it ended up abve it it seem slike 19:52
at least in the very first comment in the ticket
i mean the original description
stmuk fixed 19:53
timotimo huh, it seems like i'm allowed to edit comments, too
20:20 Ven_ joined 20:25 Ven_ joined 20:56 Ven_ joined 21:00 hoelzro joined 21:22 zakharyas joined 21:45 camelia 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!