🦋 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.
lizmat Is there a reason why we just use strings for declarator docs, instead of StrLiterals ? 09:50
*couldn't 09:51
the only reason I could think of is deparsing, but that could be easily fixed
it feels a bit weird to translate strings into StrLiterals to put them into RakuAST objects, to only have them converted back to strings at CHECK time 09:52
to wind up in $=pod
Geth rakudo/main: 8f5bb47fd7 | (Elizabeth Mattijsen)++ | 3 files
RakuAST: store declarator docs as Str rather than StrLiteral

Declarator docs can only be strings really, so it feels like a lot of work converting them to StrLiterals only to have them be converted back to Str at CHECK time. Any post-processing of strings (such as support for markup) would be done at CHECK time anyway.
Did this in a single revertable commit, for possible convenience.
10:31
rakudo/main: f9027be330 | (Elizabeth Mattijsen)++ | 2 files
RakuAST: add a HLL RakuAST::Doc::DeclaratorTarget stub

Where we can handle DeclaratorTarget logic in a HLL way
11:15
rakudo/main: 56d63c96c1 | (Elizabeth Mattijsen)++ | 6 files
RakuAST: stub in support for RakuAST::Var::Pod::Pod aka $=pod
11:42
lizmat nine: it looks like the "attaching" logic for "compunit" is finding the outer CU, instead of the inner CU of an EVAL 12:52
Geth rakudo/main: 5f66d8534e | (Elizabeth Mattijsen)++ | t/12-rakuast/var.rakutest
RakuAST: make test pass when using the legacy grammar
14:01
rakudo/lizmat-is-monotonically-increasing: 811f42b96e | (Elizabeth Mattijsen)++ | 3 files
Add "is-monotonically-increasing" method to Iterators

Returns False by default. If returning True, then .sort() can pass on the underlying iterator unchanged in a new Seq.
Added many Range iterators to set that, so that now:
   say (1..*).sort; # (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14...
will work, rather than throwing because the underlying iterator is lazy.
14:04
rakudo: lizmat++ created pull request #5243:
Add "is-monotonically-increasing" method to Iterators
14:05
Geth rakudo/lizmat-is-monotonically-increasing: 2e3f7020c5 | (Elizabeth Mattijsen)++ | 2 files
Make is-monotonically-increasing check more general
14:16
lizmat nine re "attaching" logic for "compunit" is finding the outer CU 14:45
it turns out that creating an inner CompUnit object does **not** add it to the attach-target stack 14:46
nine At what point is it missing from that stack? 14:50
lizmat at all points, I'd say 14:51
I haven't been able to find the place where the outer one gets set either
nine IMPL-CHECK pushes and pops the scope 15:07
lizmat but I don't see CompUnit implementing an IMPL-CHECK ? 15:16
it feels like LHF, but I can't seem to find where it's hanging :-) 15:19
nine RakuAST::Node does and RakuAST::CompUnit is a node 15:21
lizmat ok, this is getting stranger and stranger: push-scope *is* being called for the EVAL compunit 15:39
but is never getting called for the mainline CU
hmmm... I guess an EVAL would also imply a new Resolver object ? 15:47
nine my $resolver := RakuAST::Resolver::EVAL.new(:context($eval_ctx), :global(GLOBAL)); 15:48
src/core.c/ForeignCode.pm6:90
lizmat ok, that explains :-)
ok, I think I figured it out: $*CU is not getting updated in the grammar 15:52
nine Are you talking about EVALing an AST or a string? 15:56
lizmat AST 15:57
nine In that case, there is no grammar?
lizmat the AST is built from a string, sorry 15:58
ok, I see where you're getting at... 16:00
nine If we do parse, then $*CU gets set by the lang_setup action
Otherwise we don't need $*CU anyway. AST nodes don't use dynamic variables
lizmat right, and now I understand what my thinko was 16:01
if we want a =finish to survive while making an AST of source, we need an RakuAST::Node object to store it
lizmat in fact, we have such an object already: RakuAST::Doc::Verbatim.new(:type<finish>, :abbreviated, text => "finish test") 18:41
Geth rakudo/main: b5277b99fc | (Elizabeth Mattijsen)++ | src/Raku/Actions.nqp
RakuAST: no need to intern =finish text when encountered

