Perl 6 language and compiler development | Logs at colabti.org/irclogger/irclogger_log/perl6-dev | For toolchain/installation stuff see #perl6-toolchain | For MoarVM see #moarvm
Set by Zoffix on 27 July 2018.
00:08 Kaiepi left, Kaiepi joined 00:09 p6bannerbot sets mode: +v Kaiepi 00:29 travis-ci joined, p6bannerbot sets mode: +v travis-ci
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Final fixes to make metaops work on QuantHashes' 00:29
travis-ci.org/rakudo/rakudo/builds/455233104 github.com/rakudo/rakudo/compare/8...f03e677603
00:29 travis-ci left
buggable [travis build above] ☠ Did not recognize some failures. Check results manually. 00:29
03:13 ufobat___ joined 03:14 p6bannerbot sets mode: +v ufobat___ 03:17 ufobat_ left 04:13 MasterDuke left 05:46 robertle left 05:58 zostay left 05:59 zostay joined, huggable left, p6bannerbot left 06:03 lizmat left
releasable6 Next release in ≈2 days and ≈11 hours. 4 blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 07:00
[Tux] Rakudo version 2018.10-135-gc3f03e677 - MoarVM version 2018.10-77-g6236eb5de
csv-ip5xs0.921 - 0.925
csv-ip5xs-207.205 - 7.314
csv-parser23.293 - 23.631
csv-test-xs-200.426 - 0.433
test7.594 - 8.459
test-t1.871 - 1.905
test-t --race0.869 - 0.881
test-t-2033.114 - 33.247
test-t-20 --race10.818 - 10.934
 07:36
07:44 AlexDani` joined 07:48 AlexDaniel left 08:41 lizmat joined 08:49 robertle joined 10:09 AlexDani` is now known as AlexDaniel 10:18 AlexDaniel left, AlexDaniel joined 10:21 ChanServ sets mode: +vvvv robertle lizmat AlexDaniel zostay 10:24 timewasteable6 joined, ChanServ sets mode: +o timewasteable6
Geth_ rakudo: 1ed2b098eb | (Elizabeth Mattijsen)++ | src/core/metaops.pm6
Cache METAOP_ASSIGN ops

Not to specifically to make it faster, but to be able to assign a name to the generated block without incurring a runtime penalty for that. The name will allow metaoperators to introspect and optimize >>+=>> with about a factor of 2.
Pushed as a separate commit for bisecting.		 11:38
AlexDaniel Zoffix: if you can bring banbot back to life that'd be nice (currently running my own instance) 11:53
dogbert17 what is timewastable? 12:18
lizmat dogbert17: an instance of p6bannerbot for now 12:19
dogbert17 ah I see 12:20
lizmat: btw, how was the Grindelwald movie? 12:27
lizmat if you see the two of them in a row, as we did, it's a lot less than the first, story wise 12:28
if you're in for the magic: plenty of that :-)
dogbert17 CGI effect galore then :) 12:29
*effects
12:29 brrt joined
lizmat dogbert17: indeed :-) 12:30
12:30 timewasteable6 sets mode: +v brrt
dogbert17 lizmat: are you aware that t/05-messages/10-warnings.t is complaining? 12:32
lizmat am now, and looking at it 12:33
dogbert17 that was hyper quick :) 12:34
lizmat I guess I need to look at the [R~] generating code 12:37
that should give a name as well
argh
guess I can't key the cache on the name 12:40
Geth_ rakudo: 21434dda43 | (Elizabeth Mattijsen)++ | src/core/metaops.pm6
Correctly handle META_ASSIGN ops that don't have a name

