Adding time and rand crates for Rust

Feedback & Bugs
#16

Thanks @MaximeC ,

I did some test, I didn’t have the same result, but the same fact cargo is longer if it do everything (including download and build crates/lib).

If you’re ok to keep the compiled crates in the image (docker, ABI,… what you use) I should have a solution:

  1. use cargo to download the crates and store them on the image
  2. use rustc with thoses downloaded files.
    I could upload the project on github
➜  codingame cargo new cg_rust --bin

➜  codingame cd cg_rust

➜  cg_rust git:(master) ✗ cat >>Cargo.toml <<EOF
time = "0.1"
rand = "0.3"
EOF

➜  cg_rust git:(master) ✗ time cargo build
    Updating registry `https://github.com/rust-lang/crates.io-index`
   Compiling libc v0.2.16
   Compiling winapi-build v0.1.1
   Compiling winapi v0.2.8
   Compiling kernel32-sys v0.2.2
   Compiling rand v0.3.14
   Compiling time v0.1.35
   Compiling cg_rust v0.1.0 (file:///Users/davidb/share/codingame/cg_rust)
cargo build  4.11s user 0.92s system 40% cpu 12.366 total

➜  cg_rust git:(master) ✗ cat >src/main.rs <<EOF
extern crate time;
extern crate rand;
use rand::random;

fn main() {
    let t0 = time::precise_time_ns();
    let r: i32 = random::<i32>();
    println!("Hello, world! time: {} random: {}", t0, r);
}
EOF

➜  cg_rust git:(master) ✗ time cargo build
   Compiling cg_rust v0.1.0 (file:///Users/davidb/share/codingame/cg_rust)
cargo build  0.15s user 0.06s system 95% cpu 0.227 total

➜  cg_rust git:(master) ✗ time cargo run
     Running `target/debug/cg_rust`
Hello, world! time: 227654162133799 random: -1360491862
cargo run  0.04s user 0.02s system 93% cpu 0.073 total

➜  cg_rust git:(master) ✗ time target/debug/cg_rust
Hello, world! time: 227670286303399 random: 1928059675
target/debug/cg_rust  0.00s user 0.00s system 69% cpu 0.004 total

➜  cg_rust git:(master) ✗ time rustc src/main.rs --extern rand=target/debug/deps/librand-6fab17fc670a2bc8.rlib -L target/debug/deps -O
rustc src/main.rs --extern  -L target/debug/deps -O  0.10s user 0.03s system 77% cpu 0.170 total

➜  cg_rust git:(master) ✗ time ./main
Hello, world! time: 227722446534341 random: -1796789735
./main  0.00s user 0.00s system 71% cpu 0.004 total

So you could copy the target/debug/deps directory of the project and use it as dependencies lib.
Using rustc -L deps with this directory should be enough but it seems that rust© already include a rand carte (bug https://github.com/flycheck/flycheck-rust/issues/11), so we have to explicitly define the “rand” crate with “–extern rand=…” (the hash number could be different in your environment).

Thanks again for your time, It would be awasome if you could include time and rand crates (and -O) for the next contest.

Sorry for the long post, I hope I give you all the info.

PS: as you can see, only override the main.rs into already pre-build cargo project could also be a solution, compile time are very similar between rustc (0.10s) and cargo build (0.15s)

3 Likes
#17

Thank you for your message. I’ve put on hold my work on Rust because I needed to work on another project but hopefully I’ll be able to work on that soon.

Our current problem is that the container is reinitialized after each build+execution and as shown in your experiments, building with cargo for the first time is slow (4.11s user in your case).

I agree with your suggestion to keep the compiled crates on the system. Actually, didn’t have the time to investigate, but there might be a way to specify the path of the crates in the Cargo.toml file. But the solution using rustc would be fine too.

2 Likes
#18

You can specify a path to the .rlib files using rustc:

rustc src/main.rs -L dependency=/path/to/rand/target/debug/deps/ \
    --extern rand=/path/to/rand/target/debug/deps/librand.rlib
1 Like
#19

Thanks david_bernard_31 & bouanto, I’ve added the rlibs using rustc.

4 Likes
#20

Thanks for your efforts! Time measuring works fine now! Much better options for this contest. :slight_smile:

1 Like
#21

It seems that “extern crate time;” aborts again. :disappointed:
Has there been any changes in here or I made some mistakes?

#22

I got this error when I trying to use the ‘rand’

  error[E0463]: can't find crate for `rand`
     --> /tmp/Answer.rs:6:1
      |
    6 | extern crate rand;
      | ^^^^^^^^^^^^^^^^^^ can't find crate

    error: aborting due to previous error
#23

Oh no :frowning: . We’ve upgraded Rust recently… Sorry for the inconvenience! I didn’t see your message until now, I’ll have a look to it tomorrow.

#24

@Coac @geot it should be fixed (at least for the challenge)

#25

Thank you :slight_smile:

#26

Thanks for the quick solution! :slight_smile:

#27

Hello,

Could it be possible to update the FAQ in order to add the information that rand and time are available ?

1 Like
#28

Would you be willing to also add the itertools crate? It provides functionality similar to itertools in Python and really helps with some basic things. For example in Python you can split a string s (for example the input string) as follows:

a, b, c, d = s.split()

With itertools in Rust, you can write something similar.

use itertools::Itertools;

let (a, b, c, d) = s.split_whitespace().next_tuple.unwrap();

(Although, I can think of other ways to code this example as well without the crate, so it is not the end of the world if it can’t be added.)

#29

@_CG_Maxime I do have this error again while using crate rand perhaps due to the recent langage update:

error[E0463]: can't find crate for `rand`
 --> /tmp/Answer.rs:1:1
  |
1 | extern crate rand;
  | ^^^^^^^^^^^^^^^^^^ can't find crate

error: aborting due to previous error

Could you fix it please?
Thx
Guillaume

#30

Hello,

This is fixed. Please check this is working as expected now.

3 Likes
#31

Lo,
It works many thanks :slight_smile:

#32

Is there any way to know what crates are available for us to use? rand and time are great. Anything else?

1 Like
#33

Would it be possible to add lazy_static? IMO this is basic functionality as C++ and Java have it built in.

1 Like
Cannot use lazy_static in Rust
#34

available in the faq (/faq)

image

about lazy_static, I don’t know. I’ll check.

#35

I think time is not needed any more. The original proposal was from before the release of Rust 1.8.0, which introduced std::time::Instant and std::time::SystemTime.
I agree that lazy_static would be quite useful to introduce.

And everything else should be updated. I have recently had to work around a couple functions (such as Iterator::step_by) not yet existing in 1.27.