🦋 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 00:02 reportable6 joined 01:43 linkable6 left, greppable6 left, sourceable6 left, committable6 left, bloatable6 left, tellable6 left, squashable6 left, shareable6 left, bisectable6 left, benchable6 left, evalable6 left, unicodable6 left, quotable6 left, coverable6 left, statisfiable6 left, notable6 left, reportable6 left, nativecallable6 left, releasable6 left, greppable6 joined, tellable6 joined, linkable6 joined, evalable6 joined 01:44 coverable6 joined, squashable6 joined, statisfiable6 joined, quotable6 joined, sourceable6 joined, releasable6 joined, reportable6 joined 01:45 nativecallable6 joined, committable6 joined, shareable6 joined, bloatable6 joined, benchable6 joined, notable6 joined 01:46 unicodable6 joined, bisectable6 joined 02:56 finanalyst joined 03:56 bloatable6 left, tellable6 left, evalable6 left, sourceable6 left, reportable6 left, coverable6 left, quotable6 left, nativecallable6 left, committable6 left, benchable6 left, releasable6 left, linkable6 left, notable6 left, greppable6 left, bisectable6 left, unicodable6 left, squashable6 left, statisfiable6 left, shareable6 left 03:57 bloatable6 joined, coverable6 joined, reportable6 joined, evalable6 joined, benchable6 joined 03:58 committable6 joined, linkable6 joined, bisectable6 joined, notable6 joined, shareable6 joined, unicodable6 joined 03:59 quotable6 joined, tellable6 joined, nativecallable6 joined, sourceable6 joined, greppable6 joined, statisfiable6 joined, squashable6 joined, releasable6 joined 04:30 finanalyst left 05:45 melezhik joined 05:50 melezhik left 06:00 reportable6 left 06:02 reportable6 joined 06:48 melezhik joined 06:58 melezhik left
nine I have been working on and off on replacing the fallback lookups in BEGIN time run code with what we discussed at the summit. 07:12
I started by just replacing lexical lookups with constant lookups if we're compiling dynamically. So far that gets me almost on par with main even without the new dispatcher and support for late bound subs in calls. 07:13
However, now I hit the first road block: my constant foo = (1, 2).map({ $_ }). This fails because $_ is not a constant. I.e. we can't just treat all variables as constants in BEGIN time code. Instead we must do this only for those found outside the dynamically compiled code. 07:14
07:14 melezhik joined 07:19 melezhik left
nine This probably means that neither resolve-lexical, nor resolve-lexical-constant is what I need. 07:25
Also that $*IMPL-COMPILE-DYNAMICALLY := 1 is not enough either. I need to konw which is the outermost scope that's compiled dynamically. 07:26
I could of course just use that scope as value for the dynamic variable. But to be honest I don't like polluting all those AST nodes with dynamic variables. Their absence has been quite nice so far. 07:27
Maybe a better option would be a special BeginTimeResolver that overrides resolve-lexical with an appropriate version. 07:29
But even that would not solve the problem with early resolution - often we need to resolve symbols already during parsing. These will then have been resolved to variable lookups which then fail at runtime (because the scope they are declared in doesn't even exist yet). 07:34
So far I've just littered the Grammar and Actions with $*IMPL-COMPILE-DYNAMICALLY but that is obviously not the real solution.
The other part that requires mass changes is that in every place where we emit a call op, instead of providing the name of the symbol to call, we need to provide the resolution result, i.e. a WVal containing the code object. There are quite a few of those places, scattered all around and they need ot know whether to do the one or the other. 07:39
Unless the resolution result itself has that knowlege and can e.g. create that call op. 07:40
Thanks for rubber ducking! 07:46
ab5tract Anytime, nine! It's a pleasure to have your words back in the chat
so for the call op thing,what's the motivation behind changing the call op? how can they tell whether to do one or the other? 07:52
I ask because I just added code which has a fair number of calls in it 07:53
nine Ordinarily we emit nqp::call(:name<&foo>) for leaving the lookup until runtime. Since BEGIN time code runs without any outer scope (not even a setting) we need to emit nqp::call(&foo) instead. I think I'll give RakuAST::Var an IMPL-QAST-CALL method that returns the appropriate NQP::Op. 08:22
Normally resolved symbols will emit QAST::Op.new(:name(self.lexical-name)) while those resolved through the BeginTimeResolver will return QAST::Op.new(self.resolution.compile-time-value)
At least for symbols resolved to compile time constants outside the dynamically compiled code. 08:23
ab5tract ah, I see what you mean now, thanks 08:38
Geth rakudo: ab5tract++ created pull request #5384:
RakuAST: Re-formulate VarDeclaration::Implicit::State		 09:06
lizmat ab5tract: is there a reason why you used "min-excl" and "max-excl" in FlipFlop instead of excludes-min and excludes-max ? 09:07
to be consistent with the naming of Ranges ?
ab5tract It was the way the existing QAST was written, so it was the easiest translation
But now would be a good time to clean it up 09:08
lizmat ok, will clean that up and fix the .raku and DEPARSE support and tests :-)
ab5tract thanks for taking care of that liz 09:11
latest PR is "just" a cleanup, but it makes things a lot cleaner imo 09:18
lizmat cool 09:20
clarity is what we need! :-)
ab5tract: would it make sense to have the excludes-min / max functionality just depend on the actual operator passed ? 09:39
yeah, I think it does :-) 09:42
ab5tract It could be done that way, yeah. In fact, from a user perspective that's probably much better 09:43
sorry not to have taken that route
lizmat no worries... it also simplies .raku and .DEPARSE a lot :-) 09:44
as in it being handled by Infix :-)
ab5tract nine: do you have any idea how this could be fixed? 09:52
m: my $i; say $i += (state $s = $_) for ^2 09:53
camelia Use of uninitialized value of type Any in numeric context
0
0
in block at <tmp> line 1
Use of uninitialized value of type Any in numeric context
in block at <tmp> line 1
ab5tract m: Q|my $i; say $i += once { 21 } for ^2 | .AST.EVAL 09:54
camelia Cannot resolve caller prefix:<+>(Mu:U); none of these signatures matches:
(\a)
in block <unit> at <tmp> line 1
ab5tract basically the p6stateinit doesn't seem to get propagated when the state is defined in the compunit 09:56
*on the compunit
m: Q|my $i; say $i += once { $_ } for ^2 | .AST.EVAL 09:57
camelia Cannot resolve caller prefix:<+>(Mu:U); none of these signatures matches:
(\a)
in block <unit> at <tmp> line 1
ab5tract ah, that matches the "Use of uninitialized value of type Any" output from the state example in my cleaned up branch 09:58
anyway, the state variable is being accessed without being bound because p6stateinit op never appears to return true for these instances 10:00
I don't know where to really start with that one 10:04
m: my $i; say $i += once { $_ } for ^2; # IIUC this works because of statement_id and in_stmt_mod annotations on QAST nodes 10:06
camelia 0
0
ab5tract m: my $i; say $i += once { $_ } for 1,2; # IIUC this works because of statement_id and in_stmt_mod annotations on QAST nodes
camelia 1
2
Geth rakudo/main: 866e431035 | (Elizabeth Mattijsen)++ | 4 files
RakuAST: simplify creation of ::FlipFlop objects