Because they were generated, e.g. [R~] -> [R~]= dogbert++ for spotting		 12:55
13:04 brrt left
lizmat AlexDaniel: I guess that Travis is not getting on the channel anymore either? 13:09
AlexDaniel lizmat: oh, I think you're right 13:15
lizmat .ask samcv given a hash that has no changes in keys, will it always produce the same order in keys / values or can a second call to .keys produce a different order? 13:16
yoleaux lizmat: I'll pass your message to samcv.
AlexDaniel although
colabti.org/irclogger/irclogger_lo...8-11-15#l3
lizmat but Cache METAOP_ASSIGN ops also broke Travis
and I didn't see that here ? 13:17
AlexDaniel yeah, weird. I don't know
dogbert17 AlexDaniel: is it possible for the bots to figure out when M#720 was fixed? 13:43
synopsebot_ M#720 [open]: github.com/MoarVM/MoarVM/issues/720 Oops inline fix_coderef NYI triggered with --profile
lizmat FWIW, I've seen t/spec/S06-advanced/callframe.rakudo.moar fail with register type mismatch error 13:52
13:56 Kaiepi left, Kaiepi joined 13:57 timewasteable6 sets mode: +v Kaiepi 13:58 travis-ci joined, timewasteable6 sets mode: +v travis-ci
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Correctly handle META_ASSIGN ops that don't have a name 13:58
travis-ci.org/rakudo/rakudo/builds/455481502 github.com/rakudo/rakudo/compare/1...434dda43c8
13:58 travis-ci left
buggable [travis build above] ☠ Did not recognize some failures. Check results manually. 13:58
lizmat again, a single job failed, restarted
AlexDaniel c: HEAD chdir ‘sandbox’; run <perl6 --profile -e>, ｢say + ^100 .grep( *.indices("7") == 2 )｣
committable6 AlexDaniel, ¦HEAD(21434dd): «1␤Writing profiler output to profile-1542290336.7779298.html␤»
AlexDaniel c: 2017.06 chdir ‘sandbox’; run <perl6 --profile -e>, ｢say + ^100 .grep( *.indices("7") == 2 )｣ 13:59
committable6 AlexDaniel, ¦2017.06: «1␤Writing profiler output to profile-1542290343.84511.html␤»
AlexDaniel c: 2017.10 chdir ‘sandbox’; run <perl6 --profile -e>, ｢say + ^100 .grep( *.indices("7") == 2 )｣
committable6 AlexDaniel, ¦2017.10: «1␤Writing profiler output to profile-1542290352.65888.html␤»
AlexDaniel c: 2017.12 chdir ‘sandbox’; run <perl6 --profile -e>, ｢say + ^100 .grep( *.indices("7") == 2 )｣
committable6 AlexDaniel, ¦2017.12: «1␤Writing profiler output to profile-1542290356.16514.html␤»
AlexDaniel c: 2017.09 chdir ‘sandbox’; run <perl6 --profile -e>, ｢say + ^100 .grep( *.indices("7") == 2 )｣
committable6 AlexDaniel, ¦2017.09: «1␤Writing profiler output to profile-1542290359.05335.html␤»
AlexDaniel 6c: chdir ‘sandbox’; run <perl6 --profile -e>, ｢say + ^100 .grep( *.indices("7") == 2 )｣
dogbert17: sure, as long as we can figure out when it was *not* ok
committable6 AlexDaniel, gist.github.com/1851fb2824fb31f348...5ed62580bf
AlexDaniel dogbert17: is it this? gist.github.com/Whateverable/1851f...result-L79 14:00
14:08 travis-ci joined, timewasteable6 sets mode: +v travis-ci
travis-ci Rakudo build passed. Elizabeth Mattijsen 'Correctly handle META_ASSIGN ops that don't have a name 14:08
travis-ci.org/rakudo/rakudo/builds/455481502 github.com/rakudo/rakudo/compare/1...434dda43c8
14:08 travis-ci left
lizmat ok 20 - Exploring call frames until no code object does not crash 14:10
MoarVM panic: Register types do not match between value and node
this appears to only happen under load when running t/spec/S06-advanced/callframe.rakudo.moar repeatedly
so it seems to crash in the test for R#1781 14:11
synopsebot_ R#1781 [closed]: github.com/rakudo/rakudo/issues/1781 callframe info changes inside multi sub
dogbert17 AlexDaniel: yes 14:14
lizmat: M#992 14:15
synopsebot_ M#992 [open]: github.com/MoarVM/MoarVM/issues/992 [⚠ blocker ⚠] MVM_panic in t/02-rakudo/12-proto-arity-count.t
AlexDaniel bisect: old=2017.08 chdir ‘sandbox’; run <perl6 --profile -e>, ｢say + ^100 .grep( *.indices("7") == 2 )｣
bisectable6 AlexDaniel, Bisecting by exit code (old=2017.08 new=21434dd). Old exit code: 1
AlexDaniel, bisect log: gist.github.com/5adf73baea94e9d757...1d33b0b7db 14:16
AlexDaniel, (2017-09-04) github.com/rakudo/rakudo/commit/13...f9f0843a50
AlexDaniel mmm no that's not it 14:17
dogbert17 was hoping we could get rid of it :) 14:19
Geth_ rakudo: 234e298bf7 | (Elizabeth Mattijsen)++ | src/core/Hyper.pm6
Make metaops with assigning ops between 1.3x and 1.7x as fast

