[Coke] pretty sure I undersized the VM. 00:09
blin depends on Pakku? 01:08
ab5tract Technically it depends on everything:) 01:13
But I forget how tied it is to Pakku 01:14
[Coke] ===SORRY!=== Error while compiling /home/azureuser/Blin/site#sources/EDD4D63DD8EE273BF634E5332B98B365B8455AD4 (Whateverable)
Merging GLOBAL symbols failed: duplicate definition of symbol SSL
ab5tract Yeah, it does need Pakku 01:15
It looks like I had to do some wrangling github.com/ab5tract/whateverable 01:17
Maybe try using that repo instead
[Coke] Thanks. 01:19
same error installing your version 01:28
bug on IRC::Client suggests installing an older version of that to avoid the problem, but then I get a different error installing Whateverable. 01:35
will pick this up again tomorrow 01:38
02:29 ilogger2 left 02:55 ilogger2 joined
nine CI threw an error on that PR: 06:48
MoarVM panic: Internal error: zeroed target thread ID in work pass
t/02-rakudo/12-proto-arity-count.t
[Tux] Rakudo v2024.08-9-g23da1ce11 (v6.d) on MoarVM 2024.08-6-gac82e446f
csv-ip5xs0.263 - 0.265
csv-ip5xs-201.144 - 1.162
csv-parser1.488 - 1.522
csv-test-xs-200.141 - 0.142
test1.803 - 1.843
test-t0.402 - 0.410
test-t --race0.260 - 0.264
test-t-204.819 - 4.869
test-t-20 --race1.182 - 1.252
 06:53
tux.nl/Talks/CSV6/speed4-20.html / tux.nl/Talks/CSV6/speed4.html tux.nl/Talks/CSV6/speed.log
08:11 finanalyst joined 09:29 finanalyst left 10:38 sena_kun joined
Geth ¦ problem-solving: ab5tract assigned to samcv Issue `uniprop` and friends are buggy, inconsistent, and potentially replaceable github.com/Raku/problem-solving/issues/437 11:30
ab5tract that's been cooking for a *long* time :) 11:31
samcv appears to be auto assigned for unicode issues 11:40
nine This is odd. A @a = do loop { last; } basically compiles to Seq.from-loop(-> { last }, -> { 1 }). What's odd about that is that it could just be Seq.from-loop(-> { last }) which would create a lazy Seq. For some reason, we don't use that. 12:22
m: my @arr = do loop { state $x = 0; last if ++$x > 2; $x }; say @arr
camelia [1 2]
nine BUT:
m: my @arr = do while True { state $x = 0; last if ++$x > 2; $x }; say @arr
camelia [...]
ab5tract oh, that is strange indeed 12:24
I wonder which of these is the oversight 12:25
Geth rakudo/main: 65c318f091 | (Stefan Seifert)++ | 2 files
RakuAST: avoid compile time type checks involving subsets

The where clause on a subset can have side-effects. Thus we must not run this code at compile time if we can avoid it.
Fixes: subset A of Int where { $_ < state $x++ }; my A $y = -1; $y = 0		 12:35
rakudo/main: 9ffadf8027 | (Stefan Seifert)++ | src/Raku/ast/variable-declaration.rakumod
RakuAST: properly support state scope on signature declarations

Fixes: state (@a) = (1, 2); # to only initialize on first run
rakudo/main: 7c3b2b181c | (Stefan Seifert)++ | src/Raku/ast/statements.rakumod
RakuAST: first bits of lazy loop implementation

