🦋 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 nine: it looks like the meta-object of a Subset with a "where" is the "where" block, rather than the subset itself 09:22
without a "where" block, it *is* correct
this affects declarator blocks being attached to the wrong thing at least
ideas / suggestions / comment ?
nine Looking at RakuAST::Type::Subset I can't see how that would be the case 09:24
lizmat well, me neither, yet it is the case 09:27
hmmm... it only happens when there is an actual block, not for a Whatever code 09:29
I think I know where to look now , thanks for rubberducking
nine :)
lizmat the problem is that generic blocks can also have declarator doc 10:03
and the block of a subset is seen *before* the subset as a doc declarator target
so I guess if the subset has a where, then it would need to steal the declarand from the block 10:05
Geth rakudo/main: 6b6f28ed9c | (Elizabeth Mattijsen)++ | 2 files
RakuAST: make sure Subset.WHY is correct with a where block

Because bare blocks can also have declarator docs attached, and a "where" block of a subset is seen *before* the subset, the declarator doc was attached to the block of the subset, rather than to the subset itself.
This introduces a "cut-WHY" method on declarator targets, and a steal-declarand method in Actions, and the use of these when appropriate in the subset handling.		 10:41
rakudo/main: ee5e4c3b69 | (Elizabeth Mattijsen)++ | src/core.c/RakuAST/LegacyPodify.pm6
RakuAST: no trailing whitespace in leading/trailing declarator doc
 10:56
lizmat nine: this would have given us another test file if "macro" had been supported in RakuAST 10:57
do you have any thoughts on that ?
[Tux] Rakudo v2023.04-84-g6b6f28ed9 (v6.d) on MoarVM 2023.04-1-g965be0af5
csv-ip5xs0.839 - 0.886
csv-ip5xs-205.305 - 6.384
csv-parser4.045 - 4.135
csv-test-xs-200.379 - 0.382
test6.378 - 6.435
test-t1.425 - 1.489
test-t --race0.954 - 1.055
test-t-2021.837 - 22.217
test-t-20 --race6.441 - 6.571
 11:01
Xliff nine: When I try to EXEC a bunch of need statements, symbols in those modules are not excecuted. When I replace the AST with the actual Raku... it works. If you need further explanations, I'll write a gist. 11:20
nine A gist may be helpful 11:21
lizmat nine: looks like 11:32
my ($,) = 1;
is a problem in RakuAST
Xliff nine: Sure thing. 11:37
m: class X::E is Exception { method new ($m) { self.bless( message => $m ); }; }; sub a { CATCH { when X::E { .message.say }; }; X::E.new("Bloop!").throw }; a
camelia Stub code executed
in block at <tmp> line 1
in any at <tmp> line 1
in sub a at <tmp> line 1
in block <unit> at <tmp> line 1
Xliff Is this right or a bug? 11:38
lizmat feels like a bug at first sight 11:45
ah... maybe having a CATCH block in a sub itself, doesn't remove the "stubness" of a sub when it is declared
m: class X::E is Exception { method new ($m) { self.bless( message => $m ); }; }; sub a { CATCH { when X::E { .message.say }; 42 }; X::E.new("Bloop!").throw }; a 11:46
camelia Stub code executed
in block at <tmp> line 1
in any at <tmp> line 1
in sub a at <tmp> line 1
in block <unit> at <tmp> line 1
lizmat hmmm
so much for that theory
nine Xliff: your exception class needs to declare a "message" method. Exception itself only has a stub 11:48
message is _not_ an attribute 11:49
lizmat aaah... duh
nine++
m: class X::E is Exception { has $.message; method new ($m) { self.bless( message => $m ); }; }; sub a { CATCH { when X::E { .message.say } }; X::E.new("Bloop!").throw }; a 11:50
camelia Bloop!
lizmat or just make it an attribute in your class
Xliff -Oh... duh! Thanks!! 11:51
nine++
It must be Monday...
gfldex Is the absent requirement of use MONKEY; for .EVAL intentional? 12:54
lizmat jein 12:55
thing is, that methods are late bound: the only way to make that fail at compile time, is to inhibit *any* method called EVAL, by name
gfldex If use MONKEY; would set $*MONKEYING = true, .EVAL (and other things) could check and complain.
lizmat but "use MONKEY" is compile time 12:56
.EVAL is runtime
EVAL("foo") can be checked at compile time whether the &EVAL in question is the system's sub EVAL, and then complain 12:57
if it is
nine: it looks like
my ($a) = 42 12:58
is NYI in RakuAST, thoughts?
gfldex So .EVAL would need to become a macro. 12:59
lizmat but even then, methods are late bound
so the macro (at compile time) can only be sure if the invocant can be determined at compile time 13:00
and that can only be true if the invocant is a constant string
in which case there's no injection danger
Nemokosch maybe the EVAL method itself should have only been injected 13:01
lizmat ?
Nemokosch it shouldn't exist by default 13:02
gfldex m: say "$@*ARGS[1]".EVAL; 13:03
camelia Use of uninitialized value @ARGS[1] of type Any in string context.
Methods .^name, .raku, .gist, or .say can be used to stringify it to something meaningful.
Nil
in block <unit> at <tmp> line 1
lizmat Nemokosch how would you activate it then ? 13:04
nine: fwiw, the AST for 'my ($a) = 42' seems correct, so looks like QAST generation issue ? 13:09
Nemokosch the pragma would mix the method in 13:11
nine lizmat: signature declarations like that seem to have a lot of issues still. E.g. my ($a, $b) is default(1); doesn't work either. That's my current WIP
Nemokosch similarly to traits I guess
lizmat Nemokosch the pragma is *compile* time
Nemokosch yes, just like traits? 13:12
lizmat Nemokosch note that "use MONKEY" is *lexical*
we cannot mix in a method lexically
Nemokosch well to ask the most practical question 13:14
is it really a problem that something that is currently always available, may become accidentally available, if somebody walks down on the explicitly risky path? 13:15
sounds like a net win tbh
lizmat I'm not saying it wouldn't be a good thing
I'm saying that at the current state, we cannot implement it
and even if we had lexical refinement (aka adding methods in a lexical scope) 13:16
Nemokosch no I mean, if it cannot be done lexically, then do it globally
that's still a win compared to no limit whatsoever, that's like the whole purpose, no?
nine So you're saying if there's a "use MONKEY" anywhere in any comp unit in the process, all objects gain an .EVAL method? Did I understand that correctly? 13:18
Nemokosch yes
lizmat that's equivalent to a run-time check in Cool.EVAL 13:19
Nemokosch except it can be done compile-time, I guess?
nine Actually it can't, because it'd have to influence modules that are already precompiled
Nemokosch that's not the biggest problem with precompilation, to be frank. use lib doesn't even work with it... 13:23
anyway, understood, it cannot be done
gfldex After carefully reading the definition of proto EVAL, I have come to the conclusion that one can always cheat with nqp and get hold of a compiler directly, use MONEKY or not. 13:40
lizmat indeed 13:41
there's no real magic there
gfldex We better doc that. 13:42
Geth rakudo/main: 50fc47cf6e | (Elizabeth Mattijsen)++ | 2 files
RakuAST: add deparsing / .raku support for RakuAST::VarDeclaration::Signature