If the left hand side of a meta op is a mutable structure, and we know that the op does an assignment, we don't have to build any result structure as the result is the same as the left hand side then. This allows for quite some savings.		 14:23
AlexDaniel dogbert17: I dn't think it is resolved
don't*
lizmat makes @a >>+<< 1 only 2x as slow as $_ += 1 for @a 14:25
timotimo wait, doesn't that have to be @a >>+>> 1? 14:26
yoleaux 14:03Z <thundergnat> timotimo: Ah! I was stuck in Perl5 mode and expected a failed open to set $! That ought to go into traps at least. Thanks!
14:08Z <thundergnat> timotimo: In particular, these paragraphs are misleading (pertaining to failed open): github.com/perl6/doc/blob/master/d....pod6#L542
timotimo er
lizmat timotimo: ah, duh,. yeah
timotimo also +=
lizmat makes @a >>+>> 1 only 2x as slow as $_ += 1 for @a
timotimo typos abound :)
lizmat makes @a >>+=->> 1 only 2x as slow as $_ += 1 for @a
AlexDaniel dogbert17: ah no, maybe it is…
lizmat yt][;jkhdasl;kjghlkdahgeuygfqew,hvsc :-) 14:27
time for me to get some afk&
AlexDaniel bisect: old=2017.08 chdir ‘sandbox’; for ^20 { exit 42 if run(:out, <perl6 --profile -e>, ｢say + ^100 .grep( *.indices("7") == 2 )｣).out.slurp-rest.contains: ‘oops’ } 14:28
ok that's gonna work better
bisectable6 AlexDaniel, Bisecting by output (old=2017.08 new=21434dd) because on both starting points the exit code is 0
AlexDaniel nooooooooooo
bisectable6 AlexDaniel, bisect log: gist.github.com/c27e67c95b4874010d...2dba2aafec 14:29
AlexDaniel, (2017-08-21) github.com/rakudo/rakudo/commit/5d...72387e9f75
AlexDaniel bisect: old=2017.08 chdir ‘sandbox’; for ^20 { exit 42 if run(:out, <perl6 --profile -e>, ｢say + ^100 .grep( *.indices("7") == 2 )｣).err.slurp-rest.contains: ‘oops’ }
bisectable6 AlexDaniel, Bisecting by output (old=2017.08 new=234e298) because on both starting points the exit code is 1
AlexDaniel bisect: old=2017.08 chdir ‘sandbox’; for ^20 { exit 42 if run(:err, <perl6 --profile -e>, ｢say + ^100 .grep( *.indices("7") == 2 )｣).err.slurp-rest.contains: ‘oops’ }
bisectable6 AlexDaniel, bisect log: gist.github.com/026c61932cc0346bee...dcaafbee0c 14:30
AlexDaniel, (2018-01-01) github.com/rakudo/rakudo/commit/53...4d6c7e57d8
AlexDaniel, Bisecting by exit code (old=2017.08 new=234e298). Old exit code: 42
AlexDaniel OK now that's a good sign
dogbert17 things are looking up
bisectable6 AlexDaniel, bisect log: gist.github.com/cb53d2c60e772a72a7...613e95ee76 14:31
AlexDaniel, (2017-09-13) github.com/rakudo/rakudo/commit/7f...49c423bc9a
AlexDaniel o_o
dogbert17 that can't be the right one 14:35
AlexDaniel yeah, I'm progressing slowly on #whateverable to avoid bot spam here 14:36
dogbert17 ok 14:38
14:54 Kaiepi left, Kaiepi joined 14:55 timewasteable6 sets mode: +v Kaiepi
AlexDaniel github.com/rakudo/rakudo/commit/75...fa3327a641 15:03
github.com/rakudo/rakudo/commit/1d...f33a17066f
dogbert17: so it disappeared after these two
and I don't know what it means for that ticket 15:04
we can probably close it as “can't reproduce anymore” but the underlying issue is probably still there
dogbert17 will you close it or should I? 15:05
15:13 |Tux| left
AlexDaniel dogbert17: I left a comment: github.com/MoarVM/MoarVM/issues/72...-439074470 15:14
I don't know if closing it is just closing our eyes on the issue 15:15
15:24 |Tux| joined 16:27 brrt joined, timewasteable6 sets mode: +v brrt 16:35 Zoffix joined, timewasteable6 sets mode: +v Zoffix, ChanServ sets mode: +o Zoffix, p6bannerbot joined, timewasteable6 sets mode: +v p6bannerbot, ChanServ sets mode: +o p6bannerbot 16:36 Zoffix sets mode: +vv |Tux| timewasteable6 16:37 Zoffix left, buggable left, buggable joined, ChanServ sets mode: +v buggable, huggable joined, ChanServ sets mode: +v huggable, ZofBot left, ZofBot joined, ChanServ sets mode: +v ZofBot, timewasteable6 sets mode: +v ZofBot, p6bannerbot sets mode: +v ZofBot 16:38 SourceBaby joined, ChanServ sets mode: +v SourceBaby, timewasteable6 sets mode: +v buggable, p6bannerbot sets mode: +v buggable, timewasteable6 sets mode: +v huggable, p6bannerbot sets mode: +v huggable, timewasteable6 sets mode: +v SourceBaby, p6bannerbot sets mode: +v SourceBaby
nine lizmat: it crashes _after_ the test for R#1781, i.e. at the end of the program which is consistent with my suspicion that we try to JIT compile something when we're already shutting down 16:40
synopsebot_ R#1781 [closed]: github.com/rakudo/rakudo/issues/1781 callframe info changes inside multi sub
samcv . 17:06
yoleaux 13:16Z <lizmat> samcv: given a hash that has no changes in keys, will it always produce the same order in keys / values or can a second call to .keys produce a different order?
samcv lizmat, a second call will make the same order
if no key has been added
17:09 pmurias joined, p6bannerbot sets mode: +v pmurias, timewasteable6 sets mode: +v pmurias 17:13 timewasteable6 left
AlexDaniel Zoffix: thank you! 17:13
17:26 robertle_ joined 17:27 p6bannerbot sets mode: +v robertle_ 17:32 travis-ci joined, p6bannerbot sets mode: +v travis-ci
travis-ci NQP build failed. Paweł Murias '[js] Use jsbi instead of BigInt in most places 17:32
travis-ci.org/perl6/nqp/builds/455602348 github.com/perl6/nqp/compare/c899f...1f8d573d19
17:32 travis-ci left
pmurias what's the procedure to bump MoarVM for nqp? 17:41
it seems like we are failing a test because it depends on a MoarVM with a fixed bug? 17:42
Geth_ nqp: 115212ed85 | (Aleks-Daniel Jakimenko-Aleksejev)++ | tools/build/MOAR_REVISION
[MoarVM Bump] Brings 2 commits