Fixes: my @a = do loop { last; };
nine ab5tract: all RakuAST tests fail on latest main due to: Cannot resolve caller splice(Array:D: Int:D, Int:D); none of these signatures matches: 13:01
... 13:02
(Array:D $:: Int:D $offset, Int:D $size, **@new, *%_ --> Array:D)
Reverting c2c8d7a01362e21e9ae71a5e962d5003472f89c0 fixes the problem 13:04
linkable6 (2024-08-24) github.com/rakudo/rakudo/commit/c2c8d7a013 [6.e] Provide `is revision-gated("6.x")` trait
ab5tract weird, I didn't see any test failures locally 13:06
nine Did you test with RAKUDO_RAKUAST=1? 13:07
ab5tract do you mean the tests in t/12-rakuast
nine No, spectests
ab5tract interesting.. I thought I had done it with and without 13:09
let me see
when you say "all", are you saying literally 0/1352 spectests? 13:10
nine As far as I can tell. I didn't wait for the run to complete as it takes ages since it's trying to compile Test.rakumod for about every test 13:11
ab5tract i see...
damn.. clearly I didn't run the test suite with RAKUDO_RAKUAST=1 after all :( 13:13
nine Sounds like you can repro :) 13:14
ab5tract yeah.. I would never have merged if I say only 21 files in t/ are passing in RakuAST 13:15
*saw
give me a bit, if I can fix it in a reasonable amount of time we can roll forward 13:20
otherwise we'll revert
nine k 13:22
ab5tract from a first glance and guess, I think the issue is related to fetching $?LANGUAGE-REVISION via getlexcaller 13:28
`say("LANGUAGE REVISION: " ~ nqp::getlexcaller('$?LANGUAGE-REVISION') // "NOOOO");`
lang-call cannot invoke object of type 'VMNull' belonging to no language
nine I guess we do catch that exception somewhere and then treat it as a dispatch failure instead of an implementation error? 13:29
ab5tract yeah, I *think* that's what we are seeing 13:30
or else nqp::getlexcaller is not throwing an exception within dispatchers.nqp (there is a lexcaller, after all) 13:33
but it goes to to the `no candidates` path because `(my $caller-revision := nqp::getlexcaller('$?LANGUAGE-REVISION'))` isn't truthy
easy enough to check this out 13:34
yeah, that's it 13:37
this fixes it: `(my $caller-revision := nqp::getlexcaller('$?LANGUAGE-REVISION') // 1)`
so, while RakuAST sets $?LANGUAGE-REVISION for the QAST it outputs, it's not setup for its own scope, if that makes sense 13:38
nine Yes, it's not set in the Compiler's BOOTSTRAP which is NQP after all. So maybe an alternative fix would be to declare it there? 13:40
ab5tract Yeah that would make sense. Is there a BOOTSTRAP specifically for the RakuAST compiler? Because I do set it in compunit-y section of bootstrap.c/BOOTSTRAP.NQP 13:43
ahh, no! that was in World 13:44
to be clear, I wasn't suggesting the defined-or approach as a genuine fix, but just a fix that proved the theory I proposed 13:51
nine: any tips for how to define it, exactly? `[my|our] $?LANGUAGE-REVISION := 1` in BOOTSTRAP.nqp doesn't appear to do the thing 14:00
nine Looking at gen/moar/BOOTSTRAP/v6c.nqp that actually should do the trick. 14:06
ab5tract trying the nqp::bindlex approach now 14:11
in case it's somehow related to the '?' twigil 14:13
oh.. that only works when the lexical already exists :S 14:14
the BOOTSTRAP files cascade, right? 14:18
or am I screwing up by editing bootstrap.c instead of bootsrap.e? FWIW, I also tried the same in `rakuast-prologue.rakumod` 14:20
nine Nah, it's something else. When I add it to RakuAST::CompUnit's check method, it'll work again 14:22
Oh, that's because the RakuAST setup code is run in a BEGIN block! 14:24
(probably) 14:25
ab5tract ah! 14:26
I guess it's also an open question whether nqp::getcomp('Raku').language_version is (or should be) set at this point 14:27
14:28 dawids_ joined, dawids_ left
nine No that's not a thing in this context 14:29
Ok, it's not the BEGIN thing either. Even declaring it in src/Raku/ast/rakuast-prologue.nqp does not help
gist.github.com/niner/ef48bf732bb1...36ec1f5653 is the only working patch so far 14:31
ab5tract interestingly, this patch also works despite leaning on nqp::getcomp: gist.github.com/ab5tract/86782bc95...5b6d8f45dd 14:34
yours feels cleaner but thought it might still be worth sharing 14:35
nine The source of the problem is that in this case the caller is not Raku code at all, but really NQP code. 14:38
So I wonder whether nqp::getlexcaller('$?LANGUAGE-REVISION') // 1 would actually be the correct solution here.
Know what? I'd really commit that and get on with life :) After all, the implicit assumption here is that the caller is Raku code, which clearly is not always true. 14:43
ab5tract Well, RakuAST implementation code is definitely a pretty unique-inbetween 14:46
doing the test rounds just to be sure (though were there recent problems introduced by the MoarVM bump?) 14:50
I've got 142/1143 14:53
nine sounds close enough ;) 14:58
Geth rakudo/main: 6fa7c425cb | ab5tract++ | src/vm/moar/dispatchers.nqp
Fix the new revision-gated dispatch logic for the RakuAST compiler

