github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:39 samcv left 00:40 samcv joined 00:44 lizmat left 02:25 dalek left 02:50 synopsebot left, dalek joined, SourceBaby left 02:51 p6lert left, Geth joined, p6lert_ joined, synopsebot joined, SourceBaby joined 02:58 p6lert_ left, p6lert joined 04:42 bartolin_ left, bartolin joined 05:07 bartolin left 05:15 bartolin joined 06:07 lizmat joined 06:33 robertle joined 07:20 domidumont joined 07:27 domidumont left 07:28 domidumont joined 07:55 zakharyas joined 08:49 Ven`` joined 10:11 Ven`` left
Geth MoarVM: b7dba08a1f | (Samantha McVey)++ | src/strings/siphash/test.c
Separate SipHash tests into separate tests
 10:38
MoarVM: a1de6dec0f | (Samantha McVey)++ | src/strings/siphash/test.c
Run all siphash tests even if we get some failures

Allows the script to run to completion while still identifying failures.
MoarVM: ce9f741b48 | (Samantha McVey)++ | src/strings/siphash/test.c
Fix a bug in the SipHash tests causing them to fail on Big Endian

There was nothing wrong with the SipHash implementation itself, just the test. It accidently changed Grapheme32 array to little endian instead of making Grapheme32_LE array little endian.		 10:45
10:58 travis-ci joined
travis-ci MoarVM build passed. Samantha McVey 'Run all siphash tests even if we get some failures 10:58
travis-ci.org/MoarVM/MoarVM/builds/408444248 github.com/MoarVM/MoarVM/compare/b...de6dec0fc1
10:58 travis-ci left 11:13 travis-ci joined
travis-ci MoarVM build failed. Samantha McVey 'Fix a bug in the SipHash tests causing them to fail on Big Endian 11:13
travis-ci.org/MoarVM/MoarVM/builds/408446562 github.com/MoarVM/MoarVM/compare/a...9f741b484d
11:13 travis-ci left 11:46 zakharyas left 12:56 zakharyas joined 13:16 Ven`` joined 13:22 yoleaux left, yoleaux joined 13:24 Ven`` left 13:35 brrt joined
brrt \o 13:35
samcv so i've confirmed siphash is working correctly on big endian as well and reworked and fixed an issue that caused tests to fail on big endian (wasn't an issue with siphash, just with the test) 13:37
13:38 Ven`` joined
brrt +1 13:38
samcv++ I should say (do we still have the bot that maintains those counts anyway?)
samcv counts? 13:39
timotimo o/ brrt
brrt \o timotimo
yeah, there was a bot that counted the ++'s
timotimo at some point, yeah
brrt i don't think anybody ever looked at that though 13:40
timotimo yeah, i think only the "express happyness/gratitude for the moment" part remains
which i'm fine with
samcv also for anybodies information, powerpc emulation is much faster than mips 13:47
using a wheezy qcow2 image i found online which was pretty convenient
brrt why would that be? mips harder to emulate? 13:51
masak brrt: back when we *did* look at the counts, au++ was so far ahead that being in second place didn't really mean much 13:52
brrt hehe 13:53
masak++ and jnthn++ for escape analysis 13:54
samcv brrt: probably just less work had been done optimizing it
it seems around 5x slower though 13:55
maybe more
on mips emulated it took 30 minutes to compile moarvm
probably takes a few minutes on ppc
brrt i'm memory-handicapped at the point, so I'm not running any emulators 13:57
and cooling-capacity handicapped :-(
lizmat we reached 36.2 here, now down to 35.0 and about to get some rain, whee!! 14:26
jnthn Uff, it's horribly warm here, though not quite *that* bad 14:27
brrt \o/ 14:28
lizmat: do you have your own measurement system?
lizmat well, an outside thermometer, if you'd call that a measurement system :-) 14:29
14:29 domidumont left 14:30 domidumont joined 14:37 Ven`` left, brrt left
AlexDaniel jnthn, samcv: so what are your thoughts on this release? 14:38
I know, difficult qusetion, and the heat doesn't help at all :) 14:39
14:43 lizmat left
AlexDaniel there are many options: we can delay more, we can skip it, we can ship as is, we can release an earlier version from a branchā€¦ 14:45
14:45 lizmat joined
AlexDaniel releasing from a branch is probably not as bad, it'll be pretty much 2018.06 with a few fixes 14:46
which is ok
but can we do better? 14:47
jnthn It depends on the definition of "better"
14:48 brrt joined
timotimo depends on what your definition of "is" is 14:48
lizmat I would be in favour of releasing 2018.07 as is now, but *not* cut a Rakudo Star release from it: postpone *that* to 2018.08 14:49
AlexDaniel right, well. I personally care more about not breaking existing things, and for me additional fixes or speedups are just a nice bonus 14:50
lizmat rather than a. not release at all, or b. basically re-release 2018.06
AlexDaniel lizmat: if 2018.07 is so not good that we don't want a Star release to be based on it, why release it at all? :)
lizmat because we want to get more data points of people using the latest compiler release, so that we can make 2018.07 better 14:51
brrt we still have the windows JIT bug though 14:52
lizmat especially hash key order changes are important to get out there
AlexDaniel brrt: we can cherry pick things
lizmat ok, *that* I would consider a blocker
brrt .... whatabout... releasing 2018.07, but with a patch to disable JIT on windows
14:53 Ven`` joined
brrt I know you have your schedule and all, but I simply can't see to getting it fixed in time 14:53
jnthn Part of the point of Star was that it could have its own release schedule and lean towards stability.
So there's no reason there can't be a Star this month, just including the 2018.06 release of MoarVM/Rakudo.
lizmat that could also work 14:54
jnthn I don't feel strongly on any of the options for the Rakudo 2018.07 release. It is clear than quite a lot of people do follow compiler releases, though. 14:55
robertle any recommendations for debian? we probably don't care so much about a windows JIT bug...
not many people will be using the debian packages at the moment though...
jnthn robertle: Yes, we do care about a Windows JIT bug.
AlexDaniel more people use monthly releases than star 14:56
using them to beta test stuff for star is a no no for me
robertle jnthn: even I do care about it, but it does not matter for the debian packages as they won't be run on windows
lizmat AlexDaniel: that we know of: R* is more darkpanny
AlexDaniel lizmat: than monthly releases? Where's the info coming from? 14:57
lizmat well, deduction, really: if someone wants to just try out Perl 6 and goes to perl6.org, they very quickly wind up at a Rakudo Star download
jnthn Anyway, I think the best we can do for a 2018.07 that actually will be in .07 is to see if there's anything we really, really want to have in there over 2018.06 and if so, consider a release branch that includes those. However, merging back a cherry-pick'd thing is not nice.
AlexDaniel not nice why exactly? 14:59
because we will have some commits twice?
15:00 Ven`` left
jnthn Yes, and thus quite possibly conflicts to resolve 15:00
Not a real blocker if it's just a handful of commits though
AlexDaniel that's not an issue, I'll handle it
robertle: do you have any stats on the % of people who use testing/unstable instead of stable? 15:05
lizmat: it really depends. If I wanted to try out perl6, chances are I wouldn't even open any webpage at all (apt install perl6) 15:06
lizmat: and even if I did, I'm presented with a shiny blue button to get a third-party deb
lizmat ok, but if *that* is the case, what is the reason that Rakudo Star still exists then ? 15:07
AlexDaniel lizmat: and the alternative to that is *compiling star from source*
that's a wonderful question
that's what Zoffix also wondered when they were looking at survey results
it's different for Windows users I assume 15:08
survey: docs.google.com/forms/d/19qSBpGWWc...lytics#c31 15:09
note that tarballs+third-party+distro outweighs star 15:10
15:17 robertle left 15:29 domidumont left
AlexDaniel found debian stats: popcon.debian.org/ 15:41
ā€œStatistics per popularity-contest releasesā€
so, roughly, it's a bit more than 10% I guess? 15:43
compared to last stable 15:44
actuallyā€¦ let's look at rakudo package itself :) 15:45
ehhā€¦ no stats per version qa.debian.org/popcon.php?package=rakudo 15:46
timotimo surely robertle would be able to help us out with that 15:47
AlexDaniel well, it's not critical. I was just wondering if a significant % of users installs rakudo directly from repos on testing/unstable 15:48
heh, I don't get this one: qa.debian.org/popcon-graph.php?pac...beenhere=1 15:50
ah, I get it. apt install rakudo instead of apt install perl6 15:51
the rise of moarvm :) qa.debian.org/popcon-graph.php?pac...beenhere=1 15:52
15:55 robertle joined 16:13 brrt left
TimToady the original purpose of Star was to be a prototype distribution, on the assumption that there will eventually be multiple distributions 16:25
that future has not yet been distributed very far, however 16:26
robertle reminds me: is this the full list of modules distributed with star, or just a part of it? github.com/rakudo/star/tree/master/modules 16:30
I am trying to work out what modules are the most important ones for a distribution, and thought I could just take the list from star as a starter... 16:31
TimToady and part of the goal of that distribution model was to allow HEAD to be sufficiently unstable to continue to evolve, not follow the Perl 5 tendency toward ossification 16:35
16:36 brrt joined
TimToady and different distributions can set that stability knob differently 16:37
brrt how are we up for releasing with a known bug, but defaulting to disabling it? 16:41
once it's fixed we can do a point release? 16:42
samcv brrt: defaulting to disabling it? 16:43
the bug or the feature? not sure what we're talking about
timotimo JIT on windows? 16:45
would be disabled completely?
brrt we'd default on not enabling the JIT on windows 16:46
at configure time
i'd like to disable the bug, but unfortunately that's a bit harder
16:46 diakopter joined
samcv .hmm. isn't that a pretty big thing? 16:51
16:52 avar left 16:53 avar joined, avar left, avar joined
brrt ... yes, but realistically, how many windows users do we have, and how many of them do performance critical things 16:53
.. . and no, i'm not enthusiastic about the prospect either 16:54
samcv i mean what is wrong about releasing later? 16:58
16:58 brrt left
samcv if it's not ready, then it's not ready 16:58
timotimo Lol, i blogged: wakelift.de/2018/07/26/wow-check-o...s-garbage/ 16:59
samcv unless there are more important things fixed since last release which are cause for us to do a release
17:07 stmuk_ joined
jnthn timotimo++ # nice post :) 17:07
And nice work
17:08 stmuk left
MasterDuke yes, timotimo++ 17:10
timotimo yay 17:11
MasterDuke .ask brrt the windows problem is just with the expression jit, correct? if so, could just it be disabled? 17:14
yoleaux MasterDuke: I'll pass your message to brrt.
masak timotimo++ 17:26
17:27 AlexDani` joined
jnthn bbl 17:28
17:30 AlexDani` left, AlexDani` joined, AlexDaniel left, AlexDani` is now known as AlexDaniel 17:41 zakharyas left 18:22 Ven`` joined 18:37 Zoffix joined
Zoffix Huge -1 on "<brrt> how are we up for releasing with a known bug, but defaulting to disabling it?" 18:37
brrt: a quarter of our users use Windows. And without JIT stuff is really slow.
+1 on "<AlexDaniel>: lizmat: if 2018.07 is so not good that we don't want a Star release to be based on it, why release it at all? :)" 18:39
There's no law that we have to cut a release every month.
And glancing at the changelog, there isn't some must-have feature that must be released right now and can't wait another 3.5 weeks.
lizmat Zoffix: it's not features I worry about, it's the unexpected results of refactoring that we need to find out about 18:40
hence my suggestion to release 2018.07, but *not* do a Star release based on that
18:41 Ven`` left
Zoffix lizmat: ah, yeah, that sounds alright, if it star is not based on it. 18:41
Zoffix is mildly annoyed by now 2 devs effectively saying "who cares about windows" 18:42
TimToady
.oO(Who cares about VMS?)
 18:43
