🦋 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.
lizmat nine: now that I'm done with .assuming for now, I could take the chainsaw and remove all AT-POSses ? 00:34
I seem to recall I was the one who put them in in the first place ?
japhb What's the reason for removing them? 00:42
lizmat AT-POS doesn't exist that early in the bootstrap, I think 00:48
sleep& 00:49
nine Oh, that "expected Rakudo::Iterator::Empty but got Rakudo::Iterator::Empty" seems to be some confusion between constant Empty which is declared very early and my class Empty in Rakudo::Iterator. 08:33
Renaming the latter to EmptyIteratorType also makes us move forward
nine lizmat_: thanks, but I'm almost through with it anyway 09:52
timo how do we feel about an exception class for reporting an istype that failed with some additional smarts in the message method like "if the things have the same name, figure out why they are actually different" 10:50
or is there already an exception for that which we should be using in `multi method are` in Any-Iterable-methods.rakumod? 10:51
i guess we do have X::TypeCheck 10:52
lizmat yup, that's the one 10:56
timo not sure it has anything to handle "they have the same name, so wtf" situations 10:57
lizmat it's got $!expected and $!got attributes, that are the types that were checked, afaik 10:58
so I think it could ? 10:59
timo it could, yeah
Geth nqp/main: 990e179bd1 | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump MoarVM to get big slurpies fix, timo++
 11:05
Geth rakudo/main: 9233a89f91 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP to get big slurpies fix, timo++
 11:23
rakudo/main: d02733a40b | (Elizabeth Mattijsen)++ | lib/Telemetry.rakumod
Fix snapper's memory reporting on MacOS

Earlier versions of libuv didn't correct for MacOS's memory usage reporting, but newer versions do. And MoarVM uses that newer version, so we can remove the special handling in the snapper.
Spotted by Timo++		 11:30
rakudo/main: f7023342ca | (Elizabeth Mattijsen)++ | lib/Telemetry.rakumod
Show initial memory values with _ between thousands

Timo++ for the suggestion		 11:37
rakudo/main: 3bbb521ae7 | (Elizabeth Mattijsen)++ | src/core.c/core_epilogue.rakumod
Make sure that sub-signatures with returns work ok

The "make-simple-type" sub takes names of types, not types		 13:27
roast: e98f54674a | (Elizabeth Mattijsen)++ | 4 files
Remove all TODOs from tests that now pass

Since github.com/rakudo/rakudo/commit/4ee9503bdc		 13:31
nine Huh...another super obscure problem: in BEGIN blocks any calls to methods on e.g. an argument Capture object fail. First by dispatching to Any's candidates instead of Capture's and then by leading to a VMNull called there. Here's the twist: they do succeed if I first manually ^find_method them _and_ call that result. 15:51
Geth rakudo/main: c9c2ca453d | (Elizabeth Mattijsen)++ | src/core.c/core_epilogue.rakumod
Add support for type-smileys in .assuming

Found missing while working on RakuAST::Utils		 19:22
nine lizmat: can't motivate you to look at spectests? 19:27
lizmat you mean because of this latest commit ? 19:31
nine yes :)
Also the notable absence of any spec test fixing commits :) 19:32
lizmat spectest is clean for me? 19:35
apart from the two tests that you todoed because they only pass if optimization is on ? 19:36
nine I mean with RAKUDO_RAKUAST=1 19:37
lizmat running one now 19:43
well, at least we won t/spec/S06-currying/positional.t ? 19:47
seems like this is caused by: 19:51
m: ay Q|:(:$a = True)|.AST.DEPARSE
camelia ===SORRY!=== Error while compiling <tmp>
Undeclared routine:
ay used at line 1
lizmat m: say Q|:(:$a = True)|.AST.DEPARSE
camelia :(:$a = True)
lizmat m: say Q|:(:$a = True)|.AST.EVAL
camelia (:$a = Code.new)
lizmat what I think is the issue, is that RakuAST just checks for Parameter.default, which *always* returns a Callable 19:52
nine: ^^ 19:53
nine What is caused by that?
lizmat that the .EVAL returns a Code.new as the default for the named parameter 19:54
rather than True
is what triggers the test failing
nine Incidentally I just made a local change that made it recognize True/False as compile time constants and thus set them as default_value instead of default closures 19:55
lizmat then that should fix a lot of those tests 19:56
pretty sure that would fix all in t/spec/S06-currying/named.t 19:57
will look at the others after the meeting
. 20:00
t/spec/S06-currying/slurpy.rakudo.moar will also be fixed if you handle True/False as default_value 20:21
so we should be good after that
nine good in what way? 20:28
lizmat the files should pass again in entirety ?
with RAKUDO_RAKUAST=1 ? 20:29
nine Oh, I didn't realize there were assuming related regressions
lizmat yup :-) gotten very familiar with those tests in the past 2 weeks 20:34
m: sub a(::T $a, Array[T] $b) { dd :$a:$b }; a 42, my Int @ = 666 # something is leaking out 20:36
camelia Use of RakuAST is experimental; please 'use experimental :rakuast'