Without this, almost all tests fail when RAKUDO_RAKUAST=1.
A few different approaches were attempted to ensure that
  `$?LANGUAGE-REVISION` would be installed in the lexical scope
that is accessed by `nqp::getlexcaller(...)` in `dispatchers.nqp` ... (7 more lines)		 15:09
[Coke] is jdv the only person with a successful Blin install? 15:25
15:25 finanalyst joined
[Coke] s/install/setup/ 15:26
ab5tract [Coke]: those repos I linked to worked for me 15:28
[Coke] ok. I'm still getting the global error 15:34
Geth rakudo/main: 1081b051d0 | (Stefan Seifert)++ | src/Raku/ast/code.rakumod
RakuAST: fix compilation error on CompUnit phasers
rakudo/main: c612b32b0f | (Stefan Seifert)++ | 2 files
RakuAST: ensure INIT phasers run before compunit's ENTER phasers

Fixes: INIT say "INIT"; ENTER say "ENTER';
nine 1147
ab5tract [Coke]: global error = the SSL one?
nine++ 15:35
[Coke] github.com/lizmat/IRC-Client/blob/...10C1-L11C1 - why this very specific version?
ab5tract: yes
(I end up having to have two copies of it installed)
(and am wondering if that might be impacting the global SSL error) 15:36
ab5tract yeah, I don't understand how jdv does this consistently 15:38
I just got this error for `podman build -t rakudo-blin .`
`/bin/sh: 1: cannot create /etc/ssh/ssh_config: Directory nonexistent`
the amount of Whateverable that is actually necessary for Blin has very little overlap with all the IRC-oriented hoopla, IIRC 15:40
[Coke] ok, going down the rabbit hole of golfing the symbol merge error (happens just loading xt/lib/Testable.pm6 in Whateverable. 15:41
ab5tract Maybe I'm just getting too old for this, but the amount of bitrot here is just to damn high 15:42
*too
[Coke]: I would recommend that you set a reasonable cutoff threshold for $smoldering-rage 15:44
because there has got to be an easier way to do what we actually want to do (check a revision (merged or not) against @known-modules) 15:46
[Coke] Here's a minimal golf that you can run inside a whateverable checkout:
ab5tract that doesn't involve method that don't even know whether they are being called by IRC bots or now (github.com/Raku/whateverable/commi...1c33a9fad) 15:47
[Coke] raku -I. -e 'use IRC::Client; use Whateverable::Builds'
That triggers the merge error.
ab5tract it's so irrelevant to the intended use case that I might cry if I stare too long
nine ab5tract: of course there is
It's news.perlfoundation.org/post/grant...ration_bot 15:48
ab5tract but then again, I'm already near enough to tears given that jnthn(++) hsa left us with a comma build plan that requires Windows
nine Jesus 15:49
ab5tract I might even ask an LLM about how to interpret this .cmd file (at least call it a .bat, so I know how screwed I am!) 15:51
I guess if an automated translation doesn't Just Work, I'm out a few pnenies and nothing's the worse for it.
nine: it's even pretty cute, in the end. The instructions are: `./comma-build/complete-plugin.cmd -Dintellij.build.use.compiled.classes=false -Dintellij.build.target.os=linux` 15:53
oh, and bash registers no problem when interpreting the .cmd file 15:54
16:01 sena_kun left
[Coke] ab5tract: narrowd it down to a completely different module (several times): github.com/Raku/whateverable/issues/386 16:17
it's now failing with raku -I. -e 'use IRC::Client; use IO::Socket::Async::SSL'
but then I don't get the same error debugging in that module. 16:18
... and that class is defined twice in that module. :P 16:19
ab5tract 🙃
[Coke] OOPS 16:21
no, the other definition is my copy. Curses. Ok, still digging (but also opening a ticket in that module with what I have.) 16:22
github.com/jnthn/p6-io-socket-asyn.../issues/77 with less info than I'd hoped. 16:26
Geth rakudo/main: 59257a4b10 | (Stefan Seifert)++ | 2 files
RakuAST: fix silent removal of colonpairs from indirect lookups

Fixes: &CORE::infix:<orelse>		 16:47
roast: 0a62ade253 | (Stefan Seifert)++ | S04-exceptions/fail.t
Fix unexpected error in Failure test

The 1 in sink context in the unless block would ordinarily cause a warning (if the compiler is smart enough) but the test also fatalizes and thus turn it into an error that will make the test fail despite the Failure the test is about being defused correctly.		 17:31
roast: 8c0edcb2d4 | (Stefan Seifert)++ | S04-phasers/begin.t
Skip previously todo'ed test about binding at BEGIN time

Binding at BEGIN time to variables declared outside the BEGIN block has never worked. It was just treated as a no-op. Thus we could get by with todo'ing the test. However this may not be true for all compilers, so skip it to avoid compilation errors.
rakudo/main: 7857b8021a | (Stefan Seifert)++ | src/Raku/ast/scoping.rakumod
RakuAST: fix accidental de-containerization of external constants

Fixes: my $x = 1; EVAL Q[BEGIN { $x = 2" }];		 17:35
nine Nice! This one fixes 5 spectest files all at once.
We're at 1153 now.
[Coke] neat. 17:38
lizmat which brings us to 85_+% 17:41
nine indeed :) 17:42
ab5tract are we ready to try actually compiling CORE.setting? 17:43
lizmat that was my thought as well...
ab5tract so who's gonna remove the nqp::die and give it a go? :D 17:51
ab5tract goes to make dinner
nine I already tried that a few days ago. Then decided that it's an unneccessary distraction for now. There's certainly some work to be done there. 17:56
I fear, the move to using AT-POS to access implicit lookups for example was a bit premature. That method doesn't exist when we start compiling the setting. 17:57
[Coke] github.com/jnthn/p6-io-socket-asyn.../issues/77 - should this work without error? 17:58
we have two different versions of IO::Socket::Async::SSL in the Whateverable toolchain (because IRC::Client hardcodes a specific version), and that's what causes the duplicate symbol.
The workaround for now is probably: remove the hardcoded version in IRC::Client and cut a new version. 17:59
but whether or not this should work is probably a question for this channel and not jnthn on IO::Socket::Async::SSL
yay, now i can go watch youtube videos. :) 18:00
ab5tract :) 18:04
Geth rakudo/main: ed5c906c91 | (Stefan Seifert)++ | 2 files
RakuAST: fix result of ENTER phasers not found in thunks.

