🦋 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.
lizmat notable6: weekly 10:33
notable6 lizmat, 1 note: 2023-09-15T21:41:39Z <melezhik>: dev.to/melezhik/sparrowci-has-move...ences-110o
lizmat notable6: weekly reset
notable6 lizmat, Moved existing notes to “weekly_2023-09-18T10:33:51Z”
lizmat And yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2023/09/18/2023-...ew-search/ 10:42
Geth rakudo/main: a1a658abe6 | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: some more <sym>s that don't need to be captured
 11:17
Geth rakudo/main: c4511e4cfb | (Elizabeth Mattijsen)++ | 2 files
RakuAST: some backslash sequence streamlining
 13:01
ugexe i know i asked before, but does anyone see any optimizations that could be made to gist.github.com/ugexe/06469f5d3e06...ceed814883 ? 15:48
japhb Why do lines 7 and 8 have different placement of BEGIN? 16:08
It seems weird that lines 19-21 would be the fastest way to pad, since you can simply *calculate* how many bytes to add and then do that. 16:10
Lines 24-35 don't need all that -- you can write a 64-bit int using the endianess you desire as a single call. 16:11
Lines 44-48 could similarly be done with an endian-controlled read 16:12
Lines 62-72 should probably be broken into 4 separate loops to avoid the need for the ternary ladder 16:15
Are lines 83-91 actually faster than .base(16)? 16:16
(Or if you need to, a byteswap followed by a .base(16)) 16:18
ugexe the placements of BEGIN are different because one is mutable and one is not 16:20
in the case of the mutable array, the begin comes after the = to ensure the default values are compile time values 16:21
the `= BEGIN ...` does appear to be slower than just not using the BEGIN at all though :P 16:29
ab5tract does anyone know why we use so many different formattings for implicitly created vars? I see `__` prefixed ones (produced by Signature), `$` prefixed ones (produced in the process of assembling whatever codes), and bare names (produced by once). 18:01
tellable6 2023-09-16T18:12:20Z #raku-dev <nine> ab5tract: sorry, I don't know anything about all about how state variables are implemented
ab5tract since these implicits are available in the scope, maybe it would make sense to standardize? 18:02
Geth roast: 35456a1a68 | ab5tract++ | S02-types/whatever.t
Add test for issue 5343
 18:26
ab5tract this is in preparation for the fix :) 18:33
what happens if a fix makes some tests fail that were invalidly passing in the first place? 19:23
ugexe how old is the test? is the behavior it affects something someone has any likelyhood of depending on? 19:31
ab5tract ugexe: good questions. in this case, it turns out to be a PEBKAC assumption of mine. it turns out I can't fix postfix whatevercode scoping without addressing prefix whatevercode scoping as well 20:12
Geth rakudo: ab5tract++ created pull request #5385:
RakuAST: Fix topic over-simplification in curried ApplyPostfix		 21:47

Powered by Cro and the Raku® Programming Language.

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

Thank you!