github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
04:49 brrt joined 06:37 brrt left 06:49 lizmat left 07:04 lizmat joined 07:11 robertle joined, stmuk_ joined 07:13 stmuk left 07:30 zakharyas joined 07:33 domidumont joined 08:03 zakharyas left 08:06 zakharyas joined 08:12 brrt joined
brrt \o 08:21
nwc10 p/ 08:25
oops, off-by-one
o/
08:48 domidumont left 08:49 domidumont joined
brrt ohai nwc10 08:53
samcv good morning 08:56
brrt ohai samcv 08:57
still in .NL?
samcv yep
i'm here until YAPCEU
brrt nice :-) 08:58
where are you staying?
I apologise for the wheather
nwc10 "I'm here all week" xx 4
samcv i'm staying with my boyfriend who lives in NL
i want to get a job here
went to the NL perl workshop a week ago which was pretty fun 08:59
brrt cool :-) I kind of wanted to go but couldn't
jnthn o/ 09:08
brrt \o 09:09
jnthn is missed the NL workshop, and won't be at Glasgow, but will make it to the Swiss Perl Workshop in Bern :) 09:11
s/is// :)
brrt I'm thinking of going to the SPW as well, probably not glasgow 09:12
from my place, a train goes to bern, and that's an advantage 09:13
jnthn Yeah, that's nearly true of me too
Direct sleeper train to Zurich, then Bern is just 1 more hour
09:27 zakharyas1 joined 09:30 zakharyas left 09:34 dogbert2 joined
dogbert2 good morning 09:44
nwc10 "sleeper train" - my limited expierence was that whilst I started out by calling them that, they carefully don't *advertise* them as such, and they didn't function as such (for me) 09:45
jnthn I wouldn't say I get the best sleep ever on them, but I do tend to sleep a reasonable number of hours :) 09:46
dogbert2 do you get any sleep at all given the current heatwave 09:50
dogbert2 has 30 degrees centigrade in the apartment 09:51
brrt Airconditioning is starting to look attractive 09:52
dogbert2 indeed
brrt I renember a few years ago, lizmat and woolfy were installing airco, and I thought 'why would you need that, it isn't warm so often'
how wrong I was
Geth MoarVM: b7c6afd929 | (Jonathan Worthington)++ | src/mast/compiler.c
Use larger integer time to iterate strings heap

It was overflowing and resulting in the compilation failure reported in github.com/rakudo/rakudo/issues/2056. However, it's also perhaps a little concerning that the file has a string heap of 275,305 strings.		 09:53
jnthn gah, integer type
lizmat brrt: hmmm.... we have airco in the place we live atm, but it came with the building: in our old place there has never been airco? 09:54
fans, yes :-)
FWIW, I also remember the summer of '76 :-) 09:55
samcv brrt: it's been warm the last few nights here as well
lizmat I actually was in the UK that summer: en.wikipedia.org/wiki/1976_United_..._heat_wave
brrt :-o 09:58
dogbert2 29 degrees here (outside) atm 09:59
brrt re: trains. as usual, flying is much cheaper :-(
lizmat: then I misrenember it :-) 10:00
lizmat I think we were thinking about it at the time
I mean, the day we went to Eindhoven, it *was* very hot indeed :-)
brrt :-)
10:04 zakharyas1 left, zakharyas joined 10:05 zakharyas left 10:06 zakharyas joined 10:13 travis-ci joined
travis-ci MoarVM build errored. Jonathan Worthington 'Use larger integer time to iterate strings heap 10:13
travis-ci.org/MoarVM/MoarVM/builds/404372592 github.com/MoarVM/MoarVM/compare/a...c6afd929a9
10:13 travis-ci left
samcv jnthn: i have thought we could speed up hashing with integers keys by not converting them to strings 10:16
but i'm not sure where that code would need to be changed
jnthn Everywhere.
samcv so it doesn't convert to a string
jnthn At the moment we only support string keyed hashes 10:17
samcv well it will be string keyed
brrt hmm.... how'd that work?
samcv it will hash it as a string, but not create a VMString object
brrt oh, i see
that should be easy enough to circumvent
then again, an integer-typed hash table would be a nice addition 10:18
jnthn Ah, Travis failure is just travis-ci.org/MoarVM/MoarVM/jobs/404372600 (apt) 10:20
10:20 robertle_ joined 10:21 domidumont left 11:02 brrt left 11:03 zakharyas left 11:05 zakharyas joined 11:24 zakharyas left
samcv ok i'm going to merge the siphash code 11:34
if no objections
11:37 brrt joined 11:43 klapperl joined 11:44 klapperl_ left
brrt no objections from me :-) 12:00
samcv ok cool 12:03
Geth MoarVM: d9a3270aa2 | (Samantha McVey)++ | 12 files
Implement SipHash, use as our hashing function w/ 64bit hashvals

