[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 |