01:23 Voldenet_ joined, Voldenet left 01:24 Voldenet_ is now known as Voldenet
Geth rakudo: ugexe++ created pull request #6688:
RakuAST: keep a call's references when an assignment to one follows a native read		 01:34
nqp: ugexe++ created pull request #876:
Keep a lexicalref condition's reference when a two operand conditional yeilds it		 01:36
[Coke] Got disconnected from bus connection. Trying to reconnect... 01:55
Failed to re-add reference to unit: Transport endpoint is not connected
new failure mode for blin process.
c: af3df50dba e.say
committable6 [Coke], ¦af3df50: «Cannot test this commit (Commit exists, but an executable could not be built for it)»
Geth whateverable/main: 19b6d735ed | (Will Coleda)++ | .ping
WIP
 01:56
02:01 greppable6 left, releasable6 left, benchable6 left, unicodable6 left, nativecallable6 left, committable6 left, coverable6 left, sourceable6 left, quotable6 left, linkable6 left, shareable6__ left, bloatable6 left, bisectable6 left, evalable6 left, huggable6 left, notable6 left, tellable6 left
[Coke] c: af3df50dba e.say 02:03
Geth nqp/main: 06f61ec6a4 | (Nick Logan)++ (committed using GitHub Web editor) | 2 files
Keep a lexicalref condition's reference when a two operand conditional yields it (#876)

Previously a two operand `if` or `unless` whose condition is a native
  `lexicalref` read that condition as a native value whenever no result
kind was wanted, such as when it is a call argument. When the branch does not run the condition is the result, so the callee got the value instead of the reference. Passing `$i || 5` for an `int $i` to an ... (6 more lines)
02:04 releasable6 joined, shareable6 joined, evalable6 joined, greppable6 joined, huggable6 joined, bisectable6 joined, sourceable6 joined, linkable6 joined 02:05 quotable6 joined, coverable6 joined, committable6 joined, bloatable6 joined, benchable6 joined
Geth rakudo: ugexe++ created pull request #6689:
Bump NQP to keep the reference a two operand conditional yields		 02:05
02:06 notable6 joined, nativecallable6 joined, tellable6 joined, unicodable6 joined
Geth rakudo/main: 3f7eeeef25 | (Nick Logan)++ (committed using GitHub Web editor) | 2 files
RakuAST: keep a call's references when an assignment to one follows a native read (#6688)