This switches our hashing function from "Jenkins's Lookup2" to SipHash.
This adds a heavily modified version of github.com/majek/csiphash which has been modified to use a struct to store the state and allow us to add 64 bits at a time (two graphemes). It also has been modified to take ... (16 more lines)		 12:07
MoarVM: 3049b04200 | (Samantha McVey)++ | 2 files
Mix in the instance pointer into the first hash secret

Just in case MVM_getrandom failed, make sure we do something with both of the hashSecrets.
MoarVM: 1a4adb0e33 | (Samantha McVey)++ (committed using GitHub Web editor) | 12 files
Merge pull request #889 from samcv/siphash

Implement SipHash, use as our hashing function w/ 64bit hashvals
12:14 domidumont joined 12:17 domidumont left 12:18 domidumont joined 12:19 domidumont left, domidumont joined 12:28 travis-ci joined
travis-ci MoarVM build passed. Samantha McVey 'Merge pull request #889 from samcv/siphash 12:28
travis-ci.org/MoarVM/MoarVM/builds/404413611 github.com/MoarVM/MoarVM/compare/b...4adb0e3392
12:28 travis-ci left
dogbert2 he, SEGV in t/spec/S06-currying/positional.t - #0 HASH_EXPAND_BUCKETS (tbl=0x804f160, tc=0x804c628) at src/strings/uthash.h:577 13:02
brrt oops 13:04
jnthn yeah, I see it too 13:12
dogbert2 could it be something for samcv? 13:15
samcv yeah. which version are you on 13:16
dogbert2 sec ... 13:17
samcv (of moarvm)
dogbert2 MoarVM version 2018.06.227.g.1.a.4.adb.0.e.3
last commit is - Implement SipHash, use as our hashing function w/ 64bit hashvals 13:18
samcv ok thanks
13:20 zakharyas joined
samcv not sure why the latest commit would cause it there but 13:20
i will investigate
Geth MoarVM: 2f807cd59c | (Timo Paulssen)++ | src/spesh/facts.c
learn facts from a couple of sp_ ops

