These are chat archives for rust-lang/rust

4th
Mar 2018
Daniel Bischof
@dbischof90
Mar 04 2018 00:07
I have a somehow simple question about cross-compiling with cargo. Someone there?
Denis Lisov
@tanriol
Mar 04 2018 00:10
Just ask, someone may come and see it later :-)
Daniel Bischof
@dbischof90
Mar 04 2018 00:12
Yeah, possible :D
So I'm playing a little bit with the corr-compiler. I want to crosscompile something to a statically linked armv7, which needs another linker (from the openwrt SDK). I found the right packages and I'm now a little confused which one the linker actually is. I have worked a little bit with c++ but never had to care about these things
*cross-compiler
must be something in the line of arm-openwrt-linux-muslgnueabi-gcc
but there are roughly 10 binaries in there starting with that, for example the gnu debugger, the compiler... etc. what does cargo need now?
Daniel Bischof
@dbischof90
Mar 04 2018 00:18
Although wait, I think I got it
Denis Lisov
@tanriol
Mar 04 2018 00:19
Not sure about musl, but my arm config is
[target.arm-unknown-linux-gnueabihf]
ar = "arm-linux-gnueabihf-gcc-ar"
linker = "arm-linux-gnueabihf-gcc"
Daniel Bischof
@dbischof90
Mar 04 2018 00:19
Yes, that's mine too
I'm trying to compile some package for OpenWRT, which requires musl
Out of interest, why do you specify that 'ar'?
Denis Lisov
@tanriol
Mar 04 2018 00:22
Don't remember, looks like the current version of that software builds without it.
Daniel Bischof
@dbischof90
Mar 04 2018 00:58
Great, I got it working!
mhsjlw
@mhsjlw
Mar 04 2018 03:47
Is it recommended that I use gfx-rs, or glium?
(I mean, which to use)
Michal 'vorner' Vaner
@vorner
Mar 04 2018 07:24
@dbischof90 I did play with compiling for OpenWRT some time ago and managed to link dynamically against the in-device musl even. As I remember, I pushed hello-world down under 100kB. There't not much description, but this thing worked some time ago (might need some little adjustments, it's been some time): https://github.com/vorner/xcompile
Daniel Bischof
@dbischof90
Mar 04 2018 07:38
I got some small thing working, but a larger project failed. It seems that one of its dependencies can't be linked statically (rust-crypto). Dang.
Michal 'vorner' Vaner
@vorner
Mar 04 2018 07:48
Then you can try the dynamic linking (make sure the required library is provided by the OpenWRT, though)
Restioson
@Restioson
Mar 04 2018 07:49
Does rust use dwarf or dwarf2?
Daniel Bischof
@dbischof90
Mar 04 2018 07:59
How? So with standard gnuabi instead of musl?
Michal 'vorner' Vaner
@vorner
Mar 04 2018 08:00
No. You can make your own target description that links musl dynamically. Look at the repo I posted above.
Though it requires nightly and xargo to build the target for you.
Daniel Bischof
@dbischof90
Mar 04 2018 08:01
Okay, I will. New topic for me, that was just touch and try before.
ah dang. :smile:
Michal 'vorner' Vaner
@vorner
Mar 04 2018 08:02
I'm no expert there either. I probably just spent longer time with the trial & error approach.
Restioson
@Restioson
Mar 04 2018 08:03
ah shit
is there any way i can trace where tf a result comes from in my try chain?
Michal 'vorner' Vaner
@vorner
Mar 04 2018 08:11
@Restioson In general no. Debugger might help and some error-related crates (failure) sometimes bundle a backtrace for the error.
Restioson
@Restioson
Mar 04 2018 08:13
:L
Restioson
@Restioson
Mar 04 2018 08:28
found iit
Daniel Bischof
@dbischof90
Mar 04 2018 09:15
@vorner I'm actually not sure whether it's the dynamical linking alone. The PR I was referring to is already a little older. The error message I have during compile is
thread 'main' panicked at '                                                                                                                                            │
                                                                                                                                                                       │
Internal error occurred: Failed to find tool. Is `arm-linux-musleabihf-gcc` installed?                                                                                 │
                                                                                                                                                                       │
