Perl 6 - the future is here, just unevenly distributed

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

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

All times shown according to UTC.

Time Nick Message
01:10 TimToady joined #perl6-dev
01:49 ilbot3 joined #perl6-dev
01:49 Topic for #perl6-dev is now Perl 6 language and compiler development 2.0 | Logs at http://irclog.perlgeek.de/perl6-dev/today
04:56 RabidGravy joined #perl6-dev
07:15 cognominal joined #perl6-dev
07:48 dalek rakudo/nom: 39a707a | (Brad Gilbert)++ | src/core/Match.pm:
07:48 dalek rakudo/nom: &[=:=] in &[eqv] for Match objects should be an optimization
07:48 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/39a707a970
07:48 dalek rakudo/nom: 926f1de | niner++ | src/core/Match.pm:
07:48 dalek rakudo/nom: Merge pull request #782 from b2gills/Match-eqv
07:48 dalek rakudo/nom:
07:48 dalek rakudo/nom: &[=:=] in &[eqv] for Match objects should be an optimization
07:48 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/926f1de88e
08:28 psch well, revisiting my digging around from yesterday, it seems that we either pick the wrong CodeRef to turn into a JAST::Method, or something is wrong with the order they arrive in $*CODEREFS...
08:49 nine psch: do you share the JCLASS between JAST compilers?
08:50 AlexDaniel joined #perl6-dev
09:01 cognominal joined #perl6-dev
09:14 psch nine: only via $*W / mast_frames as per your latest gist
09:15 psch i also have a rewrite to a more class-y JAST::Compiler, similar to how QASTCompilerMAST does it, in my tree, 'cause i wanted to check if all those dynamics actually do impact performance as i thought
09:16 psch but that wasn't enough to remove all of them, and didn't change 'time make test' at all
09:16 psch not sure what'd happen with those i didn't replace, but that'd take a way bigger rewrite than i want to try during "actually working on something else" :)
09:20 psch https://gist.github.com/peschwa/abd8b24a04eef9bea12529304b4bbb5b is my rakudo and nqp diffs, at 9cfcb96 and ac38b5f, respectively
09:21 psch catching the SomethingFishyException is where i got the jdb gist yesterday from
09:21 * psch gotta run now though
09:21 psch back in something around 3 hours o/
09:21 camelia joined #perl6-dev
09:45 nine psch: my rakudo patch sucks clearly still has issues. When we run multiple BEGIN time EVALs (like when we use multiple modules), we need to use the same JCLASS for all of them and for the calling module.
09:46 nine psch: but sharing via %*COMPILING<%?OPTIONS><mast_frames> makes it too easy for the JCLASS to leak into unrelated compilations.
09:46 nine Haven't had enough quiet time this week to think it through though.
10:43 lizmat b2gills++
11:11 dalek roast: 834afc7 | lizmat++ | integration/weird-errors.t:
11:11 dalek roast: Add test for RT #128368
11:11 dalek roast: review: https://github.com/perl6/roast/commit/834afc7a26
11:13 dalek rakudo/return-without-lexotic: 13ce70f | jnthn++ | src/Perl6/Metamodel/BOOTSTRAP.nqp:
11:13 dalek rakudo/return-without-lexotic: Add back typed return outside routine exception.
11:13 dalek rakudo/return-without-lexotic: review: https://github.com/rakudo/rakudo/commit/13ce70f3ba
11:26 cognominal joined #perl6-dev
12:04 dalek rakudo/nom: 652e8f0 | lizmat++ | src/core/Seq.pm:
12:04 dalek rakudo/nom: Remove no-sink from GATHER
12:04 dalek rakudo/nom:
12:04 dalek rakudo/nom: Also streamline it, resulting in a 10% faster gather { take }
12:04 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/652e8f0f6a
12:05 lizmat all no-sinks have now been removed, again MasterDuke17++ for pursuing this
12:26 dalek rakudo/nom: 8dc7c2e | lizmat++ | src/core/ (4 files):
12:26 dalek rakudo/nom: Add "doesn't sink" notions to places I forgot
12:26 dalek rakudo/nom:
12:26 dalek rakudo/nom: While doing: d292d76 57d66ee 3b9b613 2095ed6 8cfa6c7 8887a7c 87e91cc
12:26 dalek rakudo/nom:              9cfcb96 74d7ac0 5b4470b 652e8f0
12:26 dalek rakudo/nom: I forgot to mention that the structure was needed to prevent sinking.
12:26 dalek rakudo/nom: We want to keep that info for the future.
12:26 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/8dc7c2e26d
12:28 MasterDuke_ joined #perl6-dev
12:55 cognominal joined #perl6-dev
13:18 dalek rakudo/nom: 915f454 | lizmat++ | src/core/Any.pm:
13:18 dalek rakudo/nom: Make Any.sum about 4% faster
13:18 dalek rakudo/nom:
13:18 dalek rakudo/nom: Not a lot, but for such a basic function it seems worthwhile
13:18 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/915f454d09
13:33 lizmat m: class A { method sink() { print "sunk " } }; my @a = A.new xx 10; my @b = @a.flat  # looks like .flat is sinking
13:33 camelia rakudo-moar 915f45: OUTPUT«sunk sunk sunk sunk sunk sunk sunk sunk sunk sunk »
13:33 lizmat looking at that now
13:34 skids joined #perl6-dev
13:48 lizmat m: class A { method sink() { print "sunk " } }; my @a = A.new xx 10  # looks like assigning it is sinking?
13:48 camelia rakudo-moar 915f45: OUTPUT«sunk sunk sunk sunk sunk sunk sunk sunk sunk sunk »
13:49 lizmat this shouldn't happen, now should it ?
13:50 b2gills joined #perl6-dev
15:05 jnthn lizmat: That sinking looks wrong, yeah. I mean, sinking implies "this value is being thrown away", and storing it in a variable is certainly not throwing it away :)
15:56 RabidGravy o_O
16:20 [Tux] This is Rakudo version 2016.05-92-g915f454 built on MoarVM version 2016.05-18-g1339332
16:20 [Tux] test            17.892
16:20 [Tux] test-t          10.511
16:20 [Tux] csv-parser      21.268
17:04 lizmat jnthn: ok, looking into it
17:08 lizmat actually, looks like xx is sinking it
17:16 lizmat https://rt.perl.org/Ticket/Display.html?id=128382 # ticket for xx sinking
17:33 TimToady how can it be that something named 'sink' is not throwing away the value and returning Nil instead?
17:35 TimToady something must be calling .sink and then returning the value anyway
17:35 lizmat I think the question is: why is it sinking when it shouldn't ?
17:35 TimToady m: class A { method sink() { print "sunk " } }; my @a = A.new xx 10; say @a[0]
17:35 camelia rakudo-moar 915f45: OUTPUT«sunk sunk sunk sunk sunk sunk sunk sunk sunk sunk A.new␤»
17:36 lizmat it's inside the xx oterator
17:36 lizmat *iterator
17:36 lizmat a bare nqp::push() actually
17:37 TimToady my point is that we shouldn't be using .sink as a proxy for .eager or some such
17:37 TimToady but maybe it's accidental
17:38 TimToady anyway, I'll stop spouting random sentiments and let you chase it down :)
17:40 lizmat pretty sure it is this line https://github.com/rakudo/rakudo/blob/nom/src/core/List.pm#L1094
17:41 TimToady so the basic problem is that nqp::push is returning what it pushed?
17:42 lizmat well, not sure that's a bug of a feature, but yes
17:42 lizmat m: use nqp; my $a := nqp::list; say nqp::push($a,42)
17:42 camelia rakudo-moar 915f45: OUTPUT«42␤»
17:43 TimToady so we can put a bandaid there, but maybe there are other places with the same issue
17:44 TimToady not to mention P6's push variants
17:45 TimToady slapping a :nosink on any push function or method seems like a problem waiting to happen though
17:46 TimToady we potentially have the same problem with take
17:46 lizmat I think it is only a problem in the context of iterators
17:46 lizmat because we expect push to return stuff
17:46 lizmat don't we ?
17:58 cognominal joined #perl6-dev
18:01 dalek rakudo/nom: 0ef135a | lizmat++ | src/core/List.pm:
18:01 dalek rakudo/nom: Fix for RT #128382
18:01 dalek rakudo/nom:
18:01 dalek rakudo/nom: Also streamline the xx iterators for 10% better performance
18:01 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/0ef135a522
18:03 jnthn Doesn't the Perl 6 push method return the Array?
18:03 jnthn And so no risk of sinking the value
18:04 jnthn m: my @a = 1,2; say @a.push(3)
18:04 camelia rakudo-moar 915f45: OUTPUT«[1 2 3]␤»
18:04 jnthn m: my @a = 1,2; say push @a, 3
18:04 camelia rakudo-moar 915f45: OUTPUT«[1 2 3]␤»
18:04 jnthn So, no problem for push
18:04 jnthn m: my @a = 1,2; say unshift @a, 3
18:04 camelia rakudo-moar 915f45: OUTPUT«[3 1 2]␤»
18:04 jnthn Or unshift
18:11 TimToady m: class A { method sink() { print "sunk " } }; my @a = gather for ^10 { take A.new; take 42 }; say @a[0]
18:11 camelia rakudo-moar 0ef135: OUTPUT«sunk sunk sunk sunk sunk sunk sunk sunk sunk sunk A.new␤»
18:11 TimToady take is a problem though
18:11 lizmat yeah, looking into that now
18:13 TimToady we *can* figure out whether 'take' is our built-in function at compile time, even if we can't figure out .take
18:14 TimToady but if it turns out the 'free dup' of take is not free, we need to do something about the default semantics
18:16 jnthn Yeah, take returning its value isn't so good.
18:16 jnthn I suspect we will break something if we change that
18:17 jnthn (Which may still be the lesser evil :))
18:17 TimToady we were speculating on #perl6 that it'd break at 6d
18:17 TimToady and till think have an explicit nosink annotation we could slap on hotspots
18:17 TimToady s/think/then/
18:18 jnthn Sounds reasonable
18:18 TimToady a contextualizer that simply does $ast.annotation('nosink'), I guess
18:18 jnthn Yeah
18:19 TimToady could be generally useful in any case
18:19 jnthn We could call it titani...nevermind. :P
18:19 dalek rakudo/nom: 6a6ea47 | lizmat++ | src/core/control.pm:
18:19 dalek rakudo/nom: Simplify the use of THROW
18:19 dalek rakudo/nom:
18:19 dalek rakudo/nom: Looks like we had a lot of superfluous code returning the value from
18:19 dalek rakudo/nom: take / take-rw that wasn't actually needed.
18:19 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/6a6ea47580
18:19 lizmat note this is spectest neutral  ^^
18:21 jnthn emit may also want to return Nil at 6d
18:21 timotimo lizmat: you spec tested it on jvm?
18:21 jnthn Given it's the dual of take
18:22 lizmat yeah, saw that
18:23 TimToady I know at least one rosettacode entry uses dual take
18:23 timotimo take 2?
18:23 timotimo http://ecx.images-amazon.com/images/I/91Lq1Kn4Q6L._SX522_.jpg
18:26 * TimToady wanders off to buy some cat6a cable
18:26 lizmat .oO( how old fashioned )
18:27 TimToady it's just for a preschool, 'cause AT&T won't run fiber all the way :P
18:27 lizmat .oO( teaching the kids the ropes :0-)
18:29 dalek rakudo/nom: 3d276a5 | lizmat++ | src/core/control.pm:
18:29 dalek rakudo/nom: Done doesn't need a value to the exception.
18:29 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/3d276a56b3
18:42 lizmat TimToady jnthn: so far, only 4 tests fail with take returning Nil
18:42 lizmat obvious ones like: gather $x [R/]= 1 while ($x -= take $x.floor) > 0
18:43 lizmat and other specific tests for the return value of take
18:43 lizmat no tests with emit
18:44 lizmat that fail
18:46 lizmat so my guess that the fallout of making take/emit return Nil are overseeable
18:46 lizmat *is
18:52 jnthn For take, it's easy enough to fix it in the 6.d setting. For .take, less so...though I guess that's enormously less common
18:52 lizmat yeah, it was added at a very late stage, after we got "with"
18:52 lizmat .take with $foo
18:53 jnthn *nod*
18:53 jnthn Time to steam more momos and watch the next match :) bbl
18:54 lizmat okidoke
18:54 timotimo i have no clue what momos are
18:58 cognominal joined #perl6-dev
19:02 lizmat timotimo: probably https://en.wikipedia.org/wiki/Momo_(dumpling)
19:06 edehont joined #perl6-dev
19:12 dalek rakudo/nom: 2b76da0 | lizmat++ | src/core/ (2 files):
19:12 dalek rakudo/nom: Simplify return/return-rw
19:12 dalek rakudo/nom:
19:12 dalek rakudo/nom: Not sure why we were saving the parameters to have them returned,
19:12 dalek rakudo/nom: if we're returning them by exception already?
19:12 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/2b76da0701
19:50 Zoffix joined #perl6-dev
19:50 Zoffix Sent a PR to rework is-approx that I proposed a couple of weeks back: https://github.com/rakudo/rakudo/pull/783
20:07 * lizmat waits for travis checks but can't wait to merge :-)
20:28 stmuk_ yes!
21:02 jnthn lizmat: Bah, your return/return-rw changes will make me a merge conflict :P
21:02 jnthn (They're turned into a set of multis in my branch :))
21:03 lizmat jnthn: I can revert and apply again after your merge
21:03 jnthn It's fine, though I think it's already covered by the branch
21:03 jnthn iirc they're pretty much all one-line methods now
21:03 lizmat whatever makes life easier for you  :-)
21:04 lizmat well, that's what I did as well, basically  :-)
21:07 jnthn :)
21:07 jnthn It should be easy enough for me whatever way
21:07 jnthn I've gotta sort out the JVM stuff yet also :)
21:15 dalek rakudo/nom: d5e09d9 | lizmat++ | src/core/Mu.pm:
21:15 dalek rakudo/nom: Streamline Mu.BUILDALL
21:15 dalek rakudo/nom:
21:15 dalek rakudo/nom: Makes custom object creation about 1.8x as fast.
21:15 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/d5e09d9695
21:15 dalek rakudo/nom: 388eda0 | lizmat++ | src/core/ (2 files):
21:15 dalek rakudo/nom: Revert "Simplify return/return-rw"
21:15 dalek rakudo/nom:
21:15 dalek rakudo/nom: This reverts commit 2b76da0701472418e8faaca560bf2decb9d9df11.
21:15 dalek rakudo/nom:
21:15 dalek rakudo/nom: These are actually covered by changes jnthn is about to land.
21:15 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/388eda0bd4
21:16 lizmat jnthn: ^^^
21:16 jnthn lizmat: ah, thanks...that should make it a clean merge :)
21:16 jnthn I aim to get the JVM bits done in the next few days
21:17 jnthn So I don't utterly bust it upon merge
21:21 timotimo holy crap, 1.8x as fast
21:22 lizmat for an object with 2 attributes and default values
21:22 lizmat looking forward to tomorrow's test-t  :-)
21:22 timotimo when i last tried to make buildall generated from the buildplan in the compilation stage, i stumbled upon something
21:23 timotimo wherein as soon as the first 13 shows up, only more 13s came after that
21:23 timotimo i don't actually know if anything ensures that, but we could perhaps make use of that in the regular buildall, too
21:24 timotimo but really, generating actual code from the buildallplan could be worth a lot more
21:24 timotimo spesh won't understand the loop at all, compared to when the instructions are laid out one after the other
21:24 lizmat as long as it doesn't involve EVAL, I would be for it  :-)
21:25 timotimo it uses the cool new(-ish) compiler services jnthn designed a while ago
21:27 timotimo so, it goes through the compiler, but only the same way all other things that get compiled do. i.e. no separate compilation
21:27 lizmat so where could I find use of that / examples / documentation ?
21:28 timotimo let me see
21:28 timotimo oh, the reason why i'ven't finished it yet is because it really behaves oddly, and i couldn't figure it out yet
21:28 timotimo https://github.com/rakudo/rakudo/tree/generate_buildallplan_2 - you can check out the latest commits here
21:29 timotimo there's code nearby for generating the accessor methods. that code actually works :)
21:30 jnthn I'll have to look at that soon, yeah :)
21:30 jnthn In the meantime, lizmat++ for a very nice speedup :)
21:30 lizmat didn't jnthn do that recently as well ?
21:30 jnthn I did the accessor methods
21:30 jnthn Didn't get to BUILDALL
21:30 jnthn Too many distractions with all the other things I want to do... :)
21:31 jnthn Though fixing hyper/race really better had be about the next thing.
21:31 timotimo oh, yeah
21:34 lizmat BTW, I was thinking about eradicating STATEMENT_LIST in favour or nqp::stmts in the core
21:35 lizmat jnthn: ^^^ opinions?
21:35 dalek rakudo/nom: a61f6bb | lizmat++ | src/core/Mu.pm:
21:35 dalek rakudo/nom: Oops, forgot to collapse two leading lines
21:35 dalek rakudo/nom:
21:35 dalek rakudo/nom: Gives another 5% improvement on creating objects.
21:35 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/a61f6bb3a6
21:40 jnthn lizmat: Don't feel strongly either way
21:40 lizmat STATEMENT_LIST is an implementation detail, is it not ?
21:40 jnthn I'm not quite sure how TimToady intended it, tbh
21:41 lizmat at this point, there's nothing about in specs, doc or roast
21:42 jnthn Well, then it's de facto an implementation detail :)
21:42 lizmat and one we don't want to let get free in the wild, no ?
21:43 timotimo i use it in JSON::Fast
21:44 jnthn I'm not sure...I mean, I thought it went in so there was something nqp::-less that did C-comma style behavior or somehting along those lines
21:44 jnthn But it was during the run-up to Christmas, iirc, which is all a bit of a blur
21:49 lizmat ok, I'll wait for TimToady to shine his light on this
21:49 lizmat I mean, if it is intended as a genuine user feature, it should probably have a kebab-cased name  :-)
21:50 timotimo maybe there's still remnants in the specs about SEQ?
21:50 timotimo which is the name it had previously
21:50 timotimo but that clashed with Seq type and related features
21:50 lizmat aaahhh!
21:51 lizmat alas, nothing about SEQ in specs, doc or roast either
21:52 timotimo huh, maybe it was quickly thrown out when STATEMENT_LIST came in, instead of replaced
21:54 lizmat specs commit e83a759a09acf8838ce removes the last mention of it in Oct 2014
21:54 lizmat I mean, ideally, you want the optimizer to realize that no scope is needed, right ?
21:55 timotimo wow, that's old
21:55 timotimo right. the optimizer already tries, but it's not always easy or successful
21:55 timotimo and when the optimizer doesn't do it, spesh tries it, as well
21:59 jnthn The optimizer will get better at that, mind :)
22:00 timotimo yup
22:00 jnthn Another of the things on my todo list :P
22:07 dalek rakudo/nom: 1f6d723 | (Zoffix Znet)++ | / (3 files):
22:07 dalek rakudo/nom: Rework is-approx() in Test.pm6
22:07 dalek rakudo/nom:
22:07 dalek rakudo/nom: Deprecate is_approx(). Standardize, improve, and fix bugs in the
22:07 dalek rakudo/nom: currently unspecced and undocumented extra behaviour of is-approx()
22:07 dalek rakudo/nom: (such as specifying both relative and absolute tolerances).
22:07 dalek rakudo/nom: See https://github.com/rakudo/rakudo/pull/783 for details of the changes.
22:07 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/1f6d7233f7
22:07 dalek rakudo/nom: bb165a5 | lizmat++ | / (3 files):
22:07 dalek rakudo/nom: Merge pull request #783 from zoffixznet/fix-is-approx
22:07 dalek rakudo/nom:
22:07 dalek rakudo/nom: Rework is-approx() in Test.pm6
22:07 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/bb165a577d
22:10 jnthn Rest time....'night o/
22:11 lizmat gnight jnthn
22:11 lizmat and gnight #perl6-dev
22:17 Zoffix night.
22:17 timotimo gnite jnthn!

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