This streamlines the text about editors by simply mentioning them.
RustRover is mentioned last since it's new and I don't have any
experience with it yet.
The licenses end up in the PO files, causing extra unnecessary for work
our translators. We save about 300 lines from each PO file with this.
This also solves another small problem: when a file is included with an
anchor, other anchors are automatically stripped away. This removes some
confusing `// ANCHOR: foo` and `// ANCHOR_END: foo` lines in the
solutions.
Since JetBrains [announced RustRover as their new Rust IDE
(preview)](https://www.jetbrains.com/rust/), I updated the details with
a suggestion for RR in `Using Cargo`.
This will simplify our mdbook updates since there will be fewer
customizations to copy over when a new mdbook version has changes to the
`index.hbs` template.
In the exercise guideline for the Luhn's algorithm (Day 1, Afternoon
exercise), I made a correction to step 3 to provide a more accurate
explanation. Instead of stating that doubling 7 becomes 14, I clarified
that doubling 7 results in 14, and we should sum the individual digits
of 14 to get the correct value of 5.
Hello there 👋 I'm the author of the `tokio-websockets` crate and
today we published version `0.4.0` of the crate, which finally makes the
public API consistent and aligns it with expectations.
`WebsocketStream` now implements the `Stream` trait, so calling `next()`
has to be done via `StreamExt` now. `connect()` returns a tuple of
`(WebsocketStream, Response)`, so that has to be deconstructed now. And
finally, `as_text()` now returns an `Option<&str>` instead of
`Result<&str, Error>`.
And, *very* importantly: The old `WebsocketStream::next` was **not**
cancellation safe, the new `Stream` implementation is. The exercise uses
`select!`, which very well might have caused misbehavior.
Since we also emptied the default features, I've added the very minimal
ones required to compile the exercise.
This is my first contribution here, so feel free to point me to some
things if I'm missing anything. I wasn't really sure what to do about
the translations, I guess I should leave them as is and they'll be
updated by translators in other PRs?
Signed-off-by: Jens Reidel <adrian@travitia.xyz>
Adding this test case to handle case where we have non-numeric cc number
along with a valid cc number. This is discovered when we filter with
is_numeric() instead of !is_whitespace() all test case does pass. To
handle such scenario adding this test case.
This updates our `mdbook` version to the latest version in Git. I copied
the `index.hbs` file from that version and back-ported our changes into
it. I checked English and Danish locally and they both look fine.
The new version has support for right-to-left languages:
https://github.com/rust-lang/mdBook/pull/1641.
We have an in-progress Persian translation. Download the `fa.zip`
artifact after building the PR to check how it looks. I checked Persian
locally and it looks mirrored like I expect (but we will need someone
who can read Persian to actually verify this).
Fixes#1164.
Hi all!
This CL fixes#1093:
* Avoids including current false-positives in the checking of typos
* Excludes localization-related files, as `typos` works with
English words
* Fixes existing typos caught in the repo
Tested this in CI with a typo and it showed up in the list of actions!
---------
Co-authored-by: Martin Geisler <martin@geisler.net>
…llers/examples
The proc-macro2 dependency at 1.0.50 results in a build error mentioning
an unknown feature `proc_macro_span_shrink` that no longer exists in
nightly. Per https://github.com/rust-lang/rust/issues/113152, updating
proc-macro2 to the latest version fixes the error.
The build error I saw before updating the proc-macro2 dependency was the
following:
```
> cargo build --bin minimal
Compiling proc-macro2 v1.0.50
Compiling bare-metal v0.2.5
Compiling typenum v1.16.0
Compiling nrf52833-hal v0.14.1
error[E0635]: unknown feature `proc_macro_span_shrink`
--> /home/chcl/.cargo/registry/src/index.crates.io-6f17d22bba15001f/proc-macro2-1.0.50/src/lib.rs:92:30
|
92 | feature(proc_macro_span, proc_macro_span_shrink)
| ^^^^^^^^^^^^^^^^^^^^^^
Compiling cortex-m v0.7.7
For more information about this error, try `rustc --explain E0635`.
error: could not compile `proc-macro2` (lib) due to previous error
warning: build failed, waiting for other jobs to finish...
```
This is a follow-up to #998 and the discussion in #1049. The
comparison page is now gone: like @randomPoison said, it feels
redundant and I also mostly skip over it when teaching the class.
I also took out some duplication in the Rust memory management page. I
would be up for simplifying the whole chapter down to one or two
slides as @djmitche suggests: that would leave us with more time for
covering ownership.
Most classes run with 2.5 hours for the morning session and 2.5 hours
for the afternoon session.
I have tried running the course as 2 × 2.5 hours and 2 × 3 hours. My
experience was that people ended up getting really worn out after
spending 6 hours in total on Rust (7 hours including a lunch break).
However, the experience varies from group to group, so this is just a
recommendation.
I'm preparing several PRs to submit the Spanish translation, but I need
first to normalize the existing es.po file, otherwise the PRs will be
humongous.
Part of #330, #282, #284.