The name of the given operator is be enough information		 10:21
rakudo/main: ded9b37c89 | ab5tract++ (committed using GitHub Web editor) | 2 files
RakuAST: Re-formulate VarDeclaration::Implicit::State

The class needed some re-work to function properly for other use cases like in RakuAST::StatementPrefix::Once.		 10:27
rakudo/main: 6f73a9c231 | (Elizabeth Mattijsen)++ | t/12-rakuast/operators.rakutest
RakuAST: add tests for RakuAST::FlipFlop
 11:12
rakudo/main: 0079b03ba2 | (Elizabeth Mattijsen)++ | src/core.c/RakuAST/Deparse.rakumod
RakuAST: fix deparsing of ::Feed objects in ApplyListInfix
 11:27
12:00 reportable6 left 12:01 reportable6 joined
Geth rakudo/main: 6d3904d017 | (Elizabeth Mattijsen)++ | t/12-rakuast/operators.rakutest
RakuAST: add tests for RakuAST::Feed
 12:11
13:14 squashable6 left 13:15 squashable6 joined 14:15 coverable6 left, greppable6 left, committable6 left, statisfiable6 left, quotable6 left, nativecallable6 left, tellable6 left, benchable6 left, notable6 left, bisectable6 left, shareable6 left, sourceable6 left, evalable6 left, bloatable6 left, squashable6 left, unicodable6 left, linkable6 left, reportable6 left, releasable6 left 14:16 sourceable6 joined, committable6 joined, evalable6 joined, squashable6 joined, releasable6 joined, reportable6 joined 14:17 tellable6 joined, quotable6 joined, benchable6 joined, bisectable6 joined, linkable6 joined, shareable6 joined 14:18 greppable6 joined, unicodable6 joined, notable6 joined, nativecallable6 joined, statisfiable6 joined, bloatable6 joined, coverable6 joined 16:28 ab5tract left 16:42 jgaz left
Geth rakudo/main: 60ec27c6f8 | (Elizabeth Mattijsen)++ | src/Raku/Actions.nqp
RakuAST: streamline package-def action method
 16:52