ENTER's result has to be lexical. Otherwise it won't be found in nested blocks.
Fixes: LEAVE say now - ENTER now;		 18:05
nine 1154
ab5tract \o/
lizmat nine: re AT-POS: just use postcircumfix:<[ ]> instead? 18:07
nine Won't be defined at the start of the setting either 18:09
lizmat so: reduces to NQP array and use nqp::atpos then 18:10
s/// 18:12
s/s// :-)
nine That's what we did do before commit 2caaf9f4d7011b1266f8e1f412b7ffc54f44ec56 18:14
linkable6 (2023-08-16) github.com/rakudo/rakudo/commit/2caaf9f4d7 RakuAST: some more resolver streamlining
lizmat ack... will revert that then (manually)
nine Err.. commit 38254c49413af8e4838c6d348d3ffbd14723de5b 18:15
linkable6 (2023-04-06) github.com/rakudo/rakudo/commit/38254c4941 RakuAST: streamline lookups
nine Well, let's cross that bridge when we get there
lizmat I got the impression we're there now? 18:16
nine 85 % is not 100?
m: my @a = []; for ^10 { POST @a.push($_); 42 }; is @a, [42, 42, 42, 42, 42, 42, 42, 42, 42, 42], 'POST should not see outer $_'; 18:17
camelia ===SORRY!=== Error while compiling <tmp>
Undeclared routine:
is used at line 1
nine m: use Test; my @a = []; for ^10 { POST @a.push($_); 42 }; is @a, [42, 42, 42, 42, 42, 42, 42, 42, 42, 42], 'POST should not see outer $_';
camelia WARNINGS for <tmp>:
Useless use of constant integer 42 in sink context (line 1)
ok 1 - POST should not see outer $_
lizmat no, but being able to build the setting...
nine Is it me or does this test test the opposite of what the description says? Looks to me like it wants to access the outer $_ there?
Well, I guess that depends on what "outer" refers to exactly.
lizmat I'd say it's seeing the inner, from the for loop? 18:18
nine But isn't the for loop the outer one from the POST phaser thunk's perspective? 18:19
lizmat no, because a thunk does't have its ow scope ? 18:21
aah.... but POST is supposed to get the return value in $_, so yes, outer $_ would be the $_ of the loop 18:22
18:29 finanalyst left
lizmat [Coke]: I've just released a new IRC::Client 18:38
nine m: my @a = do loop { FIRST say "first"; LAST say "last"; last; } 19:09
camelia last
first
nine m: my @a = do loop { LAST say "last"; last; }
camelia last
No such method '!capture_phasers' for invocant of type 'Code'
in block <unit> at <tmp> line 1
nine whoooops
m: loop { FIRST say "first"; LAST say "last"; last; } 19:23
camelia first
last
nine but:
m: my @a = do loop { FIRST say "first"; LAST say "last"; last; }
camelia last
first
nine The last will be the first I guess :)
Geth rakudo/main: 1fda647fcb | (Stefan Seifert)++ | src/Raku/ast/code.rakumod
RakuAST: keep block result if there's a POST phaser

