🦋 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.
nine Chances are that the bug will just disappear with the switch to RakuAST as we will have to completely rewrite the static optimizer, too 07:31
Nemokosch When you are developing/fixing something, what workflow are you using? Like, what are you checking locally, where do you push, things like that 09:49
can I use a rakubrew build or should I set up something independent? 09:50
nine I have never used rakubrew. I just have the repository checked out 10:03
Nemokosch and what do you need to rebuild in the case of a change in the core? 10:06
Voldenet just `make && make install` is sufficient 10:10
on rakudo repo
Nemokosch and how would you test the very development? 10:14
Voldenet I remember playing around the code and a lot of things you can directly copy into single file 10:15
rename classes, ignore the standard library and focus on the problem 10:16
Nemokosch under gen? 10:17
Voldenet Nope, just a regular raku script
I remember adding some opcodes to moarvm and the approach worked, insanely enough
though it required recompiling mvm/nqp obviously
Nemokosch well, that sounds funny 10:19
anyway, it would be good to have some tests that can be kept/reused
nine I don't understand this question: "how would you test the very development?" 10:31
Nemokosch what you exactly did 10:32
lizmat RAKUDO_RAKUAST=1 make spectest | grep '\. ok' | wc -l 10:34
nine I change code, run make, then ./rakudo-m -Ilib t/path/to/test/file.t
Nemokosch thanks 10:46
Geth rakudo/main: 6ef8993fbd | (Elizabeth Mattijsen)++ | src/core.c/Rakudo/Internals.pm6
Don't pollute PROCESS:: with failed $*FOO lookups

Instead, put the failed lookups in a separate internal hash. This means one additional PROCESS::.ESISTS-KEY for each failed dynamic var lookup, while retaining the advantage of not needing to make a new Exception/Failure every time.
11:00
rakudo/main: 04329e4504 | (Elizabeth Mattijsen)++ | src/Raku/ast/code.rakumod
Make sure NEXT/LAST/QUIT/CLOSE phasers capture

This was missing, causing no captures to be done by these phasers, which in turn kept tests from passing.
11:17
lizmat 109 / 635 !!! 11:18
(using nine's way of testing)
Nemokosch what are the numbers? 11:25
lizmat 109 / 139 fully passing test files in "make test" 11:28
635 / 1355 fully passing test files in "make spectest" 11:29
Nemokosch woah that's cool 11:39
[Coke] nine++, lizmat++ ! 14:58
[Coke] So, Attribute has a bunch of attributes - it's defined early, so there's not a lot of raku code for some of these, and the even the NQP code to bootstrap it is light. For example, someone just mentioned dimensions - looks like this Attribute attribute exists but doesn't have any logic associated with it. 16:05
looks like it might be something added to *every* Attribute, even if it might only be used for shaped arrays? 16:06
Nemokosch could be 16:30
nine Yes, only native and shaped array attributes use this bit of information 16:49
Geth rakudo/main: b2f61d8612 | (Elizabeth Mattijsen)++ | src/Raku/Actions.nqp
Compress setting up phasers with a helper method
17:01
rakudo/main: d2c1de3c36 | (Elizabeth Mattijsen)++ | src/core.c/RakuAST/Deparse.pm6
Compress setting up statement prefixes with a helper method
[Coke] Wonder if it would be worth reducing the scope of when it's available (get some minor memory savings?) 18:21
lizmat [Coke]: this is about the Attribute object, of which there is only one per attribute / class 19:32
nine You will safe hundreds of bytes! (in a large application) 19:33
On that note: lizmat, github.com/rakudo/rakudo/commit/d2c1de3c36 seems to safe 2 characters per affected deparse method (32 characters in total), at the expense for > 90 characters of new code. Is that really worth it? 19:36
lizmat that one is more about the binary code size, really, inlining only the ones that need it ? 19:46
nine I'd just not worry about that kind of optimization. Especially in deparsing, which just is not hot code 19:53
lizmat but it *does* live in the core... 19:59
always
nine But does it actually make a difference if the code is not run? 20:10
Geth rakudo/main: d10c27506b | (Elizabeth Mattijsen)++ | src/core.c/RakuAST/Deparse.pm6
Revert "Compress setting up statement prefixes with a helper method"

This reverts commit d2c1de3c36d2ae447efd767279ad5fbac8b89bed.
20:17
Nemokosch how long does make spectest usually run? 23:38
lizmat depends on how many core you have 23:39
with TEST_JOBS=16 on my M1 mini, it's about 3.5 minutes 23:40