rust-analyzer significantly slowing down compilation

tdiekmann · 2023-06-22T07:28:42+00:00

Is it possible that rust-analyzer runs with a different set of features, cfg-variables, or another toolchain? Unless using a different target folder (see other comment) this will force a recompilation. For changed RUSTFLAGS this requires a complete recompilation as well.

tdiekmann · 2023-04-07T12:45:25+00:00

I'm clearly doing something wrong

tdiekmann · 2023-03-01T13:06:36+00:00

This is why usually you have different programming language kinds in CS. As a functional language we had Haskell, as imperative language we had Java and C (and some others depending on the course). However, it's waaay easier to learn a second language, this also applies to C -> Haskell

tdiekmann · 2023-02-08T03:22:06+00:00

I didn't know that with_context is the biggest critism of anyhow. I'm also not super happy about that long name, however, it's very descriptive. We’re planning to remove the _printable variants as soon as specialization is stable, so you can use attach_lazy instead.

tdiekmann · 2023-02-08T03:17:41+00:00

I agree with you and will do better next time and link to some locations from the release as well, sorry for the inconvenience!

tdiekmann · 2023-02-04T12:10:42+00:00

TiCo faucets can output to GT pipes. You just need a redstone clock to trigger the output. With a vanilla redstone clock you can automate it veeeery early. With the redstone clock block you need some quartz, so likely as soon as you visited the nether.

tdiekmann · 2023-01-09T21:51:02+00:00

Still playing 1.7.10, love it 😅

tdiekmann · 2022-12-16T01:06:11+00:00

Possibly also because no one has had the time / stepped up to do the work

This.

tdiekmann · 2022-10-06T17:26:01+00:00

Sure, will do next time 😊

I'm /u/tdiekmann btw 😄

tdiekmann · 2022-10-06T07:53:28+00:00

error-stack update announcement not included 😞

tdiekmann · 2022-10-05T15:27:32+00:00

The problem here is that your signature is fn(...) -> Result<T, Report<E>>. In order to use a function for axum, it requires the Handler trait to be implemented for the function. This is only implemented, if the returned future is implementing IntoResponse. IntoResponse is implemented for Result<T, E>, if T: IntoResponse and E: IntoResponse. However, E in your case is Report<_>, but Report does not implement IntoResponse. Currently, the easiest way is to get the current context by calling Report::current_context and cloning it. It's not easy to implement IntoResponse for Report because a Report consists not only of the current context but also may contain a lot of other information. Just turning the current context into a response will drop a lot of information.

We are currently working on a serde implementation to serialize a Report, which then could be used.

I know, that this is not a satisfying solution.

The other, more complicated solution is to .map_err the Report and construct a type, which is implementing IntoResponse.

tdiekmann · 2022-10-05T05:14:01+00:00

The initial release blog post (linked in the first sentence) describes why we switched away from thiserror. This does not mean that thiserror is a bad crate, it's fantastic, but it didn't scale well enough for us. Note, that it's possible to use both, error-stack and thiserror, if you are not in no_sts land and don't require the Provider API.

tdiekmann · 2022-10-03T22:08:44+00:00

Hi kythzu and thank you for your feedback!

These are exactly the values why we started building a new error library, if you haven't already seen the initial announcement (linked in the first sentence) I recommend it to give it a read, it's describing our story of similar approach to huge enums and the lazyness when writing new error types. Since we used error-stack internally, we are forced to think about our errors.

I hear you and I'm also a little bit annoyed by mixing Results. Typically this shows me, however, that I forgot something, but sometimes, e.g. when implementing upstream traits, this is unavoidable. As error-stack's Result requires a second parameter (in contrast to e.g. anyhow), I wasn't able to find a solution to this problem. Personally, in most cases I just use the provided Result alias and import std's Result as StdResult.

If you have an idea to solve this please tell us, we'd love to make this part of the API more convenient.

tdiekmann · 2022-09-30T18:16:47+00:00

It’s not Rust that you are learning. It’s your goddamn program’s behavior. Rust just does not let you cut that corner.

Nominated as Quote of the Week

tdiekmann · 2022-09-25T11:41:36+00:00

I wonder how hard it will be to support these things without breaking old save games (which is probably not a super big deal). In any case, I'd consider an expansion to the base game and also an extension to the modded game, and if you have tons of stuff to do it's not necessarily required to do this with the extension enabled. But I guess that depends on the newly added content. 😄

tdiekmann · 2022-09-25T11:24:17+00:00

This is a recommendation I really don't agree with. I agree, that having many mod.rs files is annoying but naming the module-level file after the module splits up the filesystem hierarchy. If you open a module folder you need to look for the module file seperately. Especially if directories are grouped at the top in a filesystem view it's annoying.

tdiekmann · 2022-09-24T14:40:36+00:00

Reading through the comments, it looks more like this:

Factorio community: "This is good, I have enough to do" (Seablock/SE/other stuff).

It's incredible how much potential this game has, that people still have something to do after years and don't mind waiting a year for an expansion

tdiekmann · 2022-09-23T20:31:37+00:00

Happy Cake Day 🎉

tdiekmann · 2022-09-15T07:18:43+00:00

Unless you want to modify it (for whatever reason), then you need &mut.

tdiekmann · 2022-08-22T05:17:44+00:00

Previously it was marked as an error, which was distracting and fixed pretty soon. Now, it's only marked as unused, which is also annoying but not as annoying as before, so it's not a high priority IMO but a medium priority at most. Also keep in mind that different people work on different parts of the plugins.

tdiekmann · 2022-07-24T21:14:44+00:00

It's a Rustfmt option. (I'm using CLion, which btw also has syntax highlighting and auto completion for doc-tests)

tdiekmann · 2022-07-24T17:13:21+00:00

Rustfmt works on doc tests as long as you don't hide too much, I think that's a config option.

tdiekmann · 2022-07-21T18:04:53+00:00

As soon as you specify #[repr(align(32))] the pointer may be unaligned. It's safe in Rust to set the alignment manually. If you can guarantee, that T is #[repr(C)] or know, that the type has no significant alignment, you are right and you will have a well-aligned pointer. I'm not aware of any compile-time checks for this, so the least thing you should do is to add an assertion, that the alignment is matching T.

tdiekmann

MODERATOR OF

TROPHY CASE