[Coke] regarding Blin - what do folks think of having a "known bad" list of modules? (There are currently a large percentage where we test the new one, it fails, then we test the old one to see if the failure is new). We could save a bunch of processing time if we instead tested only new, saw it was already failing, and then reported "StilLFailing" etc. 00:28
Depending on how old these failures are/how unresponsive the author is, maybe we just stop testing them even on new.
(github.com/Raku/ecosystem-unbitrot/issues has 210 open issues that are at least as old as 2019, as a place to start looking for unfixed issues) 00:30
.ask AlexDaniel Question on raku/ecosystem-unbitrot - says tickets are closed automatically, how? Why a GPL license? 00:32
tellable6 [Coke], I'll pass your message to AlexDaniel
timo [Coke]: have you already looked at the scripts in the repo? 00:34
could someone `wget moarvm.org/releases/MoarVM-2024.08...gz{,.asc}; gpg --recv-keys 59E634736AFDCF9C6DBAC382602D51EACA887C01; gpg --verify MoarVM-2024.08.tar.gz{.asc,}` and tell me if it gives a "BAD" signature? 00:43
with 07 it works fine tho 00:47
MasterDuke `gpg: Can't check signature: No public key` 01:04
timo did you receive a key from the --recv-keys command? 01:07
i *think* i successfully received a key from the keyservers there, or maybe it didn't even look at the keyservers because i gpg --import'ed it from a file before? 01:14
`wget -O moarvm_signing_key.asc salsa.debian.org/perl6-team/moarvm...ine=false; gpg --import < moarvm_signing_key.asc` 01:16
MasterDuke `Good signature from "Justin DeVuyst <justin@devuyst.com>" [unknown]` 01:18
timo huh? what am i doing wrong then?
`sha1sum moarvm.org/releases/MoarVM-2024.08...gz{,.asc}` please?
i have ba7857eb1937384ec2075a6e08c7487701b0bf47 and cca8a9f07c88200d4f9d26a2c8590e958c23ba69 01:19
MasterDuke oh wait, those were 07 01:27
a4bf190c96a78ca7c6863d5f6c5a8aeabf852a2b  MoarVM-2024.08.tar.gz 01:28
Good signature from "Justin DeVuyst <justin@devuyst.com>" [unknown]
cca8a9f07c88200d4f9d26a2c8590e958c23ba69  MoarVM-2024.08.tar.gz.asc 01:29
timo oh thank goodness so my tarball was just b0rked during transfer somehow 01:30
yeah i just had to retry ok that's good 01:32
06:21 kjp left 06:22 kjp joined 06:24 kjp left, kjp joined 08:13 sena_kun joined
Geth ¦ problem-solving: lizmat unassigned from samcv Issue `uniprop` and friends are buggy, inconsistent, and potentially replaceable github.com/Raku/problem-solving/issues/437 11:38
13:33 vrurg_ left, vrurg joined 13:34 vrurg_ joined, vrurg left 13:36 vrurg joined 13:39 vrurg_ left 13:46 vrurg left 13:48 vrurg joined 14:10 vrurg_ joined 14:13 vrurg left 14:18 vrurg joined 14:22 vrurg_ left 14:24 vrurg_ joined 14:28 vrurg left 14:37 vrurg_ left, vrurg joined
[Coke] Blin - no regresssions on the run, but several failures-that-shouldn't-be. they failed old and new, so they don't show as a problem. 14:43
uploaded the raw output files here: gist.github.com/coke/239e6906a0a31...8bcf6666c4
didn't get an .md file output presumably because we're "clean" 14:45
nine What does dba mean in grammars? 14:51
lizmat doing business as
nine Ok...what does that mean? :D 14:52
lizmat i think it's meant as an indicator of some general function being used for a particular case?
it's basically an annotation 14:54
Geth rakudo/main: 60dbc2016e | (Elizabeth Mattijsen)++ | 2 files
Micro-opt for non-existing keys in hash

By using a native string, the bytecode size of !AT_KEY_CONTAINER is reduced from 320 to 260, allowing for better inlining
14:56
[Coke] ugexe: in Blin, every time we start, we do a 'zef update', but I'm getting "Must specify a non-empty string as a path" 15:03
(Looks like we're starting with the config file shown in 'zef --help', then updating it to change "RootDir", "TempDir", and "StoreDir" (but the original doesn't have a RootDir) 15:08
ugexe github.com/ugexe/zef/commit/8cf40e...6f3c41af40 15:19
[Coke] ah, blin just not keeping up.
ugexe RootDir was removed some time ago, but not sure why you'd see that error
Geth Blin: 6312a557e5 | (Will Coleda)++ | lib/Blin/Tester/Zef.rakumod
Remove RootDir -

Removed from zef in github.com/ugexe/zef/commit/8cf40e...6f3c41af40
15:20
[Coke] also shutting off the auto-update on all the repo types. 15:21
15:53 vrurg_ joined
Geth rakudo/main: dd66162a40 | (Elizabeth Mattijsen)++ | src/core.c/hash_slice.rakumod
Micro-opt for %h<a>:exists