A POST phaser gets the block's result as argument, so we must not sink the last statement of that block.
Fixes: { POST say $_; 69 }		 19:29
rakudo/main: 0c9a00ada0 | (Stefan Seifert)++ | src/Raku/ast/statements.rakumod
RakuAST: actually run LAST phasers in (non-for) loops

Fixes loop { LAST say "last"; last }
nine And that's 1155 which means that there are only 200 spectest files left :)
[Coke] lizmat++
ugexe last firing before first like that seems like a foot gun. i'm sort of feel like i need to double check any of my usage of those now :( 19:31
[Coke] ok, also have to fix Whateverable to not pin the old version of IRC::Client. 19:36
(which ab5tract removed from their version)
At some point, I'm going to have to write up a "get Blin setup" script that does all the rakudo/zef/module installs/apt installs, etc. 19:38
jdv only 200?
[Coke] All Blin deps now safely installed on the azure box.
ab5tract jdv: how do you manage with blin? From the outside it seems really broken, even after just a few months since I had it running 19:40
[Coke] ab5tract: how old is your fork of Whateverable?
ab5tract I’m guessing April at the latest, but let me check the commits 19:41
4/28/24 19:42
[Coke] gist.github.com/coke/b22633c236dc6...d4e9ceb23b - error in ensure-config 19:43
(part of Whateverable::Config, I'm using your version) 19:44
ab5tract Hmm
Can you try it with a specific commit instead? 19:45
[Coke] of your whateverable, or the old/new ?
ab5tract Sorry, I meant as an argument 19:46
[Coke] time RAKULIB=lib bin/blin.p6 --new=bd85145ee IRC::Client same error
ab5tract The major addition of my branch to whateverable / blin is the ability to check a single commit 19:47
That’s not the argument. One second
#| Single revision (overrides --old and --new) 19:49
Str :single($single-revision) is copy,
only relevant if you are using my blin as well as whateverable
the whole thing is complicated by the fact that those branches also have fixes for arm64 :( 19:52
[Coke] ok, i'm on x64 here in azure.
ab5tract the arm64 changes are entirely Dockerfile related 19:53
jdv the same way i deal with most of life i don't enjoy. i keep it arms left so to speak:) 19:54
ab5tract jdv: how does that work though? are you able to just spin up the same docker image month after month?
jdv it generally works and i dont mess with it unless i need to.
yes
*length 19:55
sorry, on my boat half asleep. good luck and soldier on! 19:56
afk &
ab5tract sleep well upon the waves my friend
jdv be well
ab5tract all's well that blin's well ;) 19:57
[Coke] getting the same error with mainline Whateverable (which I was finally able to install after a local fix to github.com/Raku/whateverable/issues/390 20:03
github.com/Raku/whateverable/issues/391 - not sure if this is blin or whateverable's fault 20:05
... or mine
ab5tract `- sub latest-repo($project = $*PROJECT) { “$*TMPDIR/whateverable/{$project}-repo”.IO }` 20:13
`+ sub latest-repo($project = $*PROJECT) { $CONFIG<projects>{$project}<repo-path>.IO }`
lib/Whateverable/Building.pm6
pretty sure that's the patch that solves that 20:14
my fault for not getting these fixes merged back upstream
but equally my fault for not bothering to replace the 1% of Whateverable that is required for this job with a new module 20:15
20:26 finanalyst joined
[Coke] ab5tract: doesn't seem to change anything 20:31
ab5tract boo
I honestly don't know at this point
apparently this is an entire grant's worth of work 20:32
20:33 AlexDaniel joined
AlexDaniel [Coke]: it's just checking your config file and failing to find something in it 20:38
github.com/Raku/whateverable/blob/...ig.pm6#L61
[Coke]: what do you have in <projects> ? 20:39
it seems that this is out of date maybe? github.com/Raku/Blin/blob/master/c...fault.json
[Coke]: here's the up-to-date config: github.com/Raku/whateverable/blob/...fault.json 20:41
I guess I did some work on whateverable and didn't update blin accordingly, my fault
it's just the “projects” part that's different, try changing it to the one that's in whateverable and see if it works 20:43
[Coke]: as for writing a script that does the setup, did you know that whateverable bots are running as docker swarm services? The entire recipe for the setup is here: github.com/Raku/whateverable/blob/...Dockerfile 20:51
I see no reason why the same cannot be done for Blin. Then just run Blin in docker, no need for setting anything up 20:53
I might as well do that tomorrow if I have time… but currently dealing with some annoying Caddy issue and I'm about to pull the remaining hair out 20:54
[Coke] ok, that updated file gets me a new error, cool. :) 21:15
gist.github.com/coke/a2a88ff7a6d2e...711b41c08b 21:16
21:16 librasteve_ joined
AlexDaniel [Coke]: do you have `git` installed? :) 21:17
in general you need: zstd lrzip libssl-dev build-essential (based on the Dockerfile above) 21:18
in the future whateverable will not need lrzip, and hopefully zstd will be included one way or another :) 21:19
I think new long-term storage builds are already created with zstd only 21:20
(zstd will be included in the distros I mean, for example as part of build-essential)
[Coke] yes, git is installed.
those packages all installed with apt-get 21:21
AlexDaniel [Coke]: alright, but you're on that line: github.com/Raku/whateverable/blob/...ds.pm6#L48 21:22
ah wait, that code doesn't make any sense, does it? 21:23
[Coke] Blin/data/moarvm exists and is github.com/MoarVM/MoarVM.git
AlexDaniel it's meant to be `$CONFIG<projects><rakudo-moar><repo-path>`
it's trying to cwd into the url D: 21:24
[Coke] trying local patch.. 21:26
muuuuch better 21:29
finally appear to be running Blin on the azure box. 21:30
Geth whateverable/main: 2104e7f0e2 | (Aleks-Daniel Jakimenko-Aleksejev)++ | lib/Whateverable/Builds.pm6
Fix `:cwd` thinko from months ago

