🦋 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:01 Nemokosch left 02:22 epony left 02:23 epony joined 03:01 codesections left 05:02 MasterDuke left 06:00 reportable6 left 06:02 reportable6 joined
nine lizmat: sounds more like a DEPARSE issue, since we do create a Type::Definedness at it generates correct, working code from that. 08:06
I'm pretty sure we'll have to re-do the Definedness, Concrete and Parameterized types at some point, but for another reason: they currently don't stack. Instead of a name of a base type, they should be built onto a RakuAST::Type 08:07
Geth rakudo/main: 1072872e17 | (Stefan Seifert)++ | src/Raku/Actions.nqp
RakuAST: un-break the REPL

The current REPL implementation loads the REPL class by running a comp unit that's just "REPL", i.e. evaluates the class name. It does so by stariting the compiler with :outer_ctx(nqp::null()). The old frontend took this as a signal, that the comp unit's result is wanted. The RakuAST frontend expected a concrete outer_ctx instead.
Fix by adopting the same criteria as the old frontend.		 09:08
09:09 Xliff joined
Xliff P6-GLib suite timing statistics for Raku 2022.12.1092.g.85240.f.0.c.2 09:10
Total number of projects: 33 (502775 loc)
Total non-parallel compile times: 8774.120 (265.882 avg)
Total parallel compile times: 2122.001 (64.303 avg) 4.135x speedup
Noting over 600s increase in parallel compile times since the run from 1/15/2023 for the second week in a row.
Has anything changed in the file locking during parallel comp? 09:11
Nemokosch lizmat: do you by any chance remember what this commit github.com/rakudo/rakudo/commit/6c...fb63e27174 broke? 09:54
Geth rakudo/main: bab7f837b6 | (Stefan Seifert)++ | src/Raku/ast/code.rakumod
RakuAST: give slurpy placeholder params a fixed order in the signature

The old frontend added slurpy placeholder parameters to the signature in the order of appearance in the block. At least one spectest relied on this. In general we need compilation results to be reproducible. However, we go through placeholders in hash order. That's not a problem because positionals will be sorted lexicographically anyway. It was a problem for slurpies, so just always add @_ before %_.		 10:06
rakudo/main: 445a224110 | (Stefan Seifert)++ | src/Raku/ast/code.rakumod
RakuAST: give named placeholder params a fixed order in the signature

The old frontend added named placeholder parameters to the signature in the order of appearance in the block. In general we need compilation results to be reproducible. However, we go through placeholders in hash order. That's not a problem because positionals will be sorted lexicographically anyway. It was a problem for nameds, so just give them the same treatment as positionals.
nine lizmat: these ^^^ take care of t/spec/S06-signature/unspecified.t flapping
10:10 sena_kun joined
Nemokosch github.com/rakudo/rakudo/issues/5119 do you agree with the expected behavior here? 10:15
if so, it could get a test - a test that would already pass with the new frontend 10:16
11:24 ab5tract joined
Geth rakudo/main: 4a53b6b950 | (Stefan Seifert)++ | 2 files
RakuAST: implement simple trimming of heredocs
 11:33
nine Now at 111 test and 649 spectest files :)
lizmat throws away some stashed code :-) 11:34
nine Well I'm not sure if this is the whole thing (hence the "simple trimming") 11:35
12:00 reportable6 left 12:01 reportable6 joined
Geth rakudo/main: 3a73a67efe | (Elizabeth Mattijsen)++ | src/core.c/RakuAST/Deparse.pm6
Prevent double deparsing of :D and :U for now
 12:20
rakudo/main: 775bdb2832 | (Elizabeth Mattijsen)++ | src/Raku/ast/pair.rakumod
Fix canonicalize of RakuAST::ColonPair::True/False

  :D<True> and :U<True> don't really make sense in signatures
lizmat m: my $A:D = 42; say $A:D # I wonder whether colonpairs :D :U :_ should be reserved 12:32
camelia 42
lizmat m: my $A:U = 42; say $A:U
camelia 42
lizmat m: my $A:_ = 42; say $A:_
camelia 42
lizmat and thus become part of RakuAST::Name 12:33
with :D / :U / :_ as an additional flag on RakuAST::Name
nine why? 12:34
lizmat and disallow multiple occurences:
m: my $A:D:U:_ = 42; say $A:D:U:_
camelia 42
lizmat because it is confusing 12:35
m: my \A:D:U:_ = 42; say A:D:U:_ 12:36
camelia ===SORRY!=== Error while compiling <tmp>
Variable '&A:D:U:_' is not declared. Perhaps you forgot a 'sub' if
this was intended to be part of a signature?
at <tmp>:1
------> my \A:D:U:_ = 42; say ⏏A:D:U:_
lizmat you *can* define it sigilless, but not use it
anyways, 111 / 649 confirmed here :-) 12:40
nine I'm looking into the failing heredoc tests and it's....odd. They fail because we lose the postprocessors, e.g. q:w:to becomes q:to. This apparently happens because RakuAST::Actions::nibbler first creates a RakuAST::Heredoc with heredoc postprocessor and then a RakuAST::QuotedString with the words postprocessor, but this QuotedString doesn't appear in the final AST. 12:41
lizmat yeah, I lost track of that somewhere as well... 12:42
nine: re BUILDPLAN, I think the BUILDPLAN is currently not set up correctly 12:44
compare:
m: class A { has $.a = 42 }; dd A.new; use BUILDPLAN A 12:45
camelia class A BUILDPLAN:
0: nqp::getattr(obj,A,'$!a') = :$a if possible
1: nqp::getattr(obj,A,'$!a') = 42 if not set
A.new(a => 42)
lizmat with:
m: use MONKEY; EVAL Q| class A { has $.a = 42 }; dd A.new; use BUILDPLAN A |.AST
camelia class A BUILDPLAN:
0: nqp::getattr(obj,A,'$!a') = :$a if possible
1: vivify nqp::getattr(obj,A,'$!a') if part of a mixin
A.new(a => Any)
Nemokosch Hm, could you please take a look at the issue I sent? Probably a simple "the expectation is right/wrong" would do 12:52
:(**@rest, *%rest) there is postfix | in that? 12:56
oh wait its a quote 12:57
Q|hello|
13:17 ab5tract left
Geth rakudo/main: fc9cbd3eb1 | (Stefan Seifert)++ | 2 files
RakuAST: fix missing post processors on heredocs

