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.
|Tux| Rakudo version 2019.07.1-357-gd00674b31 - MoarVM version 2019.07.1-241-gacb04a448
csv-ip5xs0.769 - 0.781
csv-ip5xs-206.388 - 6.456
csv-parser22.306 - 22.506
csv-test-xs-200.423 - 0.425
test6.852 - 7.147
test-t1.747 - 1.750
test-t --race0.795 - 0.830
test-t-2029.614 - 29.737
test-t-20 --race9.033 - 9.228
09:24
lizmat Files=1274, Tests=109501, 204 wallclock secs (26.80 usr 7.47 sys + 2887.37 cusr 245.55 csys = 3167.19 CPU) 10:13
lizmat bisectable6 my $y := 666 if 0; dd $y 11:46
bisectable6: my $y := 666 if 0; dd $y
bisectable6 lizmat, On both starting points (old=2015.12 new=d00674b) the exit code is 0 and the output is identical as well
lizmat, Output on both points: «Mu␤»
lizmat bisectable6: my $y := 666 if 0; say $y.perl 11:48
bisectable6 lizmat, On both starting points (old=2015.12 new=d00674b) the exit code is 1 and the output is identical as well
lizmat, Output on both points: «Cannot call method 'perl' on a null object␤ in block <unit> at /tmp/x46IxO2CAH line 1␤␤»
vrurg greppable6: is hidden 13:20
greppable6 vrurg, 180 lines, 35 modules: gist.github.com/5dc88e01ff6be350d6...a3ba4be6d8
vrurg greppable6: is\s+hidden\s+ 13:21
greppable6 vrurg, 7 lines, 5 modules: gist.github.com/6c8a63cca65a278c7d...ed24524313
Geth_ rakudo: 559c24f066 | (Elizabeth Mattijsen)++ | src/core.c/Backtrace.pm6
Make sure that Backtrace.list lists all the frames