I'm not entirely sure how this is working in the currently running bots, but this is definitely causing issues in Blin. Basically, when the directory structure was changed, I changed these lines incorrectly. As the result, when running this sub, it was trying to `:cwd` into the URL of the repo (which is obviously wrong).		 21:32
AlexDaniel ah, config structure, not directory structure, but you get the point :)
if everything is still cool it should restart/redeploy all bots… let's see
[Coke]: can you commit the config update to Blin too? 21:33
[Coke] AlexDaniel: just opened #392 which I think you just closed. 21:34
er, *fixed*, and can close.
I can just push the new config file I have if you like.
also #390 is a simple "fix" but I have no idea if it's the right one. I can push that too if you like. 21:35
er, I can't, can I? I'm not sure I have privs
21:35 coverable6 left, quotable6 left, benchable6 left, greppable6 left, tellable6 left, sourceable6 left, releasable6 left, evalable6__ left, bisectable6__ left, notable6 left, nativecallable6 left, shareable6 left, linkable6 left, committable6 left, bloatable6 left, unicodable6 left
AlexDaniel [Coke]: how come? 206 people can write to whateverable. Not sure about Blin, I don't have admin access there to see 21:36
[Coke] oh, right, that was Blin, not Wh. 21:37
21:38 committable6 joined
AlexDaniel [Coke]: push the fix please, we'll see what happens. Webhooks are used in various places (even for building rakudo/moarvm), but there's a timer fallback so it will not break anything 21:38
21:38 nativecallable6 joined, greppable6 joined, coverable6 joined 21:39 shareable6 joined, notable6 joined, releasable6 joined, linkable6 joined
AlexDaniel the bots are running on rakudo star 2023.02, so maybe they're not even affected by things like that. 21:39
21:39 bisectable6 joined
AlexDaniel e: say 42 21:39
21:39 evalable6 joined, quotable6 joined, sourceable6 joined
AlexDaniel e: say 42 21:40
evalable6 42
21:40 benchable6 joined, bloatable6 joined, unicodable6 joined, tellable6 joined
[Coke] (not trivial because I checked everything out with https assuming readonly. one moment.) 21:40
AlexDaniel btw guys you can actually comment out the bots that you don't need here: github.com/Raku/whateverable/blob/...mpose.yaml I'm pretty sure people haven't used some of the bots for a while :) 21:43
[Coke] Do Blin and Whateverable *both* have a config-default.json? 21:44
I think this was also part of my confusion. :) 21:45
Geth Blin: 9b7a0744be | (Will Coleda)++ | config-default.json
Pull some updated settings

