timo it might have to be "make $<simple-variable>.made` or something perhaps? 00:01
[Coke] You've gained 2 more on 'make test' 00:29
up to 145/166 (probably passing tests copied in from roast, now the total is higher.) 00:30
nine MasterDuke: you need to arrive at the $*R.declare-lexical call in method variable-declarator in Actions. That's where the compiler is made aware of there being a new lexical variable. 08:33
tellable6 nine, I'll pass your message to MasterDuke
nine MasterDuke: simple-variable uses self.compile-variable-access which already tries to resolve that variable. It's not suitable for making a declaration. 08:34
tellable6 nine, I'll pass your message to MasterDuke
nine MasterDuke: correction, stub-variable is where most variables are declared. The other thing was for `has $foo` only 08:36
tellable6 nine, I'll pass your message to MasterDuke
Geth roast: fc6af9344e | (Stefan Seifert)++ | integration/advent2011-day11.t
Fix use of undeclared variable in private method test

The test used an undeclared variable $o instead of the existing $order. Apparently the old compiler reported the problem with the private method call before even checking whether the variable it's called on exists.		 08:56
rakudo/main: 55e087ac4a | (Stefan Seifert)++ | src/Raku/ast/call.rakumod
RakuAST: prohibit unqualified private method calls on variables

Fixes: $foo!private # to fail		 09:04
nine 1129
lizmat nine: github.com/niner/Inline-Perl5/pull/188 09:37
reason I didn't make this yesterday is that apparently one needs to nuke "resources" *and* .precomp before testing each time 09:38
nine I guess the precomp files lack a dependency on Inline::Perl5 09:39
lizmat possibly, but it got very confusing at one point, I can tell you :-) 09:40
it's when I realized that even the unchanged Inline::Perl5 would crash on pre-POPULATE rakudo, I figured something was interfering :-)
nine I wonder how this problem survived blin 09:41
lizmat because there was no test for it
Inline::Perl5 installed fine on post-POPULATE 09:42
it's Fritz's golf that triggered it somehow
perhaps because it's also using NativeCall for LibXML ?
ah no... nvm
perhaps because perl's Excel::Writer::XLSX does some nasty tricks under the hood ? 09:43
although I understand that to be pure perl fwiw
Geth roast: b49054a37a | (Stefan Seifert)++ | integration/rule-in-class-Str.t
Fix wrong translation from Perl5 to Raku regex syntax

Was broken by 0cf20295bc3e00ac0fd0945cff38681b52f9a455
  japhb++ for noticing		 09:49
lizmat nine: but did you notice that those tests are bogus, as it doesn't matter whether the translation was broken ? 09:50
m: say so "bar" ~~ /<[a]>/ 09:51
camelia True
lizmat m: say so "bar" ~~ /<[-a]>/
camelia True
nine I think any matching regex is ok for that test
lizmat I think all 3 tests should be "lives-ok" tests, because that's what it is essentially testing 09:55
will adapt test accordingly
Geth roast: 2cacfd8896 | (Elizabeth Mattijsen)++ | integration/rule-in-class-Str.t
Reduce test to what actually needs testing

Namely: can we call a method in a subclass of Str, an augmented version of Str, and a re-augmented version of Str.
This all completely bypasses the fact that augment is a compile time event, so that all tests could actually be placed *before* any of the augmentation is done in the code.
All in all, pretty dubious tests		 10:02
rakudo/main: 804603ab38 | (Stefan Seifert)++ | 2 files
RakuAST: throw proper X::Comp for exceptions thrown by package compose
 10:04
nine lizmat: I don't think that test is testing what it was supposed to test anymore. The description says "Difficulty using a rule in a method of Str." which strongly implies that regex is the essential part 10:06
lizmat but <[a]> isn't a rule ?
nine The wording may have changed sind < 2009 10:07
Geth roast: 8dc881737a | (Elizabeth Mattijsen)++ | integration/rule-in-class-Str.t
Revert "Reduce test to what actually needs testing"

