Reverts google/comprehensive-rust#225. We normally include links at the
start of each exercise blocks — but we don't include links in the
individual exercises.
If we want to add such links, we should do it consistently across the
entire course.
Before, we always used the latest English source files when
publishing. This means that translations become outdated as soon as
anything is changed in the source.
This PR changes will instead freeze translations in place: they will
keep using the same English source files until a new POT file is
merged into the translation. We do this by relying on the
POT-Creation-Date field in the PO files.
We still use up-to-date versions of all other files: this allows us to
fix things in the theme, for example. So the assumption here is that
never versions of our infrastructure remains compatible with old
versions of the Markdown files.
This approach has a problem: when files are moved, the English
translation will link to the new name. This name will not exist in the
old translations. We might be able to disable these links somehow.
Part of google/mdbook-i18n-helpers#16. The
logic here should eventually be moved to somewhere in
mdbook-i18n-helpers, most likely to the renderer that @sakex is
building in google/mdbook-i18n-helpers#84.
Hi, JA translation folks (#652), here's a MR for the chapter "Send and
Sync". This chapter is particularly interesting and contains very
rust-specific concepts which seems unfamiliar to me. Any feedback and
suggestions are welcome :)
As pointed out by @njr0 in #1233, we were making the exercise confusing
by showing people code that cannot work — and then expecting the course
participants to somehow fix this, without setting clear boundaries for
what can and cannot be modified.
This PR should align the exercise with the other exercises in the course
and avoid the “brain teaser” here.
This also has the advantage of having a full working solution, with no
commented code which will bit-rot over time.
In v2 of the course, I'd like to include an estimate of the time to be
spent on each segment in the Markdown file. I think a good place for
such metadata is in the frontmatter.
For review purposes, though, I just want to display that information.
So, this is a start at a new mdbook preprocessor that just separates out
the frontmatter and includes it in a `<pre>` block. Eventually, I'd like
to parse it and put the time in the speaker notes.
---------
Co-authored-by: Martin Geisler <martin@geisler.net>
Adding speaker notes about more details when people might want to call
`drop`.
It is not about a `Drop` trait per-se, but if this is to be mentioned in
the course, this is a reasonable place.
---------
Co-authored-by: Martin Geisler <mgeisler@google.com>
Co-authored-by: Martin Geisler <martin@geisler.net>
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>