We silently dropped the post processor from eg. q:w:to and treated it like q:to. Fix by stealing not only the segments, but also the processors from the temporary QuotedString object that gets generated.		 13:45
rakudo/main: 0ccec24cd6 | (Stefan Seifert)++ | src/Raku/ast/literals.rakumod
RakuAST: dump post processors on quoted strings as extras

Post processors have significant impact on the generated code and this code's result, so include information about them in the AST dump output.
nine t/12-rakuast/heredocs.rakutest is also passing now :) 13:46
lizmat cool! 13:51
13:54 raschip joined
nine The regex related failures are weird. They are not because the regex wouldn't match. They are because we get True instead of a Match object. But that seems to only happen in those tests. An `is "foo" ~~ /./, "f"` in RakuAST succeeds 13:55
I seem to remember that smart match usually returns Bools, except for that regex case. Right? How does it even decide that? 13:57
lizmat the associated .ACCEPTS decides 14:00
nine WTF 14:09
is $target ~~ $_, $target, "@type[$++]: pass case" for EVAL($ast), EVAL($deparsed); fails because we get True instead of Match object
for EVAL($ast), EVAL($deparsed) { is $target ~~ $_, $target, "@type[$++]: pass case" } fails for the same reason 14:10
for EVAL($ast), EVAL($deparsed) -> $m { is $target ~~ $m, $target, "@type[$++]: pass case" } passes!
lizmat hmmm difference in containerization ? 14:11
or difference between PointyBlock and Block with implicit topic ?
nine No, I think it's smartmatch itself 14:13
> RAKUDO_RAKUAST=1 ./rakudo-m -e 'dd "f" ~~ $_ with /./' 14:16
Bool::True
lizmat afk& 14:18
Geth rakudo/main: 8f9a54e92f | (Stefan Seifert)++ | src/Raku/ast/expressions.rakumod
RakuAST: fix smartmatch on $_ containing a regex boolifying result

Looking at the old compiler frontend, it seems like we don't need the special smartmatch handling if the right hand side is a plain variable. While it worked in most cases anyway, things got confusing when that variable was $_. Then temporarization of that variable disturbed the check whether the right hand side was a Regex (which doesn't want its result to be boolified). Avoid the whole thing by just compiling to a call to infix:sym<~~> for variables. Just like the old frontend.		 14:44
nine And this takes care of t/12-rakuast/regex-charclass.rakutest
Geth rakudo/main: ea60d168b9 | (Stefan Seifert)++ | src/Raku/ast/signature.rakumod
RakuAST: fix multi-dispatch on natively typed parameters

Need to set the appropriate flags when a parameter is natively typed.		 15:16
nine Aaaand 650 spectests!
Also fixes most of the failures in t/12-rakuast/var.rakutest 15:17
15:18 linkable6 left, evalable6 left 15:19 linkable6 joined 15:20 evalable6 joined
nine Oh wait....var.rakutest actually passes! 15:24
Ah, because that one failing test is TODOed
18:00 reportable6 left 18:03 reportable6 joined
releasable6 Next release in ≈4 days and ≈23 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 19:00
19:31 epony left
Geth rakudo/main: ade6861e2c | (Stefan Seifert)++ | 2 files
RakuAST: make custom operators available to EVALed code
 19:54
rakudo/main: a49f5a9777 | (Stefan Seifert)++ | src/Raku/ast/variable-declaration.rakumod
RakuAST: fix initialization of shaped variables

We need to create an object of the container type, i.e. Array, instead of the default base type, i.e. Mu.		 20:11
nine With this t/12-rakuast/operators.rakutest passes, too :)
Now at 115 / 650
Both remaining failing rakuast test files seem to stumble over some $/ issue 20:13
Apart from that the major areas are language version support, producing the right error type/messages and POD
20:58 epony joined
lizmat 115 / 650 confirmed! 21:09
afk again&
Geth rakudo/main: 52b9092167 | (Stefan Seifert)++ | 2 files
RakuAST: fix $/ not containing a List after s:g///

Apparently $/ can get overwritten by the APPLY-MATCHES call of a successful s:g///, so we need to set it twice.		 21:20
nine Correction: 116 test files ;)
Geth rakudo/main: c3c1f9c5e6 | (Stefan Seifert)++ | 2 files
RakuAST: give start blocks/statements fresh $/ and $! variables

Code run in start blocks or with start prefix will run on a different thread. Sharing $/ and $! variables with the originator thread is a recipe for desaster, so don't do it.		 22:03
nine And this fixes the last of the rakuast test failures. Now up to 117 test files. And this concludes my hacking for this weekend :)
22:36 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!