Sadly RakuAST::VarDeclaration::Signature isn't QASTed yet correctly, so there is no point in writing tests yet.		 13:55
Nemokosch the difference is rather that nqp is a "you shouldn't" thing, even much more so than the MONKEY pragma 13:59
Geth roast: 48b5fc4039 | (Elizabeth Mattijsen)++ | S26-documentation/multiline-leading.t
Change the way parameters are obtained

This currently doesn't work in RakuAST, and is not really a thing being tested here. So change this, to get a passing test on RakuAST		 14:01
lizmat 822!
ok, that's all of the S26 tests that can be fixed now 14:02
the remaining failing test files fail because:
1. no support for "macro" in RakuAST (at all) 14:03
2. different semantics on how trailing declarator doc is attached
on the latter I will create a problem solving issue
Xliff nine: Sorry. Got waylaid by $dayJob. Here's the gist: gist.github.com/Xliff/e0101d427fb6...1b402cb2b2 14:46
lizmat++!
Geth rakudo/main: eaf4aea208 | (Elizabeth Mattijsen)++ | src/core.c/RakuAST/Fixups.pm6
RakuAST: move implicit code block detection in its own method

For better maintainability		 15:30
rakudo/main: ff29c918e1 | (Elizabeth Mattijsen)++ | 2 files
RakuAST: adapt deparsing of ::Doc blocks

Start with a new line, don't add one at the end. This feels more natural for reading. Adapt tests accordingly.
nine Xliff: RakuAST::Name.from-identifier(RakuAST::Name.from-identifier("GLib::Raw::Definitions")) makes no sense? 18:06
Xliff: also that EVAL would have to be run at BEGIN time because import is a BEGIN time construct. With the command you ran, the import would be done before we even tried to load a module. 18:07
lizmat argh 18:19
lizmat just finds out that implicit code blocks and explicit code blocks are rendered differently in $=pod, although they're both Pod::Block::Code objects 18:20
.oO( WTFF )
 18:21
Geth rakudo/main: 10742c9910 | (Elizabeth Mattijsen)++ | 2 files
RakuAST: hopefully last fix on code block generation

Running raku --doc on the 70K of rakudoc of App::Rak now creates the same output byte for byte, but 6.5x as fast.
Strange findings: implicit code blocks and explicit code blocks are generated differently Pod::Block::Code objects. Fixed by generating RakuAST blocks of type "implicit-code", and providing specific podification for that type.		 19:17
lizmat 139/150 in make test!
and that concludes my hacking for today 19:22
&

Powered by Cro and the Raku® Programming Language.

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

Thank you!