ugexe i was hoping to try and make `return` statements in the rakuast classes work and perform like falling off, but i don't think i'll get to it today 01:32
05:52 kjp left 05:56 kjp joined 06:07 finanalyst joined
Geth rakudo/main: 9bb53f07c7 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/Raku/ast/type.rakumod
RakuAST: turn ::Type.is-known-to-be(.exactly) into single ternary (#6786)

With a --> Bool signature to convert the result into a Bool		 07:11
lizmat ugexe: I wouldn't spend much time on that: many of these cases can be rewritten without using return 07:12
and many cases using return, already return Bools without needing --> Bool in the signature
Geth rakudo/lizmat-50: 66d18b84b8 | (Elizabeth Mattijsen)++ | src/Raku/ast/name.rakumod
RakuAST: don't create colonpairs unless needed

The RakuAST::Name object is usually created *without* any colonpairs. So instead of always allocating a list for it, only allocate a list for it when it is actually needed. This should reduce memory churn on nurseries quite a bit during compilation.
It should also help in runtime with all cases that would otherwise iterate over an empty list (at the expense of slightly bigger bytecode).		 08:56
rakudo: lizmat++ created pull request #6788:
RakuAST: don't create colonpairs unless needed		 08:57
rakudo/main: fdab3016ab | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/Raku/ast/name.rakumod
RakuAST: don't create colonpairs unless needed (#6788)

The RakuAST::Name object is usually created *without* any colonpairs. So instead of always allocating a list for it, only allocate a list for it when it is actually needed. This should reduce memory churn on nurseries quite a bit during compilation.
It should also help in runtime with all cases that would otherwise iterate over an empty list (at the expense of slightly bigger bytecode).		 09:41
ShimmerFairy So, I think I'm ready to share my work on upgrading to Unicode 18, but I have a couple question about how to do it. First, should I try to fast-forward my branches before sharing them? Second, would it be better to share it in "stages", so as to avoid spurious CI failures? (I was thinking getting MoarVM changes approved & merged in, then NQP, then rakudo + roast together?) 09:59
Sharing it in stages might cause problems for the un-updated later parts, however, depending on how things like the new grapheme rules interact with the old tests. I imagine false negatives on CI for such multi-repo changes are to be expected, but I'd still like to avoid them. 10:01
Geth rakudo/main: c4f48ce972 | (Elizabeth Mattijsen)++ | 2 files
RakuAST: make sure ::Name::Part::EmptyEdge is always instantiated

Even though it doesn't actually need to be, except any concrete checks when walking the tree.
Also add a comment as to why .add-colonpair is used		 10:38
lizmat ShimmerFairy: stages would seem the most logical to me, failures during the upgrade path are probably unavoidable
ShimmerFairy And what about fast-forwarding my local branch over main? Would it be helpful for me to try that before sharing, or do people not particularly care about how tidy the merge history is? (I actually don't know if PRs would do the ff for me, I have surprisingly little experience with pushing things to github.) 11:12
Another area where it's probably not a big deal, but considering the flurry of activity around the latest release (esp. around rakuast), a part of me thinks it'd be prudent to test everything combined with those recent changes before submitting PRs. 11:13
11:13 finanalyst left
lizmat I'd say we should only concern ourselves with the new Raku grammar, *not* the legacy grammar 11:14
we try to do branches most of the time nowadays, to test CI fallout 11:15
Geth rakudo/lizmat-51: 775f9a0cc3 | (Elizabeth Mattijsen)++ | 5 files
RakuAST: add ::Name.from-identifier-list

This is now the actuall workhorse of from-identifier-parts. It allows specification with a list. This is a significant performance improvement when slipping and slurping aren't needed.
Adjust internal calls where this would make sense.		 11:19
ShimmerFairy I don't think anything I did would be affected by grammar changes, it's just more that I'm concerned you'll see the CI on a PR say "great!", then merge to main and it suddenly breaks. All in all, unless there's any other best practice you want to tell me about, I should just get ready to start pushing branches. 11:20
Geth rakudo: lizmat++ created pull request #6789:
RakuAST: add ::Name.from-identifier-list
lizmat yeah, push branches, we'll see when it breaks :-)
still plenty of time before release :-)
ShimmerFairy That's the good part about deciding to not rush it :) 11:22
Geth rakudo/main: d985b8974d | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | 5 files
RakuAST: add ::Name.from-identifier-list (#6789)

This is now the actuall workhorse of from-identifier-parts. It allows specification with a list. This is a significant performance improvement when slipping and slurping aren't needed.
Adjust internal calls where this would make sense.		 12:04
rakudo/lizmat-52: 7704bc5c2e | (Elizabeth Mattijsen)++ | 4 files
RakuAST: use nqp::ifnull where possible

In a lot of cases, a rather elaborate structure was built to provide a value if the given value was nqp::null. Exactly for that purpose, nqp::ifnull was created. So use that instead, resulting in fewer variables and smaller bytecode footprint.
Appears to take off about .2 seconds on stage qast when building the core setting (for yours truly).		 12:59
rakudo: lizmat++ created pull request #6790:
RakuAST: use nqp::ifnull where possible
rakudo/lizmat-53: 34a7d51698 | (Elizabeth Mattijsen)++ | 10 files
RakuAST: normalize "while !x" and "if !x" structures

Using "until" or "unless" as appropriate, or re-arrange the reverse the if/else structure, sometimes allowing for a scope level to be lost		 13:42
rakudo: lizmat++ created pull request #6791:
RakuAST: normalize "while !x" and "if !x" structures
ShimmerFairy Y'know, realizing that the CI is gonna break regardless, I'm thinking I should just share the rest of my changes now, esp. since I don't want to leave things partially shared for too long. 14:21
Geth nqp/unicode-18.0: 011158ddac | Faye++ | t/nqp/106-unicodenames.t
Add tests for Jurchen and Small Seal scripts.

These tests ensure their Unicode names are properly generated by the backend.		 14:33
nqp: ShimmerFairy++ created pull request #879:
Unicode 18.0 update		 14:35
rakudo: ShimmerFairy++ created pull request #6792:
Update for Unicode 18.0		 14:41
14:46 timo joined
Geth roast/unicode-18.0: 3b29e673c4 | Faye++ | 66 files
Update generated tests for Unicode 18.0.0
 14:46
roast/unicode-18.0: 23450635d3 | Faye++ | S32-str/utf8-c8.t
Add tests for UTF-C8 synthetics in grapheme construction.

Inspired by a bug in MoarVM, these tests ensure that UTF-C8 synthetics get handled appropriately as Raku creates NFG strings. In particular, they should be treated as if they were ordinary control characters, meaning they always exist as 1-"codepoint" graphemes, never merging with any other codepoints into larger grapheme clusters. ... (10 more lines)
roast/unicode-18.0: d67e6fdee7 | Faye++ | 6 files
Update collation tests for bugfixes.

With some bugfixes to MoarVM's collation handling, the collation tests need to be regenerated, since the test generator is sensitive to the correctness of the very thing being tested.
roast: ShimmerFairy++ created pull request #923:
Update for Unicode 18.0		 14:49
ShimmerFairy That's all the repos then. I haven't touched any of the ChangeLogs or FOO_REVISION files, for the record. 14:51
ugexe we can run Blin against a branch 14:52
lizmat: return could work for more than just Bool. things are they way they are right now because they have to be written that way, not because it is some gold standard 14:54
im also worried about people thinking they can make (what they think are) inconspicuous changes and ending up breaking either the constraint contracts or optimizations 14:56
that being said i've got like a bajillion thunk issues i've been trying to work through so no idea if i'll even get around to adding that return functionality 15:01
the thunk stuff for rakuast is exponentially more difficult to get right than legacy because legacy thunks are real blocks made at parse time so closures get the right outer for free, while rakuast thunks hang off expressions and every walk (thunks, phasers, regexes, roles, BEGIN time, etc, etc) has to independently agree on where each block gets declared 15:03
and every edge case fixed opens another
and that all gets further complicated by the various optimizations so everything has to be tested and considered with and without optimizations 15:05
m: role R { method m { 42 andthen 1 + 2 } }; say "compiled"; # one example
camelia compiled
ugexe c: role R { method m { 42 andthen 1 + 2 } }; say "compiled"
committable6 ugexe, ¦role: «Cannot find this revision (did you mean “coke”?)»
ugexe raku -e 'role R { method m { 42 andthen 1 + 2 } }; say "compiled"' 15:06
===SORRY!===
QAST::Block with cuid 3 referenced from '<dependencies+deserialize>' has not appeared in -e
ShimmerFairy I'll be heading off to bed now, hope the Unicode upgrade doesn't give people too much grief. o/ 15:17
ugexe hmmm, it looks like there is going to conflicts on the branch i've been working on too :( 15:24
these large resturcturings are going to make it difficult for me to fix these larger problems that have to touch many parts of the code base 15:26
i think it would be preferable to focus on fixing issues right now 15:27
i guess its inevitable and i'm just getting frustrated with this thunk stuff :/ 15:36
15:47 lizmat left 18:58 finanalyst joined 19:00 lizmat joined 19:33 lizmat left
[Coke] (blin against a branch) - need to branch nqp separately with your change and bump moar. then rebranch rakduo with your changes there and bump nqp. the we blin *that branch* 20:46
21:55 finanalyst left

Powered by Cro and the Raku® Programming Language.

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

Thank you!