00:14 btyler joined 00:15 pyrimidine joined 00:25 jnthn joined 01:11 pyrimidine joined 02:11 pyrimidine joined 02:48 ilbot3 joined 03:17 pyrimidine joined 03:45 dalek joined 03:47 pyrimidine joined 04:56 pyrimidine joined 05:16 pyrimidine joined 05:42 pyrimidine joined 05:52 pyrimidine joined 07:01 domidumont joined 07:07 domidumont joined 07:09 pyrimidine joined 07:33 brrt joined
brrt good * #moarvm 07:35
07:37 brrt joined 07:51 pyrimidine joined 08:03 pyrimidine joined 08:31 domidumont joined 08:35 zakharyas joined
samcv hi brrt 08:43
brrt hi samcv 08:44
samcv brrt, what's the best way to add getstrfromname to jvm and js?
i mean i'm going to make an op that just basically calls getcodepointfromname and runs char on it for backends that don't have getstrfromname
where's the best place to add this?
brrt i'd expect NQP, to be honest 08:45
not moarvm clearly
samcv yeah but what file any clue 08:47
arnsholt samcv: The main file for nqp::ops in the JVM backend is src/vm/jvm/runtime/org/perl6/nqp/runtime/Ops.java 08:48
samcv well it needs to be for jvm and js
i know that file
but moarvm is going to implement that natively and all other backends will have a sub 08:49
08:52 domidumont joined 09:09 pyrimidine joined
samcv arnsholt, thoughts? 09:14
brrt moarvm leads jvm, js, and that's mostly ok 09:18
arnsholt Yeah, just not implementing it for JVM/JS is probably not that big a deal either 09:19
09:19 domidumont joined 09:24 pyrimidine joined
samcv i'd like to not have to do #?if though in Actions.nqp 09:26
what timezone is jnthn in btw 09:27
arnsholt European 09:29
lizmat CET 09:33
$ date
Wed Jan 11 10:33:18 CET 2017
samcv cool
10:01 pyrimidine joined
jnthn samcv: Still need help on the new op stuffs? 10:13
samcv uhm. arnsholt helped me and wrote a java one for me
jnthn OK 10:16
You figured out the rebootstrap thingy?
samcv nope 10:18
10:19 pyrimidine joined
jnthn Ah 10:25
There may be a Makefile target
But I tend to 10:26
1) Add the new op that I'd like to use inside of NQP
2) cp *.moarvm src/vm/stage0/
And then you've updated the stage0 compiler with the new build and the op will be available.
samcv there is a makefile target for genning the stage0 10:27
yeah i've done that and it works
jnthn ah, OK :) 10:31
samcv jnthn, going to sleep soon if you can review that PR if you aren't busy 10:50
10:53 dogbert17 joined
jnthn samcv: Have been a bit busy with $other-task but free in 2 mins 10:54
samcv kk np
jnthn 2 unused variables, otherwise it's fine :) 11:05
samcv ok i will remove those vars jnthn 11:07
extra vars removed now jnthn
jnthn oh, sorry :( 11:08
I just spotted a memory leak oto
*too
Shoulda caught that earlier
Commented where 11:09
samcv good catch 11:10
jnthn Righty, what should I work on next...
samcv memleak fixed 11:13
nwc10 jnthn: lunch! 11:14
jnthn: there remains a concurrency issue that you say you know the cause of, that can cause spectest6 under ASAN to explode with barfage 11:15
is that one hard to fix?
jnthn Yes :) 11:20
But probably also worthwhile :)
nwc10 bother
it might be the last real blocker before making spectest6 the default spectest
dogfood!
jnthn Yeah 11:21
Well, it may not be too difficult, just need to think about it carefully and chase down whether a simple solution can work without totally screwing things up :)
samcv i am going to try and sleep a bit. i will be up in 2.5 hours though jnthn. please merge my PR if everything seems fine 11:22
and i'll stage the next one when i wake up
jnthn samcv: Approved the PR; will merge after Travis gets done :) 11:23
samcv kk :) 11:24
jnthn Rest well
samcv o/
jnthn o/
dogbert17 jnthn: are you doing Perl6 work today? 11:25
jnthn dogbert17: At least some of the day, yes :) 11:29
I think I'll try and sort out the spectest6-affecting inlining/threads/compunit/locks crash
dogbert17 start with something simple (if there is such a thing) and then bring out the big guns, i.e. cheese :-)
jnthn heh, add gc on the lsit too :)
*list
Pro tip: do kill all gdb instances, remember to | grep gdb before you | xargs kill -9 11:41
*to
nwc10 just kill init - it's much faster
jnthn :P 11:42
The reason I ended up with a dozen GDB instances is because if you run the Perl 6 spectest harness using perl6-gdb-m, that executable name is inherited
And used to run all the spectests
So it's like gdbception 11:43
And this doesn't go very well
11:46 brrt joined
jnthn lunch & 11:54
11:55 pyrimidine joined 12:03 mst joined
ilmari too 12:07
12:18 pyrimidine joined 13:19 pyrimidine joined 14:22 pyrimidine joined
jnthn OK, so having analyzed things a bit 14:25
inlining can try to acquire the compilation unit update_mutex in 3 cases
None of those cases ever inside of them trigger deserialization nor GC nor acquire any further mutexes 14:26
And the data they touch is disjoint from MVM_bytecode_finish_frame and prepare_and_verify_static_frame which also use update_mutex 14:27
Which are more involved and really could do with the mutex in question
Uh, reentrant
Thus it's possible to split this up into a pair of mutexen, one GC-aware fancy one, one boring uv_mutex 14:28
Thus solving the GC in spesh issue 14:29
So, that part seems relatively easy to solve
There is however a second problem.
In that in fixing up a compunit for the sake of an inline, we realloc
But other threads could easily still hang on to the old pointer and use it 14:30
This is likely why ASAN triggered
I believe this can be fixed using the fixed size allocator and its free_at_safepoint functionality.
14:46 pyrimidine joined
Geth arVM/fix-inline-and-threads: 1f20dc77bb | (Jonathan Worthington)++ | 6 files
Fix GC in spesh triggered by managed mutex use.

