JimmyZhuo patrickb: make seems ok now, how to test it? 02:34
tellable6 2025-03-27T13:44:07Z #raku-dev <patrickb> JimmyZhuo: I've updated the PR again. Somehow GCC lto doesn't work on your system. I've disabled it. 02:35
nine lizmat: your problem isn't building or running an AST. It's doing so at BEGIN time, which is a very different kind of problem. 06:59
patrickb JimmyZhuo: I did by installing zef and then doing a zef install "SomeModule::With<angle-brackets>" 12:27
This doesn't work without this Pr and does with it. 12:28
All sorts of other non alphabetic chars are equally problematic.
lizmat nine: so that I get it right, is: CHECK $*CU.EVAL running an AST at BEGIN time ? 12:31
m: say Q|*+42:foo|.AST.EVAL()(666) 13:08
camelia Cannot resolve caller infix:<+>(Int:D, Int:D, :foo); none of these signatures matches:
( --> 0)
($x)
(\a, \b)
(Real $a, Real $b)
(Int:D $a, Int:D $b --> Int:D)
(int $a, int $b --> int)
(uint $a, uint $b --> ui…
lizmat which is to be expected, yet, I cannot find anywhere where the :foo is stored in the AST 13:09
m: say Q|*+42:foo|.AST
camelia RakuAST::StatementList.new(
RakuAST::Statement::Expression.new(
expression => RakuAST::ApplyInfix.new(
left => RakuAST::WhateverCode::Argument.new,
infix => RakuAST::Infix.new("+"),
right => RakuAST::IntLiteral.new(4…
lizmat m: say Q|*+42:foo|.AST.statements.head.expression.args # found it 13:12
camelia RakuAST::ArgList.new(
RakuAST::WhateverCode::Argument.new,
RakuAST::IntLiteral.new(42),
RakuAST::ColonPair::True.new("foo")
)
lizmat m: *+42:foo # I'd argue this is wrong, unless it can be proven that there is no infix:<+>($a,$b,:$foo) candidate at compile time 13:15
camelia ===SORRY!=== Error while compiling <tmp>
You can't adverb +
at <tmp>:1
------> *+42:foo<HERE> # I'd argue this is wrong, unless it
expecting any of:
pair value
lizmat m: sub infix:<+>($a,$b,:$foo) { dd }; *+42:foo 13:16
camelia ===SORRY!=== Error while compiling <tmp>
You can't adverb +
at <tmp>:1
------> infix:<+>($a,$b,:$foo) { dd }; *+42:foo<HERE><EOL>
expecting any of:
pair value
lizmat m: sub infix:<+>($a,$b,:$foo) { dd }; say 666+42:foo
camelia sub infix:<+>($a, $b, :$foo)
Nil
lizmat so it's acceptable as an expression, but not as a whatevercode ?
m: sub infix:<+>($a,$b,:$foo) { dd }; Q|*+42:foo|.AST.EVAL()(666) # I'd say this is correct behaviour 13:20
camelia sub infix:<+>($a, $b, :$foo)
lizmat nine: ^^^ do you agree ?
Geth roast: d0bbf8ba84 | (Elizabeth Mattijsen)++ | APPENDICES/A02-some-day-maybe/misc.t
Change compilation error test for: *+42:foo

This should *not* be a compilation error, unless it can be proven that that will never be an infix:<+>($a,$b,:$foo) or other accepting infix:<+> candidate at runtime. Which I don't think you can.
Also, an expression such as: 666+42:foo *is* allowed, and fails ... (7 more lines)		 13:34
Geth rakudo/coke/releng2: d2eb4daeee | (Will Coleda)++ | tools/releasable/Akefile
RELENG Remove stale step #'s from comments
 14:48
rakudo/coke/releng2: 42aae5aaa3 | (Will Coleda)++ | docs/release_guide.pod
RELENG - renumber steps after content changes
rakudo/coke/releng2: 1a7790adb3 | (Will Coleda)++ | docs/release_guide.pod
RELENG don't repeat all vars each time

Makes the commands we're running a little more obvious use consistently indenting.		 14:54
[Coke] jdv: ^^ checkout that one in particular.
Looks like most of the commits this week have been RakuAST - don't see a need for a Blin run this week. 15:12
github.com/rakudo/rakudo/wiki/ChangeLog-Draft - I may do a "test" blin run anyway to see if we can handle Test::Async tests these days. 15:13
lizmat [Coke] my only concern is whether bcdbbdd8bc21e78a would cause any ecosystem fallout 15:14
linkable6 (2025-03-25) github.com/rakudo/rakudo/commit/bcdbbdd8bc Make .classify/.categorize return proper object hashes
lizmat as well as related commits 8f8b95866f7e292ff3331 15:15
linkable6 (2025-03-25) github.com/rakudo/rakudo/commit/8f8b95866f Make the :{ } object hash syntax be like my %h{Mu}
lizmat and to a lesser extent: 998cde58a70898fe
Geth rakudo/main: 83d35bb5d7 | (Elizabeth Mattijsen)++ | 3 files
RakuAST: Correctly .raku/deparse ApplyInfix with named arguments

This also added support for an optional :colonpairs argument to ::ApplyInfix.new, and added a .colonpairs method to return any colonpairs that had been specified with .new, or with the
  .add-colonpair method		 15:18
[Coke] ok, then I'll both include test::async and create a ticket if anything is found.
I'll actually start that now. 15:19
Geth Blin: dbc03d1979 | (Will Coleda)++ | bin/blin.p6
Don't skip Test::Async
 15:22
Blin: ea4836cd8a | (Will Coleda)++ | bin/blin.p6
ignore CORE

  (a way to reference Test/NativeCall, etc.)
jdv did something change wrt Test::Async 15:42
been a long time but i think it hung blin flappingly 15:43
[Coke]: all the changes look ok to me
the last one could probably be done better but its better even as is
[Coke] Cool, feel free to also make edits on that branch if you like (or just ping me with suggestions) 15:46
jdv: I did a test of *just* test::async a few weeks back and it seemed fine. A large # of modules use it, so if we can get a clean run out of it, we'll be better off. 15:47
If not, I'll just re-skip it and add a comment that we tested it today.
I also didn't see any new native deps on github.com/Raku/ecosystem-unbitrot/wiki 15:48
jdv either that or fix or implement a hang timeout
anyway, fun
i don't know that page 15:50
last updated 4y ago. idk...:)( 15:51
Geth rakudo/main: 86c5bc108b | (Elizabeth Mattijsen)++ | 4 files
RakuAST: fixup handling of ::Var::Attribute::Public

  - Add method ::Var::Attribute::Public.args to return the ArgList
   of any arguments given
  - Adapt .raku / .DEPARSE accordingly
  - Add test for this functionality		 16:08
nine lizmat: yes, whether that's a Whatever or something else shouldn't make a difference 16:42
CHECK $*CU.EVAL would still count as BEGIN time, or lets say compile time 16:45
I'm not sure though how that helps with understanding? 16:46
lizmat well, since in my eyes, the Raku grammar conceptually does this: 16:50
- parse the gramme
*ar
- create an AST
- run .EVAL on it 16:51
apparently that last step is not sufficient by itself to be able to skip the first step for programmatically created ASTs 16:52
in the case of .assuming: it generates a Sub ok, and that executes ok, yet somehow is disassociated from the context enough so that it can't be serialized 16:53
[Coke] jdv: Blin readme links to page a, page a links to that. it's from blin's ancestor but they grabbed all that info at some point. Asked Smokemachine to make sure it was updated for Red. 16:54
nine It's not so much disassociated as it's not associated, i.e. you're missing active steps to fold your compilation into the already progressing outer compilation 16:55
[Coke] I love that one of blin's selling points is "Avoids segfaults by producing no useful output" 16:57
nine The compiler is blissfully unaware of what you're doing in assuming. To it you're just creating a bunch of nondescript objects that it has nothing to do with. In fact it doesn't even no that. It's just running some opaque code at BEGIN time. And vice versa assuming is unaware that there's actually a compilation happening.
jdv ok. I just got blin working by iterating and adding deps until it worked a while ago. that list may be out of date then. 16:58
nine We've had exactly the same situation with the old frontend before I implemented support for BEGIN time EVAL
[Coke] jdv: no doubt! We should probably generate the list of native deps programmatically by going through the ecosystem. Maybe have blin update a natives.md or something on each run and we can track it in blin rather than on a wiki somewhere. 17:00
lizmat nine: aha, ok, didn't know that: in that light, maybe github.com/lizmat/REPL/issues/1#is...2761879169 isn't so strange after all
jdv ah, i just adjusted to updates. no real changes.
github.com/Raku/Blin/commit/847909...853c29a001
[Coke]: sure:) 17:01
lizmat dinner&
jdv i mean that assumes they are declared properly. hopefully they are.
nine "missing static code ref for closure" usually happens when the QAST for a routine is absent from the precomp file and only the Code object itself is there 17:02
[Coke] jdv: yah, worst case we report a bug to the distro that they have a problem. (well, worst case is we just ignore the failure. eventually we should have all the kinds of blin failures logged somewhere) 17:34
⏳ 540 out of 2300 modules processed (23.47%)
Very jealous of the "2 hour" timing listed in the release guide.
jdv yeah, i think altai-man had a crazy box and i got about the same but it was at aws with a crazy box 17:50
a c6i.12xlarge maybe 17:51
nine That's about as much horse power as my desktop. That's not crazy! 17:53
jdv ha
Xliff_ \o 18:47
What's the best way to get the current progress of RakuAST? How are the weekly's getting its numbers? 18:48
nine I post them here 18:52
Of course the best way to stay on top of it is to join and fix spectests :)
Xliff_ Ah. So if I wanted to run those tests on my machine here, what's the invocation you use? 18:53
nine make && RAKUDO_RAKUAST=1 TEST_JOBS=30 make spectest 18:54
Xliff_ Files=1352, Tests=119566, 87 wallclock secs (14.28 usr 3.26 sys + 1833.67 cusr 189.53 csys = 2040.74 CPU) 19:01
nine++ 19:02
nine Many of the failing tests are just "throw the right kind of compile time exception instead of breaking in some other way" 19:06
Xliff_ I would like to help, but it seems like such a daunting task to get started... 19:08
nine It's really just code 19:32
Wait a minute....I'm not sure you specifically are allowed to find anything daunting anymore :D How many hundreds of thousands of lines have you written already? 19:33
[Coke] Xliff_: I've also been trying to track it as we go for 2025.04 release at github.com/rakudo/rakudo/wiki/ChangeLog-Draft 19:53
Geth roast: cd83d384db | (Stefan Seifert)++ | S32-exceptions/misc.t
Fix syntax error in test hiding the interesting error

This test contained a syntax error that didn't appear on the old frontend because that was reporting the self inheritance before even trying to parse the class body.		 21:33
nine Took me far too long to realize that this was the problem and RakuAST would have reported the SelfInherit exception just fine :/ 21:35

Powered by Cro and the Raku® Programming Language.

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

Thank you!