The goal of this is twofold: give translators a place to document how
certain terms are translated as well as giving people a place to quickly
find a definition of a term. The slides might not always give a quick
definition the same way a glossary can.
This example shows what kind of bugs easily slip into C code and are
made impossible via Rust.
I have created this example for the motivation slides of my master
thesis. Since then, the university institute has used it in their
introduction to Rust.
I hereby make this part available to the Comprehensive Rust course and
relicense it under the terms of the Apache 2.0 license.
Thank you @mgeisler for your invitation to contribute to this course!
---------
Co-authored-by: Martin Geisler <martin@geisler.net>
I hope the blog post can help shed more light on why we wrote the course
and how it has been used at Google.
I'm not sure if "Press" is the best title, but I hope to link other
articles later from this section at a later point.
The `name` struct field was confusing because it was named the same as
the trait method. The struct fields are now disjoint from the method
names — the fact that there are two separate name spaces is not the
point of these slides.
I also dropped the zero-sized type, this is also not the main focus
here.
I also compressed the code a bit to make the unimportant structs take
up less space.
Fixes#1292.
Here's a possible update to the GUI/TUI exercise, taking out the
callback and explaining (slightly).
See what you think.
---------
Co-authored-by: Martin Geisler <martin@geisler.net>
This is the result of running `cargo update` in every directory.
It fixes a alert: https://github.com/advisories/GHSA-9mcr-873m-xcxp. We
don’t run any HTTP server directly, so this is not super important for
us. However, it will remove the alert from my dashboard.
Initially, I also formatted the templates in `theme/`, but this triggers
https://github.com/prettier/prettier/issues/11834. So I exclude them for
now.
---------
Co-authored-by: Ming-Ying Chung <mych@chromium.org>
This builds on the work of @dyoo in
https://github.com/google/mdbook-i18n-helpers/pull/69: by adding a
special `<!-- mdbook-xgettext: skip -->` comment, we can skip the
following code block.
I also modified a few code blocks to remove translatable text: variable
names are not expected to be translated, so it’s fine to have a line
with `println!("foo: {foo}")` in the code block.
This PR removes 36 messages from the POT file. The number of lines drop
by 633 (3%).
Part of #1257.
This updates each PO file to the date when it was last touched:
for po_file in po/*.po; do
POT_DATE=$(git log -1 --date=short --format=%ad $po_file)
sed -i -e 's/"POT-Creation-Date:.*"/"POT-Creation-Date:
'$POT_DATE'\\n"/' $po_file
done
The dates will be updated with `msgmerge` in the future via
https://github.com/google/mdbook-i18n-helpers/pull/87.
The dates here can be adjusted by hand if needed — the starting point
here only serves as a rough anchor to let us freeze the translations
from further updates. So if you know that you ran `msgmerge` most
recently on a given date, please update the file to that date in a later
PR.
Hi, JA project folks (#652), here's a MR for the chapter "Control Flow".
When you have some time, could you review the diff? Any feedback or
suggestions are greatly appreciated. Thank you in advance.
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>