Well, conceivably: raised max number of elements from 101 to 1_000_001 Addresses GH#3148
14:28
synopsebot GH#3148 [open]: github.com/rakudo/rakudo/issues/3148 Backtrace.new.list.elems doesn't reflect the depth of the "callstack"
AlexDaniel quick question: will rakudo support raku goodies before the release of 6.e? 16:45
jnthn AlexDaniel: Which kind of things do you have in mind? 16:46
AlexDaniel: Some things we can't put behind a `use v6.e` anyway, and even those we can we might want to just ship anyway 16:47
AlexDaniel jnthn: let's say .raku and $*RAKU
jnthn So the point where most folks with an installed Rakudo can expect them to be there arrives sooner
Well, .raku is a method so not subject to versioning
Or at least, we can't make it so you only get it with a `use v6.e` 16:48
So that one I'd say we put in whenever we get to it. $*RAKU I'm not sure what our options are, but given it's additive, it won't break anything to have it available sooner
AlexDaniel hmm 16:49
jnthn Also, I don't really want pressure on us to do a 6.e, and tying adding Raku stuff into Rakudo to that would make us want to do it sooner. 16:49
AlexDaniel nah I just was reading the document top to bottom, and at the very end it says “Around the release of 6.e...” and suggests to do some changes 16:50
which I'm fine with, I'm just wondering
like, won't we get into the situation when people will start changing things, but most rakudo versions in the wild won't support something
but I guess we're fine
jnthn I think we'd want to make sure that by the time 6.e is released, then all the goodies are there. But I think that's likely to happen anyway.
Well, my intention in that document was to try and discourage people from changing things too soon, and making their modules incompatible for folks running some releases back ('cus they installed what was packaged, etc.) 16:51
(Or the latest MSI, or...)
AlexDaniel yeah, it does say that
I guess support of everything in .e, some deprecation in .f and removal of stuff later makes sense 16:52
jnthn I figure "when 6.e is released" is an easy thing for people to know if has/has not happened, and it gives us freedom to determine exactly when that happens
Geth_ problem-solving/path-to-raku: dc7f4512e8 | (Aleks-Daniel Jakimenko-Aleksejev)++ | solutions/language/PATH-TO-RAKU.md
Remove accidental markdown
16:53
problem-solving/path-to-raku: 2d57afe177 | (Aleks-Daniel Jakimenko-Aleksejev)++ | solutions/language/PATH-TO-RAKU.md
Replace the mention of “DarkPan”
problem-solving/path-to-raku: 51890ebe26 | (Aleks-Daniel Jakimenko-Aleksejev)++ | solutions/language/PATH-TO-RAKU.md
Minor fixes
jnthn Which felt preferable to me to putting in "in N months" or some such.
AlexDaniel it's a nice document, btw 16:54
lizmat++
vrurg Anybody remembers what was the purpose of inventing hidden classes? ('is hidden' and 'hides' traits) 16:55
greppable6: \shides\s 16:57
greppable6 vrurg, 32 lines, 18 modules: gist.github.com/2e3c2b368a9c120a38...4b7a5b5628
jnthn vrurg: Probably see S12 if you didn't already, but iirc it's to hide methods in the class from the deferral mechanism, which in turn implies no default implicit `*%_`
vrurg jnthn: thanks! 16:58
AlexDaniel treegrep: \.pod6 17:00
greppable6 AlexDaniel, gist.github.com/9d727d673ef8b065df...6be2fdd8df
vrurg jnthn: Still, I don't see what's the advatages of this? Faster method calls? 17:01
jnthn vrurg: I think that's a side-effect and the purpose is to be hidden from deferral 17:05
It's possible folks have used it for the optimization side-effect, though we're often smart enough to optimize it away for them anyway now :)
vrurg So far, neither trait is used in the core nor in the ecosystem. 17:08
tbrowder hi, all 17:12
i've just released File::Copy on cpan and hope it might be a start toward inclusion in core someday. eyeballs and testing appreciated. thnx. 17:14
japhb AlexDaniel, jnthn: Which document where you talking about that had 6.e references? 17:15
AlexDaniel japhb: path-to-raku
japhb is trying to follow along with name change stuff but only has time to catch up like once or twice a week.
So I miss stuff.
AlexDaniel japhb: github.com/perl6/problem-solving/p...8f232017cf 17:16
japhb Since there doesn't seem to be a single place to go, or single channel to watch, or single GH issue to track that has everything
Thanks, AlexDaniel
AlexDaniel japhb: it's a single PR, really, everything else is a discussion on how to change the PR 17:17
jnthn vrurg: Also see the Interface Consistency section in www.perl6.org/archive/doc/design/apo/A12.html 17:29
dinner &
japhb AlexDaniel: Yeah, that's a good doc. BTW, in the Ecosystem changes section: META6.json contains a 'perl' key; presumably that would need to change too. Also the name of that file, to e.g. RAKUMETA.json? 17:32
AlexDaniel japhb: I think we should try not to pile additional changes on top of the rename 17:33
ahh wait meta *6*
and yeah, the perl field I did notice yesterday… hmm
lizmat: maybe that's something you can tackle 17:34
why does it have a 6 in there? 17:35
treegrep: META.json
greppable6 AlexDaniel, gist.github.com/286ff90becbc62662b...1e20f4724a
AlexDaniel oh wow
but it was META.json at some point, no?
japhb: I don't know, I guess it can stay… it's still raku 6 17:36
I mean, the version is still technically 6
I'd love to change the versioning at some point but not now 17:37
japhb Sure, that's less important than the 'perl' key in that file. 17:39
AlexDaniel so while I'm playing devil's advocate here, I'm wondering, what'd be a good reason to dismiss .raku.t ? 17:58
compared to .rakutest that is
vrurg AlexDaniel: twextension? Again? 18:00
(facepalm) ;) 18:01
AlexDaniel vrurg: “Again?” is your reason? 18:03
vrurg Not this one, but as concept.
AlexDaniel so, why?
it's not one of your twextensions, btw 18:05
nine is hidden implies no implicit *%_? Now that can be useful!
AlexDaniel I know how to argue against .t.raku but not .raku.t 18:06
vrurg AlexDaniel: I know it's different. Just kidding. 18:08
[Coke] nine: how goes?
vrurg I would still .t.rk like more, but as it was said – don't care that much.
AlexDaniel well, .raku.t won't even require changes to tools, and plain `prove` will work as long as you have shebangs 18:10
and .t.rk doesn't bring any benefit unless you do all your extensions this way 18:11
and if you do, then suddenly all your modules are also executable
so .t.rk is a no go
nine Going to attack that resolve_using_guards issue now for good :) 18:12
lizmat japhb: we can't change the name of META6.json without also needing to make changes to PAUSE 19:16
so that will most definitely stay, as we don't want to burden the toolchain people with more work
japhb lizmat: Yeah, totally fair. And TBH, the name is another easter egg like Camelia's wings. 19:27
lizmat indeed :-)
RT131014 19:31
synopsebot RT#131014 [open]: rt.perl.org/Ticket/Display.html?id=131014 [BUG] multi dispatch error on signature with coerce and smiley
Geth_ rakudo: c3926928a6 | (Elizabeth Mattijsen)++ | 2 files
Make .starts-with / .ends-with quite a bit faster

Especially the Cool variants. Mostly by making them share the same proto and getting rid of the |c signature.
19:59
rakudo: 44a6a0de06 | (Elizabeth Mattijsen)++ | 2 files
Make .substr-eq quite a bit faster

Especially the Cool variants. Mostly by making them share the same proto and getting rid of the |c signature.
20:24
rakudo: 696eea2de6 | (Elizabeth Mattijsen)++ | 2 files
Make .contains quite a bit faster

Especially the Cool variants. Mostly by making them share the same proto and getting rid of the |c signature.
20:45
japhb I love seeing 'Make ... faster' commits. 20:59
lizmat++
lizmat it also makes the code bigger 21:00
but it also helps with IDE's :-)
afk&
tbrowder why 21:16
chg .t file extensions at all? 21:17
seems lang agnostic to me, 21:18
lizmat m: class A { our sub a() { }; A::a for ^10000000 }; say now - INIT now 23:05
camelia 3.2299664
lizmat m: class A { our sub a() { }; a for ^10000000 }; say now - INIT now
camelia 0.22196523
lizmat feels to me these timings should be more or less the same ?
jnthn: ^^ ?
jnthn A::a compiles into A.WHO<&a>() - e.g. a hash lookup 23:17
We can in principle inline the call itself, modulo an sf guard 23:18
But the hash access dominates
In the second one the sub call optimizes away totally. You're not actaully calling it via the package, but as a lexical (because even an `our` declaration gets a lexical alias, so its as if the `our` wasn't even there). 23:19