[00:10] *** soverysour joined
[00:10] *** soverysour left
[00:10] *** soverysour joined
[00:14] *** lichtkind__ left
[00:17] *** eseyman left
[00:18] *** eseyman joined
[00:31] *** soverysour left
[00:48] *** gabiruh left
[00:48] *** gabiruh joined
[00:58] *** soverysour joined
[00:58] *** soverysour left
[00:58] *** soverysour joined
[00:58] <ugexe> m: my $p = Promise.new; my $then-p = $p.then(sub ($r) { die "error" }); try { $p.keep(42) }; say $!; say "Original: {$p.status}"; say "Then: {$then-p.status}";

[00:58] <evalable6> ugexe, rakudo-moar f1c184644: OUTPUT: «(Any)␤Original: Kept␤Then: Planned␤»

[00:59] <ugexe> m: my $p = Promise.new; my $then-p = $p.then(sub ($r) { die "error" }, :synchronous); try { $p.keep(42) }; say $!; say "Original: {$p.status}"; say "Then: {$then-p.status}";

[00:59] <evalable6> ugexe, rakudo-moar f1c184644: OUTPUT: «Too few positionals passed; expected 1 argument but got 0␤  in sub  at /tmp/hR8tMb0Ugj line 1␤  in block <unit> at /tmp/hR8tMb0Ugj line 1␤␤Original: Kept␤Then: Planned␤»

[01:01] <ugexe> using :synchronous causes that error here: https://github.com/rakudo/rakudo/blob/f1c184644a99113145839a2ee019445ca8f50e18/src/core.c/Promise.rakumod#L184 because it isn't passing 

[01:02] <ugexe> but then other issue is it says Then: Planned which means it will never transition out of that state

[01:03] <ugexe> and another one:

[01:03] <ugexe> m: my $p = Promise.kept(42); my $result = $p.then({ .result + 1 }, :synchronous); say $result.^name; say $result ~~ Promise;

[01:03] <evalable6> ugexe, rakudo-moar f1c184644: OUTPUT: «Int␤False␤»

[01:04] <ugexe> .then(:synchronous) on a already kept promise returns raw value instead of Promise

[01:05] <ugexe> m: my $p = Promise.new; my $result = $p.then({ .result + 1 }, :synchronous); say $result.^name; say $result ~~ Promise; # when using a promise that isnt already kept

[01:05] <evalable6> ugexe, rakudo-moar f1c184644: OUTPUT: «Promise␤True␤»

[01:07] *** soverysour left
[01:08] <ugexe> it seems like .andthen(:synchronous) and .orelse(:synchronous) have teh same issues

[01:29] *** topnep left
[01:30] *** topnep joined
[01:54] *** soverysour joined
[02:00] *** kylese left
[02:00] *** hulk joined
[02:12] *** soverysour left
[02:15] *** hulk left
[02:15] *** kylese joined
[02:29] *** soverysour joined
[02:29] *** soverysour left
[02:29] *** soverysour joined
[02:33] *** soverysour left
[02:45] <Voldenet> ugexe: I remember there's PR for improving these methods https://github.com/rakudo/rakudo/pull/5917 (though I don't think that PLANNED-THEN was changed anyhow there)

[02:46] <Voldenet> in fact, .then(:synchronous) is not documented either – I'm not sure what's it for

[02:49] <Voldenet> .then and similar are kinda forgotten api, I've thought of this improvement too - https://github.com/rakudo/rakudo/issues/5919

[02:54] <Voldenet> either way, .then(…, :synchronous) seems like a very weird way to say `then(…).&await`

[02:56] <Voldenet> but in a way that lets the caller do `if we already have the result, we don't await`

[02:58] <Voldenet> nobody left docs for it so I have no idea what did it originally do

[03:20] <apogee_ntv> https://raku.land/zef:apogee/Template::Jinja2 Going to bed now. :D

[03:34] *** topnep left
[03:36] *** topnep joined
[03:41] *** annamalai joined
[03:46] <ugexe> https://github.com/ugexe/rakudo/commit/6fe163274ad0020a2bd94706e376d2a1486bc764

[03:46] <ugexe> patrickb dunno if those bugs are interesting to you or not

[03:47] <ugexe> maybe :synchronous wasn't meant to be a public api

