🦋 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.
timo from what i understood what nine wrote, things like that should go into a CHECK-related method of a rakuast node, and which part exactly it goes into probably depends on where it makes the most sense; i imagine "as far towards the leaves as you can, but if you need information from siblings, go up a node" makes a good first approximation 00:21
nine timo hi it right on the mark. $^foo is a RakuAST::VarDeclaration::Placeholder (which you can see from --target=ast output). That's the node the sorry has to be attached to in order for it to get reported at the right place. 07:25
However it could be that the actual check needs to be done by the LexicalScope because that has the full view. The last check in LexicalScope is an example for it doing the check but attaching the sorry to the offending child node. 07:31
LexicalScope already does multiple checks that lead to X::Redeclaration. Maybe they just need tweaking for it to recognize the Placeholder. 07:32
Geth rakudo/main: f40b747a3d | (Stefan Seifert)++ | src/Raku/ast/call.rakumod
RakuAST: optimize private method calls that we can resolve

We don't have to go throught dispatch:<!> if we already know the current type and can look up the callee at compile time. Generate a call op to the resolved method object in that case.
This also avoids bootstrapping issues.		 08:15
rakudo/main: 1a6bca622f | (Stefan Seifert)++ | 3 files
RakuAST: support trusts statement

Fixes: class Foo { trusts Bar; }
rakudo/main: da6c8e3634 | (Stefan Seifert)++ | 2 files
RakuAST: support qualified private method calls
rakudo/main: c6e0a64862 | (Stefan Seifert)++ | src/Raku/ast/signature.rakumod
RakuAST: relax check for multiple positional slurpies

