00:37 MasterDuke joined
timo like and rakuscribe 01:22
07:58 sena_kun joined 08:09 sena_kun left 08:33 finanalyst joined
ab5tract timo: it suddenly occurred to me ask whether you ever encountered this bug report / MR: R#5358 & R#5424 09:33
linkable6 R#5358 [open]: github.com/rakudo/rakudo/issues/5358 [ASYNC] Supply.throttle should allow `:vent-at(0)`.
R#5424 [open]: github.com/rakudo/rakudo/pull/5424 [ASYNC] Allow a value of 0 with :vent-at
ab5tract I was bummed to find that it didn’t work on my Mac (M2) 09:35
finanalyst [Coke] Sorry for delay. re 'use v6.e.PREVIEW' and 'use experimental'. Are they not the same thing? 09:53
nine They're not even related 09:59
Geth rakudo/main: 4ccbad96c1 | (Elizabeth Mattijsen)++ | lib/RakuAST/Deparse/Highlight.rakumod
RakuAST: remove unnecessary "use experimental"

The "use v6.e.PREVIEW" already covers this
lizmat they're related in the sense that "use experimental :rakuast" is a no-op in 6.e and higher 10:00
Geth roast: 779ff37c4d | (Elizabeth Mattijsen)++ | S09-subscript/slice.t
Add test for @a[**]
 10:30
10:30 finanalyst left
ab5tract nine: it just occurred to me that the current revision gating implementation doesn’t allow for removing candidates after a certain version 11:46
Setting a max version so to speak. This is probably necessary if we want revision gating to provide for replacing multi candidates that have equivalent signatures 11:50
nine True. But now that what we have is in place, this sounds like a bit of a typing exercise to get :) 12:49
MasterDuke lizmat: did you write a convert-an-existing-package-to-fez guide or am i imagining that? 13:06
ab5tract nine: true. If you reckon it’s a missing piece worth filling in, I’ll get to typing :) 13:19
timo i have never seen that bug report 13:20
that test code is relying on "sleep", maybe it should be re-made with Test::Scheduler or what it's called
13:58 sena_kun joined 16:30 finanalyst joined
ab5tract timo: thanks for the suggestion, I'll take a look into it 17:08
17:15 finanalyst left
timo it would be nice if the only reason it doesn't give the expected output on your end is that the timing is different 17:15
18:34 finanalyst joined
[Coke] uniname-words – AlwaysFail # this is in my current overview for the ongoing run of Blin. But it installs fine, it seems. Will have to investigate. 19:27
(mentioned 'cause it's lizmat - rak is in the same state on this run so far.)
gist.github.com/coke/58c2ee6579970...7d47d7a4ed - rak's log-new on this run. 20:04
I suspect there's an issue with pinning versions that Blin isn't playing well with. 20:05
Would love to have a "clean" run of Blin so I can see what the real output looks like, then I can dig into specific modules. My stretch goal was to get a list of all the failing modules and see about submitting PRs (but at least let's check the ones we don't think should be failing) 20:15
[Coke] finds github.com/Raku/ecosystem-unbitrot/issues 20:23
[Coke] wonders how long that's been bitrotting itself. 20:25
coleman you're doing the Lord's work coke 20:52
[Coke] heh 20:53
timo ab5tract: there is both Test::Time and Test::Scheduler 21:12
actually, Test::Time builds on top of Test::Scheduler it looks like 21:14
Test::Time seems to just wrap &sleep, &now, and &time in addition to what Test::Scheduler does 21:15
can someone verify the pgp signature of MoarVM 2024.08.tar.gz? it doesn't verify for me 21:36
21:41 finanalyst left
ab5tract timo: sounds useful to me 21:44
I just saw this comment: lobste.rs/s/yiiatz/hylo_safe_syste...g#c_szhqbe 21:45
And wondered whether the ‘is copy’ trait solves this problem category in general … or maybe I’m missing something? 21:46
timo is copy is shallow, that will not satisfy very many people :P 21:50
plus, there's also the question of references / object graphs 21:51
if i go over my array of Foo and mutate something inside one of the Foos, how do i know if the Foo is also in some other array somewhere else?
ab5tract Not surprised that I’m missing something :)
If is copy were not shallow, I wouldn’t expect you to be able to affect any other Foos at a distance 21:54
Which seems like a scenario that could be covered by CoW? 21:55
timo yeah, like how snapshots in many filesystems that support them work 21:56
ab5tract It would be a cool feature if we could pull it off 21:57
timo there's definitely some value in bringing your intentions on when changes can happen to what parts of your datastructure into something that the compiler or runtime can reason about
ab5tract It almost seems like is copy should be redundant and the only way to directly impact references should be via is raw/is rw (which should probably be reunited at some point) 21:59
timo i think those are really about a different kind of thing 22:00
22:03 sena_kun left
ab5tract Not sure I understand. Are you saying that is raw is significantly distinct from is rw? 22:03
timo no, just that raw, rw, and copy are only kind of tangentially related to how &mut works in rust 22:05
ab5tract I don’t know Rust, so I can only extrapolate. If it’s about controlling mutability of references in scope, those are the tools I’m aware of in Raku 22:06
timo i'm pretty sure mutable references work deeply within structures and whatnot too 22:07
ab5tract > If at any point i have a &mut, i can rely on the fact that modifying it won’t change any other reference that i have access to (mutable or not) 22:08
timo we don't really have anything like that. you put a scalar in something somewhere and boom, immediately freely mutable 22:09
yeah, there's the "borrow" checker that makes sure you're not aliasing anything and so on
i haven't done enough rust yet to know enough details though 22:10
so i think you can't have a mutable reference to an entry in an array and then get a mutable reference to the array itself
not exactly sure if i understand what they mean by "that i have access to (mutable or not)" 22:12
ab5tract It certainly sounds like an awesome feature to have. I guess it makes sense that the borrow checker is involved, but I can’t stop coming back to CoW … probably a strong indication that I don’t understand the dynamics very well 22:13
timo CoW can be thought of as "just an optimization" 22:16
which is good for understanding because whether or not cow happens doesn't matter for the outcome, except for performance in terms of memory use and time spent copying 22:20
ab5tract In this case it would be an optimization deployed to ensure that no scary little scalar can hurt you because you would automatically engender a copy upon modification 22:21
timo think of it more as "whenever you're retrieving a value, partial or whole, you're actually making a full copy" and then cow becomes "when can we leave out or postpone the copy until we really can't get away without one" 22:23
ab5tract I’m probably being in redo my dense but that just seems like another way of saying that we can get away with the cost of a shallow clone while providing the guarantees of a deep clone 22:25
“in redo my” = “incredibly dense “
timo no that's correct 22:28
well, it's a bit more than the cost of a shallow clone
ab5tract True, it’s not actually free of course. 22:30
But if you can guarantee that every parameter object is (eventually) deep cloned unless specified is raw, my naive take is that you achieve what this user is celebrating about &mut in Rust 22:32
timo well, with rust you can also go from copy-everything back to mutate-some-stuff, and the compiler helps you not mess up 22:34
ab5tract Interesting. So in a single scope you can go from “mutating this affects nothing“ back to “mutating this affects its actual reference”? 22:44
“nothing but this local copy/object/whatever” 22:45
Anyway, the actual feature of knowing whether your changes can affect references or not seems useful to me. Maybe we can even add a borrow checker via RakuAST eventually, given some strict adherence by the user to conduct themselves in ways that wouldn’t immediately invalidate it :) 22:49
timo oof ... that would be a project for sure ... 22:50

Powered by Cro and the Raku® Programming Language.

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

Thank you!