[04:16] *** Aedil joined
[05:25] <Voldenet> ah, the whole api is the result of deadlocking internals, I'd consider separate method, SYNC-THEN maybe

[05:25] <patrickb> I added :synchronous out of the need to solve a race condition in Lock::Async. I think without a good external use case it should stay an internal feature.

[05:27] <Voldenet> so .andthen and .orelse don't really need :synchronous probably

[05:29] <Voldenet> and this PR can be simplified https://github.com/rakudo/rakudo/pull/5917

[05:31] <Voldenet> (it adds auto-awaiting to `andthen/orelse` -> `if-kept/if-broken`)

[05:33] *** soverysour joined
[05:33] *** soverysour left
[05:33] *** soverysour joined
[05:36] <patrickb> m: my $p = Promise.new; my $then-p = $p.then(sub ($r) { die "error" }); try { $p.keep(42) }; say $!; say "Original: {$p.status}"; say "Then: {$then-p.status}";

[05:36] <evalable6> patrickb, rakudo-moar f1c184644: OUTPUT: «(Any)␤Original: Kept␤Then: Planned␤»

[05:36] <patrickb> why doesn't the then promise trigger?

[05:37] <patrickb> is that expected?

[05:37] *** soverysour left
[05:41] <Voldenet> I think promises are not expected to evaluate in any specific order or on a specific thread

[05:41] <Voldenet> m: my $p = Promise.new; my $then-p = $p.then(sub ($r) { say $*THREAD; die "error" }); try { $p.keep(42) }; say $!; say "Original: {$p.status}"; say $*THREAD; say "Then: {$then-p.status}";'

[05:41] <evalable6> Voldenet, rakudo-moar f1c184644: OUTPUT: «(exit code 1) ===SORRY!=== Error while compilin…»

[05:41] <evalable6> Voldenet, Full output: https://gist.github.com/b6f97b7bb38e601505554e928865a897

[05:41] <Voldenet> m: my $p = Promise.new; my $then-p = $p.then(sub ($r) { say $*THREAD; die "error" }); try { $p.keep(42) }; say $!; say "Original: {$p.status}"; say $*THREAD; say "Then: {$then-p.status}";

[05:41] <evalable6> Voldenet, rakudo-moar f1c184644: OUTPUT: «(Any)␤Original: Kept␤Thread #4 (GeneralWorker)␤Immortal Thread #1 (Initial thread)␤Then: Planned␤»

[05:42] <Voldenet> expecting anything else will introduce subtle bugs

[05:49] <Voldenet> I wouldn't even expect promise being kept synchronously in this case – it seems to be, but it just happens to be implemented that way

[05:52] <Voldenet> so the result could be any of: `(Any)␤Original: Planned␤Then: Planned␤` `(Any)␤Original: Kept␤Then: Planned␤` `(Any)␤Original: Kept␤Then: Broken␤`

[05:55] <Voldenet> oh, and there's no need to `try { $p.keep(42) }` - it should never normally fail

[06:03] <Voldenet> C# has various options in TaskCreationOptions that can influence where, when and in what order the task will be executed – in the past synchronous execution could lead to deadlocks, so RunContinuationsAsynchronously was added

[06:05] <Voldenet> but currently it's hard to force .net core to execute such code on the same thread

[06:10] *** soverysour joined
[06:10] *** soverysour left
[06:10] *** soverysour joined
[06:11] <Voldenet> so I'm suspecting that every sane programmer will reach the same conclusion eventually – it's hard to prevent deadlocks when anything is done synchronously in Promises

[06:15] *** soverysour left
[06:19] *** soverysour joined
[06:19] *** soverysour left
[06:19] *** soverysour joined
[06:26] *** soverysour left
[06:31] *** annamalai left
[06:34] <patrickb> ah, the reason the `then` isn't run is because the program ends before it has a chance to do so. So when the program would continue running, the `then` would eventually be executed?

[06:36] <patrickb> I can dig into the synchronous thing and ponder it a bit. But I'd be grateful for any feedback if that functionality is considered to have any value apart from that internal usage I initially added it for.

[06:42] *** abraxxa joined
[06:47] *** abraxxa left
[06:48] *** abraxxa joined
[06:52] *** sibl joined
[07:03] <Voldenet> oh, I forgot