When inlining, the update_mutex of a MVMCompUnit was acquired. This for some time has been a high-level mutex, made so since these are reentrant and also cannot lead to GC deadlocks. Unfortunately, spesh has a "no GC during specialization" constraint, which use of this mutex violated. Thankfully, the things it used the mutex for were disjoint from the set of things that need a high-level mutex. So, split it into two mutexes protecting the different fix, and make the one that inlining needs to acquire be a low-level mutex which will never cause entry to the GC.		 15:10
jnthn That deals with the first half of the issue.
brrt looks 15:11
jnthn This covers github.com/MoarVM/MoarVM/issues/478 and 2 related cases
15:15 FROGGS joined
jnthn No such method 'made' for invocant of type 'TAP::Runner::State' 15:16
...well, I didn't fix that issue...
15:17 pyrimidine joined
timotimo the free_at_safepoint is definitely the right way to deal with that one 15:19
15:20 pyrimidi_ joined
Geth arVM: 388cbb69e4 | (Samantha McVey)++ | 14 files
Implement getstrfromname/MVM_unicode_string_from_name

Returns a string from its Unicode name. Unlike MVM_unicode_lookup_by_name, this works for multiple codepoints. This allows us to support Emoji sequences and other potential names which are sequences of codepoints.		 15:21
arVM: c23bb45cd4 | (Jonathan Worthington)++ | 14 files
Merge pull request #492 from samcv/getstrbyname

Implement getstrbyname/MVM_unicode_string_from_name to retrieve grapheme clusters by name
arVM/fix-inline-and-threads: a98812b14a | (Jonathan Worthington)++ | 3 files
Fix data race in inlining extop fixup.

This switches to use the fixed size allocator for this memory, which provides a free-at-safepoint function. Previously, the realloc could read to a thread reading memory that was freed by the realloc.		 15:40
timotimo lead* :)
[Coke] wonders if it would be worth elminating the branch name after the first line. 15:41
Geth arVM/fix-inline-and-threads: 151cb272db | (Jonathan Worthington)++ | 3 files
Fix data race in inlining extop fixup.