',
And I supply this through my cargo config.
All other packages build with it. Why not this one?
Denis Lisov
@tanriol
Mar 04 2018 09:17
@dbischof90 Is arm-linux-musleabihf-gcc in your $PATH?
Daniel Bischof
@dbischof90
Mar 04 2018 09:18
It looks like it isn't, right. I thought so, rust-crypto is some dependency and so far seemingly the only one failing. What could be the reason?
I have added it explicitly to the path now, let's see.
Denis Lisov
@tanriol
Mar 04 2018 09:26
The Rust crates use it as a linker and are ok with the linker key in .cargo/config. However, rust-crypto uses the compiler from a build script to compile some helpers.
Daniel Bischof
@dbischof90
Mar 04 2018 09:33
Ah, overlooked that
Hm. So possibly with that left out
Daniel Bischof
@dbischof90
Mar 04 2018 09:55
Okay, I'm getting closer. Indeed, modifying the build script accordingly did help so far.

Now I get the following error:

error: linker `/./tmp/bin/arm-openwrt-linux-muslgnueabi-gcc` not found

my cargo config contains

[target.armv7-unknown-linux-musleabihf]
linker = "./tmp/bin/arm-openwrt-linux-muslgnueabi-gcc"
Michal 'vorner' Vaner
@vorner
Mar 04 2018 11:41
You probably should use absolute path
Sardor Muminov
@muminoff
Mar 04 2018 12:31

Hello everyone. I am beginner.
I am having some misunderstanding with calculating sum of vector items.

This code snippet taken from official works:

fn main() {
    let a = [1, 2, 3];
    let sum: i32 = a.iter().sum();

    assert_eq!(sum, 6);
}

And, this is my code.

const MAX: u8 = 10u8;

fn main() {
    let mut all_numbers = vec![1..MAX + 1];
    let sum: i32 = all_numbers.iter().sum();
    println!("{}", sum);
}

I thought, my code should work. But it doesn't.
It is raising following error:

error[E0277]: the trait bound `i32: std::iter::Sum<&std::ops::Range<u8>>` is not satisfied
 --> src/main.rs:5:39
  |
5 |     let sum: i32 = all_numbers.iter().sum();
  |                                       ^^^ the trait `std::iter::Sum<&std::ops::Range<u8>>` is not implemented for `i32`
  |
  = help: the following implementations were found:
            <i32 as std::iter::Sum>
            <i32 as std::iter::Sum<&'a i32>>

What am I doing wrong here?

Should I change type i32 to u8 ?
Michal 'vorner' Vaner
@vorner
Mar 04 2018 12:33
Just remove that type after the sum.
The types must match. But if you don't write the type, you let the compiler deduce it from other things.
Sardor Muminov
@muminoff
Mar 04 2018 12:34
Removed type after sum and got this error.
  |
5 |     let sum = all_numbers.iter().sum();
  |         ^^^
  |         |
  |         cannot infer type for `_`
  |         consider giving `sum` a type
Michal 'vorner' Vaner
@vorner
Mar 04 2018 12:34
Hmm, so you probably need to type explicit :u8.
Sardor Muminov
@muminoff
Mar 04 2018 12:35
I thought it should be trivial to get the result.
Refactored the code:
const MAX: u8 = 10;

fn main() {
    let mut all_numbers = [1..MAX + 1];
    let sum: u8 = all_numbers.iter().sum();
    println!("{}", sum);
}
No success.
Error:
  |
5 |     let sum: u8 = all_numbers.iter().sum();
  |                                      ^^^ the trait `std::iter::Sum<&std::ops::Range<u8>>` is not implemented for `u8`
  |
  = help: the following implementations were found:
            <u8 as std::iter::Sum>
            <u8 as std::iter::Sum<&'a u8>>
I think, the problem is in initializing the vector.

This works.

let mut all_numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];

But this doesn't.