[07:03] <Voldenet> m: my $*SCHEDULER = CurrentThreadScheduler; my $p = Promise.new; my $then-p = $p.then(sub ($r) { die "error" }); try { $p.keep(42) }; say $!; say "Original: {$p.status}"; say "Then: {$then-p.status}"; # you can enforce this

[07:03] <evalable6> Voldenet, rakudo-moar f1c184644: OUTPUT: «(Any)␤Original: Kept␤Then: Broken␤»

[07:08] <Voldenet> patrickb: I'm not fully sure if simply changing the scheduler wouldn't work here

[07:11] *** abraxxa left
[07:11] <Voldenet> nevermind, it won't work

[07:13] <Voldenet> because scheduler is a property of a promise, so then it'd force the whole protect-or-queue-on-recursion to be synchronous :(

[07:13] *** abraxxa joined
[07:20] *** abraxxa left
[07:21] *** abraxxa joined
[07:25] *** soverysour joined
[07:29] *** abraxxa left
[07:35] *** abraxxa joined
[07:35] *** Sgeo left
[07:40] *** abraxxa left
[07:41] *** abraxxa joined
[07:44] *** soverysour left
[07:45] *** topnep left
[07:46] *** soverysour joined
[07:46] *** topnep joined
[07:54] *** sibl left
[08:16] *** dakkar joined
[08:21] *** annamalai joined
[08:25] *** abraxxa left
[08:28] *** abraxxa joined
[08:35] *** abraxxa left
[08:35] *** abraxxa joined
[09:10] *** soverysour left
[09:25] *** sibl joined
[09:48] *** sibl left
[09:49] *** sibl joined
[09:50] *** topnep left
[09:51] *** topnep joined
[09:55] *** soverysour joined
[09:55] *** soverysour left
[09:55] *** soverysour joined
[10:02] *** sibl left
[11:06] *** abraxxa left
[11:08] *** abraxxa joined
[11:13] *** librasteve_ left
[11:13] *** abraxxa left
[11:15] *** abraxxa joined
[11:21] *** sibl joined
[11:35] *** sibl left
[12:38] *** sibl joined
[13:42] *** soverysour left
[13:46] <[Coke]> ended up following ugexe's suggestion and made https://github.com/coke/task-raku-dev# and updated my local script to install from that.

[13:46] <[Coke]> This should save me tens of seconds! :)

[13:53] <ugexe> patrickb: i think the exception thing would be an issue even for internal use

[13:53] <ugexe> m: my $p = Promise.new; my $then-p = $p.then(sub ($r) { die "error" }, :synchronous); try { $p.keep(42) }; say $!; say "Original: {$p.status}"; say "Then: {$then-p.status}";

[13:53] <evalable6> ugexe, rakudo-moar f1c184644: OUTPUT: «Too few positionals passed; expected 1 argument but got 0␤  in sub  at /tmp/c6r9DhKP_u line 1␤  in block <unit> at /tmp/c6r9DhKP_u line 1␤␤Original: Kept␤Then: Planned␤»

[13:53] <ugexe> the catch handler expects 1 argument here: https://github.com/rakudo/rakudo/blob/f1c184644a99113145839a2ee019445ca8f50e18/src/core.c/Promise.rakumod#L228

[13:54] <ugexe> but we don't pass an argument here: https://github.com/rakudo/rakudo/blob/f1c184644a99113145839a2ee019445ca8f50e18/src/core.c/Promise.rakumod#L184

[14:00] *** topnep left
[14:01] *** topnep joined
[14:32] *** atcroft left
[14:34] *** patrickb left
[14:34] *** greenfork left
[14:34] *** ab5tract left
[14:34] *** skaji__ left
[14:34] *** SmokeMachine left
[14:34] *** nicole left
[14:34] *** zostay left
[14:34] *** thowe left
[14:34] *** tbrowder left
[14:36] *** thowe joined
[14:39] *** sibl left
[15:25] *** patrickb joined
[15:25] *** greenfork joined
[15:25] *** ab5tract joined
[15:25] *** skaji__ joined
[15:25] *** SmokeMachine joined
[15:25] *** nicole joined
[15:25] *** zostay joined
[15:25] *** tbrowder joined
[15:35] *** patrickb left
[15:35] *** greenfork left
[15:35] *** ab5tract left
[15:35] *** skaji__ left
[15:35] *** SmokeMachine left
[15:35] *** nicole left
[15:35] *** zostay left
[15:35] *** tbrowder left
[15:35] *** nicole joined
[15:35] *** greenfork joined
[15:35] *** skaji__ joined
[15:35] *** patrickb joined
[15:35] *** zostay joined
[15:35] *** SmokeMachine joined
[15:35] *** tbrowder joined
[15:35] *** ab5tract joined
[15:38] *** sibl joined
[15:48] *** sibl left
[16:05] *** topnep left
[16:06] *** topnep joined
[16:20] *** erooke_ left
[16:20] *** erooke joined
[16:29] <tonyo> tbrowder++