This switches to use the fixed size allocator for this memory, which provides a free-at-safepoint function. Previously, the realloc could lead to a thread reading memory that was freed by the realloc.
jnthn Nice thing about working in a branch: I can get away with rebase :) 15:42
timotimo hah, i didn't expect you to actually fix that typo :D
dogbert17 dogbert@dogbert-VirtualBox ~/repos/doc $ perl6 htmlify.p6 15:43
Initializing ...
===SORRY!=== Error while compiling /home/dogbert/repos/doc/htmlify.p6
Variable '$no-highlight' is not declared
at /home/dogbert/repos/doc/htmlify.p6:1002
------> if !ā$no-highlight and $proc.started {
samcv ^^
brrt so, i've pondered a bit more with regards to the issue i was discussing yesterday; the issue is really that there can be more-than-one live range starting at a single 'point' 15:44
[Coke] dogbert17: thanks for the heads up. (moved to #perl6) 15:47
brrt so in a way, the 'only expire once per point' is pretty good, but you'd have to do it at the *last* point :-( 15:49
huge headache altogether :-( 15:52
timotimo hopefully not actual pain in your head area 16:00
Geth arVM/fix-inline-and-threads: fc771134f2 | (Jonathan Worthington)++ | 3 files
Fix data race in inlining extop fixup.

This switches to use the fixed size allocator for this memory, which provides a free-at-safepoint function. Previously, the realloc could lead to a thread reading memory that was freed by the realloc.		 16:01
arVM/fix-inline-and-threads: 5389d6080b | (Jonathan Worthington)++ | 3 files
Fix data race in callsite fixup during inlining.

Switches to using the fixed size allocator, so we can free the array of callsites at a safepoint, thus preventing reads of freed memory.
jnthn 2 down, 1 to go
brrt hmmm 16:02
dogbert17 oO
timotimo do we have a reason to turn free_at_safepoint into an immediatel free if we have only one thread active? (or are we perhaps already doing that?)
16:03 pyrimidine joined
jnthn Already doing it 16:04
timotimo OK
dogbert17 so the "Must not GC when in the specializer/JIT" message will be a thing of the past, nice 16:06
jnthn Well, for all the reasons it can occur that we've identified so far, yes :) 16:09
The bad news is that, unless this final fix to the strings heap actually nails it, the realloc bug is not the one that could cause the "method made not found" or whatever failure mode.
But it does remove a way to SEGV in spectest6
And maybe in htmlify --parallel too 16:10
Geth arVM/fix-inline-and-threads: ef4d6a767a | (Jonathan Worthington)++ | 3 files
Fix data race in string fixup during inlining.

Switches to using the fixed size allocator, so we can free the array of strings at a safepoint, thus preventing reads of freed memory.		 16:16
16:17 pyrimidine joined
Geth arVM: jnthn++ created pull request #495:
Fix bugs in interaction between inlining, GC, and threads		 16:22
jnthn There we go :) 16:23
nwc10: This should quiet the ASAN noise in spectest6
timotimo is going over the diff 16:28
do we want to build a realloc for FSA at some point? 16:29
it could allow us to sometimes not do anything because we still have a bit of extra space in the same location 16:30
jnthn I doubt we ever will withthe FSA 16:34
Since it buckets stuff
timotimo we tend to have 8 bytes at the end of a bucket if we had to round up, don't we?
jnthn Hm, though there could be some I guess
Yeah
I guess we could consider it 16:35
timotimo if we have lists of pointers, that'd cut our alloc/free amount by half if we have workloads that always add a single pointer
jnthn It may be worth factoring the pattern out if nothing else.
timotimo aye, and that
but i took that as a given ;)
looke dover the code, looks good so far 16:41
it'll get a bit cleaner when we have realloc :)
"looke dover" 16:42
mst small village near the coast 16:51
lovely cafe
17:02 domidumont joined
dogbert17 noticed an oddity wrt specttesting 17:03
if I run 'make spectest' it will immediatly log the message 'Inline::Perl5 not installed: not running Perl 5 integration tests', naturally no perl5 integration tests are run 17:04
but if I write 'make spectest HARNESS_TYPE=6' it start running stuff like 't/spec/S01-perl-5-integration/array.rakudo.moar ................... ok' 17:05
how is that possible, anyone knows? 17:06
brokenchicken didn't know you could pass env vars AFTER the command... 17:09
dogbert17 seems to do the right thing though: './perl6-m -Ilib t/harness6 --fudge --tests-from-file=t/spectest.data' 17:10
17:12 pyrimidine joined 17:20 pyrimidine joined
timotimo that's just something make allows you to do 17:28
brokenchicken ah
timotimo i.e. it'll parse its arguments for something that looks like an env var assignment 17:29
17:37 pyrimidine joined
Geth arVM: samcv++ created pull request #496:
Fix RT #117683 \c[LINE FEED] \c[CARRIAGE RETURN]		 18:01
samcv oh well i didn't do it 4 hours ago but just pulled my next PR. which is pretty minor but fixes an RT
once this is merged I can update roast to use these names instead of the unicode 1 names as per TimToady's blessing 18:03
jnthn samcv: Where are these names that we're adding from? 18:07
samcv unicode alias names
they are in roast as well
(already in roast)
eventually we're going to programmaticlly add all the alias names when we construct the hash, but for now fixing this will allow me to correct roast 18:09
since i already fixed it on jvm
jnthn Right, that was going to be my next question, why aren't we adding all of them from the UCD source :) 18:10
samcv we will soon :)
jnthn OK. I'm fine with this in the meantime, then :)
samcv sweet
diakopter originally we overrode some of those control chars because.. I can't remember
samcv because otherwise \c[NULL] wouldn't work and others etc 18:11
so once I programmatically add all the alias names we can stop storing unicode 1 names in the normal name fields
and then can add the unicode 1 names back in 18:13
as step 3
though as part of step 3 we will need to temporarily whitelist the 2 unicode 1 names which don't cooraspond to the alias names, like LINE FEED (LF) is the unicode 1 name, but the alias name is LINE FEED or LF 18:14
and just warn the user for a while if they use one of the unicode 1 names which are not alias names
18:39 pyrimidine joined 18:58 ggoebel joined 19:10 pyrimidine joined
samcv jnthn, gonna get a merge on that before you go to bed tonight? sucks we're in totally different timezones :P 19:19
19:20 pyrimidine joined
samcv though i guess i'm awake hours earlier than I usually am so that is good 19:21
20:30 domidumont joined
Geth arVM: ef734fc8d7 | (Samantha McVey)++ | 2 files
Fix RT #117683 \c[LINE FEED] \c[CARRIAGE RETURN]

