🦋 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:15 rypervenche left 00:19 rypervenche joined 02:51 MasterDuke left 06:00 reportable6 left, reportable6 joined 07:59 sena_kun joined
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
09:26 sena_kun left
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
11:18 Xliff joined
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...
12:00 reportable6 left 12:02 reportable6 joined
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
13:22 jgaz joined
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++!
15:04 kurahaupo left 15:06 kurahaupo joined
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.
18:00 reportable6 left 18:03 reportable6 joined
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
18:27 sena_kun joined
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
&
19:53 sena_kun left 21:46 sena_kun joined 22:26 sena_kun left

Powered by Cro and the Raku® Programming Language.

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

Thank you!