These are chat archives for rust-lang/rust

13th
Aug 2018
mnivoliez
@mnivoliez
Aug 13 2018 10:01
Hello! I was wondering if there is an idiomatic way to map all values of a btree to a vec, knowing that the btree will not be needed after? The tree.values().cloned().collect()way seems too expensive compared to the aimed goal.
Paul Masurel
@fulmicoton
Aug 13 2018 10:03
Have you tried .into_iter()?
mnivoliez
@mnivoliez
Aug 13 2018 10:04
it seems not to work
Paul Masurel
@fulmicoton
Aug 13 2018 10:04
(You need to apply map to remove the key)
Andrey Lesnikov
@ozkriff
Aug 13 2018 10:04
https://play.rust-lang.org/?gist=7cf0fbb700a34a09f25339cfb019c8ec - .values().into_iter().collect() seems to work fine
mnivoliez
@mnivoliez
Aug 13 2018 10:07
error[E0277]: the trait bound `std::vec::Vec<structure::Player>: std::iter::FromIterator<&structure::Player>` is not satisfied
   --> src\structure.rs:333:51
    |
333 |     let players = player_map.values().into_iter().collect();
    |                                                   ^^^^^^^ a collection of type `std::vec::Vec<structure::Player>` cannot be built from an iterator over elements of type `&structure::Player`
    |
    = help: the trait `std::iter::FromIterator<&structure::Player>` is not implemented for `std::vec::Vec<structure::Player>`
Dmitriy
@dpogretskiy
Aug 13 2018 10:08
values is an iter that borrows
should be something like btmap.into_iter().map(|(_, x) x|).collect()
mnivoliez
@mnivoliez
Aug 13 2018 10:08
I have tried to deference using map but I cannot move out of borrowed content
@dpogretskiy that seems too work! thank you
Dmitriy
@dpogretskiy
Aug 13 2018 10:10
no problems :smiley:
Alon Regev
@AregevDev
Aug 13 2018 15:49

Hello and good evening:
I have a problem with the compilation of Rust to Linux x86_64:
I have made a simple project with Cargo and written sample code,
cargo runs as usual and builds the executable file, I can run the executable but when I click on properties I can see the file type is application/x-sharedlib instead of application/x-executable.

Anyone can help me or have an idea what is going on?

I am using Linux Mint 19 cinnamon and Rust toolchain 28.0.
Thanks

Alon Regev
@AregevDev
Aug 13 2018 15:56
image.png
Denis Lisov
@tanriol
Aug 13 2018 15:57
@AregevDev The filetype identification here is a bit weird, but it's an executable :-)
Alon Regev
@AregevDev
Aug 13 2018 15:58
So it is not on my side?
Denis Lisov
@tanriol
Aug 13 2018 16:00
Yes, PIE executables can be misdetected as shared libraries in the UI. They are still correct and will execute :-)
Alon Regev
@AregevDev
Aug 13 2018 16:01
I see thanks
Zakarum
@omni-viral
Aug 13 2018 20:20
Is there a crate that helps to avoid unexpected results when workibg with differently sized integers?
For example I need to store a value that must fit in both usize and u64, whatever smallest
Lyle Mantooth
@IslandUsurper
Aug 13 2018 20:25
@omni-viral, does Rust even support usize bigger than u64? Or are you worried about compiling on a system with 32-bit pointer sizes?
Denis Lisov
@tanriol
Aug 13 2018 20:26
@omni-viral What kinds of unexpected results do you mean?
Zakarum
@omni-viral
Aug 13 2018 20:45
@tanriol as <integer> drops major bits if not fit. So if I multiply usize and u64 I can get result that doesn't fit in one of them. So at one time I need type that is smaller of two and at another the bigger
Denis Lisov
@tanriol
Aug 13 2018 20:49
If you multiply usize and u64, you get a compile-time error :-)
Speaking about as, that's why clippy suggests, for example, u64::from(my_usize) instead of my_usize as u64
Zakarum
@omni-viral
Aug 13 2018 20:50
I have two options.
For x: usize and y: u64 I can do:
  • x as u64 * y
  • x * y as usize
u64 doesn't implement From<usize> according to docs
Because usize can be bigger
So. For above two options either of them can lose significant bits
While overflow in multiplication will panic in debug as will drop bits silently
Denis Lisov
@tanriol
Aug 13 2018 20:54
Hmm... sorry, I expected it to implement it...