Actually thrown at:
in sub a at <tmp> line 1
in block <unit> at <tmp> line 1
lizmat bisectable6: old=2025.02 sub a(::T $a, Array[T] $b) { dd :$a:$b }; a 42, my Int @ = 666 20:38
bisectable6 lizmat, On both starting points (old=2025.02 new=c9c2ca4) the exit code is 1 and the output is identical as well
lizmat, Output on both points: «Use of RakuAST is experimental; please 'use experimental :rakuast'␤␤Actually thrown at:␤ in sub a at /tmp/xcfeQZp9aZ line 1␤ in block <unit> at /tmp/xcfeQZp9aZ line 1␤␤»
lizmat ah?
bisectable6: old=2024.02 sub a(::T $a, Array[T] $b) { dd :$a:$b }; a 42, my Int @ = 666
bisectable6 lizmat, On both starting points (old=2024.02 new=c9c2ca4) the exit code is 1 and the output is identical as well
lizmat, Output on both points: «Use of RakuAST is experimental; please 'use experimental :rakuast'␤␤Actually thrown at:␤ in sub a at /tmp/4l9J0qmfGb line 1␤ in block <unit> at /tmp/4l9J0qmfGb line 1␤␤»
lizmat heh
bisectable6: old=2025.02 sub a(::T $a, T @b) { dd :$a:@b }; a 42, my Int @ = 666 20:39
bisectable6 lizmat, Bisecting by exit code (old=2025.02 new=c9c2ca4). Old exit code: 1
lizmat, bisect log: gist.github.com/8de69d7f53e41e4377...087884c805
lizmat, (2025-03-07) github.com/rakudo/rakudo/commit/0b...9c112414f0
nine I actually meant fixing any of the remaining spectests 20:44
But of course the regressed ones would be a good start
lizmat "[20:55:25] <nine> Incidentally I just made a local change that made it recognize True/False as compile time constants and thus set them as default_value instead of default closures" 20:45
that should fix those two recently broken by my .assuming work 20:46
I'm about to break one again: 20:48
m: sub foo(::T $a, T @b) { "$a:@b[]" }; say foo(42, my Int @ = 666,137)
camelia 42:666 137
lizmat breaks under RAKUDO_RAKUAST=1
Geth rakudo/main: 19fe378097 | (Stefan Seifert)++ | src/Raku/ast/signature.rakumod
RakuAST: recognize True/Default as compile time known for default values
 20:49
nine Well, it doesn't look like they do
lizmat ok, /me pulls anc checks
t/spec/S06-currying/named.rakudo.moar and t/spec/S06-currying/slurpy.t now pass for me with RAKUDO_RAKUAST=1 ? 20:58
nine Ah, was missing commits from upstream main 21:01
lizmat nine: I'm seeing 146 occurrences of AT-POS in src/Raku/ast 21:03
want me to fix those to postcircumfixes ?
nine No, I have fixed them locally already 21:04
lizmat okido
I'll take that as a cue to end my hacking for today :-) 21:05
m: sub foo(::T $a, T @b) { "$a:@b[]" }; say foo(42, my Int @ = 666,137) 21:10
camelia 42:666 137
lizmat nine: re ^^, looks like Raku actions need the equivalent of github.com/rakudo/rakudo/pull/5804/files
but I haven't been able to trace that down yet
afk&
nine Are you saying that this fix went in with no regard for RakuAST despite the standing RSC decision that everything going into main is to be accompanied by an appropriate RakuAST version? 21:15
Color me surprised

Powered by Cro and the Raku® Programming Language.

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

Thank you!