samcv nice! ok i've gotten siphash down to the same time that our current hash function uses 00:14
00:28 MasterDuke joined 02:13 dogbert2 joined 02:16 dogbert17 left 03:01 stmuk_ joined 03:04 stmuk left
Geth MoarVM: samcv++ created pull request #889:
Implement SipHash instead of ‘Jenkins Hash’
04:56 lizmat left 06:29 robertle joined 06:57 brrt joined 07:13 domidumont joined 07:18 domidumont left, domidumont joined
brrt good * #moarvm 07:35
samcv good * brrt 07:36
brrt i'll take a look at your siphash PR 07:38
do you have any background documentation for me to read?
samcv uhm 07:39
idk i have my blog post i guess. and the PR description
ask if you have any questions though
07:50 zakharyas joined 08:10 domidumont left 08:12 domidumont joined
brrt I want to merge a few of those outstanding JIT PRs 08:33
I'll do the fixups myself then
Geth MoarVM/jit-expr-refactor: a75746fa90 | (Bart Wiegmans)++ | 4 files
[JIT] Parse oplist as a module

I want to have access to the type and size information in the expression template compiler, so I want to access the oplist information first.
MoarVM/master: 4 commits pushed by (Ben Davies)++ 08:40
brrt Kaiepi++
now on to the next one
Geth MoarVM/master: 49 commits pushed by (Jeremy Studer)++
brrt jstuder-gh++
awesome work both of you
.tell lizmat I feel (and git could probably tell me) that i'm no longer the major contributor of expression templates, and that seems like something worth mentioning in this weeks weekly 08:44
yoleaux brrt: I'll pass your message to lizmat.
jnthn morning o/ 09:07
yoleaux 29 Jun 2018 23:27Z <_Xliff_> jnthn: <- This page has a mispelling of Perl in the quote from the CEO.
1 Jul 2018 15:51Z <lizmat> jnthn: is still up to date, or could it use an update / refinement ?
jnthn .tell Xliff Thanks, it's fixed now :) 09:09
yoleaux jnthn: I'll pass your message to Xliff.
Geth MoarVM: 8a7da04a2f | (Jonathan Worthington)++ (committed using GitHub Web editor) | docs/gc.markdown
A few small updates and corrections
jnthn .tell lizmat It was overall up to date, though a bit off in a few places. I've updated it.
yoleaux jnthn: I'll pass your message to lizmat.
brrt \o jnthn 09:19
samcv morning jnthn 09:20
i'm gonna head to bed. jnthn if you can check out my Siphash PR and comment that would be great 09:25
it's finally ready for prime time now that i got it as fast as our current hash code
night o/
brrt night samcv 09:26
09:27 lizmat joined
jnthn samcv++ 09:43
Will take a look
nwc10 ASAN reporting SEGV from t/qast/01-qast.t 09:59
src/jit/x64/emit.dasc:898:174: runtime error: member access within null pointer of type 'struct MVMFrame'
#0 0x7f2e47fa622a in MVM_jit_emit_primitive src/jit/x64/emit.dasc:898
#1 0x7f2e47f56626 in MVM_jit_compile_graph src/jit/compile.c:57
10:03 zakharyas left
jnthn uff, I see that one too in quite a few spectests 10:03
At least now I know it's not the JIT of speshresolve that I've just locally merged causing it
10:05 zakharyas joined
brrt huh, that's not good 10:05
jnthn | mov TMP6, RV; 10:06
Is the line the debugger reports, which is odd
brrt yes....
jnthn JIT of MVM_OP_ctxcallerskipthunks that's wrong, btw
Well, that it explodes in
brrt yep
but i'm not seeing what 10:07
jnthn bizzare 10:08
Me either
| mov TMP6, FRAME:ARG2->static_info->body.is_thunk;
brrt oh, hang on
jnthn Can we actually do double derefs like this?
brrt that's two derefs
we cannot :-) 10:09
jnthn Bit off from the error line but matchings nwc10's ASAN reporting
Are you fixing or shall I? :)
brrt i'll be fixing 10:10
thanks :-)
Geth MoarVM: 0b7f26ce57 | (Jonathan Worthington)++ | 5 files
JIT-compile sp_speshresolve
MoarVM: 1fe14d3c46 | (Bart Wiegmans)++ | src/jit/x64/emit.dasc
[JIT] Define ARG5 and ARG6 on windows

Windows has only 4 arguments in general purpose registers (as opposed to POSIX which has 6). Any other arguments are passed on the stack. Define the names of ARG5 and ARG6 to be the appropriate stack locations, and make sure to introduce intermediates where necessary.
MoarVM: 150f281082 | (Jonathan Worthington)++ | 5 files
Merge branch 'jit-sp_speshresolve'
jnthn All the SEGVs look like the ctxskipthunks issue
So I guess that patch is innocent :)
brrt i'm all so a bit worried about the line above 10:12
jnthn Yes, there's two double-derefs in there 10:13
Though that's more than one line above :) 10:14
brrt :-)
let me see if i've introduced more
Geth MoarVM: 97f76b461b | (Bart Wiegmans)++ | src/jit/x64/emit.dasc
[JIT] Double derference in assembly is not a thing