This reverts commit 2cacfd889645294d82edfa32524b25a31544a76e.
It's "rule", not "role", I misread. Still weird tests, as no rule is involved?		 10:08
nine m: %::{''} 10:41
camelia ===SORRY!=== Error while compiling <tmp>
Variable '%' is not declared. Perhaps you forgot a 'sub' if this was
intended to be part of a signature?
at <tmp>:1
------> <BOL><HERE>%::{''}
nine This is an odd error to have, since: 10:42
m: %
camelia WARNINGS for <tmp>:
Useless use of unnamed % variable in sink context (line 1)
nine How can the anonymous variable be undeclared?
The history of this test is that the above code was taken from a Perl module without any translation and it led to an internal compiler error. That error later changed to the Undefined we're seeing now and that got enshrined into a spec test. But I don't see why that would be correc.t 10:43
lizmat neither
nine RakuAST parses it as a variable called "::" with a % sigil and then of course the hash index 10:45
lizmat m: $:: 10:46
camelia ===SORRY!=== Error while compiling <tmp>
Variable '$' is not declared. Perhaps you forgot a 'sub' if this was
intended to be part of a signature?
at <tmp>:1
------> <BOL><HERE>$::
nine m: dd ::
camelia PseudoStash.new(("!UNIT_MARKER" => !UNIT_MARKER,"\$!" => Nil,"\$/" => Nil,"\$=finish" => Mu,"\$=pod" => [],"\$?LANGUAGE-REVISION" => 2,"\$?PACKAGE" => GLOBAL,"\$_" => Any,"\$¢" => Nil,"::?PACKAGE" => GLOBAL,:EXPORT(EXPORT),:GLOBALish(GLOBAL)))
JimmyZhuo lto1.exe: fatal error: could not open symbol resolution file: No such file or directory 12:39
compilation terminated.
lto-wrapper.exe: fatal error: gcc returned 1 exit status
compilation terminated.
C:/Strawberry/c/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: error: lto-wrapper failed
collect2.exe: error: ld returned 1 exit status
gmake: *** [makefile:158: win-runner.exe-tmpl] Error 1
patrickb: sometimes I can't connet github, put error here ^^
./rakudo-gdb-m 13:18
Unhandled exception: While looking for '/home/jimmyz/rakudo3/perl6.moarvm': no such file or directory
patrickb JimmyZhuo: I've updated the PR again. Somehow GCC lto doesn't work on your system. I've disabled it. 13:44
tellable6 patrickb, I'll pass your message to JimmyZhuo
Geth rakudo/main: e237e2b2ff | (Stefan Seifert)++ | 10 files
RakuAST: don't swallow the leading :: in names

For names starting with :: we neglected to generate an empty name part to start the name with.		 14:31
rakudo/main: 1cd100123e | (Stefan Seifert)++ | src/Raku/ast/variable-access.rakumod
RakuAST: throw appropriate exception on %::
nine OMG I'd have never ever thought that so late in the game (we're almost at 99 %!) there'd be major changes to something as fundamental as our handling of names 14:32
Geth roast: b85f41ac37 | (Stefan Seifert)++ | integration/error-reporting.t
Fix unrelated error from error checking test

