lizmat bisectable6: old=2024.08 say 1234.polymod(1) 08:46
bisectable6 lizmat, Bisecting by output (old=2024.08 new=3610e7a) because on both starting points the exit code is 0
lizmat, bisect log: gist.github.com/4907112002255f671b...cbd08549da
lizmat, (2024-10-25) github.com/rakudo/rakudo/commit/c8...636a8364b0
Geth ¦ rakudo: lizmat self-assigned .assuming is painfully slow github.com/rakudo/rakudo/issues/2599 11:32
rakudo/main: 0efea1f1be | (Stefan Seifert)++ | src/Raku/ast/code.rakumod
RakuAST: fix default value of $/ in BEGIN time executed code.

Needs to be Nil instead of Mu so it passes default parameter type checks
  (Any)		 11:48
rakudo/main: 4067f6f620 | (Stefan Seifert)++ | src/Raku/ast/code.rakumod
RakuAST: make whitespace in ss/// actually significant

Fixes: my $a = "a b"; $a ~~ ss/a b/c d/;
nine 1189
rakudo/main: 58d923513d | (Stefan Seifert)++ | src/Raku/ast/code.rakumod
RakuAST: have S/// return a list of matches when appropriate
lizmat nine: we don't have a way (yet) to turn a Parameter object into a RakuAST::Parameter object yet, do we ? 12:12
nine Not that I'm aware of. What would you want that for? 12:30
lizmat R#2599 12:36
linkable6 R#2599 [open]: github.com/rakudo/rakudo/issues/2599 [performance][Will be addressed in RakuAST] .assuming is painfully slow
lizmat aka, building the new Callable with RakuAST, EVALling that
so far, it looks like it should be about 20x as fast as the current approach 12:37
lizmat :w 13:14
nine Looks like there's another spec test for multi dispatch of native rw args. 13:16
Quick reminder:
m: multi x(int $x is rw) { 1 }; x(my int $i = 42); 13:17
camelia ( no output )
nine m: multi x(int $x is rw) { say $x }; x(my int $i = 42);
camelia Cannot resolve caller x(BOOTInt); the following candidates
match the type but require mutable arguments:
(int $x is rw)
in block <unit> at <tmp> line 1
nine Those spec tests work on the old frontend only because the optimizer can statically inline those extremely simple functions. When it can't, dispatch fails. 13:18
lizmat interesting... then these tests should be marked TODO or skipped ? 13:19
nine Yes, that'd be appropriate. 13:20
lizmat I wonder how much would break on spectest while running with --optimize=off 13:23
first prototype of .assuming based on RakuAST, replacing 1 of 3 positional args, runs 43x as fast as the current version of .assuming 13:28
nine 27 spectest files fail when run with --optimize=off 13:35
lizmat wow
nine 9 with --optimize=0 13:37
Geth rakudo/main: 0492be40c3 | (Stefan Seifert)++ | src/Raku/ast/variable-declaration.rakumod
RakuAST: have native initializers return lexicalrefs
 13:47
nine While this didn't actually fix the spectest file I was after, it happened to fix 3 others :) And I almost reverted those changes...
1192 now
Geth roast: da7ebf4243 | (Stefan Seifert)++ | 2 files
Mark accidentally passing tests as todo

Rakudo's static optimizer can inline multi candidates in the most trivial cases. This makes a couple of tests pass when actually our multi dispatch is not yet up to the task.		 13:55
nine 1194
Geth rakudo/main: a83a0fb7e2 | (Stefan Seifert)++ | src/Raku/ast/signature.rakumod
Fix object in QAST::WVal, but not in SC for named parameter default types

Fixes: sub (::T $a, T $c) { }		 15:16
nine A very straight forward fix for one more. However, something very odd is happening. Suddenly 3 tests that have been passing for a long time started to fail. All failures seem module related. The failures are not caused by my change though. They still fail when I go back to earlier commits. 15:17
It's t/spec/S11-compunit/rt126904.t t/spec/S11-modules/nested.t and t/spec/S32-hash/perl.t 15:18
patrickb Anyone knows if it's possible to get rid of the "master" branch in the rakudo repo? On Moar the "master" branch is gone. Can we somehow do the same in Rakudo? It has potential to confuse people (given it points to some 2022.12 commit). 15:50
[Coke] +1 16:01
nine Oh, those 3 only passed because I did those no-optimizer test runs and didn't clean the .precomp dirs in between 16:27
1192 seems to be the correct count 16:30
lizmat do we have any idea why the Parameter.default_value attribute needs to contain code ? 17:41
ah, yes, sub foo($a, $b = $a) { } 17:42
duh
ah, yes, sub foo($a, $b = $a + 42) { }
Geth rakudo/main: 6535f2dfd0 | (Stefan Seifert)++ | 3 files
RakuAST: support slurpy sub signature arrays

Fixes sub foo(*[$a, $b]) { }		 18:39
rakudo/main: 8dfdb41361 | (Stefan Seifert)++ | src/Raku/Grammar.nqp
RakuAST: fix default types of parameters in sub-signatures
rakudo/main: 0ac3fa3860 | (Stefan Seifert)++ | 2 files
RakuAST: issue bindcomplete after param type check on multis
nine 1194 18:42
Geth rakudo/main: 700d34cdce | (Stefan Seifert)++ | 2 files
RakuAST: support ;; param separator in signatures
 19:00
nine 1195
Geth rakudo/main: 9afde80740 | (Stefan Seifert)++ | src/Raku/ast/code.rakumod
RakuAST: refuse declaration of anonymous multis
 19:15
nine 1196
Geth rakudo/main: 725b7b3d51 | (Stefan Seifert)++ | src/Raku/Actions.nqp
RakuAST: handle negative numbers in signatures correctly

Fixes sub foo(-1) { } # lost the sign before		 19:44
nine 1197
lizmat: you added tests for and closed github.com/rakudo/rakudo/issues/3485 but what was the actual fix? 20:26
Geth rakudo/main: 4 commits pushed by (Stefan Seifert)++ 22:41
nine OMG that's 1200
lizmat nine++ 23:17
[Coke] WOOT 23:32

Powered by Cro and the Raku® Programming Language.

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

Thank you!