inlining can cause ops that only spesh is allowed to output to be in the code when initial fact discovery is run. Until now, they weren't considered for facts like "known type" or "known value".
This helps improve code across inlines.		 13:29
samcv ok i bisected to e94d3dfdb534a4c2cba8ffeed268977d05c6917f 13:31
well it isn't triggered when I use ASAN 13:39
timotimo that would be too nice :| 13:40
samcv dogbert2: how did you find the src/strings/uthash.h:577 in HASH_EXPAND_BUCKETS 13:44
part
dogbert2 it was from gdb, I'll get you a gist ... 13:49
gist.github.com/dogbert17/0fdd3e66...918e6d9230 13:50
if I rerun the test with --no-optimize it crashes in another place, still seems hash related though 13:53
samcv well here's a gist gist.github.com/samcv/242c143b914e...75411c900d 13:55
well of valgrind
dogbert2 that might get you off the hook :)
perhaps 13:56
samcv well it seems exposed by my changes at least
though i suppose something bad could happen if something edited the hash in another thread between finding the key wanted to be deleted and it being deleted could attach to something nonexistant. or if the table expands then could cause issues 13:57
13:57 brrt left
samcv right now i'm erring on the side of my changes exposing some problem that already was there, though i could be totally wrong 13:58
but it's just totally weird that most hash code works perfectly but it crashes here
14:03 MasterDuke left 14:06 zakharyas left
samcv dogbert2: what are you thinking? 14:08
dogbert2 samcv: sometimes the error is ===SORRY!=== SC not yet resolved; lookup failed 14:09
samcv: have you tried running the test without your SIP changes? 14:10
samcv well i bisected it to e94d3dfdb534a4c2cba8ffeed268977d05c6917f
so yes
though it could also be src/6model/reprs/SCRef.c where it has HASH_FIND_AND_DELETE 14:12
so you can't delete things directly by their hash pointer anymore, you need the previous pointer, so we need to find it in the hash first
but maybe it's looking for the wrong thing. it seems like it found it, but it maybe was looking up the wrong thing?
dogbert2: here github.com/MoarVM/MoarVM/blob/mast...Ref.c#L117 14:13
that used to be HASH_DELETE(hash_handle, tc->instance->sc_weakhash, sc->body); 14:14
dogbert2 yeah
samcv dogbert2: ok i went back to before the bad commit. and commented out that delete key line, and i get the same crash 14:20
14:21 zakharyas joined
dogbert2 you mean commit d4d8ff41591f62cad686 14:24
samcv yeah that one is fine 14:25
one after is bad
dogbert2 this is tricky :) 14:27
samcv and it doesn't work when i tried to do 14:29
HASH_FIND(hash_handle, tc->instance->sc_weakhash, sc->body->hash_handle.key, sc->body->hash_handle.keylen, entry);
HASH_DELETE(hash_handle, tc->instance->sc_weakhash, entry);
well the new macros are different. but atm i'm on the last good commit 14:30
dogbert2 is sizeof(*(sc->body)) the same as sizeof(MVMSerializationContextBody *) 14:32
samcv no, left one is a struct right is a pointer 14:33
dogbert2 ah 14:35
14:42 zakharyas left 14:43 zakharyas joined 14:48 zakharyas left 15:07 zakharyas joined
jnthn Hm, turns out that just "don't inline the ctx op" isn't really enough 15:23
Because we might then go traversing (like asking for nqp::ctxcaller) 15:26
lizmat jnthn: fwiw, your last NQP change did not bring a change in broken spectests
jnthn lizmat: It never claimed ot
*to
They were all fixes for regressed modules 15:27
lizmat I know, just wanted to let you that indeed nothing changed
jnthn I'm only aware of one spectest fix I'm partiuclarly on the hook for anyway, which is the POST one
lizmat not that I expected it 15:28
jnthn ah, ok
Ah, plus there's some stressest in the async lock tests I should take alook at
* a look
I wonder how bad it would be if we just do an immediate global deopt on use of nqp::ctx 15:29
Hm, that means every single `start`
And probably various other things
lizmat any PseudoStash creation
samcv jnthn: wondering if you could help out with this issue me and dogbert2 are having 15:30
jnthn I'm not really bothered about those.
samcv: I'm already overwhelmed with stuff to fix/debug.
And not really enjoying it. 15:31
samcv ah ok
lizmat jnthn: it would also affect Regex.ACCEPTS
japhb jnthn: Yeah, I was just about to message you off-channel. You seem stressed.
jnthn samcv: If it's still an issue once I've dug myself out of this lot, I'll have a look.
samcv ok :)
jnthn japhb: Yes, I *want* to be getting on with a bunch of useful opts while I've got the time to work on them, but it looks like all the time is going to be eaten up chasing regressions. :S 15:32
japhb :-(
jnthn lizmat: ah, I'd missed that in my grep 15:33
lizmat: The use of CALLERS:: in your P5quotemeta module is the current case I'm looking at
But it's not alone 15:34
I'm wondering if we can somehow deopt chunks of the stack
But it's all really quite messy
Because what if the context is taken on one thread and used on another?
I also wondered "what if the MVMContext is paired with an inline index" 15:35
Then realized that if we do that, but then we deopt that context, it's suddenly very broken in very bad ways 15:36
Ah, and that Regex one is actually probably at the heart of my Yapsi is busted too 15:37
*of why
lizmat so, maybe we should say: if you use a PseudoStash, it's DIHWIDT if you cross thread boundaries ?
jnthn It's not that we didn't have these problems before, it's just that we've got better at inlining than we were before, and it's caught up wiht us. 15:38
lizmat: That'd be slightly awkward when we explicitly do the equivalent of that with `start`, alas.
lizmat ah, the infamous: nqp::bindattr($p, Promise, '$!dynamic_context', nqp::ctx()); hack 15:39
jnthn Well, it's not really a hack, it's implementing a feature TimToady++ insisted on, and I think was overall right to want.
lizmat perhaps a special thread-aware nqp::ctx is warranted ? 15:40
jnthn I had wondered if a "non-traversable" nqp::ctx is
So it's limited in which things you can then do with it 15:41
And asking for the one that supports everything gets you a deopt
I figure that we can probably support a handful of things safely 15:42
Just not the general traversal 15:43
And if that set of things can include what `start` and `Regex.ACCEPTS` needs, then we'll be good.
lizmat would changing CALLERS: to CALLER: help ? 15:45
jnthn Not immediately, *but* if we can see the only way we're using the pseudostash is one direct CALLER lookup, we might be able to turn it into something better 15:46
lizmat the reason I'm using CALLER: versus CALLERS: is this: Cannot access '$_' through CALLER, because it is not declared as dynamic
jnthn o.O 15:47
I thought $_ was always dynamic
lizmat so maybe CALLER:: just needs DYNAMIC_CHAIN added to its mode ?
that's also what I thought hmmm
m: sub a() { dd CALLERS::<$_>.VAR.dynamic }; $_ = 42; a # seems to be the case 15:48
camelia Bool::True
jnthn I think maybe for the sake of unbreaking things, the most immediate solution would be to make nqp::ctx deopt
lizmat and fix it before release ? 15:49
jnthn And then we can introduce a new restricted form of it and opt some things in to it
lizmat ah, ok, like that
jnthn Well, making it deopt is to make sure we fix things before the release.
lizmat ok, I see, well that could work
jnthn If we manage to get some of the special forms in before the release, that's nice.
But I'd rather do that without a long list of release blockers. 15:51
15:51 squashable6 left, squashable6 joined
lizmat m: sub a() { dd CALLERS::<$_>.VAR.dynamic }; for ^10 { a } # why it is not marked dynamic ? 15:51
camelia No such method 'dynamic' for invocant of type 'Int'
in sub a at <tmp> line 1
in block <unit> at <tmp> line 1
jnthn Because there's no Scalar container there 15:52
lizmat $_ can be bound to something that's not a container?
15:52 zakharyas left
jnthn Yes, much of the time it'll just be bound directly to a value 15:52
lizmat ok, lemme see if I can make PseudoStash.AT-KEY DTRT 15:53
jnthn Probably the always-dynamics we can just identify by name
Currently looking to see if the ANTLR regression might be another cases of this problem 15:54
It's inline sensitive at least. 15:55
lizmat changing the loop's signature "-> $_ is copy" makes it not die 15:57
jnthn Yes, is copy forces a container 15:58
aha 16:01
So the ANTLR failure has Regex.ACCEPTS near the top of its backtrace 16:02
And the failure mode looks just like the Yapsi one
So, that's 3 of the issues that probably have the same root cause
lizmat ok, so at least we have a common cause to all of these 16:03
jnthn Which is rather nicer than the 1 issue today having 3 root causes...
Hmm...odd. Sticking a deopt_all in ctx doesn't actually help the tests at all 16:14
timotimo does it have to have any kind of interaction with the jit? 16:15
jnthn Oh, hmm. I did patch the JIT too, but it seems MVM_JIT_DISABLE=1 makes things good 16:16
Doesn't help ANTLR though
Nor Yapsi 16:17
That surprises me a bit 16:18
Oh, I guess that case uses the getlexcaller op 16:19
16:19 lizmat left 16:24 lizmat joined 16:28 robertle_ left
jnthn Very odd, adding the deopt in there fixes P5quotemeta under JIT, but not EXPR JIT, but I can't see the EXPR JIT doing that op 16:31
16:33 brrt joined
lizmat
.oO( action at a distance :-( )
 16:36
jnthn I'm going to build a frame walking abstraction that can cope with inlined frames, so we can not repeat that logic "everywhere" 16:37
And that will allow for the getlexcaller op to be implemented without needing deopt
Which should solve the Yapsi issue
Maybe we can then use it to simplify the dynamic lexical lookup code too 16:38
lizmat that would be brill, as that is used a lot for some tasks
jnthn And perhaps to fix inlined things vanishing in stack traces
Note that getlexrelcaller is a different case 16:39
But we could allow for a "restricted" context to do that 16:40
I figure we'd rewrite MVM_frame_find_lexical_by_name_rel_caller with it something like gist.github.com/jnthn/f3a15e2902b4...ff60cdea4f 16:51
I'll have a break/dinner and maybe have a go at that later. 16:54
16:59 Geth left, Geth joined
lizmat jnthn++ 16:59
jnthn At least 3 busted modules are unbusted now, anyway.
16:59 brrt left
jnthn Oh, and one was yesterday to 17:02
*too
.tell AlexDaniel I don't see any Rakudo issue about the Proxy/rw behavior change. Does that mean things are fine enough with it, or do we need a back-compat fix?
yoleaux jnthn: I'll pass your message to AlexDaniel.
jnthn So far as I can tell, only that + #2080 are Rakudo level issues; the remaining blockers are MoarVM level ones 17:04
bbl
AlexDaniel . 17:27
yoleaux 17:02Z <jnthn> AlexDaniel: I don't see any Rakudo issue about the Proxy/rw behavior change. Does that mean things are fine enough with it, or do we need a back-compat fix?
AlexDaniel jnthn: how hard would it be? I was thinking that we just declare code returning proxies without `is rw` wrong, and that's it… 17:30
jnthn: not sure if you have seen that, but: colabti.org/irclogger/irclogger_log...07-14#l102 17:31
today I'm even more convinced that we should cut this release from before the rescalar merge
17:32 domidumont left
AlexDaniel so all rescalar-ish blockers are for 2018.08, in my opinion 17:32
and given that there's at least one month for these PRs that add missing `is rw`s to be merged, maybe that's not an issue 17:33
I mean back-compat is maybe not needed, but I'm not sure
and we'd have one month to decide if we need back-compat for that :) 17:35
17:37 ZofBot left 18:13 brrt joined
masak I'm getting some spurious 007 test suite failures that I think are also spesh-related 18:48
19:02 brrt left 19:28 brrt joined
moritz masak: easy to test with MVM_SPESH_DISABLE=1 19:33
masak doing so now. 19:38
19:52 ZofBot joined 19:56 lizmat left
jnthn AlexDaniel: Should be quite easy to just not bother decont'ing a Proxy. I realized that because of the way things work, at least on MoarVM we can choose that to be a 6.d change. 20:02
AlexDaniel hmmm 20:03
jnthn AlexDaniel: I'm fine with cutting a release before rescalar, but then you'll need to decide if the Star is going to ship a MoarVM release 2018.06 with Star 2016.07. Unless my analysis of things is way off, nearly all the remaining blockers are due to spesh-related changes, not due to rescalar. 20:04
20:04 lizmat joined
jnthn The 3 I fixed today were all rescalar specific. The one from yesterday was a change that came from that branch, but it exposed a long-standing bug. The github.com/rakudo/rakudo/issues/2069 issue is also related to the return value changes that came with rescalar, which is also the change that brought the Proxy behavior switch. 20:07
The rest all seem spesh related.
AlexDaniel jnthn: alternatively we can have moar 2018.07 with just a few commits cherry-picked (if there are any fixes that we really want to have)
jnthn True, though I fear there's at least some things in NQP that depend on things in moar, so there'll be some things to untangle that way too. 20:11
Up to you, but I'd be inclined not to panic yet, and see how things look by tomorrow/Wednesday.
AlexDaniel sure 20:12
though there's no panic, I'm just convinced that these changes are not ready for the Star release 20:13
in many different ways :) 20:14
jnthn Yeah, the timing is unfortunate.
lizmat as I said before, we could delay the release by a week or so 20:15
giving us extra time
and still be in time for e.g. TPCiG and the publication of Learning Perl 6 by brian d foy 20:16
AlexDaniel I don't understand, are these changes known to cause incredibly massive practical perf improvements or something? Why rushing them into the release is even considered? 20:17
no change in Text::CSV, nothing that I can see at least 20:18
jnthn AlexDaniel: There's some, but it's largely groundwork to make the next round of opts possible. 20:19
I already said that Star could go so far as to pick an entire MoarVM release back, so I'm hardly pushing for all the stuff in MoarVM master now to go in to it. :) 20:22
I'm just pointing out that there's dependencies across the 3 components, so any cherry-picking of various pieces would need careful testing. 20:23
AlexDaniel sure. I always rerun toaster right before every release, that counts as some testing at least 20:25
jnthn e.g. there's tests in NQP HEAD that need stuff that wasn't in MoarVM 2017.06, so either they'd need to be dropped or the relevant commits identified and picked.
AlexDaniel well, if these don't pass the release tarball won't be generated :) 20:26
tooling++
jnthn Sure, I'm not so much worrying about those as anything more subtle we might miss. :)
AlexDaniel anyway, I guess we'll come back to this a day or two later 20:27
AlexDaniel 💤 20:28
20:58 brrt left 21:05 MasterDuke joined
lizmat and another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2018/07/16/...llination/ 21:06
timotimo lizmat: i think rather than seize you meant cease? 21:15
lizmat grrr you're right 21:16
timotimo :)
at least you didn't write "crease"
lizmat
.oO( crease the moment )
geekosaur grease the moment? (they can be slippery at times...) 21:25
MasterDuke are moments as slippery as MONKEYs? 21:27
just got a segv building nqp, during `/home/dan/Source/perl6/install/bin/moar --libpath=src/vm/moar/stage0 src/vm/moar/stage0/nqp.moarvm --bootstrap --setting=NULL --no-regex-lib --target=mbc --stable-sc=stage1 --output=gen/moar/stage1/nqpmo.moarvm gen/moar/stage1/nqpmo.nqp`
geekosaur when they're not being silly putty, at least
21:35 lizmat left 21:36 lizmat joined
jnthn lizmat++ # thanks for another weekly! 21:58
22:12 robertle left
Geth MoarVM/frame-walker: fc747c94dd | (Jonathan Worthington)++ | 6 files
Extract frame walking logic from getlexcaller

It's not yet inline-aware. This step just separates out the walking logic from the various other activities we may perform while doing a walk.		 23:41
23:43 nebuchadnezzar left 23:48 buggable left, buggable 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!