Previously a native value read ahead of an impure argument moved that argument into a temporary of the native kind the argument yields. A native assignment to an `is rw` native parameter yields the reference. The temporary only held its value, so the callee got a plain native where it needed the reference. `f($text, $pos = $pos + 1)` inside a ... (8 more lines)		 02:14
02:18 bisectable6 left, tellable6 left, evalable6 left, greppable6 left, benchable6 left, quotable6 left 02:21 bloatable6 left, coverable6 left, nativecallable6 left, notable6 left, committable6 left, sourceable6 left, huggable6 left, shareable6 left, releasable6 left 02:22 unicodable6 left, linkable6 left 02:23 bloatable6 joined, evalable6 joined, greppable6 joined, benchable6 joined, quotable6 joined, shareable6 joined 02:24 linkable6 joined, nativecallable6 joined 02:25 coverable6 joined, sourceable6 joined, unicodable6 joined, releasable6 joined, bisectable6 joined, committable6 joined, huggable6 joined 02:26 tellable6 joined, notable6 joined
Geth rakudo/main: 67f2e3bcff | (Nick Logan)++ (committed using GitHub Web editor) | tools/templates/NQP_REVISION
Bump NQP to keep the reference a two operand conditional yields (#6689)
 02:46
rakudo: ugexe++ created pull request #6690:
RakuAST: settle argument passing for short circuit operands and at check time		 04:09
04:18 Pixi joined 04:20 Pixi` left 04:41 Pixi left 05:35 kjp joined 05:50 gfldex left 05:51 gfldex joined
lizmat [Coke]: can confirm that all of my modules that were failing in blin because of JSON::Fast, are now ok with JSON::Fast:ver<0.21.0>:auth<zef:timo> 09:22
timo++
ugexe: looks like dependencies on IO::Socket::Async::SSL fail 09:34
RAKUDO_RAKUAST=1 raku -MIO::Socket::Async::SSL -e '' 09:35
===SORRY!=== Error while compiling -M
Missing or wrong version of dependency 'core#sources/72CE4C03920AA05A7835016EDEC049AAB9DCAF7D (CompUnit::Repository::Staging)' (from '/Users/liz/Github/rakudo/install/share/perl6/site/sources/54DA18A673601FAFD8F6161DA647BED3ABCA650F (IO::Socket::Async::SSL)')
at -M:1
09:35 finanalyst joined
lizmat OpenSSL itself does not appear to be affected 09:36
IRC::Client being one of the dependents 09:37
timo have you already tried throwing away the installed version of IO::Socket::Async::SSL and re-installing it? 09:48
is it normal for IO::Socket::Async::SSL to depend directly on CURS?
lizmat uninstalling/installing doesn't fix it 09:57
what do you mean?
timo well, the error says it's trying to load CompUnit::Repository::Staging from the IO::Socket::Async::SSL module's precomputation file? 10:02
lizmat ah... yeah, that's the error, I'd say 10:03
timo but it could be that it's requiring something from in there for reasons of getting at the .so for the SSL stuff? didn't look at the module in question yet 10:04
lizmat this is the full RAKUDO_MODULE_DEBUG output: gist.github.com/lizmat/fe95f8ddf46...2caf2e60c1 10:05
timo "72CE4C03920AA05A7835016EDEC049AAB9DCAF7D" only appears that one time, at the very end. so how best to figure out where it actually comes from? 10:07
if you `moar --dump` the precomp file from IO::Socket::Async::SSL there should be a frame called something like `<dependencies+somethingsomething>` or the other way around 10:08
that's what's causing all dependency compunits to be loaded through the ModuleLoader
lizmat gist.github.com/lizmat/cdce4194c5e...ed5f835642 10:17
10:19 finanalyst left
lizmat so it looks like it substituted IO::Socket::Async::SSL with CURS ? 10:19
in line 42?
timo "substituted"? 10:20
lizmat nah, guess not, the dump of the non-RakuAST bytecode file shows the same 10:21
added the non-rakuAST dump and diff to the gist 10:23
changes at 00035 and 00044 feel relevant ?
timo this is a bit odd. you see, the code there creates an SC from that first ID, the hex string in 39, and gives it a description, that's the one in line 42, then calls `deserialize` on it right? because there's a null as the first argument, it takes the serialized data from the .moarvm file that you were --dump'ing 10:24
in order to see if the wval changes are relevant, we'd have to look at the dependent SCs at the very beginning of the dump output, and it's not so trivial to see what exactly is at an sc idx without running some nqp code for example 10:25
do you know that this .moarvm file is actually the result of precompiling IO::SAS? is that a fresh --target=mbc --output=blah.moarvm or something? 10:27
lizmat non-RakuAST: Sep 16 10:15 RakuAST one: Sep 16 10:40 10:29
so yes, I's say they're recent ?
guess I could nuke them both and see what happens? 10:30
timo can you take a snapshot of some kind of your installation including precomps and such? for later analysis?
actually, not sure if we will ever really look back if nuking and rebuilding fixes things 10:32
lizmat nuking didn't fix 10:35
ok, this is getting weird 10:36
rm -rf install/share/perl6/core/precomp
confirmed it nuked all of the precomps in there
then run: RAKUDO_MODULE_DEBUG=1 RAKUDO_RAKUAST=1 raku -MIO::Socket::Async::SSL -e '' 10:37
aaah..,.. ok
fumbled it
timo the core/precomp stuff, is it fine to be rebuilt just from running a raku command?
lizmat core/site diff 10:38
timo or does it have to be made with install-core-dists.raku?
lizmat it should be
and lo and behold, nuking install/share/perl6/site/precomp fixes the issue
timo OK 10:39
lizmat ok, going to rebuild Rakudo from scratch and try again
ab5tract things like the above are why I always follow nine++'s advice to just rebuild the whole stack from a deepclean 10:46
timo I want to get liz to adopt a workflow with containers but I'm not sure if containers on macos are still "we install a linux vm for you so you can use docker or podman inside of it" which defeats the purpose 10:47
ab5tract it adds a few minutes to each rebuild but eventually it saves some hours of hair pulling
lizmat I do a *lot* of rebuilds 10:48
ab5tract well of course the calculus is up to you
I like pre-paying to avoid the hair pulls
lizmat ok, looks like the nuke fixed IRC::Client's issue
after all this: why is the bytecode of a module containing a reference to CURS in the first place ? 11:00
zef --deps-only should also install test dependencies, should it not ? 11:05
aaahh... --deps-only --/test doesn't install test dependencies 11:09
one needs to add --test-dependencies in that case 11:11
* --test-depends 11:16
so I'm testing all of my modules with a small script that first does: zef install . --deps-only --/test --test-depends 11:18
and then runs the tests (which in my case is the "run-tests" file 11:19
)
it runs them in alphabetical order
so first IRC::Client, then IRC::Client::Plugin::Logger, then IRC::Client::Plugin::Rakkable
::Logger has IRC::Client:ver<4.0.13+>:auth<zef:lizmat> as a dependency (IRC::Client is at 4.0.15) 11:20
::Rakkable has IRC::Client:ver<4.0.15+>:auth<zef:lizmat> as dependency (so 4.0.15+ instead of 4.0.13+) 11:21
it just failed on ::Rakkable, but no longer after a nuke :-( 11:26
timo yeah i think we had an issue like that at some point where we store stuff somewhere based on the defined version required and not the one we end up resolving to? 11:27
so the .13+ and .15+ may get the same module but something mismatches and some issue happens. i think it might have been in debian packaging where we got that issue 11:28
lizmat ok, down to 16 problematic modules 11:31
11:52 Pixi joined
lizmat ok, several community modules are pinned to a :auth<cpan:TIMOTIMO> version of JSON::Fast, will update these now 12:24
one of them being upstream from App::Mi6
timo yeah that's quite out of date :) 12:33
[Coke] lizmat: (confirm) not easily, but will add that to the blin run queue. 13:00
also it sounds like you're in the middle of something? 13:02
lizmat [Coke]: testing all of my modules with RakuAST and 6.e 13:03
down to 13 suspicious ones
with some interesting finds :-) 13:04
[Coke] ok. redoing a regular blin run to a recent HEAD right now, can make another branch to test the 6.e stuff as well when that's done.
lizmat sure... and please ignore any of auth:<zef:lizmat> as I will be looking at them 13:05
he, looks like fez has two useless use cases in Fez::Web (lines 32 and 39) 13:06
[Coke] github.com/coke/raku-blin-release-...ailures.md - latest blin run through ff41340331 13:33
linkable6 (2026-09-15) github.com/rakudo/rakudo/commit/ff41340331 RakuAST: make sure Node.apply-sink accepts :$okifnil
[Coke] 3 failures, one of which is, I think, outstanding
other two bisect to github.com/rakudo/rakudo/commit/63...dcfdb78373 which is weird.
ah, no, that one also does touch Perl6 Grammer, not just Raku
lizmat: ready for another run for 6.e stuff or do you have more cleanup coming? 13:35
lizmat more cleanup coming... I'd say, hold off at least a day at this point 13:36
[Coke] ok.
ls 13:49
ww
lizmat fg 13:50
Geth rakudo/main: 4 commits pushed by (Nick Logan)++ 13:58
rakudo/main: f2d4e8ce08 | (Nick Logan)++ (committed using GitHub Web editor) | 2 files
Quote dependency specification matchers in .raku (#6685)

Previously CompUnit::DependencySpecification.raku wrote its version, auth and api matchers inside `<...>`. A precompiled module stores that text for each of its dependencies and EVALs it when the dependencies need to be resolved again, e.g. when the repository chain changed. So a
  `use Foo:auth('')` came back with no auth at all and printed a "Pair with
... (5 more lines)		 14:05
ugexe those Glib failures actually look like an bug in Glib 14:11
m: say try { EVAL q[class C { method new (: :$a) {self.bless} }; say C.^lookup("new").signature.raku; C.new(:a)] } // "DIED: $!" 14:13
camelia DIED: Can only use : as invocant marker in a signature after the first parameter
[Coke] could be.
I am also doing regular 'apt upgrade's on this box, could be something that got tickled on an upgrade.
ugexe so the method the errors in the Blin output would never have worked if actually called
nah, it is a bug (typo) in those Glib modules 14:14
./install/bin/raku -e 'say try { EVAL q[class C { method new (: :$a) {self.bless} }; say C.^lookup("new").signature.raku; C.new(:a)] } // "DIED: $!"'
DIED: Can only use : as invocant marker in a signature after the first parameter
now we die with that, which is correct. removing the stray : also makes the method callable 14:15
github.com/Xliff/p6-GLib/blob/00f3...s.pm6#L133 14:16
stray :
ab5tract nice catch 14:18
ugexe raku -e 'say try { EVAL q[class C { method new (: :$a) {self.bless} }; say C.^lookup("new").signature.raku; C.new(:a)] } // "DIED: $!"' 14:26
:(:$a:: *%_)
DIED: Too many positionals passed; expected 0 arguments but got 1
sorry the first code snippet i gave used the current blead so didnt show this error (the error Blin currently gives, that shows the call while parsable isn't actually callable) 14:27
but yeah, the fix would need to be in GLib itself
[Coke] the modules, not the c library, aye? 14:30
Can someone help us out and open a ticket for those?
timo we would need to get the module to the community modules org first 14:31
[Coke] Are they abandoned? 14:32
(not everything needs to be a community module).
If we open a ticket on the old repo, I can also start skipping them in blin with a pointer to the ticket.
ugexe the author passed away yeah 14:34
lizmat ah, yeah :-(
lemme see if I can do a quick release 14:35
ah, it depends on Inline::Perl5, so we would need to update that first 14:38
skipping GLib for now 14:39
ugexe why would it need an update? 14:40
lizmat because it won't install with RakuAST / 6.e ?
that was my impression ?
[Tux] Rakudo v2026.08-432-gf2d4e8ce08 (v6.d) on MoarVM 2026.08-9-gebc3f7069
csv-ip5xs0.257 - 0.259
csv-ip5xs-201.114 - 1.126
csv-parser1.137 - 1.159
csv-test-xs-200.115 - 0.117
test1.901 - 1.918
test-t0.488 - 0.492
test-t --race0.299 - 0.310
test-t-206.551 - 6.564
test-t-20 --race1.606 - 1.659
 14:41
csv-test-xs 0.018 - 0.018
ugexe well the error itself happens on legacy as well. but regarding rakuast the inline::perl5 changes to work on rakuast are merged, it just needs a release
tux.nl/Talks/CSV6/speed4-20.html / tux.nl/Talks/CSV6/speed4.html tux.nl/Talks/CSV6/speed.log
lizmat yeah, but only nine can do that 14:42
ab5tract . o ( maybe we have to type nine nine different times to summon him? ) 14:45
which would make nine at least three times as powerful as Candyman (by my count we have hit five mentions so far this afternoon) 14:46
[Coke] m: "\c[DIGIT NINE]" == sqrt("\c[DIGIT NINE]" * "\c[DIGIT NINE]") 14:59
camelia WARNINGS for <tmp>:
Useless use of "==" in expression "\"\\c[DIGIT NINE]\" == sqrt(\"\\c[DIGIT NINE]\" * \"\\c[DIGIT NINE]\")" in sink context (line 1)
[Coke] m: say "\c[DIGIT NINE]" == sqrt("\c[DIGIT NINE]" * "\c[DIGIT NINE]")
camelia True
timo how powerful is nine up-arrow nine? 15:07
[Coke] lizmat: probably doing another 6e/ast run to test the pile of commits from ugexe. 15:45
can do another one tomorrow if you have more changes then. No worries.
lizmat okidoki...
[Coke] just pushed to a rakudo branch... 15:49
geth stuck? 15:50
lizmat kicks Geth 15:51
15:52 Geth__ joined
Geth__ rakudo/f2d4e8ce0-but-ast-6.e: a699894c10 | (Will Coleda)++ | src/main.nqp
Default to AST
 15:52
rakudo/f2d4e8ce0-but-ast-6.e: a2e7f19e50 | (Will Coleda)++ | src/main.nqp
Default to 6.e
15:53 Geth__ left, Geth__ joined 15:55 ChanServ sets mode: +o lizmat, Geth left 15:56 Geth__ left, Geth joined, ChanServ sets mode: -o lizmat
Geth rakudo/worktree-jesp-direct-lazy-records: 233 commits pushed by ab5tract++
review: github.com/rakudo/rakudo/compare/b...f1aa481175		 16:30
rakudo/main: b83057b10c | (Elizabeth Mattijsen)++ | src/Raku/ast/base.rakumod
Revert "RakuAST: make sure Node.apply-sink accepts :$okifnil"

This reverts commit ff413403319a5472eb5d249978e3acac2c36dcc6.
It appears that calling Node.apply-sink with an :$okifnil named argument, is actually a symptom of a deeper codegen issue. So reverting this for now, as it just makes things break at bytecode writing time		 18:18
lizmat ugexe: RakuAST::Utils basically tested a bare RakUAST::Parameter object... apparently that can only live reliably inside a Signature object 18:32
removed the test for using if bare for now, so RakuAST::Utils is not an issue anymore
lizmat updated and/or migrated 12 dists today, and is going to take the rest of the day off :-) 18:34
ugexe maybe a better fix than accepting :okifnul would be for Statement::Expression to reject a non Expression argument when its constructed 19:04
20:58 finanalyst joined
[Coke] c: b83057b10c e.say 21:02
committable6 [Coke], ¦b83057b: «2.718281828459045␤»
ugexe oh hmm, the method already types its argument as Statement::Expression... its just that the ast compiler output for all the stuff under Raku/ast/*.rakumod doesn't actually do any type checking on anything 21:18
Geth rakudo: habere-et-dispertire++ created pull request #6691:
Add slanted equal to operator for comparison		 21:56
22:47 finanalyst left 23:55 lucs left

Powered by Cro and the Raku® Programming Language.

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

Thank you!