from raw.githubusercontent.com/Raku/wha...fault.json
  (avoiding those that are outside the scope of what Blin needs)		 21:49
AlexDaniel pretty sure that all updates below "sandbox-path" were not needed :) 21:51
[Coke]: yeah, Blin doesn't need all these values for running the bots, just some values for running itself 21:52
[Coke] AlexDaniel: ok. 21:53
testing (it needs some of it, will remove what i can) 21:56
22:01 finanalyst left
AlexDaniel [Coke]: Also I just realized that there's this: github.com/Raku/Blin/tree/master/d...cker-image 22:02
Geth Blin: 1562d7ce1f | (Will Coleda)++ | config-default.json
Remove un-needed Whateverable boilerplate

  AlexDaniel++
[Coke] docker has never worked for me on mac m2, so I was just trying to run out of the repo 22:04
er, *Blin on docker has...*
which now it seems to be doing.
(running out of repo, with the fixes and workarounds from today.) 22:05
anyone know why I get dozens of
🥞🥞 Module Test::Async is ignored because it causes havoc
Looks like locks not getting freed. Run once - fine. Run again, get: 22:06
/tmp/whateverable/rakudo-moar/e390ae09e880c3d9a38373fed883bfaacc8e63ab is locked. Waiting…
ab5tract: so NOW I can think about "can we test a specific revision and not just tags (looks like I can't do time RAKULIB=lib bin/blin.p6 --new=361cf2310 App::SudokuHelper right now 22:12
(up to 49¢ usage so far in August (pretty sure it's a day lagged) 22:17
AlexDaniel: one of those config removals killed the ability to fetch non-fetched builds. 22:21
so anything after that worked but complained about the endpoints. 22:22
"worked"
Geth Blin: 371c3fef86 | (Will Coleda)++ | config-default.json
Restore latest config

Removed too much config, missing part that allowed downloads of not-previously downloaded rakudo versions		 22:27
22:37 sena_kun joined 22:54 sena_kun left
AlexDaniel Hmm, yeah, that "mothership" line was definitely needed 23:06
everything else, not so much :) 23:07
23:46 AlexDaniel left 23:52 AlexDaniel joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!