u/maggit

I wrote cargo-license-hound to this end back in 2017. I haven't paid attention to what's been happening in this space since then, but I thought I'd mention it for completeness :)

Having just dipped my toes in the Rust Protobuf ecosystem, I am really confused. rust-protobuf seems to be the only option offering reflection, which opens up lots of interesting use cases, so I couldn't do without it.

Thanks for your hard work! I hope the maintainer situation works out well for you in the end!

There's also a blanket impl on ToString for anything that impls Display, giving you .to_string() if you actually need the String.

I'm looking forward to see what you will end up with here. I always enjoy when people really push the limits with Rust!

That said, Linus Torvalds strongly recommends against the use of a spinlock in user space: do not use spinlocks in user space, unless you actually know what you're doing

By unless you actually know what you're doing, I think he means you should fully understand the consequences for the whole system and the kernel in particular. This will in turn inform how you write your application and interpret the measurements of it. It's not that the spinlocks will steal CPU time from the other processes. The problem is that spinlocks aren't as fast as you may naively think. At least, that's the way I read Linus in this post.

Anyway, good luck!

I have a similar experience, except I've noticed it as pegging a CPU core, not exhausting RAM.

I have also configured autoformatting on save, and it seems there is a dependency that rust-analyzer completes its indexing before autoformatting can be triggered. And autoformatting must happen before save. In the end, I cannot save the files I'm editing while rust-analyzer is enabled (any time rust-analyzer gets into this state), so this completely ruins rust-analyzer for me 😢

cdylib is indeed the most direct analogy.

It's worth noting that dynamically linking native code is inherently unsafe, since the dynamic library in principle could do anything. This is not insurmountable, but if it's important to have a safer boundary, it could be worth looking into loading WASM modules using something like Wasmer. Specifically for game mods, I would be much more willing to try out WASM mods from arbitrary third party developers than native code mods.

The documentation for new_current_thread says:

Returns a new builder with the multi thread scheduler selected.

I'm confused. Should it be "single threaded" instead?

Oh, that's a shame. I like the inclusion of high-level abstractions, it makes a good case for attempting to use Rust on embedded.

(By the way, your "full code" listing now shows (0..).take(times))

There is a distracting mistake here:

We create an infinite range (0..times) followed by calling take to limit the number of times the iterator runs…

The given range is of course finite. This looks like a typical case of mistakes sneaking in when editing the text :) The range should be (0..), and then everything works out. (Same for the snippets of code)

The chain reminds me of this beautiful impractical fork: https://static.boredpanda.com/blog/wp-content/uploads/2014/08/useless-object-design-the-unusable-katerina-kamprani-5.jpg

Sure, but there is not much there: https://www.reddit.com/r/rust/comments/ffvszw/rustanalyzer_changelog_15/fk3gldm/

I have the same problem with rust-analyzer. It was suggested to me that I should file a bug report for it, but I haven't found the time yet :)

I cannot get rust-analyzer to show me compiler errors and warnings, I have to resort to the command line again. Well… it shows a few errors, sometimes. Can I get it to show all of them? I'm sorely missing that from RLS :)

Another alternative, if refs are OK and especially if there is more than one element, is to use an array: [1].iter() (playground)

Just to counter this, I am very much into async programming! Both in general and in Rust. I find it fun to work with and, like you say, I am able to more clearly express my intent (in those particular cases). I find it uncomfortable when my code doesn't model the difference between actual work and waiting for I/O or other processes.

"Do it already!" is my take on it, but I come from a background of having worked with reactor and proactor implementations in C++, so I have a particular interest :)

🤔 Perhaps I never got it working on my mac. Not sure, to be honest.

I find it to be an underpromoted performance tweak. LLD is the LLVM linker, not used by rustc/cargo by default. On my Linux and Mac systems, I have been able to reduce link times by setting the environmental variable RUSTFLAGS to include -C link-arg=-fuse-ld=lld. I also had to install LLD.

Hi :) There is a different sub dedicated to stuff like this, /r/rustjerk/. You may have more luck there.

This is not a reply to your question, but you should be aware that several bignum implementations already exist in the Rust ecosystem. And maybe you are already aware :)

If I understand you correctly, for your if !let case I would use .map_err:

let result = try_parse_blob(blob)
    .map_err(|e| /* handle failure */)?;

Ikke verst, men de har litt å gå på før de kommer opp på propagandanivået til nyveien til Os! https://www.youtube.com/watch?v=wd394YpkF04&feature=youtu.be

Yup, that's a shame.

This link is still read by RSS readers [1], so you can give the address of the HTML page to it.

[1] of course I can't speak for all of them, but in my experience they do

I have seen that for open RFCs, but not for tracking issues. Don't the tracking issues come only after a descision has been made to merge the RFC?

That's an RFC, though, not a tracking issue. My confusion here is about the tracking issues. Don't they come after a descision has been made, such that the very question of disposition is obsolete?

One boring meta-thing, I have been wondering for a while what the point is of listing disposition for the issues under "Tracking Issues & PRs". Is the disposition for these issues ever going to be anything other than "merge"?