🦋 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.
NemokoschKiwi bisectable6: sub demo(Int :@values) { dd @values;};demo(); 09:16
bisectable6 NemokoschKiwi, Will bisect the whole range automagically because no endpoints were provided, hang tight
NemokoschKiwi This seems to have been fixed - but was it intentional or not?
bisectable6 NemokoschKiwi, Output on all releases: gist.github.com/72e895222948fab1e1...adf8c3b0ed
NemokoschKiwi, More than 4 changes to bisect, please try a narrower range like old=2022.03 new=HEAD
NemokoschKiwi hmmm... "it's complicated" :D 09:18
Geth rakudo/main: 6ae35eb958 | (Elizabeth Mattijsen)++ | 6 files
RakuAST: rework how regular expressions are codegenned

Before this commit, the behaviour of :s (aka sigspace) was codegenned into the ASTs. After this commit, the sigspace functionality is a a parameter taken into account when creating the QAST for a regex.
This means that as a developer building custom regex ASTs, one does ... (25 more lines)
10:51
lizmat *phew* that took a few days to figure out
m: say "oo oo" ~~ ms/ oo / # TIL ms// is a thing the same as m:s// 10:53
camelia 「oo 」
Nemokosch pfff
I still feel this aversion for ~~ m//, even though that's not the problem in my approach either 10:54
lizmat fwiw, I think ms// should be deprecated 10:55
Nemokosch it's hard to keep track of these one-character shortcuts for sure
lizmat it doesn't seem to be documented
it *is* tested, which is how I found out 10:56
Nemokosch 🤯
I wonder how long my RakuAST solution to that weekly challenge like 2 weeks ago will survive 😅 10:58
perhaps I should have pinpointed the exact commit to which one should build to make that work, lol
lizmat pretty sure it will
the one with the character class from a string ? 10:59
Nemokosch yep
Geth rakudo/main: b3ac1d747e | (Elizabeth Mattijsen)++ | 2 files
RakuAST: fix faulty test + prevent wrapping recursion

So this basically prevented from *any* whitespace wrapping to occur, but without breaking any test files :-( I guess more work is needed.
12:40
rakudo/main: 28822c8462 | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: add comments to keep %*RX<s> for now
13:21
lizmat is getting really confused as to where :ratchet behaviour is encoded in regexes 14:00
that ASTs of token / regex appear to be identical
s/AST/QAST 14:01
Geth rakudo/main: ad97d8d5dc | (Elizabeth Mattijsen)++ | 2 files
RakuAST: remove %*RX<r> setting from grammar

And add it to the QAST mods hash when creating QAST for RakuAST::RegexDeclaration objects
The odd thing is that just removing the %*RX<r> settings from the grammar doesn't seem to affect any spectests.
14:04
Geth rakudo/main: c6b2f8ac03 | (Elizabeth Mattijsen)++ | 3 files
RakuAST: add basic tests for RakuAST::RegexDeclaration
15:26
rakudo/main: a774873881 | (Elizabeth Mattijsen)++ | t/12-rakuast/regex-declaration.rakutest
RakuAST: demonstrate re-usability in regex declarations

Mostly to ensure that WithWhitespace wrapping is neutral by itself, only when used inside a rule, will it gain sigspace semantics.
15:42
Geth rakudo/main: fb53d50a8a | (Elizabeth Mattijsen)++ | 2 files
RakuAST: eradicate use of %*RX<s> in the grammar

Instead introduce a more descriptive $*WHITESPACE_OK dynamic variable, and have a local version of nqp's <atom> rule use the newly added X::Syntax::Regex::InsignificantWhitespace class if whitespace is detected and $*WHITESPACE_OK is not set.
17:11
nine Parameter tangling is a tangled mess....but I fear the only way to do it is to actually copy the existing mess 18:42
lizmat copying is a start, I guess :-) 18:43
BTW, do we have better syntax for looking up multi-part types in the setting than this?
m: dd SETTING::<IO>.WHO<Path>.WHO<Unix> 18:44
camelia IO::Path::Unix
Geth rakudo/main: 331fd237a2 | (Elizabeth Mattijsen)++ | src/core.c/Exception.pm6
Some exception message tweaking
18:45
nine I don't know any 18:46
[Coke] I started looking at making 'use v5' throw the right error in AST, and I will have questions. 18:47
nine cool! 18:49
[Coke] ... oh, it makes more sense this time. lang_setup in Actions, yes? 18:51
Geth rakudo/main: 16924b4128 | (Elizabeth Mattijsen)++ | src/core.c/IO/Path/Parts.pm6
Fix IO::Path::Parts.raku

It needs to be a multi to handle the type object correctly
18:56
nine Definitely the place to start 19:03
[Coke] ok, lang_setup appears to have logic to check version, but the error on use v5 when runningn with RAKUDO_RAKUAST is really coming from src/Perl6/Compiler.nqp 19:57
that was my confusion from before, I think. digging 19:59
... the exception type is actually being set in World, I think. 20:05
lizmat there is no World in RakuAST 20:16
nine The world is no more 20:28
Geth rakudo/main: 9ef618ff5c | (Elizabeth Mattijsen)++ | 2 files
RakuAST: fix deparsing of RakuAST::Type::Setting

It's butt ugly, but we don't have an other syntax for it. Adapt test and add a test for multi-part lookups.
20:37
lizmat vrurg: wouldn't it make a lot of sense to stick both "UNIT::" and "SETTING::" in a bindhllsym for easy fetching and no stack walking ? 20:54
tellable6 lizmat, I'll pass your message to vrurg
lizmat afk& 20:56
vrurg__ lizmat: bindhllsym is a global thing, UNIT is different for each compunit. 20:57
tellable6 2023-03-21T20:54:45Z #raku-dev <lizmat> vrurg: wouldn't it make a lot of sense to stick both "UNIT::" and "SETTING::" in a bindhllsym for easy fetching and no stack walking ?
vrurg lizmat: SETTING is problematic too because it depends on compunit's language version. 20:58
[Coke] Is it OK to change the nqp::die in src/Perl6/Compiler about unsupported version to throw an exception of the right type there? 21:58
[Coke] (I am currently trying to find a way to code it that doesn't explode) 22:00
vrurg [Coke]: I'm afraid, exception classes might not be available at that location and, very likely, that time. 23:23
[Coke] ok. 23:25