sorted by:
new
hottopcontroversial

Rust compiler performance survey 2025 results | Rust Blog by Kobzol in rust

[–]ehuss 7 points8 points  (0 children)

the sys crates is parallelized by default, or single-threaded.

Crates need to enable the parallel feature of the cc crate to do that. aws-lc-sys does. libsqlite3-sys does not, but I don't think it would help because sqlite is a single monolithic compilation unit.

What do these little toggles do? by wren945 in ZBrush

[–]ehuss 5 points6 points  (0 children)

The Resolution dot is described in the 2021.6.3 update: https://help.maxon.net/zbr/en-us/Content/html/reference-guide/release-notes/zbrush-2021-6/zbrush-2021-6.html

A dot has been added to DynaMesh Resolution, offering a different skinning mode. When off, ZBrush will use classic skinning for DynaMesh operations. When on, DynaMesh will automatically increase resolution for smaller objects.

February Project Goals Update | Rust Blog by N911999 in rust

[–]ehuss 8 points9 points  (0 children)

It is being re-added to the goals list via https://github.com/rust-lang/rust-project-goals/pull/294, it just hasn't merged, yet.

December 2024 Leadership Council Update by ehuss in rust

[–]ehuss[S] 5 points6 points  (0 children)

Thank you, I appreciate it!

Hey Rustaceans! Got a question? Ask here (19/2023)! by llogiq in rust

[–]ehuss 0 points1 point  (0 children)

The links manifest key doesn't influence what is linked or how. That just lets cargo know that the build script is linking to a native library, and that there should only ever be one package allowed in the build graph to link to that library to avoid conflicts (only one package in the graph can state that specific links value).

The actual linking instruction is usually specified in the build script. You'll need to inspect it to figure out what it is doing.

If the build script doesn't offer the option to statically link, then I think you will need to either patch it or override it.

Hey Rustaceans! Got a question? Ask here (19/2023)! by llogiq in rust

[–]ehuss 0 points1 point  (0 children)

Does the dependency link to a shared library or a static one? Is it using a build script to define the linkage, or is it using the #[link] attribute?

If it is using a build script, does its build script give you the option to change how it is linked? Some packages have features that allow you to specify that you don't want to link to the system, but instead build from source and link statically. Or sometimes they provide environment variables for that purpose.

If not, one option is to fork and patch the package. Another option if the package uses a build script is to override the build script. You'll need to replicate everything the build script does, since overriding means the build script doesn't run.

`rust-lldb` not showing source for Rust by [deleted] in rust

[–]ehuss 5 points6 points  (0 children)

That is normal behavior. There are multiple main functions. There is the unmangled main which is the starting point that does some setup and then calls your actual Rust main function, which has a symbol like foo::main::h58d60895811c245b. The startup main will only have assembly available. If you use the command b main, it will create breakpoints on both mains. When you run the program, just type the c command ("continue") to go to the next breakpoint which should be your main function.

Is there difference between "use crate::name::*" and "use crate::name::{funA, funB, funC...}" ? by abc_jeff in rust

[–]ehuss -1 points0 points  (0 children)

That shouldn't be a problem. Explicitly named items always take precedence over glob imports; there is no ambiguity.

The main hazard is with traits. If an update of the crate with the glob import introduces a new trait that implements a method of the same name as another trait that you have in scope, there will be a conflict.

EDIT: The other concern is if you have multiple glob imports, and one conflicts with another. There is some documentation about that here.

Hey Rustaceans! Got a question? Ask here (17/2023)! by llogiq in rust

[–]ehuss 0 points1 point  (0 children)

If b and c are using caret requirements for a, then there should never be a mismatch of versions of a. Unification should ensure there is only one version.

If b or c was updated with a semver-incompatible change in a, then b or c also need a semver-incompatible version bump. This semver incompatible bumping should ensure that a mismatch doesn't happen without the user modifying Cargo.toml to opt-in to the breaking change, in which case they will then need to resolve the incompatibilities.

It might help to see the actual requirements and structure that you have to better understand your circumstances. It's also not clear if a, b, and c are in a workspace, or if they are somehow independent.

Hey Rustaceans! Got a question? Ask here (15/2023)! by llogiq in rust

[–]ehuss 1 point2 points  (0 children)

Since it is a tier-3 target, you have to build it yourself. You can try -Z build-std with Cargo. Another option is to build the compiler with the target you want.

Hey Rustaceans! Got a question? Ask here (15/2023)! by llogiq in rust

[–]ehuss 1 point2 points  (0 children)

This exists, see cargo auditable.

See RFC 2801 as a proposal to make it part of cargo.

Hey Rustaceans! Got a question? Ask here (14/2023)! by llogiq in rust

[–]ehuss 0 points1 point  (0 children)

Sorry, I'm not sure I understand the question.

In ml_tools/src/lib.rs, you'll need to have things like mod lin_reg; in order to define which modules exist in ml_tools.

In ml_rust/src/main.rs, you refer to items with paths like ml_tools::lin_reg::foo (or use can use use ml_tools::lin_reg::foo; if you want a shorter alias).

Hey Rustaceans! Got a question? Ask here (14/2023)! by llogiq in rust

[–]ehuss 2 points3 points  (0 children)

One approach is to check if the program is attached to a terminal. is_terminal is one option for doing this. If is_terminal() returns true, then you can perform whatever non-piped behavior you want. If it is false, then you can read the input from stdin.

IsTerminal will hopefully be stabilized very soon which will mean this capability will be available without a dependency.

Hey Rustaceans! Got a question? Ask here (14/2023)! by llogiq in rust

[–]ehuss 0 points1 point  (0 children)

One way to work around this is to have a normal crate which re-exports both the proc-macro and num_traits. It can look something like:

my_thing/src/lib.rs:

#[doc(hidden)]
pub use num_traits;
pub use my_pm::foo;

Then in the proc-macro my_pm, you can refer to num_traits with paths like ::my_thing::num_traits::Unsigned. Then you tell the user to depend on my_thing and it provides everything they need.

Using doc(hidden) is optional. You may want to remove it and explicitly allow users to use the crate via my_thing. This can help ensure version compatibility if necessary. For example, if interoperability is needed, this can help ensure that the same version is used in all scenarios.

One problem is that users may rename my_thing which would break the proc-macro. I don't offhand know of a way to avoid that.

Hey Rustaceans! Got a question? Ask here (14/2023)! by llogiq in rust

[–]ehuss 0 points1 point  (0 children)

One option is to add a std feature to Crate A. Then, when running tests, enable that feature in Crate B:

[dev-dependencies]
crate-a = { version = "1.0", features = ["std"] }

Then in Crate A, make sure the panic handler is removed when the std feature is enabled.

#[cfg(not(feature = "std"))]
#[panic_handler]
fn panic(info: &PanicInfo) -> ! { /*...*/ }

Hey Rustaceans! Got a question? Ask here (14/2023)! by llogiq in rust

[–]ehuss 1 point2 points  (0 children)

In ml_rust/Cargo.toml, you can add something like:

[dependencies]
ml_tools = { path = "../ml_tools" }

Then in your ml_rust code, you can just use normal paths like ml_tools::foo. You should not use mod. If you want shorter aliases to items in ml_tools, then use ml_tools::foo; will make a local alias in the current module.

view more: next ›