This breaks the "Traits" slide into three smaller sub-slides. It also
addresses part of #1511 by explicitly addressing associated types.
---------
Co-authored-by: Martin Geisler <martin@geisler.net>
I was reading the docs and I stumbled upon this.
I'm unsure about when exercises should be solved directly on the site
and when they should be copied and pasted into a playground. But since
the previous chapter's exercise is solvable in the site [(fibonacci
sequence)](0cb7f496b5/src/types-and-values/exercise.md (L15)),
I figured this one might be missing the attribute. Anyway amazing work
on the docs!
The first change is to reformulate the English in a way, that
emphasizes, that this is not a decision of the compiler, but the
impossibility of computing an infinite value (e.g. changed the language
from "not compute" to "would not be able to compute").
The second change is to fix the error message, of course the error
message from the compiler is "recursive withOUT indirection", as
"recursive with indirection" is actually what we want.
In the old version, using "break 'outer;" and using "break;" (without
the label) produce the same output.
This version fixes that to make the example more illustrative.
---------
Co-authored-by: Martin Geisler <martin@geisler.net>
Tested with rust 2015, 2018, 2021 and 2024, on amd64 musl, amd64 glibc
and aarch64 musl, all of them represent Strings with (ptr, capacity,
len).
This is an internal implementation detail, that shouldn't be exposed
anyway, so it's no big deal, but in the speaker notes, we provide a
debugging tool for demonstration purposes, so at least that should have
a correct output.
In the example, somebody who is trying to understand this code has to
follow a lot of moving pieces: prefix, name, make_greeter, and then also
learn the new move concept at the same time.
It'd be better if the content were to actually match the name of the
variables. "Hi" is a good prefix, but "there" is not a name, so let's go
with an actual name.
Bumps the patch group in /src/exercises/bare-metal/rtc with 1 update:
[chrono](https://github.com/chronotope/chrono).
Updates `chrono` from 0.4.33 to 0.4.34
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
In the details section, it is suggested to adjust the signature of the
nearest function to "lie" about the lifetimes returned to:
fn nearest<'a, 'q'>(points: &'a [Point], query: &'q Point) -> Option<&'q
Point> {
to demonstrate the compiler checks lifetimes for validity. However, the
syntax for 'q is incorrect and it should instead be
fn nearest<'a, 'q>(points: &'a [Point], query: &'q Point) -> Option<&'q
Point> {
Based on feedback from @marshallpierce that mornings took about 2.5
hours, this adjusts a bunch of the morning times downward to try to
match that. In other words, this is trying to make the times in the
course more accurate, rather than reducing the amount of time available
for these slides.
This also updates the `course-schedule` tool to be able to show
per-segment timings.
Knowing to_string method is good for learner to use at some situation.
Knowing print complete struct object can be useful while debug.
---------
Co-authored-by: Dustin J. Mitchell <djmitche@google.com>
Swapping forks for one philosopher feels like cheating. It's like one of
the philosophers is facing away from the table. Or perhaps it's the only
right-handed philosopher at the table.
More importantly, there is no effective mechanism to prevent deadlocks.
Add that mechanism, it's useful for learning Rust.
The new code demonstrates let-else, drop and returning values from a
loop. `std::mem::swap` remains in the thread version of the Dining
Philosophers exercise for now.
This also fixes compilation. `left_fork` and `right_fork` had to be
`mut` in `main()` for the workaround to compile.
Bumps the patch group in /src/exercises/bare-metal/rtc with 1 update:
[chrono](https://github.com/chronotope/chrono).
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps the patch group in /src/bare-metal/alloc-example with 1 update:
[buddy_system_allocator](https://github.com/rcore-os/buddy_system_allocator).
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Long overdue.
It felt a bit "odd" self-assigning merit, especially because I think I
haven't nearly contributed enough translations. So I looked at the
[history of `it.po` file](https://github.com/google/comprehensive-rust/commits/main/po/it.po)
and identified also @henrythebuilder as the other "owner" of the Italian
translation (definitely, based on number of lines contributed).
@henrythebuilder please confirm you are comfortable with this.
IMO it is better to explain to users the common usage / applicability
domain for anyhow and thiserror crates
---------
Co-authored-by: Dustin J. Mitchell <djmitche@google.com>
This should be a bit simpler, and notably
* does not require trait objects, which per #1516 should be moved later
in the course
* does not require a lot of futzing with string formatting
But all that hard work developing the GUI exercise is not for naught: it
remains in the "Modules" segment, where students will get a chance to
read some Rust code and reorganize it a little bit.
Fixes#1617.
R=mgeisler as the original author of the GUI exercise.
Bumps the minor group in /src/exercises/bare-metal/compass with 1
update: [lsm303agr](https://github.com/eldruin/lsm303agr-rs).
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps the patch group in /src/exercises/bare-metal/rtc with 1 update:
[bitflags](https://github.com/bitflags/bitflags).
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps the patch group in /src/bare-metal/aps/examples with 1 update:
[bitflags](https://github.com/bitflags/bitflags).
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps the patch group with 1 update:
[tokio-websockets](https://github.com/Gelbpunkt/tokio-websockets).
Updates `tokio-websockets` from 0.5.0 to 0.5.1
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Dustin J. Mitchell <djmitche@google.com>
Attempt to address #1677.
Expert review is needed. The new text is my best guess based on the
original text and other explanations I could find online.
A few things to note:
* I'm trying to distinguish the future we return and the future we
await. My assumption is that the stack contents goes to the future the
code returns, not the future the code is awaiting.
* Readers could be worried if they need to pin the code they write. I'm
reassuring them that the borrow checks would normally catch bad
references.
* I'm intentionally avoiding the words that something is unsafe (or
would be unsafe). The async Rust is safe.
* I'm trying to be clear that `Pin` is a protective wrapper around a
pointer, not a mechanism that changes the pointer or the pointed object.
* Likewise, I don't want to give an impression that an unpinned pointer
to a future is inherently unsafe or invalid. It just cannot be used to
poll the future.
* I dropped the vague mention of the "issues", as it probably refers to
the issue with replacing a future (as opposed to resetting it in place).
It's already mentioned in the notes further on this page. It affects
pinning on stack only, `Box::pin()` can be replaced.
Co-authored-by: Martin Geisler <martin@geisler.net>
Bumps the minor group with 1 update:
[googletest](https://github.com/google/googletest-rust).
Updates `googletest` from 0.10.0 to 0.11.0
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
This adds a GH action to add a comment to every PR giving the updated
course schedule with the PR merged.
To accomplish this, I broke `mdbook-course` into a library and two
binaries, allowing the mdbook content to be loaded dynamically outside
of an `mdbook build` invocation.
I think this is a net benefit, but possible improvements include:
* diffing the "before" and "after" schedules and only making the comment
when those are not the same (or replacing the comment with "no schedule
changes")
* including per-segment timing behind `<details>` (with a few minutes
effort I couldn't get this to play nicely with the markdown lists)
---------
Co-authored-by: Martin Geisler <mgeisler@google.com>
