| IRC logs at
Set by AlexDaniel on 12 June 2018.
00:39 Kaeipi joined, Kaiepi left 01:14 Altai-man joined 01:17 sena_kun left 01:44 MasterDuke left 02:26 AlexDaniel joined, AlexDaniel left, AlexDaniel joined 04:15 unicodable6 left, benchable6 left, quotable6 left, coverable6 left, notable6 left, linkable6 left, bloatable6 left, releasable6 left, nativecallable6 left, reportable6 left, statisfiable6 left, evalable6 left, shareable6 left, sourceable6 left, committable6 left, greppable6 left, bisectable6 left, tellable6 left, squashable6 left, coverable6 joined, benchable6 joined 04:16 sourceable6 joined, linkable6 joined, releasable6 joined, unicodable6 joined, shareable6 joined, evalable6 joined, nativecallable6 joined, bisectable6 joined, greppable6 joined, tellable6 joined, bloatable6 joined, quotable6 joined 04:17 statisfiable6 joined, squashable6 joined, reportable6 joined 04:18 notable6 joined, committable6 joined 05:15 sena_kun joined 05:16 Altai-man left 07:10 zakharyas joined
nwc10 good *, #moarvm 07:13
07:36 leont joined 08:39 squashable6 left, squashable6 joined
jnthn morning o/ 08:57
nwc10 \o
09:14 Altai-man joined 09:16 sena_kun left
Geth MoarVM: 497748f719 | (Nicholas Clark)++ | 23 files
Split `flags` in struct MVMCollectable into `flags1` and `flags2`.

This permits us to avoid a data race when one thread needs to set MVM_CF_HAS_OBJECT_ID and a second needs to set MVM_CF_REF_FROM_GEN2.
For now, don't change the flag bit values used in the two new members.
MoarVM: 7f854e655a | (Nicholas Clark)++ | src/6model/6model.h
Shrink `flags1` and `flags2` in struct MVMCollectable down to MVMuint8.

Change the values of the MVM_CF_* flags to sit in the range 1-128.
MoarVM: 9a5203395c | (Jonathan Worthington)++ (committed using GitHub Web editor) | 23 files
Merge pull request #1336 from MoarVM/flags-split