Had missed this during review, oops.
brrt that one should've fixed the ctxcallerskipthunks one
jnthn Thanks, spectesting :)
Want to get a clean baseline master so I know what I've broken in rescalar :) 10:18
brrt hmm, not entirely clean just yet, it seems 10:23
nwc10 NQP passes all tests 10:25
we march onward to Rakudo
jnthn brrt: Yeah, I see a SEGV occasionally in t/spec/S06-advanced/callframe.rakudo.moar 10:28
brrt disappears under MVM_SPESH_BLOCKING :-( 11:02
even in a hundred iterations under MVM_SPESH_BLOCKING 11:20
maybe ASAN knows better
and, it doesn't 11:22
11:30 zakharyas left 12:10 MasterDuke left
brrt hmm, i can't git bisect because the ctxskipcallerthunks fix is way past all the other fixes 12:18
13:32 zakharyas joined
jnthn Hmm, wonder if there's some spesh plugin bug in multiple levels of speshgetattr 14:26
Getting a guard fail that totally should match
Hm, though it's on the notobj guard I recently did 14:27
brrt reverting ctxcallerskipthunks for the JIT unbreaks the callframe.rakudo.moar test 14:39
Geth MoarVM: f66ebd4bdb | (Bart Wiegmans)++ | 2 files
Revert "Implement JIT template for ctxcallerskipthunks"

This reverts commit 2abe03d34874dd8c7d814d197c45095a12302e39.
MoarVM: 20d44791b6 | (Jonathan Worthington)++ | src/spesh/plugin.c
Fix guard evaluator attribute handling

We need to reset the collected objects array each time we fail to meet a guard, otherwise it will have bogus entries for the next guard and so cause it to fail to be met.
dogbert2 o/ 15:12
a question if you have time 15:13
I just got this message: MoarVM panic: Illegal Gen2 -> Nursery in caller chain (not in inter-gen set)
brrt hmm
that looks messy
15:13 zakharyas left
dogbert2 when running t/spec/MISC/bug-coverage.t with MVM_GC_DEBUG=1 15:13
This is Rakudo version 2018.06-56-g72ccd43 built on MoarVM version 2018.06-95-gf66ebd4 15:14
15:14 brrt left
dogbert2 runs valgrind 15:15
15:16 zakharyas joined
.oO( how would that work with an application called "away" ? )
dogbert2 gisted the gdb output here: 15:23
15:36 zakharyas left 15:42 reportable6 joined
dogbert2 lizmat: that wouldn't work so well :) 15:48
15:55 domidumont left 15:57 zakharyas joined 15:58 zakharyas left 16:01 zakharyas joined 16:03 robertle left 16:39 domidumont joined 17:01 zakharyas left 17:52 zakharyas joined 18:06 zakharyas left 18:17 Zoffix joined
Zoffix Is there a configure time option to set stack to be executable? 18:18
So you wouldn't need to run `sudo execstack -c nqp/MoarVM/` ?
18:21 Ven`` joined, lizmat left
Zoffix Trying to figure out instructions for installing on WSL, but can't figure out how to stick the `sudo execstack` piece and yet still use the `--gen-moar` options 18:32
18:46 ilogger2 joined
samcv i'm not sure what's going on with this appveyor msvc error 19:04
oh oops i was looking in the wrong file
Zoffix samcv: FWIW, the latest 2 rakduo commits also has appveyor failures in the version that tests with master moar. Something about deprecated "o" options and inability to find make 19:07
samcv nice msvc doesn't support LLU 19:11
though to be fair they have UI64, which is nice having a sized suffix. IMO we should have both standardized 19:21
19:38 lizmat joined
dogbert2 jnthn: should I report the bug mentioned a couple of hours ago or do you already know what it is? 'MoarVM panic: Illegal Gen2 -> Nursery in caller chain (not in inter-gen set)' 19:44
jnthn dogbert2: Yes 20:12
Geth MoarVM: febffaa265 | (Ben Davies)++ | src/io/syncsocket.c
Expose file descriptors of IO::Socket::INET instances

Before, `.native-descriptor` was available from IO::Socket, but always returned -1.
MoarVM: 7547dd8002 | (Jonathan Worthington)++ (committed using GitHub Web editor) | src/io/syncsocket.c
Merge pull request #880 from Kaiepi/socket-handle

Expose file descriptors of IO::Socket::INET instances
dogbert2 jnthn: will do: I suspect that the bug is quite new
samcv i hate msvc 20:24
dogbert2 done, 20:27
20:43 Ven`` joined
lizmat and another Perl 6 Weekly hits the Net: 20:51
20:56 Ven`` left 21:10 MasterDuke joined
MasterDuke for uses of the fixed size allocator functions, is anything other than tc->instance->fsa ever used? 21:22
samcv ok now i fixed my previous appveyor issue but there's some one that isn't my fault 22:01
jnthn MasterDuke: Not *currently*, though it's plausible we'd want to set up isolated ones in the future. 22:13
MasterDuke: I've sometimes been a tiny bit tempted to rip out that arg but...I can't see it actually making a difference. :)
MasterDuke jnthn: yeah, removing it doesn't seem like there's a major reward, but then again typing tc->instance->fsa over and over gets old... 22:37
jnthn Not old enough for the disruption and/or having to undo it later, I suspect. 22:38
samcv jnthn: well when we tear down the instance it only takes an instance 22:39
though. i guess that's only dealloc?
so i guess it could be removed hah
jnthn I think it just frees all the things there
samcv jnthn: i've been thinking we need to randomize our iteration order for the hashes 22:42
but i'm not sure how to do it. i was trying to read how perl 5 does it. but their hash code is very confusing
and also i think they have many more buckets than us. between num_items and num_items *2. whereas we have max 10 per bucket 22:43
but i guess we could start by randomizing the order we iterate buckets. 22:44
so perl 5 essentially will add things either to the first or the second slot in a bucket randomly. and it works well since things have 1 or 2 items in them generally. since we have more it makes it slightly less effective 22:45
jnthn Doesn't the random hash seed already give us random iteration order? 22:46
Or are you considering something more than "random between runs"?
sleep o/ 23:35
samcv jnthn: the thing is to give less information to attackers. and ordering is pretty juicy