🦋 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.
Geth rakudo/main: dc452c57c0 | (Elizabeth Mattijsen)++ | src/Raku/ast/call.rakumod
Remove RakuAST::Call::Method.shortname

Replace by .canonicalize, as per nine++ suggestion		 10:04
Geth rakudo/main: 0354c47892 | (Elizabeth Mattijsen)++ | src/core.c/RakuAST/Deparse.pm6
Simplify circumfixing in deparsing

Also add a missing () in an error message		 11:10
lizmat nine: should semilists be deparsed with ; as delimiter, or as , ? 11:58
nine I'm not sure I understand Raku well enough to answer that :D 11:59
lizmat basically the difference between: 12:04
m: my @a = <a b c d>; say Q/@a[0,1]/.AST.dump
camelia CompUnit 𝄞 /home/camelia/EVAL_0:1 ⎡@a[0,1]⎤
StatementList 𝄞 /home/camelia/EVAL_0:1 ⎡@a[0,1]⎤
Statement::Expression ▪𝄞 /home/camelia/EVAL_0:1 ⎡@a[0,1]⎤
ApplyPostfix ⎡[0,1]⎤
Var::Lexical ⎡@a⎤…
lizmat and:
my @a = <a b c d>; say Q/@a[0;1]/.AST.dump
m: my @a = <a b c d>; say Q/@a[0;1]/.AST.dumpa
camelia No such method 'dumpa' for invocant of type 'RakuAST::CompUnit'. Did
you mean any of these: 'DUMP', 'dump'?
in block <unit> at <tmp> line 1
lizmat m: my @a = <a b c d>; say Q/@a[0;1]/.AST.dump
camelia CompUnit 𝄞 /home/camelia/EVAL_0:1 ⎡@a[0;1]⎤
StatementList 𝄞 /home/camelia/EVAL_0:1 ⎡@a[0;1]⎤
Statement::Expression ▪𝄞 /home/camelia/EVAL_0:1 ⎡@a[0;1]⎤
ApplyPostfix ⎡[0;1]⎤
Var::Lexical ⎡@a⎤…
lizmat I think one of the tests is set up incorrectly... 12:06
glad I have the .AST method now... :-)
Nemokosch what does it do? 12:33
lizmat it parses the given string using the new Raku grammar, and returns the produced RakuAST nodes 12:36
Nemokosch oh, and deparse takes this a step further by providing a Raku source code representation? 12:38
lizmat yes 12:38
m: say Q/my $a = 42/.AST.deparse 12:39
camelia No such method 'deparse' for invocant of type 'RakuAST::CompUnit'. Did
you mean 'DEPARSE'?
in block <unit> at <tmp> line 1
lizmat m: say Q/my $a = 42/.AST.DEPARSE
camelia my $a = 42
lizmat the leading spaces are a bug
in the deparsing
m: say Q/my $a = 42/.AST.dumo
camelia No such method 'dumo' for invocant of type 'RakuAST::CompUnit'. Did
you mean any of these: 'DUMP', 'dump', 'sum'?
in block <unit> at <tmp> line 1
lizmat m: say Q/my $a = 42/.AST.dump
camelia CompUnit 𝄞 /home/camelia/EVAL_0:1 ⎡my $a = 42⎤
StatementList 𝄞 /home/camelia/EVAL_0:1 ⎡my $a = 42⎤
Statement::Expression ▪𝄞 /home/camelia/EVAL_0:1 ⎡my $a = 42⎤
VarDeclaration::Simple ⎡$a = …
lizmat nine: something like "(3,4)" codegens into a SemiList(Statement::Expression(ApplyListInfix(...))) 13:29
however, all seems to work without the Statement::Expression step
aka: SemiList(ApplyListInfix(...))
is this an optimization not yet performed on the codegen side, or should I adapt deparsing tests accordingly ? 13:30
nine No! That's plain wrong. SemiList is a StatementList and the contained statements are required to be RakuAST::Statement subclasses. I have only just fixed a bug where we didn't stick to this rule in commit 8b9fb402b9cbcfaf9762b49e90a74840c06621ef. Let's not introduce more problems like that. 13:37
lizmat ok, so I guess I'll need to fix a few tests :-) 13:38
nine I assume an empty SemiList can live without a Statement::Expression in it 13:45
nine Sure. An empty list is an empty list. It's just that if there is something in it, it must be statements. 13:46
lizmat ack 13:49
Geth rakudo/main: 9aea72f59c | (Elizabeth Mattijsen)++ | 3 files
Fix deparsing of SemiLists