It will only get serialized if there is a reference to $=finish anyway.
Also add the future code for making it a "normal" pod block element
18:51
nine m: class A { }; EVAL q<class A { }>; 18:56
camelia ===SORRY!=== Error while compiling /home/camelia/EVAL_0
Redeclaration of symbol 'A'.
at /home/camelia/EVAL_0:1
------> class A⏏ { }
expecting any of:
generic role
nine but:
use Test; class A { }; eval-lives-ok q<class A { }>;
evalable6 ok 1 -
nine How does that make sense?
lizmat eval-lives-ok doesn't inherit the scope ? 19:02
nine It should still find A in GLOBAL's stash. 19:03
m: my class A { }; EVAL q<class A { }>;
camelia ( no output )
nine This ^^^ clearly shows that we look in the current lexical scope and in the stashes.
m: class A { }; EVAL q<my class A { }>; 19:04
camelia ( no output )
nine And this ^^^ shows that we only look in stashes for our-scoped packages. Which makes sense.
lizmat eval-lives-ok does a try { EVAL $code } and returns $!
m: class A { }; try EVAL Q|class A{}|; dd $! 19:05
camelia Redeclaration $! = X::Redeclaration.new(symbol => "A", postfix => "", what => "symbol", pos => 7, filename => "/home/camelia/EVAL_0", line => 1, directive-filename => Any, column => Any, modules => [], is-compile-time => 1, pre => "class A", post => "…
lizmat but yeah, weird
nine According to my understanding, this eval-lives-ok should actually fail. Looks like a bug that it doesn't. A bug that several tests and spectests depend on unfortunately :/ 19:06
lizmat meh... yeah we were bound to find some warts in this project :-)
I know I did :-) 19:07
nine But why does it have to be packages and stashes of all things!? Any day I don't have to touch that stuff is a good day
lizmat m: class A { }; try { EVAL Q|class A{}| }; dd $! 19:11
camelia Redeclaration $! = X::Redeclaration.new(symbol => "A", postfix => "", what => "symbol", pos => 7, filename => "/home/camelia/EVAL_0", line => 1, directive-filename => Any, column => Any, modules => [], is-compile-time => 1, pre => "class A", post => "…
lizmat blocky try makes no difference
nine m: class A { }; package Moo { EVAL q<class A { }> } 19:13
camelia ( no output )
nine If it can't find it in the current lexical scope it's looking in the current package, but not in GLOBAL
lizmat but that would be a Moo::A
not A
m: class B::A { }; package Moo { EVAL q<class B::A { }> } 19:14
camelia ( no output )
lizmat hmmm
nine m: use Test; eval-lives-ok q<class A{}.^name.say>
camelia Test::A
ok 1 -
lizmat aha!
nine Yeah, all these packages are declared in Test
lizmat so, why does have Test "unit module Test" at the top? 19:15
I think it can do without ?
nine So one can opt out of importing everything and call Test::ok instead
lizmat and the our subs should be renamed to have a Test:: prefix? 19:16
nine Anyway at least this behaviour now makes sense and I know how to adjust my code to match it 19:17
lizmat still, this feels like a bug / shortcoming of Tesrt
*Test
Geth rakudo/main: a1c73f38bb | (Stefan Seifert)++ | 2 files
RakuAST: re-use a stubbed package's meta-object for the real thing

Fixes failures of type checks done before the lexical location of where the package is defined for real, e.g. class F {}; sub(F $f) {}; class F {};
19:56
vrurg_ BTW, speaking of namespaces, the following looks like a bug to me: 20:27
m: class Foo { role Bar { }; class Bar::Baz does Bar { } }; say Bar::.keys
camelia (Baz)
vrurg If the role declaration is removed then things go as they must: 20:27
m: class Foo { class Bar::Baz { } }; say Bar::.keys 20:28
camelia ===SORRY!=== Error while compiling <tmp>
Undeclared name:
Bar used at line 1. Did you mean 'Bag'?
vrurg And it actually doesn't matter if it's a role, or any other packagy-entity. 20:29
Nemokosch should Bar even be visible? 22:23
nevermind
m: class Foo { role Bar { } }; say Bar::.keys 22:25
Raku eval Exit code: 1 ===SORRY!=== Error while compiling /home/glot/main.raku Undeclared name: Bar used at line 1. Did you mean 'Bag'?
Nemokosch m: class Foo { class Bar::Baz { } }; say Foo::Bar::.keys 22:26
Raku eval (Baz)
Nemokosch this is very hard to forgive, though