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