chore(hints): update hints to be consistent

added hint for tests3 and formatted other hints
This commit is contained in:
Zerotask 2021-04-25 00:01:01 +02:00
parent 22ceff7379
commit 07f7caa5f4
No known key found for this signature in database
GPG key ID: 1C87F67E23FCB283

View file

@ -51,6 +51,7 @@ using a special keyword. Unfortunately this doesn't help us much in this exercis
because we want to assign a different typed value to an existing variable. Sometimes because we want to assign a different typed value to an existing variable. Sometimes
you may also like to reuse existing variable names because you are just converting you may also like to reuse existing variable names because you are just converting
values to different types like in this exercise. values to different types like in this exercise.
Fortunately Rust has a powerful solution to this problem: 'Shadowing'! Fortunately Rust has a powerful solution to this problem: 'Shadowing'!
You can read more about 'Shadowing' in the book's section 'Variables and Mutability': You can read more about 'Shadowing' in the book's section 'Variables and Mutability':
https://doc.rust-lang.org/book/ch03-01-variables-and-mutability.html#shadowing https://doc.rust-lang.org/book/ch03-01-variables-and-mutability.html#shadowing
@ -146,7 +147,7 @@ For that first compiler error, it's important in Rust that each conditional
block return the same type! To get the tests passing, you will need a couple block return the same type! To get the tests passing, you will need a couple
conditions checking different input values.""" conditions checking different input values."""
# TEST 1 # QUIZ 1
[[exercises]] [[exercises]]
name = "quiz1" name = "quiz1"
@ -202,6 +203,7 @@ mode = "compile"
hint = """ hint = """
Stop reading whenever you feel like you have enough direction :) Or try Stop reading whenever you feel like you have enough direction :) Or try
doing one step and then fixing the compiler errors that result! doing one step and then fixing the compiler errors that result!
So the end goal is to: So the end goal is to:
- get rid of the first line in main that creates the new vector - get rid of the first line in main that creates the new vector
- so then `vec0` doesn't exist, so we can't pass it to `fill_vec` - so then `vec0` doesn't exist, so we can't pass it to `fill_vec`
@ -425,7 +427,7 @@ Yes, it would be really easy to fix this by just changing the value bound to `wo
string slice instead of a `String`, wouldn't it?? There is a way to add one character to line string slice instead of a `String`, wouldn't it?? There is a way to add one character to line
9, though, that will coerce the `String` into a string slice.""" 9, though, that will coerce the `String` into a string slice."""
# TEST 2 # QUIZ 2
[[exercises]] [[exercises]]
name = "quiz2" name = "quiz2"
@ -484,13 +486,11 @@ at the test helper function `test_with_str`, since it returns whatever
`read_and_validate` returns and `test_with_str` has its signature fully `read_and_validate` returns and `test_with_str` has its signature fully
specified. specified.
Next hint: There are three places in `read_and_validate` that we call a Next hint: There are three places in `read_and_validate` that we call a
function that returns a `Result` (that is, the functions might fail). function that returns a `Result` (that is, the functions might fail).
Apply the `?` operator on those calls so that we return immediately from Apply the `?` operator on those calls so that we return immediately from
`read_and_validate` if those function calls fail. `read_and_validate` if those function calls fail.
Another hint: under the hood, the `?` operator calls `From::from` Another hint: under the hood, the `?` operator calls `From::from`
on the error value to convert it to a boxed trait object, a Box<dyn error::Error>, on the error value to convert it to a boxed trait object, a Box<dyn error::Error>,
which is polymorphic-- that means that lots of different kinds of errors which is polymorphic-- that means that lots of different kinds of errors
@ -499,20 +499,18 @@ since they all implement the `error::Error` trait.
Check out this section of the book: Check out this section of the book:
https://doc.rust-lang.org/book/ch09-02-recoverable-errors-with-result.html#a-shortcut-for-propagating-errors-the--operator https://doc.rust-lang.org/book/ch09-02-recoverable-errors-with-result.html#a-shortcut-for-propagating-errors-the--operator
Another another hint: Note that because the `?` operator returns Another another hint: Note that because the `?` operator returns
the *unwrapped* value in the `Ok` case, if we want to return a `Result` from the *unwrapped* value in the `Ok` case, if we want to return a `Result` from
`read_and_validate` for *its* success case, we'll have to rewrap a value `read_and_validate` for *its* success case, we'll have to rewrap a value
that we got from the return value of a `?`ed call in an `Ok`-- this will that we got from the return value of a `?`ed call in an `Ok`-- this will
look like `Ok(something)`. look like `Ok(something)`.
Another another another hint: `Result`s must be "used", that is, you'll Another another another hint: `Result`s must be "used", that is, you'll
get a warning if you don't handle a `Result` that you get in your get a warning if you don't handle a `Result` that you get in your
function. Read more about that in the `std::result` module docs: function. Read more about that in the `std::result` module docs:
https://doc.rust-lang.org/std/result/#results-must-be-used""" https://doc.rust-lang.org/std/result/#results-must-be-used"""
# Generics # GENERICS
[[exercises]] [[exercises]]
name = "generics1" name = "generics1"
@ -639,9 +637,10 @@ mode = "test"
hint = """ hint = """
You can call a function right where you're passing arguments to `assert!` -- so you could do You can call a function right where you're passing arguments to `assert!` -- so you could do
something like `assert!(having_fun())`. If you want to check that you indeed get false, you something like `assert!(having_fun())`. If you want to check that you indeed get false, you
can negate the result of what you're doing using `!`, like `assert!(!having_fun())`.""" can negate the result of what you're doing using `!`, like `assert!(!having_fun())`.
# TEST 3 To test if 2 arguments are equal, you can use the macro `assert_eq!()` (eq = equal). To test if
2 arguments differ, you can use the macro `assert_ne!()` (ne = not equal)"""
[[exercises]] [[exercises]]
name = "quiz3" name = "quiz3"
@ -686,6 +685,8 @@ is too much of a struggle, consider reading through all of Chapter 16 in the boo
https://doc.rust-lang.org/stable/book/ch16-00-concurrency.html https://doc.rust-lang.org/stable/book/ch16-00-concurrency.html
""" """
# ITERATORS
[[exercises]] [[exercises]]
name = "iterators1" name = "iterators1"
path = "exercises/standard_library_types/iterators1.rs" path = "exercises/standard_library_types/iterators1.rs"
@ -695,8 +696,10 @@ Step 1:
We need to apply something to the collection `my_fav_fruits` before we start to go through We need to apply something to the collection `my_fav_fruits` before we start to go through
it. What could that be? Take a look at the struct definition for a vector for inspiration: it. What could that be? Take a look at the struct definition for a vector for inspiration:
https://doc.rust-lang.org/std/vec/struct.Vec.html. https://doc.rust-lang.org/std/vec/struct.Vec.html.
Step 2 & step 2.1: Step 2 & step 2.1:
Very similar to the lines above and below. You've got this! Very similar to the lines above and below. You've got this!
Step 3: Step 3:
An iterator goes through all elements in a collection, but what if we've run out of An iterator goes through all elements in a collection, but what if we've run out of
elements? What should we expect here? If you're stuck, take a look at elements? What should we expect here? If you're stuck, take a look at
@ -779,14 +782,12 @@ mutate the data at a time. Take a look at this section of the book:
https://doc.rust-lang.org/book/ch16-03-shared-state.html#atomic-reference-counting-with-arct https://doc.rust-lang.org/book/ch16-03-shared-state.html#atomic-reference-counting-with-arct
and keep reading if you'd like more hints :) and keep reading if you'd like more hints :)
Do you now have an `Arc` `Mutex` `JobStatus` at the beginning of main? Like: Do you now have an `Arc` `Mutex` `JobStatus` at the beginning of main? Like:
`let status = Arc::new(Mutex::new(JobStatus { jobs_completed: 0 }));` `let status = Arc::new(Mutex::new(JobStatus { jobs_completed: 0 }));`
Similar to the code in the example in the book that happens after the text Similar to the code in the example in the book that happens after the text
that says "We can use Arc<T> to fix this.". If not, give that a try! If you that says "We can use Arc<T> to fix this.". If not, give that a try! If you
do and would like more hints, keep reading!! do and would like more hints, keep reading!!
Make sure neither of your threads are holding onto the lock of the mutex Make sure neither of your threads are holding onto the lock of the mutex
while they are sleeping, since this will prevent the other thread from while they are sleeping, since this will prevent the other thread from
being allowed to get the lock. Locks are automatically released when being allowed to get the lock. Locks are automatically released when
@ -846,7 +847,7 @@ You only need to add a single character to make this compile.
The way macros are written, it wants to see something between each The way macros are written, it wants to see something between each
"macro arm", so it can separate them.""" "macro arm", so it can separate them."""
# TEST 4 # QUIZ 4
[[exercises]] [[exercises]]
name = "quiz4" name = "quiz4"