🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm
Set by lizmat on 8 June 2022.
ugexe I think we need a better way of versioning core modules 00:43
they used to be versioned as 6.c etc, but now the version is based on rakudo verion i.e. 2023.XX.XXXX 00:44
MasterDuke huh. how/when did that happen?
ugexe the first thing wrong there is anyone that was doing `use Test:ver<6.*>` (for example I used `Test:ver<6.c+>` a lot) would have be had their code broken
but the important thing is some version scheme is followed from here out. other compilers that would also have to provide NativeCall, Test, etc should version theirs similarly 00:45
so that one can depend on a specific version of Test that isn't compiler specific but also has whatever features they need of that version
m: say CompUnit::RepositoryRegistry.repository-for-name("core").installed[0].meta<ver>' 00:46
camelia ===SORRY!=== Error while compiling <tmp>
Two terms in a row
at <tmp>:1
------> -for-name("core").installed[0].meta<ver>⏏'
expecting any of:
infix
infix stopper
postfix
statement end
…
ugexe m: say CompUnit::RepositoryRegistry.repository-for-name("core").installed[0].meta<ver>
camelia v2023.08.45.g.16595.e.843
ugexe v2022.04 is the last rakudo release where the version shows 6.d. v2022.06 shows v2022.06 00:49
nemokosch so this may be related to zef emitting dummy warnings at installation
[Coke] "dummy" 00:51
I think you mean deprecation.
nemokosch not deprecation, literal "implicit coercion of type object to string" warnings
> Methods .^name, .raku, .gist, or .say can be used to stringify it to something meaningful. in method try-load at (Zef) line 155 00:53
line 155 coincides with > my $plugin-is-core = so $?DISTRIBUTION.meta<provides>{$short-name}.?chars; 00:55
MasterDuke .tell codesections btw, i saw this a little while ago and thought it would be up your alley if you haven't already seen it news.ycombinator.com/item?id=36672957 03:40
tellable6 MasterDuke, I'll pass your message to codesections
Geth rakudo/main: f09fa022f2 | (Elizabeth Mattijsen)++ | src/core.c/Rakudo/Iterator.pm6
Make .combinations about 25% faster
 07:31
rakudo/main: 695b9dc468 | (Elizabeth Mattijsen)++ | src/core.c/Rakudo/Iterator.pm6
Make .combinations another 7% faster

By using lexicals in hot loops instead of attributes		 07:59
nemokosch lizmat: this is just a guess but have you thought if push and pop are wasty? 10:17
The other suspicious thing for me is the amount of nqp::clone calls, even on something that is guaranteed to be a C native int 10:18
ab5tract nine: any idea on where one might start looking to resolve the lack of role inheritence in RakuAST? 14:16
vrurg ab5tract: src/Perl6/Metamodel, *Role*HOW* 14:21
ab5tract vrurg: thanks! I already started poking around in there 14:30
vrurg ab5tract: good luck on this! I'm keeping my eye on the issue, but can't start with it yet.
MasterDuke blog.carlmjohnson.net/post/2020/py...pposition/ relevant to several discussion that have been had here 20:35
m: say so all([]) 20:36
camelia True
MasterDuke huh. changing the `nqp::clone` to `nqp::decont` here github.com/rakudo/rakudo/blob/main...r.pm6#L843 causes `say (1..100).combinations(4).Array.elems` to slow down from ~5.7s to ~8.2s 20:47
m: use nqp; my int $a; for ^1_000_000 -> int $i { $a = nqp::clone($i) }; say now - INIT now; say $a 20:48
camelia 0.047119263
999999
MasterDuke m: use nqp; my int $a; for ^1_000_000 -> int $i { $a = nqp::decont($i) }; say now - INIT now; say $a
camelia 0.011423033
999999
MasterDuke but as ^^^ shows, nqp::decont should be faster... 20:49
nemokosch yep 20:50
and by the way, are all the clone calls necessary 20:51
for example, cloning the value that is a native int?
MasterDuke yeah. at least that one is. but i'm not sure why
m: say (1..100).combinations(4).tail; 20:53
camelia (97 98 99 100)
MasterDuke if you just remove the nqp::clone completely, you instead get `((Mu) (Mu) (Mu) (Mu))` 20:54
nemokosch pfff 20:58
MasterDuke and removing the ones around $combination cause `Cannot unbox a type object (VMNull) to int.`
MasterDuke the ones around $combination make sense. each time $combination (i.e., $!combination) gets *set* to a new combination, so it needs to be cloned when it gets pulled out as an individual element of the overall result list 23:28
what i don't understand is when i remove $!combination and create $combination as a new IterationBuffer each time, why i can't then remove the nqp::clone's around it 23:29
`Cannot unbox a type object (VMNull) to int. at SETTING::src/core.c/Rakudo/Iterator.pm6:2462` 23:30
MasterDuke huh. wouldn't have expected that gist.github.com/MasterDuke17/bb2dc...cc4762990a would slow down `say (1..100).combinations(4).tail; say now - INIT now` by ~1s 23:49

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!