🦋 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.
00:00 reportable6 left, reportable6 joined 00:13 MasterDuke left 03:34 linkable6 left, evalable6 left 03:35 evalable6 joined, linkable6 joined 06:00 reportable6 left 06:02 reportable6 joined 07:43 squashable6 left, epony left, bloatable6 left, coverable6 left, statisfiable6 left, tellable6 left, sourceable6 left, shareable6 left, bisectable6 left, nativecallable6 left, benchable6 left, greppable6 left, codesections left, kjp left, jdv left, samcv left, bartolin_ left, jjatria left, bartolin joined, jjatria joined, kjp joined 07:44 jdv joined, codesections joined 07:45 samcv joined 07:58 kjp left 08:03 sourceable6 joined, bisectable6 joined, shareable6 joined, tellable6 joined, benchable6 joined, nativecallable6 joined, statisfiable6 joined, squashable6 joined, coverable6 joined, bloatable6 joined, greppable6 joined 08:12 sena_kun joined 09:02 epony joined 09:19 sena_kun left 09:49 kjp joined
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
10:03 sena_kun joined 10:12 sena_kun left, Altai-man joined
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
12:00 reportable6 left 12:02 reportable6 joined 12:04 ab5tract joined 12:21 ab5tract left
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
14:14 Guest10 joined
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
14:58 Guest10 left
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
15:24 Xliff joined
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
16:56 epony left 17:11 Altai-man left 17:27 epony joined 17:46 sena_kun joined 18:00 reportable6 left 18:01 reportable6 joined
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)
20:27 vrurg_ is now known as vrurg
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
21:55 sena_kun left
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
22:55 linkable6 left, evalable6 left, linkable6 joined 22:57 evalable6 joined 23:29 Xliff left