MoarVM bump brought: github.com/MoarVM/MoarVM/compare/2...g6236eb5de 6236eb5de it's important to use these facts, or else crashes 950011e14 Make sure nqp::serializetobuffer always returns a buffer		 17:43
¦ nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2...g6236eb5de
rakudo: 4d8d897b94 | (Aleks-Daniel Jakimenko-Aleksejev)++ | tools/build/NQP_REVISION
[NQP Bump] Brings 5 commits

NQP bump brought: github.com/perl6/nqp/compare/2018....g115212ed8 115212ed8 [MoarVM Bump] Brings 2 commits 861f8d573 [js] Use jsbi instead of BigInt in most places c899f4a08 [js] Fix nqp::serializetobuf 846b8fcf2 [jvm] Implement nqp::serializetobuf 19653bf34 Basic test for nqp::serializetobuf
¦ rakudo: version bump brought these changes: github.com/perl6/nqp/compare/2018....g115212ed8
AlexDaniel pmurias: the easiest way is to use z script: github.com/zoffixznet/z
otherwise you just run `git describe` and put the output into appropriate files
17:54 pmurias left 17:55 pmurias joined, p6bannerbot sets mode: +v pmurias 17:59 travis-ci joined, p6bannerbot sets mode: +v travis-ci
travis-ci NQP build passed. Aleks-Daniel Jakimenko-Aleksejev '[MoarVM Bump] Brings 2 commits 17:59
travis-ci.org/perl6/nqp/builds/455612960 github.com/perl6/nqp/compare/861f8...5212ed85bc
17:59 travis-ci left 18:11 brrt left 18:12 brrt joined 18:13 p6bannerbot sets mode: +v brrt 18:19 Geth_ left, p6lert_ left, Geth joined, ChanServ sets mode: +v Geth, synopsebot_ left, p6lert joined, synopsebot joined, ChanServ sets mode: +v synopsebot, p6bannerbot sets mode: +v Geth, p6bannerbot sets mode: +v p6lert 18:20 p6bannerbot sets mode: +v synopsebot
Geth rakudo: 6fe278941a | (Elizabeth Mattijsen)++ | src/core/Rakudo/Iterator.pm6
Introducing R:I.AssociativeIterableKeys