And adapt tests to use AppltListInfix where applicable		 14:15
rakudo/main: 8ee5e99bd5 | (Elizabeth Mattijsen)++ | t/12-rakuast/call.rakutest
Some more explanations in TAP output
 14:27
Geth rakudo/main: d0916e9a51 | (Stefan Seifert)++ | src/Raku/ast/name.rakumod
Implement canonicalization of expression parts in names

The canonical form of arbitrary Raku expressions is obviously the deparsed string as parsing+deparsing takes all the possible forms one can spell a Raku expression and turns them into one canonical form.		 15:16
rakudo/main: dcff39f62d | (Stefan Seifert)++ | src/Raku/Actions.nqp
RakuAST: fix failure to resolve &infix:<<whatever>> variables

We need to turn such a name into its canonical form before looking it up in surrounding scopes as it will be registered under the canonical name.
nine 89 passing test and 605 passing spectest files
Nemokosch nine: is all this something that you just know by heart or is any of this written down anywhere? 15:42
nine Nemokosch: it's just good old fashioned debugging and reasoning. What else but the deparse result could be a canonical form of an expression? And with many different ways to spell the same name, we must standardize on one form if we want to find it in a lookup hash (which is what resolving a name really does) 15:46
tellable6 nine, I'll pass your message to Nemokosch
Nemokosch no, I mean, what a certain source code should correspond to in AST form 16:04
because that has been the biggest burden for me for one; not knowing what even is the right interpretation 16:05
lizmat nine: wouldn't these references to .DEPARSE fail once we try to build the setting with the Raku grammar ? 17:08
ugexe fyi there appears to have been a regression re: windows and module installation -- github.com/ugexe/zef/issues/491 17:59
ugexe i dont think this is specific to TAP either. Other people have noted similar issues with their windows github actions that appear to be precomp related 18:03
timeline wise the only thing that sticks out is github.com/rakudo/rakudo/commit/71...0453f618b6 but I'm not sure how that change would fail most of the time but succeed rarely 18:05
unless its a race condition with CALLERS.EXISTS-KEY
it looks like that wasn't in the 2022.12 release though 18:07
vrurg The race condition doesn't look as an unlikely cause. 19:35
Geth rakudo/lizmat-unicode-version: 0be7a68d37 | (Elizabeth Mattijsen)++ | 4 files
Introduce $?UNICODE-VERSION in 6.e

Instead of doing difficult things in MoarVM or JVM, just set the constant in the setting code. Whenever a Unicode update is to be done, updating this constant should be part of the Pull Request.		 19:36
rakudo: lizmat++ created pull request #5153:
Introduce `$?UNICODE-VERSION` in 6.e
ugexe does the jvm even support unicode 15? 19:52
13 rather
similarly the other backends 19:53
lizmat well, I don't know... but that could be easily handled by #?if jvm etc 20:02
Geth rakudo/lizmat-unicode-version: 484eed9544 | (Elizabeth Mattijsen)++ | src/core.e/core_prologue.pm6
Make $?UNICODE-VERSION check the unicode database

As suggested by Stephen Schulze		 20:12
ugexe sure, but i was questioning what was there 20:21
ugexe actually im not sure #?if jvm would help for e.g. jvm since it would need to be more like #?if jvm:ver<...> 20:39
however, that runtime code looks like it should solve all those problems 20:40
nine lizmat: could be come a problem. But that's then. We'll deal with it somehow. It may just be that the settings code never reaches this case. 22:27
lizmat one can hope :-) 23:27

Powered by Cro and the Raku® Programming Language.

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

Thank you!