[16:29] <tonyo> much appreciated, man

[16:35] *** dakkar left
[16:49] <[Coke]> antoncube - LLM::Functions fails its tests on win

[16:51] <[Coke]> once I install all the other stuff, will open a bug.

[17:01] <[Coke]> apparently in my little subset of things I'm installing for zef, I have one requirement for HTTP::Tiny 0.2.5, and one for 0.2.6. :P

[17:01] <[Coke]> s/for/with/

[17:07] <apogee_ntv> https://github.com/Raku/tap-harness6/issues/64

[17:08] <apogee_ntv> Found an issue in TAP that breaks prove6 on escape sequences leaking. This affects mi6 and zef install specifically. Perl5 prove works.

[17:11] *** soverysour joined
[17:11] *** soverysour left
[17:11] *** soverysour joined
[17:12] <timo> is there a TAP spec that rigidly defines what should happen when there's unrecognized stuff of any kind in the TAP stream?

[17:14] <apogee_ntv> Don't know but it breaks any tests that need terminal raw mode and emit escape seqs.

[17:15] *** soverysour left
[17:21] <apogee_ntv> https://github.com/m-doughty/Notcurses-Native - Example (see the t/ and xt/ split and the nasty helper function I had to make to get xt/ to pass at all).

[17:21] <[Coke]> Data::Dump *still* broken on windows, it's been over a year.

[17:22] <[Coke]> tonyo: ^^

[17:22] <[Coke]> added some more details, let me know if there's some other thing I can run to give data.

[17:22] <tonyo> i thought that issue was resolved?

[17:22] <tonyo> i'll take a look but don't have a way to test

[17:24] <[Coke]> the original one might, but the ticket was still open - just tested it again, failed, pasted in the error from this time.

[17:25] <[Coke]> one of the dumps is giving `undefined` instead of `(Nil)`

[17:25] <[Coke]> and, it seems, throwing an exception while it's doing it. (only running 1 test of 3)

[17:25] <tonyo> i'm removing that now

[17:25] <[Coke]> If you want to put diagnostic output in a branch or something, I can run it on windows and give you the output.

[17:25] <tonyo> do you have the repo locally?

[17:25] <[Coke]> yes

[17:25] <tonyo> alright give me a minute and i'll push directly so you can pull

[17:26] <apogee_ntv> https://raku.land/zef:apogee/Notcurses::Native Anyway got this uploaded, it's only low level bindings but if anyone wants to build TUI stuff :D

[17:26] <tonyo> can you run t/08 ? that should have output prior to dying

[17:27] <apogee_ntv> Probably wont work on Windows without a lot of faff, notcurses on Windows is notorious.

[17:27] <[Coke]> commented on issue

[17:31] <tonyo> ahh i see

[17:31] <tonyo> give me a second to rework these

[17:31] <tonyo> tyty

[17:33] <tonyo> what is $*KERNEL.Str on win?

[17:37] <[Coke]> win32

[17:45] <tonyo> can you do a pull and run the tests again?

[17:45] <tonyo> should account for any diff across platforms

[17:46] <[Coke]> main?

[17:48] <[Coke]> may "Dubious, test returned 255", followed by "all x subtests passed"

[17:48] <[Coke]> *many

[17:48] <[Coke]> if I try to run 08 again by hand, I get "Cannot resolve caller min(Any:U: ); none of ...

[17:49] <tonyo> let me see if it's easy for me to get a windows vm so i don't need to keep bugging you

[17:50] <tonyo> sorry about that, kind of assumed the core fix would fix the rest of the issue

[17:50] <[Coke]> I can hook you up with one in azure if you need.

[17:51] <[Coke]> ... but that might be a problem for future me.

[17:51] <[Coke]> I'm going to go take a nap or something. cheers. Thanks for trying to dig in!

