🦋 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.
nine Why wouldn't they be? You already have a resolver. That can give you those exception classes 07:53
ab5tract nine: Any other low-hanging fruit that for RakuAST that you aren't working on? 11:02
lizmat fwiw, I'm working on RakuAST::Type::Setting to actually do a setting lookup only 11:04
which has some interesting bootstrap issues
ab5tract lizmat++ 11:15
Bootstrap Issues == Implementor Torment Inevitable
Geth rakudo/main: bc481335ba | (Elizabeth Mattijsen)++ | 2 files
RakuAST: make single part setting lookups work

The multi-part one still fails, but that's code in the resolver that will need closer scrutiny
11:42
lizmat afk&
[Coke] any pointers on how to do the lookup? 13:19
I tried copycatting some others (was on a different laptop so I don't have the exact code), but my attempts compiled but failed to find the class. 13:22
nine ab5tract: I don't know about low hanging. But I'd love for someone to take charge on POD. 13:29
Nemokosch Are the nodes also missing? 13:50
lizmat m: my class IO::Path { }; dd MY::<IO>.HOW<Path>.^methods.elems # I sorta expected to see 1 here (for BUILDALL) 16:28
camelia 87
lizmat nine vrurg ^^ is that to be expected?
in other words: we cannot lexically shadow multi part names? 16:29
m: my class IO::Path { }; dd MY::<IO>.HOW<Path> # looks like ^methods falls back to the setting ? 16:33
camelia Failure.new(exception => X::AdHoc.new(payload => "Type Perl6::Metamodel::ClassHOW does not support associative indexing."), backtrace => Backtrace.new)
lizmat argh
argh HOW/WHO mixup again 16:34
[Tux] Rakudo v2022.12-1-gd52342eb0 (v6.d) on MoarVM 2023.02-3-g6adfc376c
csv-ip5xs0.807 - 0.835
csv-ip5xs-205.506 - 5.720
csv-parser4.113 - 4.164
csv-test-xs-200.417 - 0.440
test6.299 - 6.621
test-t1.463 - 1.472
test-t --race0.821 - 0.921
test-t-2020.528 - 21.369
test-t-20 --race7.021 - 7.357
16:43
lizmat m: my class IO::Path { }; dd IO::Path.WHERE; dd IO.WHO<Path>.WHERE; dd SETTING::<IO>.WHO<Path>.WHERE # nine vrurg shouldn't that last one be different ? 17:46
camelia 2924936958752
2924936958752
2924936958752
lizmat m: BEGIN dd IO::Path.WHERE; my class IO::Path { }; dd IO::Path.WHERE; dd IO.WHO<Path>.WHERE; dd SETTING::<IO>.WHO<Path>.WHERE 18:31
camelia 3881366585920
3881419809824
3881419809824
3881419809824
lizmat more extensive: the first one is the one from the setting, the last one is the local one, which it shouldn't be ?
since this is broken with the current grammar as well, I'm not going to be spending more time on that now 18:34
vrurg lizmat: it's not broken. You override IO namespace. 18:46
Geth rakudo/main: 3a9c1540de | (Elizabeth Mattijsen)++ | src/Raku/ast/resolver.rakumod
RakuAST: streamline constant lookup in resolver

Specifically the IMPL-RESOLVE-NAME-CONSTANT method, with reduction of duplicated code, and support for partial lookups added.
The IMPL-PARTIALLY-RESOLVE-NAME-CONSTANT method is removed.
... (18 more lines)
vrurg I mean, it's not a bug with SETTING::, it's a bug with my-scoping of multi-part declarations. 18:47
lizmat well, it's not a bug in RakuAST, so I won't be spending any time on it further for now
afk& 18:48
vrurg Likely so.
tbrowder__ I'm working on a calendar module, and Isee a need for a couple of missing methods on the Dateish role. if I'm not mistaken, there is no routine for giving the total number of full and partial weeks in a month. in the Gregorian calendar. That would be the number of rows shown in a conventional monthly calendar layout. 20:09
I would be happy to file a Rakudo issue and take on the PR if there is any support for the idea. 20:10
in the meantime i will add them to my Date::Utils module 20:12
[Coke] I don't think that needs to be in core, my 2¢ 20:34
nine Multi part names and lexicals don't mix well. As the stash that final symbol will installed into may be a global. 21:08
lizmat: I have thought on and off about this since I first discovered this behavior, but haven't come up with any alternative that would work better. I often arrive at "maybe Perl actually did this right", i.e. that nested stashes are maybe not worth it. But then, apparently in real-life code it doesn't really cause problems either. 21:12
vrurg I thought that perhaps it would be better to install symbols in lexical scope. This would then require duplicating the whole IO namespace into the lexical scope. Never got to the point of considering all possible side effects and problem though. 21:32