🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm
Set by lizmat on 8 June 2022.
timo > moarvm armel 2024.09+dfsg-3 00:53
wait a bloopy minute
now where did i get that link from 00:56
where did i put the core dump now >_> 01:08
01:27 sjm__ joined, sjm_ left
ugexe .tell finanalyst the best way to discover that would be to look at how that code works - github.com/rakudo/rakudo/blob/b527...#L309-L338 01:47
tellable6 ugexe, I'll pass your message to finanalyst
Geth rakudo/main: e5c74d0aca | (Will Coleda)++ | src/core.c/CompUnit/RepositoryRegistry.rakumod
fix comment typo
 02:06
04:10 guifa left 06:34 Xliff left 07:34 librasteve_ left 07:37 finanalyst joined 08:38 finanalyst left 08:39 melezhik joined
melezhik . 08:40
lizmat .tell finanalyst the about page feels very crowded: suggest grouping all people with < 10 commits in total into an "others" group 09:13
tellable6 lizmat, I'll pass your message to finanalyst
09:35 melezhik left, melezhik joined
lizmat notable6: weekly 10:02
notable6 lizmat, 2 notes: 2025-05-03T21:53:29Z <antononcube>: github.com/ab5tract/resource-wrangler ; 2025-05-03T21:56:34Z <ab5tract>: github.com/ab5tract/resource-wrangler
lizmat notable6: weekly reset
notable6 lizmat, Moved existing notes to “weekly_2025-05-05T10:02:38Z”
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2025/05/05/2025-...d-dancing/ 10:35
10:38 sjm_ joined, sjm__ left 10:41 sjm_ left 10:42 sjm_ joined 10:43 guifa joined 11:04 melezhik left, sjm_ left 11:05 sjm_ joined 11:15 melezhik joined 11:39 finanalyst joined 11:58 melezhik left
ab5tract is there a way to mock $?DISTRIBUTION? 12:51
tests don't seem to have valid values for this
though maybe it's an X-Y problem?
timo it may depend on how exactly you are running the tests? 12:52
12:52 melezhik joined
ab5tract it breaks with raku -I. and it fails when zef tries to install 12:54
tellable6 2025-05-05T12:53:54Z #raku <melezhik> ab5tract: are you going to add a minimal documentation to Resource::Wrangler? I am thinking maybe I could use it for Sparky distributionn
ab5tract melezhik: yeah, some documentation should arrive soon.
github.com/raku-community-modules/...984?pr=109 12:55
melezhik cool
timo ah i was afraid that might be the case, yeah 12:57
you're not asking $?DISTRIBUTION from inside the test file directly, right? 12:58
12:58 melezhik left 13:00 melezhik joined 13:02 melezhik left, melezhik joined
ab5tract not in this case, now 13:03
*no
but in the test suite for Resource::WRangler that would obviously be preferraable to hardcoding a sha1, as I do now
13:06 melezhik left
nine What purpose would mocking $?DISTRIBUTION have? 13:08
ab5tract ohhh
nine: so it doesn;t explode?
nine So what doesn't explode in what way? 13:09
ab5tract it's the same reason to mock anything: the sha1 varies according to the value of $?DISTRIBUTION
nine What sha1?
ab5tract github.com/ab5tract/resource-wrang...akumod#L13 13:10
so sure, if the test file had $?DISTRIBUTION set to an actual value, there would be no reason to mock
github.com/ab5tract/resource-wrang...kutest#L18 13:11
but it's actually super simple to do
ab5tract m: sub term:<$?DISTRIBUTION> { "mocked" }
( no output )n
timo hey nine since you're here right now, do you think the code that handles creating precomps for inclusion in packages could get a flag for "violently explode if any dependencies don't have valid precomp files already"? so that trouble with packages turns into "package doesn't compile" instead of the QA infra having to create bug reports that packages X, Y and Z have an undeclared conflict because 13:12
they all include some precomp files for a shared dependency?
ab5tract m: sub term:<$?DISTRIBUTION> { "mocked" }; dd $?DISTRIBUTION
camelia "mocked"
timo if that sounds reasonable to you, i can probably build it. it's more a question of "where's the best spot to put that code" and you know that code way better than me
nine $*TMPDIR.add(nqp::sha1(~$?DISTRIBUTION)) is the wrong idea anyway. It's a text book incsecure temporary file vulnerability 13:13
timo: yes, that's definitely a good idea 13:15
The only valid path you may create in $*TMPDIR is a randomly generated one. 13:19
ab5tract nine: then I would still need a reasonable way to mock things 13:20
but to be sure, that's the opposite advice I got previously
nine Then I would be more careful with chosing your sources for advice. owasp.org/www-community/vulnerabil...orary_File 13:21
timo i also need to re-think the handling of the rakudo compiler ID. currently in debian we do this: salsa.debian.org/perl6-team/rakudo...=heads#L27 plus salsa.debian.org/perl6-team/rakudo...=heads#L37 which seems like an incredibly bad idea, especially as long as rakudo isn't fully
reproducible yet
ab5tract it was advice from here in this chat
so maybe we could be speaking with less veracity at the moment 13:22
nine It's still just plain wrong though :)
ab5tract my original plan was randomization anyway
though my original code very much wasn't 13:23
nine timo: yeah, those patches look horribly wrong to me
timo i'm not exactly sure what precise issues these patches were introduced to fix at the time 13:24
presumably "every time we rebuild rakudo, this changes, and all modules built from the rakudo get invalidated and that's not OK" but the fix was inadvertently "make the modules not be invalidated immediately and instead explode on first use" 13:25
nine Warrants a bug report I guess
timo how do you handle it on suse? always rebuild all modules when a new rakudo package comes around? so there cannot be a version mismatch between the modules and the rakudo package?
nine yep 13:26
timo then users don't have a way to downgrade packages of modules, right? 13:27
nine If the compiler id changes, you have to recompile everything. Our remaining problems is that not even the compiler id is sensitive enough (though it should be if all bugs were fixed). So that Debian patch goes into the completely wrong direction.
timo right 13:28
the differences between two rakudo compilations are now *almost* zero i think
oh, i think that was just the core setting or something that i was looking at in particular 13:45
14:00 melezhik joined 14:07 finanalyst left 14:12 sjm_ left
ab5tract okay, now each temp resource file gets a randomized sub-path in $*TMPDIR and a randomized file name under that path 14:12
14:12 melezhik left
ab5tract while also providing the user the opportunity to specify either or both of those manually 14:13
14:15 finanalyst joined 14:17 melezhik joined 14:18 melezhik left 14:47 sjm_ joined 14:48 finanalyst left, finanalyst joined 14:56 finanalyst_ joined 14:58 finanalyst left 14:59 finanalyst__ joined 15:01 finanalyst_ left
timo i found out we were wasting a lot of performance reading very small files into bufs with IO::Path.slurp(:bin) 15:18
oh, and apparently also leaking memory too 15:20
15:22 finanalyst_ joined 15:25 finanalyst__ left
timo the normalizecodes op also had a leak i think 15:26
(if used repeatedly on the same buffer object)
(which we weren't doing at all in core, it looks like) 15:27
ah, but we were also passing a newly created buf into readfh every time when we read binary data 15:32
we could reuse those buf objects, and with the in-progress patch it wouldn't even leak memory %)
15:33 finanalyst__ joined 15:35 finanalyst_ left 15:37 finanalyst_ joined 15:40 finanalyst__ left 15:47 finanalyst_ left
timo it would be kind of neat to have a way to join a bunch of Buf instances together into a large Buf 15:50
we can [~] @bufs at least 15:51
not very efficient, though. like it wouldn't pre-allocate the exact correct size for the result in one go 15:52
lizmat it could, though 16:07
timo where can we catch this particular case? 16:08
16:09 japhb left 16:22 japhb joined 16:34 japhb left 16:35 japhb joined
lizmat hmmm... I thought dd (Buf.new(1,2,3),Buf.new(4,5,6)).join would work 16:36
timo nah, join is stringy by nature 16:37
hmm.
if there was a variant where you pass Buf.new() as the delimiter to make clear that you want buf joining, not string joining maybe? 16:38
and then we get to figure out what happens if the types of bufs you pass in don't match :)
lizmat m: dd (Buf.new(1,2,3),Buf.new(4,5,6))..are
camelia ===SORRY!=== Error while compiling <tmp>
Undeclared routine:
are used at line 1. Did you mean 'PRE'?
lizmat m: dd (Buf.new(1,2,3),Buf.new(4,5,6)).are
camelia uint8 = Buf
timo and what if you want to have a different type as the result of the join operation that none of the bufs that go in are, and the delimiter type is maybe also different 16:39
lizmat hmmm... I thought we shortcutted [+] 1,2,3 to (1,2,3).sum somewhere ? 16:45
timo yeah i thought so too. we don't? 16:49
lizmat nothing obvious is showing in METAOP_REDUCE_LEFT nor in the generated QAST 16:51
aha, in Rakudo::Metaops 16:54
the optimized version of [~] could do an .are on the list, and if it's a Buf, be smart 16:55
timo a few string-based "die" in there that could be something like a good first contribution or something
lizmat only problem I see if there are no elems in the list, how will [~] know to produce an empty Buf rather than '' 16:56
17:00 finanalyst_ joined
[Coke] jdv: you want this upcoming release? 17:04
17:04 japhb left
timo indeed, that doesn't seem solvable. it seems like a re-run of the Hash.classify-into thing 17:07
17:11 japhb joined
timo m: say &infix:<+>:[Buf:D, Buf:D]; 17:12
camelia Use of uninitialized value element of type Buf:D in string context.
Methods .^name, .raku, .gist, or .say can be used to stringify it to something meaningful.
in any term at /home/camelia/rakudo-m-inst-2/share/perl6/lib/Perl6/Grammar.moarvm line…
timo just a random thing i stumbled over 17:16
jdv is it the ast release, 17:17
timo in any case, i don't have a good suggestion how to allow telling [~] that the special case of "no arguments" should result in a Buf of some kind, apart from `[~] Buf.new(), |@things` which isn't great
jdv [Coke]: whatever you want
[Coke] I'd love it if you could take this one. 17:21
jdv done and dusted mein freund! 17:26
17:30 japhb left
timo in theory i guess [~] makes an iterator and if you STORE it into a variable that's typed, it could take the type of that, but i'm not sure any other part of the language do things much like that, so it could be surprising to see 17:37
no, [~] doesn't make an iterator, of course 17:38
lizmat the more I think of it, it feels like we need some kind of protocol for these cases 17:43
timo at first blush "protocol" leads me to think of "wantarray", which we don't want to reproduce 17:47
in theory, something like an Allomorph is perhaps a good match, but i can't imagine that turning into an efficient and convenient and debuggable experience for the end user 17:48
or maybe something more like how assigning Nil gives you the .default for a container 17:49
17:54 japhb joined 18:52 finanalyst_ left 19:02 japhb left, japhb joined 19:08 finanalyst_ joined 19:13 japhb left 19:15 sjm_ left 19:28 japhb joined 19:44 japhb left 19:50 japhb joined 20:04 japhb left
ugexe github.com/rakudo/rakudo/blob/main...ns.rakumod contains multiple hash writes to %DEPRECATIONS that are not thread safe 20:07
tellable6 2025-05-05T12:42:35Z #raku <wayland76> ugexe Btw, that module rewrite PR (on the doco repo) is ready for another review when you're ready
20:10 japhb joined 20:16 finanalyst_ left
timo good catch 20:16
20:19 japhb left
timo m: await do for ^1000 { start { DEPRECATED($_.Str) } } 20:19
camelia ( no output )
20:19 japhb joined
timo m: await do for ^1000 { start { DEPRECATED($_.Str, v6.a) } }; Deprecation.report(); 20:20
camelia ( no output )
timo ah it inspects what sub it's called from i assume?
that's a little annoying to generate :D 20:21
m: my @subs = do for ^2000 { (Q[sub dep_] ~ $_ ~ Q[_test() is deprecated { }]).EVAL }; await do for ^50 { start { for @subs.pick(100) -> &bla { bla } } }; Deprecation.report(); 20:23
camelia ===SORRY!=== Error while compiling /home/camelia/EVAL_0
Can't use unknown trait 'is' -> 'deprecated' in sub declaration.
at /home/camelia/EVAL_0:1
expecting any of:
rw raw default DEPRECATED inlinable onlystar export leading_docs…
timo we don't have a trait for it i guess?
m: my @subs = do for ^2000 { (Q[sub dep_] ~ $_ ~ Q[_test() { DEPRECATED("dep_] ~ ($_ + 1) ~ Q[_test()") }]).EVAL }; await do for ^50 { start { for @subs.pick(100) -> &bla { bla } } }; Deprecation.report(); 20:24
camelia MoarVM oops: MVM_str_hash_fetch_nocheck called with a stale hashtable pointer
at SETTING::src/core.c/Hash.rakumod:56 (/home/camelia/rakudo-m-inst-2/share/perl6/runtime/CORE.c.setting.moarvm:AT-KEY)
from SETTING::src/core.c/hash_slice.rakumod:…
20:28 japhb left, japhb joined 20:44 japhb left, japhb joined
ugexe the trait is `is DEPRECATED(...)` although with a compile time trait it might be harder to expose 20:55
timo well i just wanted a bit of test code that provokes a crash because of the simultaneous multi-threaded access 20:57
21:19 japhb left 21:21 japhb joined 22:47 japhb left 22:48 japhb joined 23:01 japhb left 23:02 japhb joined 23:54 benchable6 left, benchable6 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!