rakudo/main: 40a94e23e5 | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: package declarators don't need to capture <sym>
 17:02
17:18 squashable6 left 17:20 squashable6 joined 17:44 coleman left 17:45 coleman joined
Geth rakudo/main: 97683f98a1 | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: prevent some more unnecessary captures

And somei grammar streamlining		 17:51
18:00 reportable6 left 18:02 reportable6 joined
nine ab5tract: sorry, I don't know anything about all about how state variables are implemented 18:12
tellable6 nine, I'll pass your message to ab5tract
nine p6stateinit seems to check a flag on the frame. That flag should get set if the frame contains declarations of state variables 18:20
Geth rakudo/main: ef0aa2b6a6 | (Elizabeth Mattijsen)++ | 2 files
Allow translation of "constraint-where"
 18:32
lizmat meh, that actually is a RakuAST commit
nine It's quite possible that at time of resolving we don't know yet whether a symbol needs to be resolved to a variable or to a constant (cf early resolution) 19:53
Actually that shouldn't matter all that much since we resolve names we found in the setting to constants anyway and declarations usually have compile time values (their meta object) 20:02
21:54 coverable6 left, squashable6 left, greppable6 left, statisfiable6 left, unicodable6 left, tellable6 left, releasable6 left, bloatable6 left, committable6 left, benchable6 left, linkable6 left, evalable6 left, shareable6 left, quotable6 left, nativecallable6 left, sourceable6 left, notable6 left, bisectable6 left, reportable6 left 21:55 evalable6 joined, greppable6 joined, tellable6 joined, shareable6 joined 21:56 squashable6 joined, bloatable6 joined, reportable6 joined, sourceable6 joined, statisfiable6 joined, unicodable6 joined 21:57 notable6 joined, releasable6 joined, benchable6 joined, coverable6 joined, quotable6 joined, linkable6 joined, bisectable6 joined, committable6 joined 21:58 nativecallable6 joined 22:58 unicodable6 left, evalable6 left, reportable6 left, coverable6 left, benchable6 left, bloatable6 left, statisfiable6 left, releasable6 left, nativecallable6 left, squashable6 left, committable6 left, notable6 left, linkable6 left, tellable6 left, sourceable6 left, bisectable6 left, quotable6 left, greppable6 left, unicodable6 joined, evalable6 joined, linkable6 joined, reportable6 joined 22:59 greppable6 joined, committable6 joined, nativecallable6 joined 23:00 coverable6 joined, notable6 joined, releasable6 joined, sourceable6 joined, quotable6 joined, bisectable6 joined, statisfiable6 joined, squashable6 joined 23:01 benchable6 joined, bloatable6 joined, tellable6 joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!