🦋 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:04 kjp left 00:07 kjp joined 01:09 japhb left 01:33 japhb joined 05:10 japhb left 06:00 reportable6 left, reportable6 joined 07:53 bloatable6 left, nativecallable6 left, sourceable6 left, committable6 left, shareable6 left, statisfiable6 left, benchable6 left, bisectable6 left, notable6 left, greppable6 left, reportable6 left, evalable6 left, quotable6 left, coverable6 left, squashable6 left, unicodable6 left, tellable6 left, releasable6 left, linkable6 left, benchable6 joined, committable6 joined, shareable6 joined, sena_kun joined, reportable6 joined 07:54 sourceable6 joined, notable6 joined, bloatable6 joined, tellable6 joined, linkable6 joined, greppable6 joined, releasable6 joined 07:55 nativecallable6 joined, coverable6 joined, evalable6 joined, statisfiable6 joined, unicodable6 joined, quotable6 joined, squashable6 joined 07:56 bisectable6 joined 09:01 squashable6 left, squashable6 joined
Geth rakudo/main: 6e8abbf9be | (Elizabeth Mattijsen)++ | src/Raku/ast/variable-declaration.rakumod
RakuAST: removed dead code
10:29 sena_kun left 11:06 ab5tract joined
lizmat Sanity check: we don't have anything such as "is raw" or \ for sub parameters in NQP, do we ? 11:08
I'm trying to find a way to fix the "no strict; $a = 42" case, and was thinking of creating a subclass of Var::Lexical (Var::Lexical::Auto) 11:20
and make that the object hanging off the match in the grammar\ 11:21
and then handle the resolving and QASTing inside that subclass
which would mean limited overhead for the normal case
Geth rakudo/main: e5e5acb418 | (Elizabeth Mattijsen)++ | 3 files
RakuAST: one step closer to supporting "no strict"

  - create a subclass of Var::Lexical called Var::Lexical::Auto
  - have the Action.compile_variable_access check for "no strict" and
   create a Var::Lexical::Auto instead of Var::Lexical
  - have the Grammar.check_variable method only check exact Var::Lexical
   objects, and panic if not defined
... (10 more lines)
lizmat nine: ^^ see rest of commit message :-) 11:55
afk for a while& 11:56
11:56 lizmat left 12:00 reportable6 left, reportable6 joined 12:16 hankache joined 12:47 hankache left 13:08 sena_kun joined 13:17 sena_kun left 13:18 sena_kun joined 13:34 japhb joined 14:03 RakuIRCLogger left
nine lizmat: in NQP all parameters are raw 15:15
tellable6 nine, I'll pass your message to lizmat
15:49 lizmat joined
lizmat . 15:52
tellable6 2023-03-24T15:15:12Z #raku-dev <nine> lizmat: in NQP all parameters are raw
16:06 lizmat left 16:22 japhb left 18:00 reportable6 left 18:02 reportable6 joined
[Coke] in src/Perl6/Compiler.nqp, there are many cases of, e.g. nqp::gethllsym('Raku', 'Version'); 18:04
my $ex := nqp::gethllsym('Raku', 'X::Language::Unsupported'); runs but doesn't find the exception. 18:05
This with RAKUDO_RAKUST=1 and calling in to Perl6/Compiler from the AST path. 18:14
AST Actions.
vrurg [Coke]: Because this is not how hllsym works. You have to bind the symbol first. 18:43
19:11 japhb joined 20:03 japhb left 20:07 japhb joined
nine This mechanism is used for just a few symbols. From RakuAST you need to use the resolver to find arbitrary symbols in the setting. 20:39
20:40 sena_kun left 20:43 sena_kun joined 20:45 sena_kun left 22:24 lizmat joined
lizmat . 22:24
22:41 ab5tract left
[Coke] I'm trying to move this into Perl6/Compiler, which could be called from RakuAST or not 23:28
if it's rakuast specific, I'll have to throw the adhoc exception, catch it, and throw the "real" exception from the AST actions. (which is, I think, what the non-AST is doing; it's throwing an adhoc internally and then world is fixing it up) 23:29
... unless the resolver isn't AST specific? 23:30
I'll try doing the catch/rethrow on the AST side. 23:34