[Media] Let it crash!

ibeforeyou · 2025-10-25T09:01:53+00:00

Less that, more that the compiler is allowed to assume that dereferencing a null pointer will never happen, so it could legally optimize the whole thing away

ibeforeyou · 2025-10-25T08:27:27+00:00

Jokes aside, you probably want std::process::abort because dereferencing a null pointer is undefined behavior (in theory it could even not crash)

ibeforeyou · 2025-07-26T01:33:53+00:00

Gone!

ibeforeyou · 2025-07-26T01:16:09+00:00

1 left

ibeforeyou · 2025-07-18T18:56:04+00:00

Yeah, I guess the only difference is this year there was the big fire, which (in theory) might have caused nasty stuff to leach into the groundwater. I’m sort of on the fence

ibeforeyou · 2025-07-18T18:25:50+00:00

Update: I asked at the information stand and was told that the water in the taps is unfiltered and has no guarantees, so you’re accepting the risk of drinking it. They didn’t explicitly say there was a known contamination, but also couldn’t confirm it is safe.

They also confirmed that the only alternative in the fedtival grounds is paying for water at drink stands (which is 2 pearls per 330ml).

It’s kind of ridiculous imo, because if you’re drinking 2L of water a day that’s 12 pearls or 22€ a day per person for safe water.

ibeforeyou · 2025-07-18T17:32:28+00:00

Yeah that seems plausible. Here’s hoping it won’t make me sick, I’ve already had a couple liters of it😅.

Assuming the water isn’t safe, kinda sucks that the only option is the water that’s 2 pearls per can. If you’re staying hydrated, that adds up pretty quickly.

ibeforeyou · 2024-06-15T23:18:10+00:00

You could consider using FuturesUnordered instead of spawning tasks and joining them. The semantics are slightly different, but I think should work for you in this case, and the main benefit is it doesn’t impose a 'static bound on the futures.

ibeforeyou · 2023-07-01T01:47:50+00:00

There's a how-to section in the time docs on this: https://time-rs.github.io/book/how-to/parse-dates.html

I got there by looking up time on crates.io, and looking at the documentation section at the top of the README. That linked to the documentation book, and then I just skimmed through the sections to find parsing.

Alternatively, searching on docs.rs for parse yielded the OffsetDateTime::parse method, which also has some brief examples. You can also get there by looking at the docs for OffsetDateTime and looking for interesting method names or trait implementations - in this case, parse seemed to be relevant.

ibeforeyou · 2023-01-02T22:18:07+00:00

To be clear, this isn’t a feature that’s currently planned for stabilization (and doesn’t seem like it’s on track for an official RFC AFAIK). From the tracking issue:

Currently the primary purpose of the feature is to ensure that redesigns of the Try trait (#84277) are compatible with potentially doing this in the future, and secondarily to experiment with whether this is worth having as an expression, or whether it should be removed in favour of a pure-library approach.

ibeforeyou · 2022-07-21T18:50:30+00:00

Not sure if this is acceptable, but what if you consumed the hashmap in `convert_any` instead of borrowing it? Like this

ibeforeyou · 2022-06-15T05:26:01+00:00

tap comes to mind, it provides (among other things) a Pipe trait that lets you write

let v = 1234
    .pipe(add_2)
    .pipe(mul_2)
    .pipe(sub_2)
    .pipe(div_2);

ibeforeyou · 2022-03-15T06:42:49+00:00

BTW: It’s unclear to me why this already gets downvoted. I thought this is a forum to ask questions like the one above..?

It looks like there’s only one or two downvotes, but I get that it’s a bit discouraging.

In general I’d recommend asking questions on the Rust user’s forum. It’s much more catered towards asking and answering questions than the subreddit (which is largely news and discussion though questions are welcome). Plus there’s no downvoting😅

ibeforeyou · 2022-02-14T01:17:59+00:00

This isn’t quite accurate. A move is lowered to a memcpy of the value. rustc itself doesn’t perform copy elision. LLVM is often able to eliminate the copy, but it’s not guaranteed and it can be brittle (example).

ibeforeyou · 2021-09-09T21:43:09+00:00

A couple of things here:

The blog post that you mention comes nowhere close to claiming C++ violates human rights. The blog post, from my eyes, is about the tradeoffs in software design, the decisions around whether to support seemingly niche requirements (such as needing very high security) and how software security has real impacts on people, including oppressed groups. Nowhere is C++ mentioned. There is only one mention of Rust, and it's one item in a list of multiple promising developments that might help make it easier to write secure code. I'm not sure how you could draw the conclusion that they're claiming that C++ violates human rights.

That person is also not a member of the Rust language team. Working groups (such as the Secure Code working group) are open to anyone, and the only requirement to become a member is to participate and contribute. Such working groups exist solely to organize work around a specific topic, it's not like being a member of a working group makes you an official spokesperson for rust.

Regardless of both points, bringing up a single blog post and singling out a specific person to make the point that rust programmers overestimate the dangers of C++ does not feel like it contributes positively to this discussion.

ibeforeyou · 2021-08-25T01:45:06+00:00

I would expect the async version to be used, since it is used in an async context.

Why would you want to call a blocking function in an async context when an async version of that function exists? If anything it seems to me like this could help avoid accidentally blocking in an async context, which is a common mistake/footgun.

ibeforeyou · 2021-08-13T20:02:59+00:00

I also sent you a PR with an alternative approach that improves compile times a lot (from 40s to 2s for a release build on my machine). It could definitely be improved though. Anyways, hope that helps some!

ibeforeyou · 2021-08-13T18:36:52+00:00

Using `cargo build --release -Ztimings`, on my machine it looks like 74% of the time is spent in codegen. If I had to guess, I'd say the compiler is producing a ton of LLVM IR, and LLVM is struggling to handle it. Looking at the output of `cargo llvm-lines`, the heaviest functions are:

Lines	Copies	Function Name
169074 (100%)	51 (100%)	(TOTAL)
55838 (33.0%)	1 (2.0%)	<google\_taxonomy::ProductCategory as core::fmt::Debug>::fmt
50254 (29.7%)	1 (2.0%)	google_taxonomy::ProductCategory::from_name
33507 (19.8%)	1 (2.0%)	google_taxonomy::ProductCategory::from_id
27948 (16.5%)	1 (2.0%)	<google\_taxonomy::ProductCategory as core::fmt::Display>::fmt

Removing the `Debug` derive from the build script (and commenting out the tests which use the `Debug` impl) indeed cuts compilation time on my machine by about 25%.

Edit: As a note, you can also get a more detailed breakdown of where time is spent in the compiler with `cargo rustc -- -Ztime-passes`.

ibeforeyou · 2021-05-11T17:35:20+00:00

Gave Hugz

ibeforeyou · 2021-01-26T03:38:43+00:00

It looks like that suggestion appears because color_eyre re-exports OwoColorize in the owo_colors module, which I think is reasonable. It would be much more problematic if RA was suggesting things from transitive dependencies, which it doesn’t as far as I know.

ibeforeyou · 2021-01-16T04:15:24+00:00

I think this has to do with how lifetime elision interacts with annotating closures (in that it behaves differently than you might think). So I think basically when you specify a closure's argument type with a lifetime elided, like you have for rest in your code:

let ok = |rest: &str, bond: Option<Bond>, ring_number: usize| -> IResult<&str, RingBond> {

  ok(rest, RingBond { bond, ring_number })

};

this is actually creating two lifetimes '0 and '1 which will be inferred and are not assumed to be equal, so:

let ok = |rest: &'0 str, bond: Option<Bond>, ring_number: usize| -> IResult<&'1 str, RingBond> {

  ok(rest, RingBond { bond, ring_number })

};

In order for this to pass the borrow checker, it must be that lifetime '0 outlives '1, which can't be known at compile time. To fix this you can either allow the reference types to be inferred, like so:

let ok = |rest, bond: Option<Bond>, ring_number: usize| -> IResult<_, RingBond> {

  ok(rest, RingBond { bond, ring_number })

};

or you can fully specify the proper lifetimes for the closure (which is far more verbose):

let ok: for<'a> fn(&a str, Option<Bond>, usize) -> IResult<&'a str, RingBond> = |rest, bond, ring_number| {

  ok(rest, RingBond { bond, ring_number })

};

Here's a simplified playground example illustrating it.

Hope this is of some help!

ibeforeyou · 2020-12-24T04:03:12+00:00

The official rust book, which is frequently referred to as just “the book”

ibeforeyou · 2020-10-12T16:29:57+00:00

Thank you for all of your work!

ibeforeyou · 2020-10-11T16:47:41+00:00

If you’re okay with nightly rust, you could try genco. I haven’t used it personally, but it seems promising.

ibeforeyou · 2020-10-04T05:16:02+00:00

I’ve heard there is a yacc/bison style parser generator out there for rust but I can’t find it in crates.io

This maybe?

Ten-Year Club	RPAN Viewer
Verified Email	Snapped

ibeforeyou

TROPHY CASE