error: failed to select a version for the requirement `ring = "^0.11.0"`
  candidate versions found which didn't match: 0.16.11, 0.16.10, 0.16.9, ...
  location searched: crates.io index
required by package `cookie v0.9.1`
    ... which is depended on by `rocket v0.3.0`
    ... which is depended on by `ch1-time-api v0.1.0

I'm not really sure how to fix it, but it won't compile. Listing 1.2 on page 9.

I tried updating rust, etc but nothing changed

Obviously I'm at the start of the book so can't offer much help, but if I figure out the solution I'll leave a reply here.

all_rows doesn't exist in this scope: https://github.com/rust-in-action/code/blob/7d7955e9605ca156f6eb7cb5bc9f124c97927d25/ch2/ch2-mandelbrot/src/main.rs#L28

Hey - want to start out by saying thank again for the great book!

The insert_but_ignore_index code appears incorrect to me. If the underlying file is pointing at position in_the_middle when insert is called, the KV will be correctly appended at the end of the file, but the index will say the KV is at position in_the_middle

https://github.com/rust-in-action/code/blob/e23c70ec1cb9e9b9037f364b8edfa6ee882e8f77/ch7/ch7-actionkv2/src/lib.rs#L174-L182

I wrote test_index_maintenance to confirm my suspicion, expecting it to fail. But the test passes!

To understand what was happening, I altered get_at to print out the file' position after performing the read - and then the test fails!

    pub fn get_at(&mut self, position: u64) -> io::Result<KeyValuePair> {
        let mut f = BufReader::new(&mut self.f);
        f.seek(SeekFrom::Start(position))?;
        let kv = ActionKV::process_record(&mut f)?;

        // Even though `f.seek` does take `&mut self`, my understanding is calling it
        // with `SeekFrom::Current(0)` simply says "where am I at in the stream" without
        // altering anything. In fact there's even a convenience function that claims
        // exactly this: https://doc.rust-lang.org/std/io/trait.Seek.html#method.stream_position
        //
        // However, commenting these two lines makes `test_index_maintenance` pass
        let final_pos = f.seek(SeekFrom::Current(0))?;
        println!("after reading at {}, final_pos is {}", position, final_pos);
        Ok(kv)
    }

So now there's at least these few options on what's going on.

1. .seek(SeekFrom::Current(0)) is not actually a functional no-op, and calling it breaks the system in some expected way. i.e. what I thought looked like a bug in .insert isn't a bug.
2. There is a bug in .insert and for some magic the .seek(SeekFrom::Current(0)) sheds light on it. (Maybe something due to the extra buffer flush?
3. .seek(SeekFrom::Current(0)) is intended to be a no-op, but there is a bug in it that this case triggered.

I'd assume 1 is by far the most likely, followed by 2 and then 3 a long way off.

Either way hope this helps and interested to hear what the answer is!

(Related: #4 since it also mentions the in memory index)

Hi, thanks for the book and the much helping source code. I think I found a problem here: https://github.com/rust-in-action/code/blob/cff02d525ac50a1aa16dafba9780da66fc6d6661/ch9/ch9-clock3/src/main.rs#L41-L44 Per the definition in https://en.wikipedia.org/wiki/Network_Time_Protocol your code should be let offset = (self.t2 - self.t1) + (self.t3 - self.t4);

Both this code and the book wording threw me off balance enough to check the wikipedia article, as your code doesn't have any difference between delta and theta, except for the 2 factor. their fixed definitions makes much more sense.

https://github.com/rust-in-action/code/blob/7d7955e9605ca156f6eb7cb5bc9f124c97927d25/ch2/ch2-mandelbrot/src/main.rs#L73-L74

This should be calculate_mandelbrot(1000, -2.0, 1.0, -1.0, 1.0, 80, 24) as mentioned in https://www.reddit.com/r/rust/comments/o980ip/rust_in_action_is_released/h3aktuf

I wasn't able to run the basic starting example. The shown configuration and tools are both incomplete and not updated. When trying to build using bootimage, the command is now different (cargo bootimage) and in particular there was an error about not being able to find the crate core.

It's thus incomplete because cargo-xbuild is installed but not actually used. Fortunately, I knew there was another tutorial on writing a kernel with Rust where I found the updated information: https://os.phil-opp.com/minimal-rust-kernel/

Basically, with Rust nightly 2020–07–15, we can now just simply write this in .cargo/config.toml:

[unstable]
build-std = ["core", "compiler_builtins", "alloc"]

Also this is much better because I was also able, with the latest version which fixed a bug with the nightly toolchain, to continue using rust-analyzer in vscode. OTOH, you are left with no intellisense with cargo-xbuild.

I hope this info will be helpful for someone, you can see the source code of the chapter with updated configuration at https://github.com/jiayihu/lab/tree/master/rust/fledge-os

The code seems to use pre rust-2018 conventions. For example in the first chapter the code:

extern crate serde_derive;   // <3>
...
#[derive(Serialize)] // <6> Automatically generate a string representation of this struct (which will be used as JSON)
struct Timestamp { // <7> Syntax to create a custom type 

Can be re-written as

use serde::Serialize;
...
#[derive(Serialize)] // <6> Automatically generate a string representation of this struct (which will be used as JSON)
struct Timestamp { // <7> Syntax to create a custom type 

I am new to Rust but when I run the chapter 2-complex example codes, then there is an error like below.

error[E0658]: use of unstable library feature 'dec2flt': internal routines only exposed for testing
 --> src/main.rs:1:5
  |
1 | use core::num::dec2flt::number;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^

Rust & Cargo version

• 1.62.0

Bumps smallvec from 0.6.9 to 0.6.14.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

I try to build mget on rust v1.60 on mac and the build fails because of:

➜  ch8-mget git:(1st-edition) ✗ cargo build
   Compiling mget v0.1.0 (/Users/adria/Programming/rust-in-action/ch8/ch8-mget)
error[E0432]: unresolved import `smoltcp::phy::TapInterface`
 --> src/main.rs:2:5
  |
2 | use smoltcp::phy::TapInterface;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^ no `TapInterface` in `phy`

error[E0432]: unresolved import `smoltcp::phy::TapInterface`
 --> src/http.rs:7:38
  |
7 | use smoltcp::phy::{wait as phy_wait, TapInterface};
  |                                      ^^^^^^^^^^^^ no `TapInterface` in `phy` 

I also had to modify Cargo.toml because curly bracket content cannot be separated over several lines.

In my IDE, I can however see that TapInterface exists. Any idea?

OS: MacOS

When in the root ch6-particles crate created with cargo, the following error is generated:

zsh: illegal hardware instruction  cargo run

Oddly, the programs behaves as expected (well, without the standard output) when commenting out the eprintln! line.

From my findings so far this appears to an OS specific issue and any suggestions would be much appreciated!

The book has the following input for the ch10-render-hex project

$ cargo run -- $(
>   echo 'Rust in Action' |
>   sha1sum |
>   cut -f1 -d' '
> )

However on Mac OS X, the tool is shasum and not sha1sum, and works great with the following input

$ cargo run -- $(
>   echo 'Rust in Action' |
>   shasum |
>   cut -f1 -d' '
> )

Just thought I should share for the author or anyone else searching for why they're getting "Opps, all Noops!" in their cereal box.

Very cool project, and great book. Thanks!

Errors:

1. feature = "const_fn", feature(const_fn) has been removed
2. cannot find macro asm in this scope

Steps to fix:

1. Clear the cargo cache so that the old dependencies are not picked up (can use this cargo-cache crate, or google this up).
2. Update the following packages to the new versions as specified below.

[dependencies]
bootloader = "0.9.22"
x86_64 = "0.14.10"

3. Code should build and run as expected.

In https://github.com/rust-in-action/code/blob/1st-edition/ch9/ch9-clock3/src/main.rs#L40-L50:

impl NTPResult {
  fn offset(&self) -> i64 {
    let delta = self.delay();
    delta.abs() / 2
  }

  fn delay(&self) -> i64 {
    let duration = (self.t4 - self.t1) - (self.t3 - self.t2);
    duration.num_milliseconds()
  }
}

The definition of offset is incorrect (source on Wikipedia). Offset can be positive or negative, whereas delay is always positive. You can see that the equations above always return positive values.

Offset should let delta = (self.t2 - self.t1) - (self.t3 - self.t4);. Currently, it rearranges to let delta = (self.t2 - self.t1) - (self.t4 - self.t3);, i.e. the last two terms are swapped.

(I see there was an attempt to correct in #51, but as the OP later noted, the PR did not fix the issue.)