geekosaur that's a little different, since the list of non-carers includes its owner 18:45
Zoffix lizmat: in your suggestion, would star be based off 2018.08 or 2018.06? 18:47
lizmat 2018.08
Zoffix +1
lizmat well, if we deem 2018.08 to be good enough, or course :-)
Zoffix :)
japhb +1 to that from me as well, FWIW. I am strongly against a Star based on a weak release. 18:52
Since as TimToady points out there is not really a competitive landscape in Rakudo distros, and I'd like to have at least one Rakudo distro that monotonically converges on stable (sortof the RHEL/CentOS role back in the day), Star is it for now. 18:54
19:01 Kaiepi left 19:02 Kaiepi joined 19:07 Kaiepi left 19:25 Zoffix left
AlexDaniel Zoffix: the changelog is actually not fully populated, I was postponing it because I wasn't sure which commits would be in the release 19:36
19:37 Kaiepi joined
AlexDaniel anyway, I'm not sure. I guess it's ok to skip 2018.07, but I can also do a light release from 2018.06 + some fixes 19:45
and I'm definitely not releasing what we have on HEAD :) 19:50
lizmat AlexDaniel: why ? 19:56
20:11 brrt joined
AlexDaniel because people use monthly releases and I think that testing something knowingly unstable on them is unfair 20:17
if we release it as 2018.08-RC then it's different
stmuk_ star needs to work on windows with JIT so I can base star either on 2018.06 or 2018.06+cherrypicking 20:20
AlexDaniel or wait for 2018.08, right?
stmuk_ yes
20:23 robertle left
AlexDaniel šŸ’¤ 20:25
brrt hmm 20:26
i'm not thrilled about htis
stmuk_ what about 2018.06-25-ge9351cb? 20:27
brrt finding myself in the critical path of the release 20:28
stmuk_ apparenlly that passes on windows
brrt what commit is that, actually? 20:29
stmuk_ that was from github.com/rakudo/rakudo/issues/20...-405027222 20:31
I will experiment on windows tomorrow 20:33
20:34 Ven`` joined
stmuk_ I can bisect to last working windows (probably later than 2018.06-25-ge9351cb) 20:34
brrt that'd help, maybe
MasterDuke brrt: would the jit bisect tool help? 20:36
brrt if you have a test that doesn't spawn, maybe, yes 20:37
what would help most is a clean replication
because that is probably the most time consuming element
japhb timotimo: Amongst a couple minor typos in your GC post, a possibly confusing one: "The little asterisk denotes which GC was responsible for kicking off the GC run." Perhaps the first 'GC' should be 'thread' instead? 20:38
brrt oh, yes, timotimo++ 20:39
japhb Also, in the new UI, it might be nice for the "Time spent per GC run" chart at the top to somehow highlight which ones were full collections. 20:40
Otherwise very nice work (and post) timotimo! 20:42
20:47 Ven`` left 20:49 brrt left 20:51 avar left 20:55 avar joined, avar left, avar joined 21:18 brrt joined
timotimo indeed, thank you japhb 21:21
japhb: yup, until just before i made the screenshot, i had filtered out the major collections by default, i just decided to turn that off, and later have a switch in the UI
what other typos did you find? 21:22
miliseconds -> milliseconds apparently
21:29 brrt left
Geth MoarVM: jstuder-gh++ created pull request #920:
Move some exprjit templates to the proper order		 21:50
japhb timotimo: Oh, didn't remember them all. I can check again if need be, but these days I usually worry less about the minor typos that don't change meaning, than the ones that might actually confuse someone. :-) 22:17
timotimo japhb: imgur.com/44vePUL this is what it looks like if you don't filter out major collections by default :D
japhb OOOhhh. I see the problem 22:20
Better scale (or non-linear mapping) needed. 22:21
timotimo i believe my charts library supports that
japhb Perhaps something like the one I did for the speed sparkline in #perl6-dev
timotimo filter out outliers? 22:22
japhb Yeah, exactly. 22:25
Outlier detection is useful, and by itself can make a huge difference to graph readability, without having to go to a scaling that doesn't make a lot of sense to people's mental models. 22:26
And the trick is not to filter them out entirely, but to just not include them in picking the Y range.
timotimo right 22:27
how do you do this right? 22:28
sort by value and see if the first value is very far from the rest?
jnthn timotimo: Maybe compare to some kind of average? 22:29
geekosaur compute standard deviation and reject values outside some multiple of it, often
timotimo filter out anything above 3x standard deviation?
ah, heh. 22:30
japhb github.com/zoffixznet/perl6-buggab.../Speed.pm6
It ... has grown a bit over the years.
Also, it has to do clipping in a kindof funky way, because it doesn't have the advantage of just drawing outside a clipping rectangle, and it has to handle multiple lines of text pretending to be one graph.
But essentially geekosaur is correct, see lines 48 through 55 22:31
(Line 55 prevents a *very* steady value, so all variation is just measurement noise, from getting magnified into what appears to be all over the range) 22:32
Lines 73 to 81 are my attempt at doing the stats in a way that doesn't cause you to go blind. :-) 22:33
timotimo hm, what's the param_on2_* and param_rn2_* ops for? 22:34
i.e. what's the 2 for?
oh? the jit log has "A PHI node should not have an after label" 22:36
22:36 Kaiepi left
japhb timotimo: You appear to be responding to someone who isn't there. 22:36
22:36 Kaiepi joined
jnthn timotimo: Renaming syntax 22:39
sub foo(:a(:$aadvark)) { }
timotimo ah, i see
japhb: i'm spouting out new random findings, actually
japhb Ah 22:40
timotimo ctxcaller shouldn't be hard to jit, right? nothing very special about it? 22:41
Geth MoarVM: 41108cdaaa | (Timo Paulssen)++ | src/jit/expr.c
more consistently \n in exprjit log output
 22:44