Slurpy positional args don't have to have a @ sigil. They may not have a sigil at all. The really important part is that they don't have a % sigil.
Fixes: sub unique(+a, |c) { }		 08:40
nine If anyone is ever curious. This is the minimal setting required for a RakuAST compilation: 11:42
use nqp; class Pair { ... }; role Iterable { ... }; role Positional { ... }; role Associative { ... }; class Attribute { method compose($) { } }; class Array { method new() { nqp::create(self) }; method elems() { 0 } }; class Pair { }; class CompUnit::RepositoryRegistry { }; class Any { method Hashray() { self } }
lizmat I'm surprised about the Hashray 11:48
that's a fairly recent addition
nine RakuAST::Doc::Block.Hashray
lizmat interesting... but there's no rakudoc in the setting ? If there is, it should be removed :-) 12:45
rakkable: eco-provides .= 12:48
rakkable lizmat, Running: eco-provides .=, please be patient!
lizmat, Found 7042 lines in 1885 files (655 distributions):
lizmat, gist.github.com/9b2495d0d5e8fbc59a...1ca153deb9
lizmat clearly a popular feature 12:49
nine Stage parse : 34.385 12:58
Stage syntaxcheck: 0.000
Stage ast : 0.000
Stage qast : 2.901
Stage mast : 6.887
Stage mbc : 0.652
+++ Compiling blib/Perl6/BOOTSTRAP/v6d.moarvm
JimmyZhuo The following step can take a long time, please be patient. 13:00
Stage start : 0.000
Stage parse : 74.196
Stage syntaxcheck: 0.000
Stage ast : 0.000
Stage optimize : 8.097
Stage mast : 14.151
Stage mbc : 2.522
long time :)
nine Well mine was with the RakuAST frontend :) For comparison the old frontend: 13:01
Stage parse : 29.314
Stage syntaxcheck: 0.000
Stage ast : 0.000
Stage optimize : 2.926
Stage mast : 5.377
Stage mbc : 0.950
Also this means that we're through CORE.c.setting!
JimmyZhuo nine++
sjn nice 13:03
JimmyZhuo I have a very old cpu, 10+ years old
[Coke] great news on CORE.c 13:04
lizmat NICE! nine++ 13:10
JimmyZhuo throws-like ' {my $foo; $^foo;}(1) ', X::Redeclaration is bit hard for me, because 'if $lexical-name && ! $_ =:= self {' always true, I change it to 'if $lexical-name && (!nqp::istype($_, RakuAST::VarDeclaration::Implicit) || ! $_ =:= self)' , then 13:18
$ RAKUDO_RAKUAST=1 ./rakudo-m -Ilib t/spec/S06-signature/positional-placeholders.t
===SORRY!===
Redeclaration of symbol '%_'.
at E:\OpenSource\Rakudo\lib\Test.rakumod (Test):69
Redeclaration of symbol '$?CLASS'.
at E:\OpenSource\Rakudo\lib\Test.rakumod (Test):68
Redeclaration of symbol '::?CLASS'.
at E:\OpenSource\Rakudo\lib\Test.rakumod (Test):68
*always false* 13:19
nine JimmyZhuo: before changing the code, I'd add some debug print to check whether the RakuAST::VarDeclaration::Placeholder even appears in that place and to see why its name doesn't match the existing lexical's (probably $x vs $^x or the like) 13:25
JimmyZhuo yeah, I tried, because 'if $lexical-name && ! $_ =:= self {' always false, seems it never work before 13:27
so '! $_ =:= self' this one , I don't know how to change it, to make all test happy 13:28
nine JimmyZhuo: a Placeholder is not is-simple-lexical-declaration. So I wouldn't expect it to even be in the list self.ast-lexical-declarations. If it declares something, it'll appear in self.generated-lexical-declarations. 13:32
JimmyZhuo yes, it is
nine at-lexical-declarations is everything where we know from the AST node just being there that it's a declaration. Like VarDeclaration::Simple. That's always gonna declare something (it's is-simple-lexical-declaration). 13:33
Everything that needs some calculation to determine whether it's even gonna declare something or not is a generated lexical declaration.
Not every Placeholder is a declaration, e.g. in $^x, $^x only the first occurence will declare, while the second one is just a variable access. Thus the first Placeholder node will generate the declaration. 13:35
JimmyZhuo 'my $foo' can't be in %lookup, because 'if $lexical-name && ! $_ =:= self {' always false, and $^foo is right there
nine Why is that false? Is it because $lexical-name is empty or because $_ =:= self? And do you at least encounter the VarDeclaration::Simple in that look? 13:36
s/look/loop/
JimmyZhuo ! $_ =:= self 13:37
this one
nine That means $_ =:= self. That's surprising as self would be the LexicalScope (i.e. the RakuAST::Sub)
You sure you're interpreting your debug output correctly? 13:38
JimmyZhuo yes
put nqp::say(1) after 'if $lexical-name && ! $_ =:= self {', it never outputs 13:40
nine What do nqp::say($_); and nqp::say(self) say before that? 13:51
JimmyZhuo I didn't try it, sleep time here, good night 13:54
Geth rakudo/main: c9423ed2a3 | (Stefan Seifert)++ | src/Raku/ast/package.rakumod
RakuAST: don't replace outer scope's package stubs with lexical package

A lexically defined package in a nested scope must not be used to replace a package stub defined in an outer scope.
Fixes: class Foo { ... }; { my class Foo { } }		 15:16
rakudo/main: 068f564cac | (Stefan Seifert)++ | 2 files
RakuAST: fix stubs of packages with multi-part names not found

Fixes: class Foo::Bar { ... }; class Foo::Bar { }		 15:49
nine That's one less workaround in the setting
Though I still think it's not a great idea to have a my class Map in Rakudo::Internals::HyperRaceSharedImpl 15:50
lizmat why not rename that class then? It's an implementation detail ? 16:02
nine out of scope 16:08
Geth rakudo/main: fed35e5796 | (Elizabeth Mattijsen)++ | src/core.c/Rakudo/Internals/HyperRaceSharedImpl.rakumod
Use less confusing "private" class names

Making setting compilation under RAKUDO_RAKUAST=1 less troublesome		 16:29
lizmat probably mustard after the meal, but yeah 16:30
nine Well it did uncover a bug that needed fixing 16:32
lizmat there's that :-) 16:33
[Coke] (MaaM) huh, TIL 16:34
(MatM) letters hard.
Geth rakudo/main: ab04e6b60f | (Elizabeth Mattijsen)++ | tools/add-leap-second.raku
Update leap second date adding logic

In response to #5769. It will now just write to the source-file. Use git diff to check results.		 16:58
rakudo/main: ee28391b87 | (Elizabeth Mattijsen)++ | docs/release_guide.pod
Remove leap second check step from release process

It looks like there won't be another leap second *added* in our lifetime. There might be a negatve leap second, but that would require quite a bit more than just running the leap day script.
In any case, having another leap second added, will be major news ... (5 more lines)		 17:05
lizmat inspired by a reaction to dev.to/lizmat/quicker-to-assume-2cpj I was wondering why we couldn't support a syntax such as: 18:02
-> $a // 0, $b // 0 { $b < $a }
basically a variation on:
-> $a = 0, $b = 0 { $b < $a }
but instead of having the default value applied if the argument is absent, have the default applied if the argument is !.defined 18:03
would prove to be an interesting challenge to hang in the binder, but still... 18:04
gfldex I would prefer `-> $a //= True { ... }` . Closer to general Raku syntax. 18:21
lizmat github.com/Raku/problem-solving/issues/469 18:25
good point, will adapt accordingly
ugexe i brought this up before, and remember jnthn had some comments. alas, i cannot find any record of this 18:32
lizmat yeah, it feels like this idea is too good to be just imagined for the first time by me just now 18:33
what I *do* know, is that jnthn didn't want to work on the binder, which this feature would require
but also, I'm pretty sure these comments were then pre new dispatch mechanism 18:34
ugexe just a recent comment by myself "in perl 5.38 you can use //= in subroutine signatures, something you can't do in raku"
lizmat aha... ok, maybe I subconsciously remembered that 18:35
ugexe anyways if my memory is true then i think jnthns comments were along the lines of "that could be nice, although $some_edge_case needs some thought"
similarly ||= 18:37
irclogs.raku.org/perl6-dev/2017-07...html#15:31 18:49
lizmat and irclogs.raku.org/perl6-dev/2017-07...15:33-0005 18:51
ugexe i feel like im still thinking of another earlier conversation
lizmat well Zoffix mentioned a proposal
ugexe yeah there is a whole conversation
lizmat actual, it's in the speculation 18:52
github.com/Raku/old-design-docs/bl...parameters 18:54
"Missing optional arguments default to their default values, or to an undefined value if they have no default. (A supplied argument that is undefined is not considered to be missing, and hence does not trigger the default. Use //= within the body for that.)"
ah, U misread
*I
*in the body* 18:55
nvm
Geth rakudo/lizmat-backtrace: b90acbeb0b | (Elizabeth Mattijsen)++ | src/core.c/Backtrace.rakumod
Add support for RAKUDO_NOPATH_STACKFRAME envvar

In response to #5751 . When specified with a True value, will shorten a line such as:
   in method relationship-model at /opt/rakudo-pkg/share/perl6/site/sources/9740DDE0E85E093DCDF40F690C620BD9BAEE9078 (Red::Attr::Relationship) line 43
to:
   in method relationship-model at Red::Attr::Relationship line 43		 19:52
rakudo: lizmat++ created pull request #5811:
Add support for RAKUDO_NOPATH_STACKFRAME envvar		 19:53
SmokeMachine That looks like the reduce problems I fixed on red today… 19:56
ugexe i really dislike that option. people already seem to forget when they have e.g. RAKULIB=lib set, then they file issues, and the only way someone knows what their issue is (since of course no one posts their e.g. ENV vars or other useful debugging information unless explicitly asked) is to recognize it from those paths 20:06
its a stack frame, it should be verbose 20:07
end users shouldnt be seeing them, and if they are then the code author should fix their code
I'm not sure the code is implemented in a satisfactory way either since it seems to rely on .words, and paths can certainly contain spaces 20:11
lizmat well, yes, I had my doubts as well, hence made it into a PR :-) 20:16
afk&
SmokeMachine How can I see if Red is failing in blin? 20:20
[Coke] blin runs are manual. 20:35
I can check my last run.
This will be pre-last release. 20:36
nope, didn't fail 20:37
when a blin run is done, there's a ticket that's created for core devs to work off of - 20:38
github.com/rakudo/rakudo/issues?q=...sue%20blin
SmokeMachine Thanks! That’s very odd… the change on `reduce` broke Red and its tests… it should show on blin, no? 20:48
I’m afraid Red is not being tested… :( 20:50
[Coke] when did that change go in? 20:54
Might be being skipped for some reason
I only checked if it was explicitly failing, checking if it was skipped 20:55
SmokeMachine Red had no change and I tested with 2025.02, and it was broken… then I fixed it… 20:58
[Coke] weird, I'm seeing it as Red – AlwaysFail 20:59
SmokeMachine That explains it… but why? It works…
[Coke] that's in the overview, not sure why it's not in the markdown 21:00
oh, because it failed before and after.
I can try it manually on that box.
SmokeMachine Please! (Thanks for your help)
[Coke] Sure! 21:01
(anything with AlwaysFail should probably be tracked separately and tickets opened with the various modules (or we can remove them from the test runs) 21:02
ugexe probably has to do with setting up Postgres or whatever 21:05
in other words: it wouldnt surprise me if distributions that depend on system configuration / setup are often marked as AlwaysFail or skip etc for Blin runs since setting those things up for each such distribution would take more effort than what was desired at the time by whoever was doing it 21:07
[Coke] Very likely
there is a list of "hey install all this random crap so you can test more distros" but it's not checking the distro itself to see what's required. 21:08
SmokeMachine Red tests test only SQLite… :)
[Coke] if that's it, I'll add it to the box and the blin directions, at least.
Same thing, different package.
"pq:from<native>:ver<5>" 21:10
isn't that postgress?
that's in DB::Pg
SmokeMachine Yes, Postgres… it does not test Postgres, but depends on it 21:11
[Coke] ... ok, but we still have to build it...
SmokeMachine github.com/FCO/Red/blob/master/META6.json#L9
[Coke] so it does depend on it. 21:12
SmokeMachine Yes… makes sense…
[Coke] starting a blin run is very slow and I've had to do it 3 times now to get to the punchline to verify, apologies.
SmokeMachine Sorry for all the work… 21:13
[Coke] eh. no worries.
Good catch. I hadn't reviewed the alwaysfails yet.
something about updating the fez mirror is very slow on this box. 21:14
... crap I should have saved the previous run's output folder. 21:17
wait, Red is using sqllite in tests? It doesn't depend on anything native? 21:24
SmokeMachine Sqlite3
[Coke] ok - but it's not a declared dependency? 21:25
(also, there is a pq installed on this box, but it's in /usr/games/pq)
SmokeMachine It depends on DBIish and I think that depends on swlite3 (or one of its dependencies) 21:26
[Coke] blin run is just hanging now. 21:29
nothing in top showing anything using cpu
SmokeMachine: can you add any native deps needed for blin for your stuff (or deps) here: github.com/Raku/ecosystem-unbitrot/wiki ? 21:31
I'll make sure I have those installed before the next blin run (and I'll do a full run in the next few days)
SmokeMachine [Coke]: add it on Red’s META or on that wiki? 21:32
[Coke] no need to add it to red's meta if it is in a dependency's meta - but if a dependency you're using has a 3rd party dep and it's not on that list, please add that. 22:01
Or let me know, and I'll do it before the next blin run. 22:02
SmokeMachine ok, I'll add pq and sqlite3... I'll try to find out another module depending on it to copy the exact name... 22:03
[Coke] +1 22:06
if none of your deps depend on sqlite3, you should also add it to your own deps. I can check that too, one sec.
zef-deps Red | grep 'from<native>' # doesn't show a dep on sqlite at all 22:12
(only pq:ver<5>:from<native> shows up)
so yes, you'll need to add that to Red's meta 22:13

Powered by Cro and the Raku® Programming Language.

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

Thank you!