* Add chrome.css and general.css to override default css file. This is
necessary to fix links without underline (hyperlinks relying only on
color).
* Fix pop-out button without id and wrong ARIA-ROLE
* Speaker's notes now at correct heading sequence (H3)
I want to contribute to German translation, so i set up the complete
toolchain and git project for proper operation. This is my initial
commit to verify, that all is correct and i can continue.
Implement two tests for the rust playground:
- successful run of the hello world example with the hello world message
in stdout and a hidden stderr
- on purpose compilation error is shown in stderr and "No output" in
stdout
These are some minor updates from walking through the session myself.
* Add some context to the `entry.S` slide, which is otherwise a bit
terrifying for someone who does not speak ARM assembly.
* Include a simple, fake example of MMIO.
* Add a "Using It" section to the minimal UART segment, parallel to the
better UART
* Better explanation of the `unwrap` calls in the logging example.
Unwrap is never "unsafe", so remove that word.
* Allow dead code in some `.rs` files.
* Remove redundant warning about use of memory before MMU setup.
* Rephase text about buddy-system
* Fix lint warning in spin slide.
The custom function `cap` does the same as `Ord::clamp`, which was
introduced in Rust 1.50. Let's use the latter instead.
I've flashed the new program onto my microbit and can confirm it still
works as intended.
Bumps the patch group in /src/bare-metal/aps/examples with 1 update:
[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>
The current example demonstrating how rustc prevents dangling references
is really gross and hard to read (my own fault lol, I wrote that
example). I finally realized that there's a much simpler, easier to read
way of expressing the same thing. I also moved this to its own slide
after the reference slides so that we can call it out as an early
example of the borrow checker. I then call back to this example in the
borrow checker slide to remind students that the aliasing rule isn't the
only thing the borrow checker is enforcing.
The side bar is out of date, and also the the unit testing docs are
talking about integration tests. These tests are discussed on the next
slide in "Other Types of Tests".
I think it would be good to simplify the expression evaluation exercise
by removing the error handling around the divide-by-zero case. I think
it overcomplicates the exercise and and adds confusion since at this
point we haven't introduced `Result` (or at least not in any detail).
This allows the students to just focus on writing the pattern matches on
`Expression` and `Op`, and allows the exercise to be shorter (and I
think we need to free up some time where we can, my classes often run
long and cut into how much time students have for exercises).
The current slide on visibility introduces the idea that modules are the
encapsulation boundary, but it doesn't explicitly doesn't talk about
struct fields/methods. I think it's worth talking explicitly about
structs and encapsulation because most students are going to be coming
from a background where types (instead of modules) are the encapsulation
boundary. It's worth talking explicitly about how encapsulation works,
even if we're kind of repeating information from the previous slide.
The `(&values).into_iter()` construct used in the solution to the
iterators exercise is kind of awkward and always gets questions from
students. I think the better thing would be to use the `iter` method to
get the initial iterator, as that's the more idiomatic way to. It's also
an opportunity to point out that there are helper methods for getting an
iterator for a collection.
The solution to the modules exercise changes how `Button`, `Window`, and
`Label` are referenced, adding a `widgets::` prefix to them. This seems
weird to me because the more idiomatic thing to do would be to import
those types at the top of the file. Unless I'm missing a reason why the
solutions is written the way it is, I think this is a good
simplification.
It used to have a ugly error message shows that "Playground
Communication: Cannot read properties of undefined (reading 'trim')",
which is due to the fact that the response lacks stdout attr.
Issue: #2477
Signed-off-by: Alx-Lai <alexabc722@gmail.com>
"Third-party" is a Googleism that doesn't make much sense otherwise.
Most references to crates just say "crate", implying that they are
open-source packages available on https://crates.io, so this updates a
few additional locations to do the same.
On my chromebook:
* I needed build-essentials to install cc
* I needed to enable sharing the USB device with linux. This instruction
was from a support.google.com article so well-known but not obvious.
---------
Co-authored-by: Martin Geisler <martin@geisler.net>
Update translations from SUMMARY.md.
Unfortunately, poedit changes the wrapping length of the po files and I
could not get it back by changing the poedit setting for line length. I
believe we won't get any more of these noisy diffs for my further
changes this week.
`Cancellation` is the last item I modified in this PR.
---------
Co-authored-by: Hidenori Kobayashi <hidenorik@google.com>
Without this, compilation fails. The comment *is* in the included Rust
file — but we only include a fraction of the file to keep the example
short. This makes it cumbersome to both show something that works in the
slides while also making it possible for the instructor to show more
complex examples.
@randomPoison, we need to make our examples simpler here: the complexity
here makes it hard to modify the files and I feel it's hard to show
during class. I would suggest splitting this up into a very basic
example (what the birthday service was) and then add 1-2 slides with
more complex samples (if necessary). Last I taught the class, I had a
hard time a) making every example compile and b) finding time to cover
everything.
I would err on the side of makings things simple and clear.
The page is not mentioned in the `SUMMARY.md` file and has apparently
been forgotten.
We could consider adding a check for this situation, but since I don't
think it occurs very often, I don't consider it high priority.