[18:13] <tonyo> np, i should have it working shortly.  i think i see what's happening

[18:23] *** annamalai left
[18:23] *** soverysour joined
[18:23] *** soverysour left
[18:23] *** soverysour joined
[18:24] *** annamalai joined
[18:49] <tonyo> m: my $d; say Nil|Any ~~ $d.WHAT

[18:50] <evalable6> tonyo, rakudo-moar f1c184644: OUTPUT: «True␤»

[18:50] <tonyo> on windows: PS C:\Users\tonyo\Documents\dd> raku -e 'my $d;  say Nil|Any ~~ $d.WHAT;' => False

[19:01] <tonyo> [Coke]: when you're feeling fresh again can you pull & give it a go?  not sure what to make of the CORE emissions but it should pass/work

[19:01] <tonyo> and then if that passes for you too then i'll bump v and pub

[19:09] <ugexe> that cannot resolve caller error might be a precomp error

[19:11] <ugexe> ah i guess not. sometimes stale precomp files result in cannot resolve errors which is why i mentioned that

[19:14] *** [Coke] left
[19:25] *** abraxxa1 joined
[20:39] *** soverysour left
[20:41] <patrickb> ugexe: Thanks for the investigation and ping! I'll definitely look into this.

[20:55] *** kylese left
[20:56] *** kylese joined
[21:10] *** [Coke] joined
[21:19] <[Coke]> back online for a bit, going to check...

[21:22] <[Coke]> tonyo: HEAD works now on windows!

[21:23] <[Coke]> ... wait

[21:23] <[Coke]> 'zef test .' worked. 'zef install .' gave me "cannot unbox a type object (Str) to a str"

[21:28] <[Coke]> same issue with 'zef install <git repo url>'

[21:50] <lizmat> tonyo: are we sure that's the same version of Rakudo ?

[22:00] *** abraxxa left
[22:01] *** abraxxa1 left
[22:11] *** soverysour joined
[22:15] *** soverysour left
[22:32] <[Coke]> oh, very likely not. let me upgrade my rakudo

[22:32] <[Coke]> my windows is at 2025.10

[22:35] <[Coke]> now zef test . passes but is very noisy

[22:35] <[Coke]> type Any, type Mu uninit warnings

[22:35] <[Coke]> same warnings on install, but install is successful.

[22:35] <[Coke]> wonder what changed.

[22:48] *** simcop2387 left
[23:06] <[Coke]> does 'zef install --serial' stop after *any* module fails to install? (I've run it a few times and it I think it's got some randomization, and so I've had two different failures running it twice. (I kind of want it to install *everything it can*, even if something fails, if there's another thing that doesn't depend on it, it should install that too)

[23:06] <[Coke]> (this is especially helpful on windows where I'm not sure if a module on my huge list of dev modules will work)

[23:07] <tonyo> i tested on 2026.03

[23:07] <tonyo> [Coke]: you want i should pub as is to at least get you going or should i try to reduce noise first?

[23:10] <tonyo> yeh, same version of raku - behaves differently on windows than on linux for that specific comparison

[23:12] <[Coke]> I'm installed from git at the moment.

[23:13] <[Coke]> If you want to take some time and clean things up, I'm fine with that.

[23:15] *** simcop2387 joined
[23:16] <tonyo> i'll give it a go tonight but it didn't seem easy, i wonder if reversing the check so it doesn't go through the linux check first is as easy as it is

[23:22] <ugexe> [Coke]: --serial makes more sense when zef does not use staging repos because it prevents extra modules from being installed. when zef does use staging repos if a test fails then none of the modules are installed so there isn't really a reason to use --serial

[23:23] <ugexe> but yeah --serial is basically a no-op when installing to a staging repo, i.e. any of the default repos

[23:23] <ugexe> installing *with* a staging repo rather

[23:39] <[Coke]> ugexe: is there an option for my use case here (which I admit is rare) - install everything possible from the deps list, omitting only those that fail tests and have no failing deps?

[23:40] *** Aedil left
[23:40] <[Coke]> (I basically want it to get down to a "here are the modules you want to use that fail on windows" without having to go through one a time.

[23:48] <ugexe> no

[23:54] <ugexe> personally i wouldnt worry much about the "and have no failing deps" part. i'd run something like `zef install Whatever --debug --force-test` and grep for [FAIL] or just feed all the output to an llm and ask it what failed