Reduces the bytecode size of postcircumfix:<{ }>(:$exists!) from 216 to 92 bytes, allowing for easier inlining
15:53
15:55 vrurg left 15:59 vrurg_ left
lizmat meh: just found out that using "given" in a sub, will prevent it from being inlined 16:17
m: sub a($a) { 42 given $a }; a(666) for ^100000
camelia ( no output )
lizmat a BB(2, 196 bytes) -> BB(3):
target has a :noinline instruction - ins: takeclosure
timo oh, that seems optimize-away-able unless we require it for the way we make $_ "mean something else" for the duration of the block? 16:31
lizmat perhaps, hope so :-) 16:37
timo i wonder if we already compile "given" differently in rakuast in some way and it's better there? 16:38
lizmat hmmm lemme check 16:39
looks like, indeed... it does get inlined then
not sure whether that's a bug or a feature of RakuAST though 16:40
Geth rakudo/main: 83d7a7ffea | (Elizabeth Mattijsen)++ | src/core.c/hash_slice.rakumod
Micro-opt %h<a>:exists:p

by adding a dedicated candidate for it, makes it 10+x as fast
16:43
lizmat afk&
ab5tract [Coke]: A successful blin run! awesome :D 16:54
17:41 finanalyst joined
[Coke] ugexe: anything look weird about this one? gitlab.com/pheix/raku-node-ethereu...type=heads 18:04
... nevermind, that was the last *good* one in this run, it's the next one that's giving the error, oops 18:05
github.com/khalidelborai/raku-SOD/...META6.json - I think it's the resources: [ "libraries/" ] 18:08
yup, can duplicate the error with 'zef install SOD' on another box. 18:09
[Coke] opens github.com/khalidelborai/raku-SOD/issues/2 18:13
So hopefully, worst case, that error is going to cause badly constructed distros to not install. 18:14
(and therefore AlwaysFail)
... It may also prevent Blin from updating the copies of the repo, though (since trying to update this one bad module seems to kill the update) 18:15
If so, this *might* mean that previous blin runs by jdv have been done on an outdated copy of the ecosystem. Not sure. 18:16
ugexe: should a bad resource like that be a warning instead of a stop the world error?
(or perhaps caught and then complained on as a stop the world error about the META6.json file instead of an IO error) 18:17
18:58 vrurg joined
Geth rakudo/main: cc194cdcd1 | (Elizabeth Mattijsen)++ | src/core.c/hash_slice.rakumod
Micro-opt %h<a>:exists:kv

by adding a dedicated candidate for it, makes it 10+x as fast.
Also fix :exists:!p, apparently this isn't tested for single keys
18:59
ugexe A bad anything should prevent something drkm 19:10
from Being installed
lizmat bisectable6: my %h = a => 42; dd %h<a b>:!kv 19:12
bisectable6 lizmat, Will bisect the whole range automagically because no endpoints were provided, hang tight
ugexe I’m not sure if that error is from zef or rakudo but indeed the error could be better
bisectable6 lizmat, ¦6c (83 commits): «("a", 42, "b", Any)␤»
lizmat, Nothing to bisect!
lizmat heh
[Coke] ugexe: zef tries to do something with the file name in "libraries/" (which is empty), then rakudo says "that's not IO::Path-able" 19:15
19:55 doomslord joined
doomslord God, I hate copy on write so much 19:55
They sell it as a performance enhancement 19:57
But it’s just a nest of surprises
Suddenly, write = copy + write 19:58
All behind your back
Of course, it fits the Unix principle since you 99.9% of the time fork and then just wipe out everything to exec 19:59
All other use cases are clearly less obvious
timo ah you're refering to copy-on-write after fork in linux primarily? 20:00
doomslord Yes, that is the only sane use case I can think of
timo cp or rsync with reflinks for example 20:01
snapshots of file systems or subtrees of filesystems, snapshots of VMs
writable overlay filesystems over read-only filesystems 20:02
doomslord Sorry, I prefer multiple copies
And I would rather share read only filesystems
Just a personal preference 20:03
I can think of many situations where having multiple copies, on different continents, saved my job 20:04
Worse thing is the use of copy on write buffers to share data with the kernel, as was done on many old os to save a copy 20:06
You would write your buffer, get cowd with the kernel, next time you write over your buffer you fault 20:07
Basically twice the number of syscalls to not even save a copy 20:08
Linux got it right with ring-buffers
timo you mean io_uring or something else? 20:09
doomslord yes, io_uring
But before io_using it was all copy. Linux never implemented cow on this usecase
Basically, if you share data with an opaque actor such as the kernel, you need to rely on a clear contract. COW is not as clear 20:11
timo content-addressed storage like git uses for its data could also be called copy-on-write 20:13
since changing an object necessarily causes its address to change
doomslord Indeed, but since you know what you are doing I don’t see it as an issue 20:16
What I see as an issue is when you have something that looks like normal but is in fact backed by a cow mechanism 20:17
20:29 doomslord left 20:30 sena_kun left 20:57 sena_kun joined 20:58 sena_kun left 21:06 sena_kun joined 21:21 sena_kun left
Geth rakudo/windows_latest_azure_pipeline: 5d1e0a8c6b | (Timo Paulssen)++ | azure-pipelines.yml
use windows-latest for windows builds on azure
22:59
rakudo/windows_latest_azure_pipeline: 3ba8b91c9b | (Timo Paulssen)++ | azure-pipelines.yml
disable mac and linux build for now
rakudo: timo++ created pull request #5639:
Try using "windows-latest" in the azure pipeline
23:05
rakudo/windows_latest_azure_pipeline: 0ee9cdf867 | (Timo Paulssen)++ | azure-pipelines.yml
fix typo in image name
23:08
rakudo/windows_latest_azure_pipeline: 1e8ac61d09 | (Timo Paulssen)++ | azure-pipelines.yml
skip JVM build on windows as well
23:13 finanalyst left
Geth rakudo/windows_latest_azure_pipeline: 141b0b510a | (Timo Paulssen)++ | src/vm/moar/ops/perl6_ops.c
try to get a stacktrace when a rakudo process exits
23:56