🦋 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: ... | log inspection situation still under development | For MoarVM see #moarvm
Set by lizmat on 22 May 2021.
japhb Xliff: Yeah, raydiak had the idea of what I meant. Sorry I'm in and out -- working on TinyFloats and CBOR::Simple improvements 00:02
Xliff How can I check if a compunit has been loaded? 00:10
ugexe call .loaded on a cur 00:22
Xliff ugexe: How can I get a CUR by name? 00:23
ugexe m: say CompUnit::RepositoryRegistry.^methods 00:25
camelia (repository-for-spec setup-repositories use-repository repository-for-name register-name name-for-repository file-for-spec run-script head resolve-unknown-repos resolve_repossession_conflicts BUILDALL)
Xliff use ICal::GLib::Raw::Definitions; my $a = try ::("ICal::GLib::Raw::Definitions"); say $a.HOW.^name unless $a ~~ Failure 00:26
Tells me 'Perl6::Metamodel::PackageHOW'
Without the use statement, I get (Any) not failure, so 00:28
What's the best way to test for Any? I thought "$a =:= Nil" worked. 00:29
moon-child Any ~~ $a?
m: my $x := Nil; say Any ~~ $x # hmm, maybe not quite 00:31
camelia False
Xliff Huh! Works for my intended use-case...
moon-child oh, Nil ~~ Any, so you can use Nil ~~ $a 00:33
Xliff Odd. Why the reversed operands? 00:35
moon-child well, $x ~~ Any is almost invariably true... 00:36
$x ~~ Nil is true only if $x is actually Nil, but not if it's a type object 00:38
Also my Any ~~ apparently doesn't work correctly either
m: my $x; my Int $y; say Any ~~ $x; say Any ~~ $y #same with Nil ~~
camelia True
False
ugexe Int $y does not accept Any 00:39
i generally try to read $x ~~ $y as "does $y ACCEPT $x" 00:40
Geth rakudo: niner++ created pull request #4393:
Speed up setup of NativeCall subs and reduce memory usage		 06:42
Geth rakudo/rakuast: fff9aad3da | (Jonathan Worthington)++ | 2 files
RakuAST handling of regex adverbs on m//, rx//
 15:45
lizmat notable6: weekly 16:09
notable6 lizmat, 3 notes: gist.github.com/9631289339b5d9742f...f15279f11d
Geth rakudo/rakuast: 69ef021910 | (Jonathan Worthington)++ | 2 files
Compile @$foo style contextualizers to RakuAST

They're the same as @($foo) semantically, so no need for another AST node type.		 16:11
lizmat notable6: weekly reset 16:12
notable6 lizmat, Moved existing notes to “weekly_2021-06-07T16:12:19Z”
Xliff lizmat: I know you are working on the weekly, but do you know if the RakuAST node for "do" blocks has been created? 16:24
lizmat: At your leisure.
lizmat Xliff: looks like there are passing tests for it: github.com/rakudo/rakudo/blob/raku...ixes.t#L29 16:26
so I'd say: yes
Xliff lizmat++ # Thanks!
Geth rakudo/rakuast: bf8e2a967b | (Jonathan Worthington)++ | src/Raku/ast/code.rakumod
Regex thunks should have their own $/

Otherwise we can end up with incorrect modifications of an outer $/ if there are embedded code blocks.		 16:57
lizmat And another Rakudo Weekly News hits the Net: rakudoweekly.blog/2021/06/07/2021-...ing-funky/ 17:17
Geth rakudo/rakuast: 5e80ee42f4 | (Jonathan Worthington)++ | src/Raku/ast/regex.rakumod
Make /<foo>/ assertions look for lexical rules too
 17:34
lizmat afk for a few hours& 17:42
[Coke] to build a raku with rakuast, just checkout the branch and go? Any env vars to set or config options to pass? 18:41
raydiak I just built it the normal way, seems to run all the ast tests just fine 19:14
[Coke] ok 19:35
MasterDuke don't you have to set an env variable at runtime to actually use the new frontend? 19:38
RAKUDO_RAKUAST 19:39
Geth rakudo/rakuast: ae2ba0a5aa | (Jonathan Worthington)++ | src/Raku/ast/regex.rakumod
Don't try and compile args if there aren't any
 21:47
rakudo/rakuast: 203a83f308 | (Jonathan Worthington)++ | src/Raku/ast/regex.rakumod
Don't leak internal mods out of capture groups
rakudo/rakuast: f7244fc1e0 | (Jonathan Worthington)++ | src/Raku/ast/regex.rakumod
Coalesce sequences of regex literals

When we have `/st/`, the compiler frontend currently produces two RakuAST::Regex::Literal nodes. These were individually compiled also, which breaks matching against the ligature st (with the appropriate options set). Coalesce these as part of the compilation from RakuAST to QAST, meaning that the same job doesn't have to be done by all those synthetically constructing RakuAST in order to get correct matching.
raydiak quite possibly. I only ran the tests in 12-rakuast, which build RakuAST nodes explicitly. it could still be using the old frontend and run those tests 22:55
looks like yes, to enable the new frontend you need RAKUDO_RAKUAST as stated in github.com/rakudo/rakudo/blob/raku.../README.md and at github.com/rakudo/rakudo/blob/raku...in.nqp#L18 22:58
when running. I don't see any sign that it matters for building 23:00

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!