An iterator that takes an Associative (or anything else that supports AT-KEY) and an Iterable, and creates an Iterator of the values of these keys in the Associative.		 18:27
rakudo: b83179f057 | (Elizabeth Mattijsen)++ | src/core/hash_slice.pm6
Make hash slices without adverbs about 5x as fast

By using the new R:I.AssociativeIterableKeys iterator.
lizmat that should be noticeable in some applications :-) ^^ 18:40
hmmm... is there a way that a single candidate for the same number of iterations, use 181ms vs 27ms ? 19:24
19:37 brrt left 19:49 travis-ci joined, p6bannerbot sets mode: +v travis-ci
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Make hash slices without adverbs about 5x as fast 19:49
travis-ci.org/rakudo/rakudo/builds/455629501 github.com/rakudo/rakudo/compare/4...3179f0571b
19:49 travis-ci left
buggable [travis build above] ☠ Did not recognize some failures. Check results manually. 19:49
lizmat again, only one job failed, restarted
nine What failures are these? 19:58
lizmat didn't look 20:02
it's all green nonw
I assume one of the flappers
nine: I think you're assumption may be true 20:05
I'v added another test to S06-advanced/callframe.t
and ran it while spectesting in another window:
ok 22 - we've been good
MoarVM panic: Register types do not match between value and node
so, it cam through the test, and the test after that, and *then* crashed 20:06
*came 20:07
nine OTOH the error occurs before we reach the end of MVM_interp_run 20:11
Furthermore, while it finishes all tests, it doesn't print the FUDGED! message at the end 20:15
Well it was a nice theory 20:16
lizmat hmmm... good point :-( 20:32
Geth rakudo: e8285c0127 | (Elizabeth Mattijsen)++ | src/core/metaops.pm6
We need to cache on name

nqp::objectid is different for each call (not sure why), so that meant that the cache was filled with stale data. Now, if an op requests an META_ASSIGN, and it has no name, then it will take a slower path very close to what it originally was. If it *does* have a name, then it will be cached on the name of the original op.		 20:34
timotimo do we want to limit the size of the cache? 20:47
lizmat how many different metaop-assign ops would one use in a program ? 20:52
timotimo dunno, but it'd still not be great to have unlimited growth of caches like that :)
lizmat true, and actually I am considering priming them for += ~= -= 20:54
but I'll check first how much that would help :-)
the advantage of priming them would be that we could literally use the op, so "+" instead of "op" 20:55
that *should* optimize better, shouldn't it ?
timotimo i'm not entirely sure how you mean that 20:56
lizmat -> \a, \b { a + b } should optimize better than -> \a, \b { a op b } 20:57
timotimo you mean if op is a value closed over?
lizmat where op is a parameter to the sub returning that block
yup
timotimo hm, actually, i think if we're lucky with the inlining, it can actually inline at least one instance of those ops 20:58
but yeah, having a sub specifically for the op in question gives us a different cuid, which will have its own set of spesh candidates and everything
lizmat so you're saying it doesn't improve things.
timotimo not entirely sure which of the effects is stronger 20:59
lizmat ah, ok, I see... 21:00
timotimo there's also the question of whether we can generate the exact right ops at compile time, or if that already happens 21:01
lizmat well, I'm looking at why infix:<+> in one case takes (187.64ms) to do 26K invocations
timotimo if you use the profiler, it could very well be the profiling overhead is too strong to accurately measure
lizmat and in another situation takes (29.38ms) for the same 26K invocations 21:02
timotimo oh, wow, that's quite a difference
lizmat yeah... and that difference accounts for the difference I see *without* running the profiler
timotimo OK 21:03
lizmat basically the difference between %h >>+<< %h and %h >>+=<< %h
the latter should be cheaper as we don't need to build a result: the left hand side in that case *is* the result
but it's not :-( 21:04
21:04 ZzZombo left 21:05 ZzZombo joined, p6bannerbot sets mode: +v ZzZombo
lizmat timotimo: I think it's an artefact of it being called from a closed over "op" 21:20
Geth rakudo: 32ab0d30cb | (Elizabeth Mattijsen)++ | src/core/Hyper.pm6
Abstract final handling of %h >>op<< %h
 22:12
rakudo: 90ac0940aa | (Elizabeth Mattijsen)++ | src/core/metaops.pm6
Refactor METAOP_ASSIGN_NEW

It now takes the name and the op, making things simpler and allows it to also be used for priming.
22:13 [Tux] left 22:17 robertle_ left
lizmat jnthn timotimo: is there a technical reason not to have a built-in &infix:<+=> (and friends) ? 22:38
if we would have that, we could probably also get rid of the += rewriting optimization in the static optimizer 22:39
which seems, with the current optimizations, like a lot of codegen bloat
jnthn It'd mean that anyone who did and override of + had to also add one for that, no? 22:40
lizmat if it would be: sub infix:<+=>(\a,\b) { a = (a.DEFINITE ?? a !! 0) + b } 22:46
then it would still refer to whatever the infix:<+> is at moment of execution, no?
jnthn No
It'd refer to the + in the lexical scope where that sub was written
lizmat but if that would be at the same scope as the systems infix:<+>, then there wouldn't be an issue, would there be? 22:47
jnthn But what if the user's code had its own candidates too? 22:48
22:48 MasterDuke joined, p6bannerbot sets mode: +v MasterDuke, MasterDuke left, MasterDuke joined, herbert.freenode.net sets mode: +v MasterDuke, p6bannerbot sets mode: +v MasterDuke
lizmat jnthn: but don't we have that issue already with the METAOP_ASSIGN code returning a Block ? 22:48
that closes over the op ? 22:49
jnthn I thought that worked by passing in the current op?
lizmat aaah... ok... 22:50
hmmm...
ok, maybe I've been looking at an X/Y problem
given an op, I would like to know if the op is of a type that does assignment: aka += would be true, + would be false 22:51
my idea was to add the name to the generated blocks with the closed over ops
and then look if the name of an op ends in "=>"
jnthn In order to do what? 22:52
lizmat in meta ops, don't build a return result if the op was +=
as the return result will be the left hand side of the meta-op 22:53
makes something like %h >>+=<< %h about 25% faster
jnthn Ah, I see. Interesting. 22:54
Hmmmm...
lizmat ok, I see now that the caching is a potential source of issues... 23:01
going to revert that until we have a better idea on how to find out if an op is a METAOP_ASSIGN or not 23:02
so how can I quickly introspect if a given block was generated by METAOP_ASSIGN ? 23:06
Geth rakudo: f7007ac0e6 | (Elizabeth Mattijsen)++ | src/core/metaops.pm6
Remove METAO_ASSIGN caching

As discussed on #perl6-dev just now, it may cache a block that has a incorrect version of the op, even though the name is the same.		 23:11
23:14 [Tux] joined 23:15 p6bannerbot sets mode: +v [Tux], pmurias left 23:42 lizmat left

Powered by Cro and the Raku® Programming Language.

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

Thank you!