Split `flags` in struct MVMCollectable to avoid data races when setting `MVM_CF_HAS_OBJECT_ID` and `MVM_CF_REF_FROM_GEN2`
nwc10 \o/
thanks 09:25
jnthn Anything else? :)
nwc10 the XXXes on the hash. And the other 40 something commits :-)
but don't forget coffee or lunch
jnthn Bit early for lunch. Already have coffee.
Hm, had. That went quickly...
Is the thing I should be looking at? 09:26
nwc10 yes
but I have one local fix to one of the commit
in code that is never hit
Geth MoarVM/AAAA-A-better-hash: 9 commits pushed by (Nicholas Clark)++ 09:27
jnthn Hm, the PR is YYY-A-Better-Hash; is this AAAA-A-better-hash better to run/review/test? 09:28
nwc10 commit 7c65ae56b76b61044951bbc432c0987ace07f0d4 has a fix for commit 073dfda3ab2c3b1c5cbe1b928202709c97a76e18
and yes, totally
sorry, forgot that I had not updated the PR
IIRC YYY has some fixes, ZZZ is rebased onto the split flags and fixes nearly everythign else we found 09:29
AAAA fixes a fatal off-by-one in uni_hash_table.c in code that isn't actually called
and adds one more commit at HEAD
should I kill 1334 and open 1337? :-) 09:30
jnthn :D
Yes, it'd be a bit easier
This also deserves the number :P
nwc10 I hope that I'm still on target for it 09:31
Geth MoarVM: nwc10++ created pull request #1337:
A better hash
nwc10 score!
jnthn has comments (that's the XXX one) 09:39
nwc10 Thanks. I think that I have now answered everything as best that I can. 09:54
jnthn Wildly unscientific measurements 10:02
Before) NQP build: 28.762s, Rakudo build: 1m32.880s, Stage parse: 51.435s
After) NQP build: 27.963s, Rakudo build: 1m29.499s, Stage parse: 48.313s
10:08 zakharyas left
jnthn nwc10: It builds/tests clean here, fwiw 10:14
10:15 zakharyas joined
nwc10 bother, I forgot to comment anywhere - there's a mention of MVM_HASH_GET in docs/extops.markdown 10:34
it's clearly wrong. But I don't know if enough of that document (from 2013 or so) is useful enough to make it better to fix it
or if it's so far from what we now have that it's better just to delete it and start again
jnthn Or just delete it because extops are going away in hopefully not too long... 10:36
nwc10 well, delete it and then "never qute start again" works 10:37
jnthn Indeed 10:39
nwc10 lunch! 10:53
have I commented on everything that needed commetning on? 10:54
jnthn I've just finished going through it. I mean, in only so much detail, but still...
Well, my final comment is probably worth an answer (about the iter debug define) 10:59
But otherwise I think all is answered
nwc10 is it better to go through the branch and rework history to incorporate the improvements (which makes history of the code easier to read, but somewhat confuses the history of the code review) 11:24
or to stick commit(s) on the end to fix things? 11:25
jnthn I prefer the latter in that it's much easier to review the fixes 11:29
It'd be nice if there were a way to see what the rebased changes did (like a diff between before/after rebasing) but I ain't aware of a way to see that
(Without pushing a branch name with the old thing and diffing them) 11:30
nwc10 diff -u <(git show $sha1) <(git show $sha2)
and a lot of manual work.
samcv nwc10, nice. ++ at better hash. will take a look at the MR later today 11:31
nwc10 actually, the *ultimate* makework version of this is 12:00
1) series of commits on the end to fix the issues
2) iterate until happy
3) snapshot that tree
4) rebuild the history with all the fixups moved into their relevant commits
5) if the end trees are identical, it's the approved code 12:01
however, I am told that I need to go out this afternoon
(in about 90 minutes)
(and this might take longer than yesterday's trip. And involve cider)
jnthn Buying or consuming? Or is that incider information? 12:09
nwc10 consuming. I'm the designated drinker. (And map" reader) (usually) 12:10
(Except on Sunday, when suddenly it was "you're driving now")
and the folks we're visiting, sadly, he's both. So can't change roles if he's the one travelling here. 12:11
12:18 zakharyas left 13:15 sena_kun joined 13:17 Altai-man left 13:27 zakharyas joined 13:36 squashable6 left 13:37 squashable6 joined
Geth MoarVM/AAAA-A-better-hash: 9 commits pushed by (Nicholas Clark)++ 13:41
nwc10 I think that that adresses all the current comments.
but I assume that if no new ones are found, then still before merging the branch needs to be rebased, to edit out the `XXX` from that commit message 13:42
(and I *think* but have not checked, that commit bafd06fafde1839ad3d529cd739c67a6e89348a0 could be folded into commit 90eb6992c03755f533b331abe810b67974068dfc 13:43
(commit 90eb6992c03755f533b331abe810b67974068dfc is the one with the XXXes)
still here, but likely to be AFK very soon, possibly without futher warning 13:44
14:33 dogbert17 joined 15:18 squashable6 left 15:20 squashable6 joined 16:56 zakharyas left 17:14 Altai-man joined 17:17 sena_kun left 18:39 vrurg left 18:43 squashable6 left 18:46 squashable6 joined 18:50 Kaiepi joined 18:52 Kaeipi left 19:04 vrurg joined 19:09 zakharyas joined
dogbert17 any data race experts around? 19:31
nwc10 I wouldn't consider myself to be one.
dogbert17 is there a trick in figuring out if the following example points to a real problem or is it in fact a false positive? 19:32
nwc10: parts of the stack trace might look familiar to you
nwc10 Yes, erk, but not enough that I can say *anything* useful here. Sorry 19:36
I just don't know.
dogbert17 perhaps someone else will chime in
if I understood how to differentiate real problems from false positives I might be able to sift through the rather large amount of warnings that tsan spits out 19:38
19:45 zakharyas left 20:48 vrurg left 21:04 MasterDuke joined 21:15 sena_kun joined 21:17 Altai-man left 21:48 MasterDuke left