🦋 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.
MasterDuke nine: huh, thanks. will attempt that 02:29
hm. so i added `has int $!p5isms;` and `nqp::bindattr_i($obj, int, '$!p5isms', $p5isms ?? 1 !! 0);` to RakuAST::Call::Name and then `p5isms => $*LANG.pragma('p5isms')` to all the places (i think) a RakuAST::Call::Name is created in src/Raku/Actions.nqp and rakudo builds, but i get `P6opaque: no such attribute '$!p5isms' on type int in a 03:18
RakuAST::Call::Name when trying to bind a value` when running `RAKUDO_RAKUAST=1 raku -e 'use isms <Perl5>; say'`
nevermind, `nqp::bindattr_i($obj, int, '$!p5isms', $p5isms ?? 1 !! 0);` should be `nqp::bindattr_i($obj, RakuAST::Call::Name, '$!p5isms', $p5isms ?? 1 !! 0);` 03:26
nine lizmat: how early do you need core.c? 07:48
Geth rakudo/main: 134418bd16 | (Stefan Seifert)++ | src/Raku/Grammar.nqp
RakuAST: fix regression in BEGIN time EVAL processing

Commit a7571cb482847267c176455e9d1b6680c0511a4c removed the old POD implementation from the grammar, but also removed an unrelated line leading to the regression.
08:15
lizmat nine++ 09:22
nine: *before* any code is encountered 09:23
during parsing
Geth rakudo/main: 2dd66bcb85 | (Stefan Seifert)++ | 2 files
RakuAST: load CORE.c setting early for POD parsing

Parsing of POD needs classes defined in the CORE.c setting, so load it early and unconditionally. Any other setting will be loaded on top of that anyway.
09:30
nine lizmat: you're not out of the water yet. $*CU.pod-content.push($_.value.make-legacy-pod); will fail because there's no $*CU yet 09:31
lizmat nine: well, that's temporary anyway
it will need to create the legacy pod at CHECK time anyway 09:32
otherwise you won't be able to create custom RakuAST::Doc::Block nodes
nine I'll leave that in your capable hands :) 09:41
And another broken spectest: throws-like { EVAL 'module MY;' } 09:48
It's only coincidence that we throw the expected expection before realizing that the "unit" is missing
lizmat m: say␤=head1 FOO␤$=pod 09:52
camelia ===SORRY!===
Argument to "say" seems to be malformed
at <tmp>:1
------> say⏏<EOL>
Other potential difficulties:
Unsupported use of bare "say". In Raku please use: .say if you meant
to call it as a method on $_, or u…
nine m: unit module MY;
camelia ===SORRY!=== Error while compiling <tmp>
Cannot use pseudo package MY in package name
at <tmp>:1
------> unit module MY⏏;
expecting any of:
generic role
nine m: package Foo { module MY { } }
camelia ===SORRY!=== Error while compiling <tmp>
Cannot use pseudo package MY in package name
at <tmp>:1
------> package Foo { module MY⏏ { } }
expecting any of:
generic role
nine m: module Foo::MY { }
camelia ( no output )
lizmat MEH 09:53
m: say␤=head1 FOO␤␤$=pod
camelia [Pod::Heading{:level("1")}
Pod::Block::Para
FOO
]
lizmat TIL that you can have pod blocks in the middle of a statement
nine: did you know that ? 09:54
nine is a total POD newb
lizmat was as well
it's because pod blocks are basically the same as whitespace 09:55
Geth rakudo/main: b29e108487 | (Elizabeth Mattijsen)++ | src/Raku/Actions.nqp
RakuAST: reorganize Actions.statement a bit

Move the common code to the end of the method, for readability, but mostly to allow common statement actions to be done in one place. Also add some comments for clarity.
10:35
rakudo/main: aedeadf988 | (Stefan Seifert)++ | src/Raku/ast/name.rakumod
RakuAST: treat COMPILING as pseudo-package

COMPILING seems to be a reserved name and should be prohibited for declarations as pseudo-package, even though it's not actually implemented as such.
10:37
rakudo/main: 8b462b40a6 | (Stefan Seifert)++ | 4 files
RakuAST: prohibit using pseudo-package names in declarations
[TuxCM] github.com/rakudo/rakudo/issues/2483 extended with my yesterday findings 12:17
lizmat nine: ok, so I have the rakudoc blocks being added to the statement lists 17:44
however, it looks like they don't have their PERFORM-CHECK methods getting called
m: use v6.*; dd RakuAST::StatementList ~~ RakuAST::CheckTime 17:46
camelia Bool::False
lizmat meh
nine Are those blocks RakuAST::CheckTime? 17:55
lizmat the RakuAST::Doc::Blocks are 17:56
think I found it 17:57
nine What was it? 18:02
lizmat yup, StatementList.visit-children was explicitely ignoring RakuAST::Doc::Blocks
nine Oh, yes, that can't be good. 18:03
lizmat codesections o/ 18:32
apparently we have spectests for pod inside code 18:37
inside a statement
apparently, having pod inside a { } intended to be a hash, now codegens as a block
also: having t/spec/S26-documentation/07b-tables.t pass until now, was a false positive 18:38
lizmat it only contains 4 dies-ok tests, and one of them doesn't die anymore 18:38
nine: re the block / hash test, any idea where I should look for that? 18:40
lizmat I'm inclined to push even though tests are +1 -1 18:56
with the note that the passing of S02-lexical-conventions/pod-in-multi-line-exprs.t before was a false positive 18:57
nine: ^^ ok with that ?
nine lizmat: block-or-hash in src/Raku/ast/code.rakumod 19:48
nine If the test previously passing was just a false positive, "regressing" it is ok, I'd say 20:09
vrurg I wonder, if a BOOTHash corruption is the primary suspect of a problem, is there a way to track it down somehow? Worst case, it's a memory corruption, but could be something else. 21:17
Geth rakudo/main: 2bd735225e | (Elizabeth Mattijsen)++ | 6 files
RakuAST: RakuDoc blocks now interpreted correctly

Legacy pod blocks are now correctly created in $=pod from RakuAST objects, by moving the creation of the legace pod objects from the grammar to the CHECK time phase.
In the grammar, RakuDoc blocks are first stored in a dynamic array ... (9 more lines)
21:54
lizmat 794!
*phew*! 21:55
sleep&