| japhb | buggable: speed | 02:55 | |
| buggable | japhb, ?????????????????????????????????????????????????? data for 2017-07-12–2017-08-01; range: 4.025s–4.960s; 2% slower | ||
| Geth | rakudo/nom: 01dbd874ee | (Nick Logan)++ (committed using GitHub Web editor) | src/core/Version.pm Improve Version smart match with different lengths (#1118) If RHS has more version parts than LHS then pad LHS with `.0` until both versions have a similar number of parts. If the RHS is longer, continue with the current behavior of padding with `.*`. e.g. `say v6 ~~ v6c` is now False. Fixes `perl6 -e 'use Test:ver(v6.c.1.2.3);'` (...in that it now fails instead of loading a `v6.c`) |
03:40 | |
| roast/Altai-man-patch-1: 54415941e4 | Altai-man++ (committed using GitHub Web editor) | S09-subscript/slice.t Test for #131827 Lizmat++ for the actual bugfix. Closes rt.perl.org/Public/Bug/Display.html?id=131827 |
08:01 | ||
| synopsebot6 | Link: rt.perl.org/rt3/Public/Bug/Display...?id=131827 | ||
| Geth | roast: Altai-man++ created pull request #292: Test for #131827 |
08:02 | |
| synopsebot6 | Link: rt.perl.org/rt3/Public/Bug/Display...?id=131827 | ||
| [Tux] | This is Rakudo version 2017.07-116-g01dbd874e built on MoarVM version 2017.07-266-ged84a632 | 08:38 | |
| csv-ip5xs 2.559 | |||
| test 12.362 | |||
| test-t 4.152 - 4.242 | |||
| csv-parser 12.996 | |||
| Geth | roast: 6da51968d3 | Altai-man++ (committed by Zoffix Znet) | S09-subscript/slice.t Test for #131827 (#292) Lizmat++ for the actual bugfix. Closes rt.perl.org/Public/Bug/Display.html?id=131827 |
09:56 | |
| synopsebot6 | Link: rt.perl.org/rt3/Public/Bug/Display...?id=131827 | ||
| Geth | roast: fe8754b9ee | (Zoffix Znet)++ (committed using GitHub Web editor) | S09-subscript/slice.t Fix test description |
10:04 | |
| AlexDani` | after reading github.com/perl6/doc/issues/1428 I have this question | 10:14 | |
| AlexDaniel | why does this leak memory? say (1…?).map(*+2).grep(* < 0)[^10] | ||
| and, can somebody confirm it? | 10:15 | ||
| jnthn | Indexing calls .cache | 10:16 | |
| But that shouldn't account for lunch | 10:17 | ||
| uh, for much | |||
| hah | |||
| AlexDaniel | (^?) does not leak, but (1…?) does | ||
| Zoffix | AlexDaniel: yeah, confirmed; leaks about 5MB per second | 10:31 | |
| perl6 -e 'loop { $ = (1...?).map(*+2).grep(* < 0)[^10] }' # leaks | |||
| perl6 -e 'loop { $ = (1..?).map(*+2).grep(* < 0)[^10] }' # doesn't | |||
| AlexDaniel | what's the point of that loop there? | 10:32 | |
| Zoffix | Oh, well then there's no leaking hehe | 10:33 | |
| It just never finishes | |||
| AlexDaniel | well, that's the point? All of the values are thrown away, so yes, it doesn't finish but it shouldn't take more memory as it goes | 10:34 | |
| at least, that's what I expected | 10:35 | ||
| jnthn | Note that the bigints are getting bigger | ||
| Dunno if that's where it comes from | |||
| AlexDaniel | I don't think it's *so* fast | 10:36 | |
| Zoffix | s: (1...?), 'iterator', \() | 10:37 | |
| SourceBaby | Zoffix, Sauce is at github.com/rakudo/rakudo/blob/01db...Seq.pm#L50 | ||
| Zoffix | s: (1...?).iterator, 'pull-one', \() | 10:38 | |
| SourceBaby | Zoffix, Sauce is at github.com/rakudo/rakudo/blob/01db...ble.pm#L96 | ||
| Zoffix | s: &SEQUENCE | 10:39 | |
| SourceBaby | Zoffix, Sauce is at github.com/rakudo/rakudo/blob/01db...rs.pm#L112 | ||
| Zoffix | AlexDaniel: dunno, something with continuations? Range.iterator just has a custom Iterator, while sequence operator uses gather/take, and this "leaks" too: perl6 -e 'gather { loop { take 1 } }.map(*+2).grep(* < 0).head: 10' | 10:41 | |
| AlexDaniel | not sure why leaks is in quotes, that's some actual leakage there :) | 10:42 | |
| Zoffix | OK | ||
| Doesn't leak without map, strangely | 10:43 | ||
| AlexDaniel | hmmmmmm | ||
| Zoffix | Or even without WhateverCode in map | 10:44 | |
| perl6 -e 'gather { loop { take 1 } }.map( * + 2).grep(* < 0).head: 10' # leaks | 10:45 | ||
| perl6 -e 'gather { loop { take 1 } }.map({$_+2}).grep(* < 0).head: 10' # doesn't | |||
| lizmat | m: dd (* + 2).signature | 10:47 | |
| camelia | { ... }? | ||
| lizmat | m: dd { $_ + 2 }.signature | 10:48 | |
| camelia | :(;; $_? is raw)? | ||
| lizmat | that seems a weird sig for the WhateverCode? | ||
| Zoffix | m: dd ((* + 2)).signature | 10:49 | |
| camelia | :(;; $whatevercode_arg_1 is raw)? | ||
| jnthn | It curries the .signature :) | ||
| m: say (* + 2).signature.WHAT | 10:50 | ||
| camelia | (WhateverCode)? | ||
| jnthn | :) | ||
| lizmat | ah, duh | ||
| ok, the difference in signature is that optionalness of the {$_} case | 10:51 | ||
| Zoffix | perl6 -e 'gather { loop { take 1 } }.map(-> $_ is raw {$_+2}).grep(* < 0).head: 10' # doesn't leak | 10:52 | |
| AlexDaniel | ok, RT #131829 | 11:00 | |
| synopsebot6 | Link: rt.perl.org/rt3/Public/Bug/Display...?id=131829 | ||
| lizmat | I'm thinking of adding a 'method increasing(--> False) { }' to Iterator | 12:41 | |
| allowing an iterator to override it with --> True, to indicate that the iterator is guaranteed to produce increasing values | |||
| jnthn | o.O | 12:42 | |
| What for, ooc? | |||
| lizmat | Which would be True for Range.iterator | ||
| if an iterator is used to create a slice | |||
| it would remove the need to cache | |||
| jnthn | Except the .cache is actually done by AT-POS | 12:43 | |
| lizmat | well, it wouldn't have to use AT-POS in some situations, is my point | ||
| jnthn | I'm not sure making .[...] have unpredictable caching semantics is wise though | 12:44 | |
| lizmat | I have a patch that would make @a[1,2,3] about 6x faster | ||
| but it creates a MMD hell | |||
| and while making it, I realised we have still quite a few bugs in that area | 12:45 | ||
| jnthn | I'd rather see some method like head/tail but with indices that you promise are ascending | ||
| The calling of .cache ain't a bug though | |||
| It's just how .[...] is designed | |||
| lizmat | I'm not saying it's a bug | ||
| I'm just saying that in case of 1...Inf[^10] it's not needed | 12:46 | ||
| in any case, I'm considering a hash_slice/array_slice overhauil | 12:47 | ||
| fixing things like: | 12:49 | ||
| m: dd ("a".."z")[(1,2,3),4,5] | |||
| camelia | (("b", "c", "d"), "e", "f")? | ||
| lizmat | versus: | ||
| m: dd ("a".."z")[(1,2,3),4,5]:p | |||
| camelia | (4 => "e", 5 => "f")? | ||
| jnthn | *nod* | ||
| Note that at the moment is one of the worst times to do any performance measurement fwiw | |||
| lizmat | well, pretty sure it won't be merge ready until way after the TPCiA | 12:50 | |
| jnthn | :) | ||
| Fair enough | |||
| Not saying that as a reason not to work on it | |||
| Just noting that any measurements you do right now might not hold up in a week or so's time | |||
| lizmat | yeah, got ya :-) | ||
| jnthn | Actually array/hash indexing was one of the cases I had in mind wiht the spesh redesign | 12:53 | |
| In that AT-POS and friends tend to be stable in their first 2 args but not their third | |||
| Now we'll typically have the data to see that | 12:54 | ||
| And with some work that's yet to some, be able to specialize only on the first 2 | |||
| *yet to come | |||
| Which means in real-world code that indexes lots of different types of thing we should be able to spend more time in spesh'd/JITted code | 12:55 | ||
| lizmat | wouldn't a similar thing apply to time spent in pull-one or push-all ? | 12:56 | |
| jnthn | The .push called by push-all for sure | 12:57 | |
| pull-one and push-all don't have much variance in their arguments | |||
| But they do of course have a good bit internally | 12:58 | ||
| And yeah, we should have more samples now | |||
| So can hopefully get less deopts | |||
| lizmat | cool | ||
| hopefully the bug that needs extra scopes in Any-iterable will be gone as well :-) | 12:59 | ||
| Geth | rakudo/nom: 5f68c77527 | (Elizabeth Mattijsen)++ | src/core/Any-iterable-methods.pm Remove extra scopes They do not appear to be necessary anymore. And in light of the work jnthn++ is doing atm, it would seem a good time to get rid of them. |
13:35 | |
| rakudo/nom: 3c797b05fd | (Elizabeth Mattijsen)++ | src/core/array_slice.pm Revert "Add missing deconts, spotted by sena_kun++" This reverts commit 59ba9c025eb95b33817fe60fb4bb600bb57d80db. Fixes RT #131830 |
14:30 | ||
| synopsebot6 | Link: rt.perl.org/rt3/Public/Bug/Display...?id=131830 | ||
| Geth | rakudo/nom: 7599e0c3ff | (Elizabeth Mattijsen)++ | src/core/array_slice.pm Revert "Make @a[Range] about 3x faster" This reverts commit a256c26d850c0e5ff986a6dfa1b1ef1ffaf55f40. |
||
| lizmat | hmmm... one revert too many | ||
| ah, no, just right :-) | |||
| Zoffix | lizmat: how come that commit caused the issue? It added the Range candidate but the issue says it's the `:(\SELF, int $pos)` candidate that's conflicting? | 14:32 | |
| I mean, according to the commitable bot that commit does indeed causes the bug, but why :\ | |||
| lizmat | I have no idea | 14:34 | |
| but since I'm rethinking the whole slicing business | |||
| Zoffix | lizmat: Ah... my good guess would be the `:D` on SELF | 14:35 | |
| lizmat | and it produced an issua at a distance, I rather revert since it is a performance thing only that should not affect anything else | ||
| Zoffix | Other candidates don't got it, so it makes it more narrower | ||
| lizmat | well, then we actually have a bigger issue, cause the other candidates should probably have it | ||
| Zoffix | Well, maybe :\ | ||
| I mean maybe my hypothesis.. There's no :D on other candidates, but at the same time, the error complains about `int` candidate, not Range. | 14:36 | ||
| lizmat | this is a. one of the oldest parts of rakudo, and b. the first big thing I did in Rakudo | ||
| a lot has happened since :-) | |||
| Zoffix | m: use NativeCall; multi foo (List:D \SELF, Range:D \range, *%_) {}; multi foo (\SELF, int $pos) {}; multi foo (NativeCall::Types::CArray:D \array, $pos) {}; foo CArray[Str].new, my int $ = 1 | 14:39 | |
| camelia | ( no output ) | ||
| Zoffix shrugs | |||
| Oh well, a puzzle for another day. | |||
| mspo | would you guys be open to replacing the perl6 shell script with a c program? | 15:00 | |
| so it works on bsd/osx? | |||
| lizmat | fwiw, in principle I wouldn't mind, but I'm not sure I'm qualified to judge that | 15:02 | |
| mspo | I wrote one (although I'm a bad c programming) gist.github.com/msporleder/62d5bbd...730e8c77de | 15:04 | |
| seems to work locally. The libpath stuff would need to be generated at compile time via some method so it had the PREFIX | 15:05 | ||
| jnthn | A more ideal solution would be to have it just embed moar rather than shelling out to it, though admittedly that's more work :) | ||
| But yeah, in principle, I'm happy with something like this happening | 15:06 | ||
| mspo | jnthn: if moar itself had a if (argv[0] == "perl6") { behave-like-perl6(); } it might also work via a link | 15:07 | |
| jnthn | mspo: That's a less good way to do it :) | 15:08 | |
| mspo | jnthn: okay | ||
| anyway small steps before something more ambitious like embedding moar | 15:09 | ||
| Zoffix | FWIW MSVC MoarVM tries to support will complain about those variables declared after statements | 15:16 | |
| ilmari | .oO( -Werror=declaration-after-statement ) |
15:17 | |
| timotimo | yes | ||
| Geth | rakudo: Altai-man++ created pull request #1127: Tests for RT #131830 |
15:25 | |
| synopsebot6 | Link: rt.perl.org/rt3/Public/Bug/Display...?id=131830 | ||
| ilmari | huh, that redirects to …/issues/1127, which 404s | 15:27 | |
| Geth | rakudo/nom: 6cc858a0e6 | Altai-man++ (committed using GitHub Web editor) | t/04-nativecall/05-arrays.t Tests for RT #131830 Closes rt.perl.org/Public/Bug/Display.html?id=131830 |
||
| synopsebot6 | Link: rt.perl.org/rt3/Public/Bug/Display...?id=131830 | ||
| Geth | rakudo/nom: c43ba0d01b | (Zoffix Znet)++ (committed using GitHub Web editor) | t/04-nativecall/05-arrays.t Merge pull request #1127 from Altai-man/patch-1 Tests for RT #131830 |
||
| synopsebot6 | Link: rt.perl.org/rt3/Public/Bug/Display...?id=131830 | ||
| Zoffix | ilmari: weird. Link works fine for me. | 15:29 | |
| Maybe a race between webhook generating stuff and links to PR working | 15:30 | ||
| ilmari | yeah, it worked after a moment | 15:31 | |
| ugexe | Zoffix: they are trying to install to a custom location but refuse to set PERL6LIB. each time I point it out they say they understand but don't do anything to suggest they do, or complain that zef does not automatically set such env vars (instead of his packaging script) | 15:35 | |
| the error could be better yeah, probably that way because of how CU::RR.run-script invokes scripts now (via require $some-path) | 15:36 | ||
| mspo | what writes that perl6 shell script? | 18:06 | |
| if I wanted to try and do a PR with the wrapper program instead | |||
| Zoffix | mspo: something in CompUnit* modules. Try grepping for parts of its code | 18:14 | |
| ugexe | there has to be a perl6 entry point, so that would prevent the ability to precompile bin scripts (which we dont do yet either) | 18:24 | |
| mspo | ugexe: you mean compile a standalone binary? | 18:26 | |
| ugexe: I'm trying to replace perl6.sh with perl6.c, but it's basically the exact same thing | |||
| ugexe | i mean precompile them like modules | 18:27 | |
| I put my bin scripts in Foo::CLI and inside bin/script is just `use Foo::CLI` (so it gets precompiled) | 18:28 | ||
| the wrapper does something similar now, `require $some-path-to-script;` | |||
| but you can't just launch a precompiled script, it needs a perl6 entry point | 18:29 | ||
| additionally it needs to know how to parse versions/auths/apis etc like CompUnit::Repository, because it has to be able to handle multiple versions of the same distribution being installed | 18:30 | ||
| mspo | are we talking about the same thing? Mine just looks like this: exec /usr/pkg/bin/moar --execname="$0" --libpath="/usr/pkg/share/nqp/lib" --libpath="/usr/pkg/share/nqp/lib" --libpath="/usr/pkg/share/perl6/lib" --libpath="/usr/pkg/share/perl6/runtime" /usr/pkg/share/perl6/runtime/perl6.moarvm "$@" | 18:31 | |
| ugexe | oh not the wrappers it creates for modules... gotcha | 18:32 | |
| mspo | ugexe: I'm talking about the thing you put in #! | ||
| jnthn | A while back I think we had to comment out (or similar) some native candidates because of a spesh bug. There's a chance it was what I just fixed in github.com/MoarVM/MoarVM/commit/3f33a8419b | 20:40 | |
| Zoffix | RT#131306 | 20:50 | |
| synopsebot6 | Link: rt.perl.org/rt3/Public/Bug/Display...?id=131306 | ||
| Zoffix | with kludges existing in github.com/rakudo/rakudo/blob/nom/...#L400-L413 | 20:51 | |
| lizmat | sub a(Any:U $a) { say nqp::isconcrete($a) } # can that ever say 1 ?? Don't think so, right ? | 20:57 | |
| Zoffix | That's my understanding of it, yeah | 21:02 | |
| Geth | rakudo/nom: 84d052a012 | (Elizabeth Mattijsen)++ | src/core/Any.pm Simplify Hash creation for auto-vivification Also add comment to remember that the isconcrete check is necessary even though the signature has a :U |
21:19 | |
| Zoffix | :) | 21:25 | |
| Geth | rakudo/nom: e86bdfca41 | (Elizabeth Mattijsen)++ | src/core/Perl.pm Remove a 3-year old hack Pretty sure this is not needed anywhere anyhow. Removal did *not* cause any spectest to fail. |
21:45 | |
| lizmat | and that concludes my hacking for today& | 21:46 | |
| Geth | rakudo: MasterDuke17++ created pull request #1128: Remove kludge for RT131306 |
22:29 | |
| synopsebot6 | Link: rt.perl.org/rt3/Public/Bug/Display...?id=131306 | ||
| Geth | rakudo/nom: e4802f4a5e | MasterDuke17++ | src/core/Int.pm Remove kludge for RT131306 irclog.perlgeek.de/perl6-dev/2017-...i_14959534 |
23:23 | |
| rakudo/nom: d9f51da884 | (Zoffix Znet)++ (committed using GitHub Web editor) | src/core/Int.pm Merge pull request #1128 from MasterDuke17/remove_kludge_for_RT131306 Remove kludge for RT131306 |
|||
| synopsebot6 | Link: rt.perl.org/rt3/Public/Bug/Display...?id=131306 | ||
| synopsebot6 | Link: rt.perl.org/rt3/Public/Bug/Display...?id=131306 | ||
| jnthn | About that merge, the fix is at MoarVM HEAD but I'm not sure there was a version bump | 23:28 | |
| Zoffix | There wasn't. The PR test said spectest pased, so I'm guessing some earlier changed fixed the issue. | 23:30 | |
| s/test/text/; | |||
| (there *are* tests covering the bug: github.com/perl6/roast/commit/c1d62112f3 ) | |||
| MasterDuke | oops, i was on moarvm HEAD | 23:31 | |
| Zoffix | Ohhh. lol :) | ||
| Zoffix is too tired to do the bumps and goes to bed | |||
| \o |