The test code contains 2 errors and the test relied on the compiler to report the "interesting" one first (and only that). A compiler may however also report the redeclaration first (and arguably that's the more helpful message even). That redeclaration however is not needed for testing whether X::Composition::NotComposable.message is accessible so remove it.		 14:49
[Coke] releasable6: next 15:14
releasable6 [Coke], Next release in ≈23 days and ≈3 hours. There are no known blockers. 61 out of 62 commits logged
[Coke], Details: gist.github.com/3c8425b6a88c7fdbaa...d4d0e2c50d
Geth rakudo/main: 5 commits pushed by (Stefan Seifert)++ 15:44
nine 1330. This file was a lot more effort than I anticipated at this stage
[Coke] m: say 1330/1350 15:51
camelia 0.985185
[Coke] *squeee*
Geth rakudo/main: 3caa98a97c | (Stefan Seifert)++ | lib/Test.rakumod
Fix throws-like applying matchers to group instead of expected exception

When throws-like finds an X::Comp::Group it also looks inside this group for the expected exception as the compiler may report multiple problems at once. However we still applied any matchers to the group instead of the exception that we want to test.		 15:55
nine 1331
[Coke] weird. I added the 5 rakuast ones in the combo geth report above... and releasable is saying those don't exist. 15:59
next 16:04
releaseable6: next
releasable6 [Coke], Next release in ≈23 days and ≈2 hours. There are no known blockers. 61 out of 62 commits logged (⚠ 5 warnings)
[Coke], Details: gist.github.com/97302bf30cec8a1e16...b075f75754
[Coke] (but 65a0e543 *is* on main. weird.)
c: 65a0e543: say 3 16:05
committable6 [Coke], ¦65a0e543:: «Cannot find this revision (did you mean “45ae5b9”?)»
[Coke] ah, it's stuck behind a build queue, maybe? (feels like that should only depend on git log, not whateverable buildS) 16:06
lizmat nine: it looks like the new .assuming now survives on the legacy backend 16:15
in precomped modules 16:16
nine How did that happen? 16:17
lizmat I haz no idea
going to double check the failing modules in the blin ticket 16:18
nine Be sure to clean your .precomps
And that there's no accidental RAKUDO_RAKUAST in your environment :) 16:19
lizmat module B with: our &foo = &sprintf.assuming("%x");
raku -Ilib -MB -e 'say foo(666)
29a
I think that qualifies as precomped usage 16:20
hmmm 16:21
ah, but BEGIN our &foo ... still fails :-(
meh
ah, yes, without the BEGIN, the .assuming was still runtime when the mainline of the module executed on loading 16:22
sh*t
nine I'd have been quite surprised if things had fixed themselves magically 16:23
lizmat the RakuAST error appears to have become more meaningful: 16:24
Serialization Error: missing static code ref for closure '' (src/Raku/ast/code.rakumod:145)
[Coke] releasable6: next 16:56
releasable6 [Coke], Next release in ≈23 days and ≈2 hours. There are no known blockers. 66 out of 68 commits logged
[Coke], Details: gist.github.com/6e90e138e26226d145...74d441a80c
lizmat heh. even the old .assuming implementation has issues with: BEGIN our &foo = &sprintf.assuming("%x"); 16:59
No such method 'list' for invocant of type 'VMNull'
in sub __PRIMED_ANON at EVAL_2 line 4
in sub __PRIMED_ANON at EVAL_2 line 1
lizmat rakkable: eco-pr use OO::Monitors 18:05
rakkable lizmat, Running: eco-provides use OO::Monitors, please be patient!
lizmat, Found 22 lines in 22 files (18 distributions):
lizmat rakkable: eco-pr use OO::Monitors 18:06
rakkable lizmat, Running: eco-provides use OO::Monitors, please be patient!
lizmat, Found 22 lines in 22 files (18 distributions):
lizmat, gist.github.com/35c246c5517be7c9e4...d8c52ecbaa
lizmat nine: the following hack gist.github.com/lizmat/16e30718158...5eaed84372 makes RakuAST and legacy both produce: 19:21
Serialization Error: missing static code ref for closure '' (src/Raku/ast/code.rakumod:145)
(well the same error type) 19:22
suggestions for a different hack that would to avoid the "Nil" not resolved error ? 19:23
nine: should this work? CHECK $*CU.EVAL 19:37
if not, why?
afk&
nine Why not just fix it for real on RakuAST? 19:42
MasterDuke nine: the `$*R.declare-lexical` is only hit in the `if $var.is-attribute && !$var.twigil {` block, where `method is-attribute` is `$scope eq 'has' || $scope eq 'HAS'` 20:39
tellable6 2025-03-27T08:33:32Z #raku-dev <nine> MasterDuke: you need to arrive at the $*R.declare-lexical call in method variable-declarator in Actions. That's where the compiler is made aware of there being a new lexical variable.
2025-03-27T08:34:50Z #raku-dev <nine> MasterDuke: simple-variable uses self.compile-variable-access which already tries to resolve that variable. It's not suitable for making a declaration.
2025-03-27T08:36:46Z #raku-dev <nine> MasterDuke: correction, stub-variable is where most variables are declared. The other thing was for `has $foo` only
MasterDuke oh, maybe that's what your last message was saying... 20:40
nine Yes, that's what I meant 20:52
MasterDuke huh, `method stub-variable($stub) { ... }` never actually uses `$stub`? 21:07
nine That's wrong. It should be $/ 21:08
From time to time I think that arguments passed to grammar methods end up in the associated action method which just isn't how this works 21:09
MasterDuke oh, but the first line is `my $/ := $*VARIABLE-MATCH;` 21:10
nine Yep. That's why it doesn't matter that this parameter has the wrong name
MasterDuke ha. well now i got `my $kinds = 4; say $kinds` to just print '(Mu)' instead of throwing...progress? 21:12
(by changing the argument to $/ and commenting out the assignment) 21:13
nine That doesn't sound right 21:14
MasterDuke there's much here that isn't right 21:16
nine You mean in main or with your local changes? 21:21
MasterDuke local changes 21:23
nine I'm glad :D 21:25
Geth rakudo/main: e5adb4d9b7 | (Will Coleda)++ | tools/releasable/Akefile
RELENG Fix -I path, use META6.json
 21:34
[Coke] jdv: do you ever use L<Z script|github.com/Raku/z> ? 21:49
If not, I'm going to remove it from the release guide 21:50
Geth rakudo/coke/releng2: 620dfda3b1 | (Will Coleda)++ | 2 files
RELENG Split rakudo-stress-errata into lang vers

New targets are rakudo-stress-errata-c rakudo-stress-errata-d
Closes #5827		 22:27
rakudo/coke/releng2: 3af63de646 | (Will Coleda)++ | docs/release_guide.pod
RELENG cleanup release guide slightly

  * use valid perldoc
  * Move some items around to match practice (e.g. changelog work can be done all month)
  * slight cleanup
[Coke] jdv: I'll throw a bunch of stuff on that branch and make you a reviewer of the PR. 22:30
jdv [Coke]: never used Z 23:00
cook
*cool
Geth rakudo/coke/releng2: 845f53c5e8 | (Will Coleda)++ | docs/release_guide.pod
RELENG pod, not markdown
 23:04
rakudo/coke/releng2: 9b991dcbde | (Will Coleda)++ | docs/release_guide.pod
RELENG remove ref to z tool

Not used by current RELENG
lizmat nine: re "Why not just fix it for real on RakuAST?" My point was that you could conceptually consider "CHECK $*CU.EVAL" as the process that turns an AST tree into bytecode and execute it 23:48
so, what is missing if we take an artificially built AST (which shouldn't be too different from the one built by the Raku grammar) and call .EVAL on it? 23:49
I'll get back to this after some sleep&

Powered by Cro and the Raku® Programming Language.

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

Thank you!