Also fixes \c[NEXT LINE] and \c[FORM FEED] as well.		 20:48
arVM: 64e2d938df | (Jonathan Worthington)++ | 2 files
Merge pull request #496 from samcv/RT#117683

Fix RT #117683 \c[LINE FEED] \c[CARRIAGE RETURN]
samcv yey
jnthn samcv: Figured I'd wait on the Travis build...they're a bad slow these days
samcv np. yeah they are slow
jnthn Well, to be fair, seems the OSX ones are to blame
timotimo oh yeah, clang is really bad at our interp.c 20:49
samcv also jnthn how to silence 3rdparty/uthash.h:151:10: warning: assignment from incompatible pointer type [-Wincompatible-pointer-types] 20:50
head = (add);
i mean everything is fine. but the type checking is causing it to warn
probably because i added a new typedef for the new hash to store the sequence names 20:51
jnthn samcv: Urgh, I suspect the answer lies in a nest of macros... 20:52
timotimo most likely
isn't it supposed to show like 20 lines of explanatory text?
20:54 pyrimidine joined
jnthn Any feedback on github.com/MoarVM/MoarVM/pull/495 welcome 21:00
I wouldn't mind checking that the SEGVs I see now in spectest6 also happen on master 21:01
Will do that tomorrow or so
timotimo that, or if?
jnthn Well, if they're not on master and they are on this branch, it's a tad suspect :) 21:02
timotimo sure
i don't actually have a spectest6 target, so i actually have to HARNESS_TYPE=6 make spectest? 21:08
lizmat timotimo: yes
timotimo 'k
when i run into that segfault, the whole thing stops, right? not just one single test file? 21:09
jnthn Right, it's in the harness
lizmat yup
timotimo good
have we tested the harness with valgrind/asan?
jnthn Not yet :)
lizmat afaik a loooong time ago
jnthn Oh
timotimo i can try that, then
jnthn nwc10++ did 21:10
But I fixed the bug he found
That's what my branch is about :)
So "not since my branch" :)
timotimo should i investigate what happens if i cherry-pick the "make gen2 collection happen more often" commit? or is that already landed in master? 21:12
jnthn It's in master 21:13
timotimo there it is, yes
jnthn My branch is the PR you reviewed
timotimo right
jnthn Off for a little walk in the snow :)
timotimo gdb be like 21:14
detached after fork. detached after fork. detached after fork. detached after fork. detached after fork.
21:22 pyrimidine joined 21:31 pyrimidine joined
timotimo interesting 21:33
moar: 3rdparty/libuv/src/unix/stream.c:1499: uv_read_start: Assertion `((stream)->io_watcher.fd) >= 0' failed.
i wonder how that happens? 21:38
i mean, this is from syncstream, so we literally just started the thing up 21:39
two times in a row i got that assertion 22:04
geekosaur either something is not catching an error return (likely inside of libuv since it should fail if explicitly given a negative fd), or there is memory corruption 22:05
22:32 pyrimidine joined 22:38 pyrimidi_ joined
timotimo annoyingly i can't print the moar-level stacktrace, because it gets a signal while trying to dump the backtrace 22:44
geekosaur I think you just selected the "or" there...
timotimo :) 22:45

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!