jnthn timotimo: Not any more
timotimo ctxouter is probably almost the same except the traversal mode argument is different 22:45
right, i have the code right in front of me
i see bails for those in json_fast, but i believe they are not actually "hot"
SET_BLOCK_OUTER_CTX sound like compiler internals 22:46
handle_optional gets a ctxouter bail, which could be interesting for code in general 22:47
is_bindable from the bootstrap has an arrow function invoked via "p6invokeunder" and that uses ctxouter. probably not very hot, either, but maybe interesting 22:48
is_bindable is bailed by reprname %)
do we require repr names to be unique? in that case spesh could rewrite an eq of reprname and a const string to a reprid comparison 22:49
jnthn yes, repr names are unique 22:52
timotimo probably barely worth it :D 22:53
japhb Depends on how often it happens. :-) 22:58
23:05 travis-ci joined
travis-ci MoarVM build failed. Timo Paulssen 'more consistently \n in exprjit log output' 23:05
travis-ci.org/MoarVM/MoarVM/builds/408725677 github.com/MoarVM/MoarVM/compare/c...108cdaaa07
23:05 travis-ci left
timotimo is_bindable is called 8008 times throughout my json::fast benchmark, and it's actually at 3.77% inclusive time somehow 23:10
but the vast majority of time from that is spent below bind 23:14

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!