let mut all_numbers = [1..MAX + 1];
Michal 'vorner' Vaner
@vorner
Mar 04 2018 12:44
Ah, right. Because 1..MAX + 1 isn't bunch of numbers. It's an object of type Range ‒ and just one such object. But you can iterate over that object.
So you can do let all_numbers = 1..MAX + 1;.
You can call sum directly on that. But note that it is iterator itself, so it is used up by the .sum().
Sardor Muminov
@muminoff
Mar 04 2018 12:47
Thanks @vorner
David Harvey-Macaulay
@alteous
Mar 04 2018 13:49
It seems the crates.io UI is not rendered on neither Safari nor Firefox on iOS. Only the green background is visible. Is anybody else experiencing this?
Ryan Levick
@rylev
Mar 04 2018 13:49
Hello! If I have a &mut String and I want the contents of that string to be completely replaced by the contents of another String, is there a more efficient way than to original_string.clear() and original_string.push_str(&other_string)?
David Harvey-Macaulay
@alteous
Mar 04 2018 14:09
@rylev You could take ownership with *original_string = other_string, otherwise you will have to copy as you have described.
Ryan Levick
@rylev
Mar 04 2018 14:15
Cool. Thanks! I think I was running into issues with that strategy before because I had a &mut str and not a &mut String. I tried it and it worked :-D
TatriX
@TatriX
Mar 04 2018 17:11
Hi. I'm trying to write some test for an rest api. Some tests obviously depends on the others. For example you can't login before you register a user. Or you can't delete an article, before you created it. So I need a way to define the order for tests. What's the best way to achieve that?
Michal 'vorner' Vaner
@vorner
Mar 04 2018 17:14
If you want to do that with the built-in framework, then there's no way to order them. But you can write the prerequisites as functions and call them before each test. The best practices say you should always start with well defined state (not to be influenced by other tests).
Or you can put all the testing into one long test, if there's a real order.
Or you can do it manually/with some other crate and configure cargo not to include the built-in harness for that test file.
TatriX
@TatriX
Mar 04 2018 17:16
I see, thanks!
Michal 'vorner' Vaner
@vorner
Mar 04 2018 17:21
(look through crates.io ‒ there might be some testing framework to help you with your use case, I'm only stating that the default one insists on tests being independent of each other)
Songbird0
@Songbird0
Mar 04 2018 18:13

Hi there,

I have a somewhat awkward problem. I got a ParseIntError { kind: InvalidDigit } while unwrapping my value when I try to parse it from keyboard. What have I done wrong? I didn't find anything on the web about it.

        let mut buffer = String::new();
        match io::stdin().read_line(&mut buffer) {
            Ok(content) => {
                let answer: usize = buffer.parse().unwrap(); // panic! here
               /* ... */
                println!("{} bytes read", content);
                println!("Your answer: {}", buffer)
            },
            Err(err) => println!("Uhoh: {}", err),
        }

CLI:

Write your prose:
55
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ParseIntError { kind: InvalidDigit }', src\libcore\result.rs:916:5

rustc --version: rustc 1.24.1 (d3ae9a9e0 2018-02-27)
cargo --version: cargo 0.25.0 (96d8071da 2018-02-26)

Denis Lisov
@tanriol
Mar 04 2018 18:15
@Songbird0 Try buffer.trim().parse()
Songbird0
@Songbird0
Mar 04 2018 18:16
facepalm
Thanks @tanriol. It works!
Michal 'vorner' Vaner
@vorner
Mar 04 2018 19:39
I wondering. If I look at C++'s std::list, it has a nice property. It's iterators are not invalidated by changes to the list provided the item itself isn't removed. So one can store the iterator somewhere else, update the event while in the list, etc. But such „handle“ to an element seems somehow against the rules of Rust. So, how do people work around that? My question isn't directly about linked lists, but I wondered how I'd go about writing a dijkstra's algorithm. And it is nice if I can keep a handle into the heap, so I can call decrease on it (and the heap will bubble the element to the right place).
Denis Lisov
@tanriol
Mar 04 2018 19:44
@vorner Do you really need a handle deep into the heap for a Dijkstra's algorithm?
Michal 'vorner' Vaner
@vorner
Mar 04 2018 19:49
Well, you could put duplicate elements into the heap instead of decreasing them. But that'll take more memory and longer time. But it's not the only one ‒ a combination of std::map and std::list can be made to a lru-size-limited data structure with lookup, for example. So my question is more general ‒ if I wanted to do such things, how would I go about designing the API of a collection that allows keeping handles to the elements?
Denis Lisov
@tanriol
Mar 04 2018 20:00
I'd start thinking from the Rc side of things...
Michal 'vorner' Vaner
@vorner
Mar 04 2018 20:02
Right, I was thinking a bit in that direction. But I was curious if there's some commonly used trick.
Clvtor
@clvtor
Mar 04 2018 21:26
which crate to use for importing/exporting JSON data from files and web ?