Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6-dev, 2016-06-09

| Channels | #perl6-dev index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:09 [Coke] Sure, a PR can't hurt. just leave a comment that it's exploratory.
00:09 [Coke] thanks for trying it out.
00:34 dalek joined #perl6-dev
06:53 [Tux] This is Rakudo version 2016.05-73-g60731a0 built on MoarVM version 2016.05-18-g1339332
06:53 [Tux] test            19.246
06:53 [Tux] test-t          11.927
06:53 [Tux] csv-parser      22.418
07:52 RabidGravy joined #perl6-dev
08:12 dalek rakudo/nom: 42f07cd | lizmat++ | src/core/IO/Handle.pm:
08:12 dalek rakudo/nom: Fix scoping issue with IO::Handle.comb(N)
08:12 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/42f07cda3f
08:12 dalek rakudo/nom: 65e1b54 | lizmat++ | src/core/Iterator.pm:
08:12 dalek rakudo/nom: Squeeze a few % out of default Iterator code
08:12 dalek rakudo/nom:
08:12 dalek rakudo/nom: - use nqp::eqaddr instead of =:=
08:12 dalek rakudo/nom: - use nqp::not_i instead of !
08:12 dalek rakudo/nom: - use nqp::add_i instead of prefix ++
08:12 dalek rakudo/nom: - use postfix until instead of empty body until
08:12 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/65e1b54c9d
08:14 lizmat m: class A { method sink { say "sunk" } }; use nqp; nqp::stmts(A.new)  # jnthn: looks like nqp::stmts doesn't sink
08:14 camelia rakudo-moar 60731a: ( no output )
08:15 lizmat m: class A { method sink { say "sunk" } }; A.new
08:15 camelia rakudo-moar 60731a: OUTPUT«sunk␤»
08:15 lizmat m: class A { method sink { say "sunk" } }; STATEMENT_LIST(A.new)
08:15 camelia rakudo-moar 60731a: ( no output )
08:15 lizmat nor does STATEMENT_LIST apparently
08:36 dalek rakudo/nom: d292d76 | lizmat++ | src/core/Any-iterable-methods.pm:
08:36 dalek rakudo/nom: Remove 2 unnecessary no-sink's, MasterDuke++
08:36 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/d292d76daa
08:36 lizmat afk for a few hours&
08:43 jnthn lizmat: nqp::stmts will not, it's just too low level
08:43 jnthn STATEMENT_LIST probably should
09:13 |Tux| joined #perl6-dev
09:16 |Tux| joined #perl6-dev
10:30 lizmat jnthn: ok, so I will not use STATEMENT_LIST to prevent sinking
10:35 lizmat m: class A { method sink { say "sunk" } }; my $a = A.new; $a   # shouldn't this just say "sunk" ?
10:35 camelia rakudo-moar d292d7: OUTPUT«WARNINGS for /tmp/GDbzqJZ7_5:␤Useless use of $a in sink context (line 1)␤»
10:43 retupmoca joined #perl6-dev
11:04 lizmat jnthn: at appears that postfix while also doesn't sink
11:05 lizmat m: class A { method sink { say "sunk" } }; while $++ < 5 { A.new }   # sinks
11:05 camelia rakudo-moar d292d7: OUTPUT«sunk␤sunk␤sunk␤sunk␤sunk␤»
11:05 lizmat m: class A { method sink { say "sunk" } };  A.new while $++ < 5   # doesn't sink
11:05 camelia rakudo-moar d292d7: ( no output )
11:05 lizmat I guess that's one of the reasons MasterDuke could remove the no-sinks in many places without problems
11:05 lizmat question is: this is probably a bug, right ?
11:06 sexy-coder-girl joined #perl6-dev
11:23 dalek rakudo/nom: 57d66ee | lizmat++ | src/core/Iterator.pm:
11:23 dalek rakudo/nom: Remove unnecessary no-sinks from default Iterator
11:23 dalek rakudo/nom:
11:23 dalek rakudo/nom: Turns out they were not needed at all because postfix while/until
11:23 dalek rakudo/nom: currently doesn't sink (which could be argued is a bug).  Replaced
11:23 dalek rakudo/nom: with nqp::while/until which *are* guaranteed to not sink.
11:23 dalek rakudo/nom:
11:23 dalek rakudo/nom: MasterDuke17++ for pursuing this
11:23 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/57d66ee76a
11:48 dalek rakudo/nom: 3b9b613 | lizmat++ | src/core/ (2 files):
11:48 dalek rakudo/nom: Remove no-sink from basic List/Array iterators
11:48 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/3b9b6132dd
12:16 dalek rakudo/nom: 2095ed6 | lizmat++ | src/core/Any-iterable-methods.pm:
12:16 dalek rakudo/nom: Remove no-sink from the grep family
12:16 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/2095ed65d1
13:44 skids joined #perl6-dev
14:36 [Tux] Drrrrrrrrrrrrrrrrrum Rrrrrrrolllllllllllllllllllllllllllllll ………
14:36 [Tux] This is Rakudo version 2016.05-79-g2095ed6 built on MoarVM version 2016.05-18-g1339332
14:36 [Tux] test            18.609
14:36 [Tux] test-t          10.702
14:36 [Tux] csv-parser      21.906
14:37 [Tux] YiiiiiiiiiHa!
14:38 timotimo wow
14:38 timotimo that's an improvement!
14:39 timotimo how many "return" statements are in your code all in all, btw?
14:39 timotimo because that's going to get super crazy improvement soon
14:39 timotimo and after a bit more complex optimization later on it'll almost be free
14:43 nine Woah! I would love to know what exactly was responsible for this speedup :)
14:45 [Tux] timotimo, 47
14:46 timotimo [Tux]: any clue how many of them are on hot paths?
14:46 [Tux] moment …
14:47 jnthn Also, note that every routine will get a little faster due to less overhead from return related stuff too, once that stuff lands
14:48 timotimo \o/
14:48 [Tux] 6 are real hot (when no parse errors happen)
14:50 [Tux] 19 including end-of-row and end-of-file states
14:50 [Tux] many more when extended features are used
14:51 masak [Tux]: how many can be trivially removed, because they're the last line of a routine?
14:51 [Tux] none
14:51 [Tux] lizmat and I already did that
14:53 masak aha.
15:05 [Coke] nice to give lizmat & jnthn some positive feedback on their speedup work.
17:19 dalek rakudo/nom: b6902e5 | TimToady++ | src/core/Exception.pm:
17:19 dalek rakudo/nom: s/call/resolve caller/
17:19 dalek rakudo/nom:
17:19 dalek rakudo/nom: "Cannot call foo(Bar); none of these signatures match" is confusing insofar
17:19 dalek rakudo/nom: as it can be taken to mean that foo(Bar) actually exists as a candidate.
17:19 dalek rakudo/nom: Message now reads "Cannot resolve caller foo(Bar)".
17:19 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/b6902e5192
17:26 timotimo don't you mean callee?
17:34 patrickz joined #perl6-dev
18:02 [Coke] I htnk you would already have had to resolve the callee.
18:03 [Coke] wait.
18:03 [Coke] yup, I need more Coke Zero.
18:06 stmuk_ try Club Mate :)
18:07 [Coke] I think I had some of that in switzerland. Wasn't my favorite, as I recall
18:14 hoelzro I've seen very colorful language used to describe the taste of club mate
18:14 * hoelzro doesn't care for it either
18:15 hoelzro I think it's an acquired taste
18:15 * [Coke] recalls finding an ample supply of Zero there, though.
18:23 mst hoelzro: I would rather drink my own urine.
18:41 hoelzro haha
18:41 hoelzro that's some of the colorful language I've seen employed =)
18:48 * stmuk_ likes it
19:22 AlexDaniel joined #perl6-dev
19:27 perlpilot joined #perl6-dev
19:35 cognominal joined #perl6-dev
20:00 bisectable joined #perl6-dev
20:03 lizmat nine: I think it's 57d66ee76aa727b7ed
20:03 lizmat mostly
20:30 dalek rakudo/nom: 8cfa6c7 | lizmat++ | src/core/Any-iterable-methods.pm:
20:30 dalek rakudo/nom: Streamline .unique
20:30 dalek rakudo/nom:
20:30 dalek rakudo/nom: 20% faster for all unique values, 30% faster for all identical values.
20:30 dalek rakudo/nom:
20:30 dalek rakudo/nom: - remove unnecessary no-sink's
20:30 dalek rakudo/nom: - use nqp::eqaddr instead of =:=
20:30 dalek rakudo/nom: - more generally, use nqp::ops
20:30 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/8cfa6c76ec
20:34 [Coke] is the hope that eventually spesh will be smart enough to make rakudo ops like =:= fast enough to use?
20:35 [Coke] s/fast.*/as fast as nqp ops/ ?
20:37 lizmat that is my hope, yes
20:38 lizmat in profiles, infix:<=:=> typically takes 2% of the CPU in any type of iterator
20:39 lizmat fwiw, I think the nqp::p6bool is to blame there
20:41 jnthn The problem is that it's a megamorph, and spesh is pretty awful and coping with those.
20:42 jnthn (with regard to =:=)
20:46 [Coke] megamorph is a MTG term. Does it mean here that it has a lot of multis?
20:47 jnthn MTG is a TLA I don't know :P
20:47 jnthn Not "a lot of multis", but rather "called with a lot of different argument types"
20:48 [Coke] magic the gathering, a collectible card game. :)
20:48 jnthn oh :)
20:48 timotimo right, because we =:= all kinds of different types
20:48 timotimo even though it doesn't actually make any difference to the optimization in this very case
20:49 jnthn Yeah. Spesh in its present form produces specializations by type, and doesn't yet try to track if the specialization is actually more general :)
20:49 jnthn And it puts a limit on how many specializations it'll make, and inlining only uses existing specializations of the target.
20:50 jnthn Which between them mean bad things for =:=
20:50 jnthn (But fine things for many, many cases)
20:51 jnthn We have the same problem with .sink, which can be called on a huge number of argument types, but just evaluates to Nil
20:51 jnthn And various other things
21:07 * jnthn gets an early night o/
21:09 lizmat good night, jnthn
21:13 dalek rakudo/nom: 4173600 | lizmat++ | src/core/Iterator.pm:
21:13 dalek rakudo/nom: Temporary fix for RT #128357
21:13 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/41736009bf
21:28 dalek rakudo/nom: 8887a7c | lizmat++ | src/core/Any-iterable-methods.pm:
21:28 dalek rakudo/nom: Streamline .repeated, like .unique
21:28 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/8887a7c4ca
21:50 dalek rakudo/nom: 87e91cc | lizmat++ | src/core/Any-iterable-methods.pm:
21:50 dalek rakudo/nom: Streamline .squish, like .unique
21:50 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/87e91ccc64

| Channels | #perl6-dev index | Today | | Search | Google Search | Plain-Text | summary