🦋 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
|