🦋 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.
00:00 reportable6 left 00:02 reportable6 joined, guifa joined 02:40 linkable6 left, evalable6 left 02:42 evalable6 joined, linkable6 joined 04:38 heartburn left 04:41 heartburn joined 05:17 jaguart left 06:00 reportable6 left, reportable6 joined
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
09:05 ab5tract joined
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
10:09 ab5tract left
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.
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.
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
11:32 linkable6 left 11:34 linkable6 joined
Nemokosch woah that's cool 11:39
12:00 reportable6 left, reportable6 joined 13:00 reportable6 left, unicodable6 left, linkable6 left, committable6 left, shareable6 left, benchable6 left, notable6 left, coverable6 left, greppable6 left, quotable6 left, sourceable6 left, squashable6 left, bloatable6 left, releasable6 left, tellable6 left, statisfiable6 left, evalable6 left, bisectable6 left 13:01 coverable6 joined, releasable6 joined, bloatable6 joined 13:02 tellable6 joined, shareable6 joined, statisfiable6 joined, evalable6 joined, greppable6 joined, unicodable6 joined 13:03 bisectable6 joined, committable6 joined, squashable6 joined, reportable6 joined, quotable6 joined, benchable6 joined, linkable6 joined, sourceable6 joined, notable6 joined
[Coke] nine++, lizmat++ ! 14:58
15:01 linkable6 left, evalable6 left, evalable6 joined 15:03 linkable6 joined 15:16 epony left
[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
rakudo/main: d2c1de3c36 | (Elizabeth Mattijsen)++ | src/core.c/RakuAST/Deparse.pm6
Compress setting up statement prefixes with a helper method
18:00 reportable6 left 18:01 reportable6 joined
[Coke] Wonder if it would be worth reducing the scope of when it's available (get some minor memory savings?) 18:21
19:14 linkable6 left, evalable6 left 19:16 linkable6 joined, evalable6 joined
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
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.
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