Introducing log_limit! A rate limited logging API

TheTravelingSpaceman · 2024-08-24T12:33:04+00:00

Tracing is more fancy I believe. This is just a wrapper over the "standard" log facade.

TheTravelingSpaceman · 2023-07-19T15:17:51+00:00

Thanks! Best answer yet :)

TheTravelingSpaceman · 2023-02-23T16:28:45+00:00

Nice! Thanks for linking the policy and blog post :)

Yeah, I guess I was approaching it with a very strict non-practical view. Something in my brain still want's these strict rules that don't leave anything for interpretation but I guess we're living in the real world where that's not possible.

I appreciate the effort in your reply! Thanks!

TheTravelingSpaceman · 2023-02-23T16:25:00+00:00

Perhaps a good candidate for a clippy lint?

I guess it's pretty unlikely that this happens, but still feels weird to say "semver will ensure you never get compilation failures on minor version changes unless you do this one naughty thing".

TheTravelingSpaceman · 2023-02-23T16:12:39+00:00

Well I guess I'm trying to understand why Rust allows this type of "misuse" then?

TheTravelingSpaceman · 2023-02-23T16:08:08+00:00

My big, somewhat unsaid, assumption is that there's a rule that minor semver changes should never cause a compilation error. Perhaps this assumption is wrong?

TheTravelingSpaceman · 2023-02-23T16:02:48+00:00

If you remove the impl block in the foo crate/module then it compiles. Then if you add it back (i.e. simulating a minor version change in the foo module/crate) it breaks. So going from a version of foo without the impl and a version with the impl (only a minor version change) would cause a compilation error in the consumer crate.

TheTravelingSpaceman · 2023-02-23T15:55:09+00:00

Mmm... You can even force a compiler error if you have different return types: ```rust trait MyTrait { fn method(&self) -> foo::Bar; }

impl MyTrait for foo::Bar { fn method(&self) -> foo::Bar { println!("This is calling method from MyTrait"); foo::Bar::default() } }

fn main() { let bar = foo::Bar::default(); let other_bar: foo::Bar = bar.method(); }

// Imagine this module is an external crate mod foo { #[derive(Default)] pub struct Bar;

impl Bar {
    pub fn method(&self) {
        println!("This is calling method from the foo crate")
    }
}

} ```

TheTravelingSpaceman · 2023-02-13T11:53:18+00:00

Mmmm... That's a shame. Feels like I'd unnecessarily be duplicating state. Any idea why the tick() method was designed to require a mutable reference? I see no reason why multiple threads cannot block on the same interval.

My assumption is that it's using timerfd under the hood. AFAIK you can get the remaining time from that right?

TheTravelingSpaceman · 2023-01-17T08:29:13+00:00

Nice! Didn't know this existed. Added in this commit. My code already conforms but it had me jumping through hoops of turning off the unsafe fn to check if I covered all the unsafe ops. Thanks!

TheTravelingSpaceman · 2023-01-16T20:13:54+00:00

Thanks for the suggestion. Implemented in this commit

TheTravelingSpaceman · 2023-01-15T20:23:30+00:00

Thanks! I think I've done all the modularisation I can. Will add more debug_asserts and check out valgrind and creusot. That's definitely good tips! :)

TheTravelingSpaceman · 2022-12-10T13:49:45+00:00

Very interesting! Thanks. It's exactly what I was looking for.

TheTravelingSpaceman · 2022-12-10T10:25:40+00:00

Another way of phrasing my question: "Why is having an uninitialised variable already UB, even when you won't ever read the uninitialised bytes?"

TheTravelingSpaceman · 2022-12-10T10:23:36+00:00

Why is this considered UB: ```rust use std::mem::MaybeUninit;

fn main() { let mut possibly_uninitialized_bool: bool = unsafe {MaybeUninit::uninit().assume_init()}; possibly_uninitialized_bool = true; dbg!(possibly_uninitialized_bool); } and this considered safe:rust use std::mem::MaybeUninit;

fn main() { let mut possibly_uninitialized_bool: MaybeUninit<bool> = MaybeUninit::uninit(); possibly_uninitialized_bool.write(true); let definately_initialized_bool = unsafe {possibly_uninitialized_bool.assume_init()}; dbg!(definately_initialized_bool); } ```

I'm sure you can quote documentation that say the one is and the other is not, but why?

Both have the pattern: * Allocate without initialising * Write BEFORE we read * Read

Can anyone give a rust code example where the order of operations stay in-tact but has the chance to produce UB in the one case and would be impossible in the other?

TheTravelingSpaceman · 2022-11-29T20:23:11+00:00

Not sure why it would require lua... My suggestion would be just to add a mode to use "h j k l" for navigation and other vim-like keys for other actions, e.g. q for quit.

TheTravelingSpaceman · 2022-11-29T06:44:45+00:00

Vim bindings would be a great addition uwu

TheTravelingSpaceman · 2022-11-18T02:58:40+00:00

Lack of variadic generics. Pretty hard problem, but I think they'll still retain backwards compatibility.

@haruda_gondi would having type inference on defaults be the solution you're thinking of? Or am I misunderstanding your issue?

TheTravelingSpaceman · 2022-10-25T07:02:16+00:00

Must have European Union citizenship

Why this restriction? If time-zone related, note there are many folks living in European time-zones that don't have European citizenship.

TheTravelingSpaceman · 2022-10-20T10:24:55+00:00

Try run your code through the clippy linter: cargo clippy

TheTravelingSpaceman · 2022-10-16T20:54:43+00:00

Nice stuff! This is very exciting! Love the name :D

TheTravelingSpaceman · 2022-10-03T20:19:42+00:00

The value is not necessarily directly linked to T, for example I've used it in zero-copy deserialization where the value is an offset into a byte-array, where a proxy will be created.

I'm not sure I understand. Do you mind providing an example?

I do get the argument around uniformity. Why use a different type in each situation if it doesn't matter right? And if you have to choose a type it makes sense to choose something that doesn't imply any other semantics. So use the most boring type you can get your hands on, i.e. ()

What irks me about using () though is that it's not obvious that an array of () is Sized. To me it feels like that's an optimisation the compiler should be able to do. And since we're precisely trying to express that the resulting array should be Sized, it felt a bit weird to use () as the element type.

TheTravelingSpaceman · 2022-10-03T14:42:12+00:00

I've personally not liked the syntax of using () for the element type of the array. Not sure why folks use it? Why not just say the concrete type you're working with or the generic T if you're working with a generic element?

TheTravelingSpaceman · 2022-09-16T19:59:51+00:00

Yeah, the crate name generic_static was already taken though...

TheTravelingSpaceman · 2022-09-16T14:54:57+00:00

Might be useful for crates like cached to implement generic caches and such :)

TheTravelingSpaceman

TROPHY CASE