Part of #2478 to clean up code blocks when all that is needed is a
trivial debug print statement.
As mentioned in previous related PRs, in some places I've opted to
retain the use of println! because dbg! makes it less readable.
Co-authored-by: Eric Githinji <egithinji@google.com>
Use chopstick to explain why 2 are needed to eat.
Limit async to 2 philosophers so they can deadlock in tokio.
(Tested with [3, 4, 5] philosophers and they all were able to run
without deadlock
with lock ordering disabled.)
---------
Co-authored-by: Sterling Stein <scubed2+git@gmail.com>
Part of #2478 to clean up code blocks when all that is needed is a
trivial debug print statement.
In certain slides (8.1, 9.2, 9.3, 10.5) I've opted to retain the use of
println! because dbg! makes it less readable. The
dbg! macro uses pretty-printing by default and this results in a simple
array such as the one in 8.1 being printed vertically instead of a
cleaner one-liner.
Co-authored-by: Eric Githinji <egithinji@google.com>
As mentioned in #2478, this cleans up the code blocks when all that is
needed is a trivial debug print statement.
Only making changes to Day 1 morning session so that I can get feedback
before proceeding with the rest of the course.
---------
Co-authored-by: Eric Githinji <egithinji@google.com>
This is more idiomatic than what we had before.
We keep the trait bounds for the inherent impl, because the new method
can use them to guide inference of unannotated closure arguments.
The content slides all use `fn main`, with the exception of the testing
segment. But with this change, where it makes sense exercises use tests
instead, and not both tests and `fn main`.
A small change in `book.js` supports running tests when a code sample
does not have `fn main` but does have `#[test]`, so these work
naturally.
Fixes#1581.
The speaker notes on the borrowck slide are a bit hard to read since
it's a big block of bulleted points. I've reorganized the notes to be a
bit easier to read by making some of the bullet points nested and by
moving some of the points to the "More to Explore" section. I've also
added a note on re-borrowing since students sometimes ask about it, and
I've added some playground links to demonstrate some of the points.
This approach seems to balance formalism with understanding. That is, it
doesn't mention contravariance, but suggests that lifetime annotations
in parameters and return values mean "opposite" things. It also
leverages the understanding that types must be specified in function
signatures, and are used to check types in the function body and at call
sites.
The old slice was doing several things at the same time: demonstrating
both external functions as well as unsafe Rust functions.
We now treat those two topics separately. In addition, the “Calling
Unsafe Functions” heading has become its own slide with a non-crashing
example that shows what can go wrong if an argument is misunderstood
in a call to an unsafe function. The old example didn’t actually
illustrate the danger clearly: it would produce mangled UTF-8 output,
which the Playground server refuses to print.
Part of #2445.
---------
Co-authored-by: Dustin J. Mitchell <djmitche@google.com>
Co-authored-by: Andrew Walbran <qwandor@google.com>
It's generally more idiomatic in Rust to not have trait bounds on the
data type itself. I think we better demonstrate how trait bounds are
used in impl blocks with generic data types in the impl block below the
struct definition. I've also added a speaker note to call this out if
students ask.
Bumps the patch group in /src/bare-metal/aps/examples with 2 updates:
[log](https://github.com/rust-lang/log) and
[cc](https://github.com/rust-lang/cc-rs).
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/exercises/bare-metal/rtc with 2 updates:
[log](https://github.com/rust-lang/log) and
[cc](https://github.com/rust-lang/cc-rs).
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps the minor group in /src/exercises/bare-metal/rtc with 1 update:
[bitflags](https://github.com/bitflags/bitflags).
Updates `bitflags` from 2.6.0 to 2.8.0
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps the minor group in /src/bare-metal/aps/examples with 1 update:
[bitflags](https://github.com/bitflags/bitflags).
Updates `bitflags` from 2.6.0 to 2.8.0
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
The "Generic Data Types" slide now uses trait bounds, which makes it
very confusing to explain. (e.g., "ignore this trait bound stuff while I
explain why we need to stutter to describe the generic args on an impl
block").
Also in the "Generic Functions" slide, the speaker notes talks about how
we essentially need to treat the generic args as black boxes - this is
probably more important to address then talking about all the ways you
can make things generic.
I suppose my `svgbob` skills leave a bit to be desired, but I think the
meaning is clear:
Now that I look through the `Rc` implementation, there's a weak count
for every strong count, so the `weak: 0` here is inaccurate. But, maybe
this is too much of an implementation detail? Should I just concentrate
on strong refs? I suppose I could put a `...` in that upper-right box,
to suggest there's more going on here?
This slide had two code samples, neither of which had a `main` and thus
neither of which would run. This removes the first (which is redundant
to one a few slides earlier), adds a `main`, and expands the second to
use a 3-tuple.
When teaching the course, I got a little tripped up thinking students
would need to make the `VerbosityFilter` generic over `Logger`. Let's be
clearer that this is not required, and will be described later.
This also updates the generic-types slide to repeat the exercise,
completing that thought.
