I created a first implementation for the mdbook-slide-evaluator I
described in #2234.
One has to run a WebDriver compatible browser (e.g. selenium-chromium)
so the slides can be rendered. The browser can access the file either
via a file:// or http:// uri.
The tool grabs the configurable element from that page and evaluates the
size of this element. Output can be stored in a csv file or at stdout
and looks like this at the moment:
```
$ mdbook-slide-evaluator book/html/android/aidl
book/html/android/aidl/birthday-service.html: 750x134
book/html/android/aidl/example-service/changing-definition.html: 750x555
book/html/android/aidl/example-service/changing-implementation.html: 750x786
book/html/android/aidl/example-service/client.html: 750x1096
book/html/android/aidl/example-service/deploy.html: 750x635
book/html/android/aidl/example-service/interface.html: 750x570
book/html/android/aidl/example-service/server.html: 750x837
book/html/android/aidl/example-service/service-bindings.html: 750x483
book/html/android/aidl/example-service/service.html: 750x711
book/html/android/aidl/types/arrays.html: 750x291
book/html/android/aidl/types/file-descriptor.html: 750x1114
book/html/android/aidl/types/objects.html: 750x1258
book/html/android/aidl/types/parcelables.html: 750x637
book/html/android/aidl/types/primitives.html: 750x366
book/html/android/aidl/types.html: 750x197
```
---------
Co-authored-by: Martin Geisler <martin@geisler.net>
As I mentioned in #1536:
* Break into segments at approximately the places @fw-immunant put
breaks
* Move all of the files into `src/concurrency`
* Add timings and segment/session metadata so course outlines appear
There's room for more work here, including some additional feedback from
@fw-immunant after the session I observed, but let's do one step at a
time :)
This PR moves the slides for slices and strings into the day 1 section
on references. This seems like the more natural place to introduce
slices since slices are a type of reference. It then also made sense to
me to follow that with the introduction of `&str` and `String`, since
students now have the context to understand what a "string slice" is. I
also removed the strings slide from the types and values section since
it didn't make sense to cover the same topic twice in the same day. I
tested this new organization in my class on Wednesday and it didn't
cause day 1 to take too long.
After #1528 and #1532, we now have actual slides which showcase the
crates in action. So we can reclaim a few minutes by removing the slide
which mentions Mockall and GoogleTest slide.
The slide mentioned [proptest](https://docs.rs/proptest) and
[rstest](https://docs.rs/rstest) as well. While I'm sure the libraries
are useful, we don't have them imported into AOSP and I've never
personally used them. We should therefore not advertise them yet at this
point since they won't be useful to Android engineers.
Of course we can mention things that are not in AOSP (or in Chromium),
but I think we should do it in the speaker notes at most.
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.
I've taken some work by @fw-immunant and others on the new organization
of the course and condensed it into a form amenable to a text editor and
some computational analysis. You can see the inputs in `course.py` but
the interesting bits are the output: `outline.md` and `slides.md`.
The idea is to break the course into more, smaller segments with
exercises at the ends and breaks in between. So `outline.md` lists the
segments, their duration, and sums those durations up per-day. It shows
we're about an hour too long right now! There are more details of the
segments in `slides.md`, or you can see mostly the same stuff in
`course.py`.
This now contains all of the content from the v1 course, ensuring both
that we've covered everything and that we'll have somewhere to redirect
every page.
Fixes#1082.
Fixes#1465.
---------
Co-authored-by: Nicole LeGare <dlegare.1001@gmail.com>
Co-authored-by: Martin Geisler <mgeisler@google.com>
Add a number of slides that cover most of CXX's functionality and
demonstrate how it can be used.
Fixes#823.
---------
Co-authored-by: Martin Geisler <mgeisler@google.com>
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>
The i18n-helpers are now available as a stand-alone crate:
https://crates.io/crates/mdbook-i18n-helpers.
Because we cache the Rust binaries in our GitHub workflows, I bumped
the cache prefix to ensure we use a clean cache. Otherwise, Cargo
won’t install the new binaries in mdbook-i18n-helpers because it sees
the old ones from this repository.
* Move Cargo.toml for exercises to exercises directory.
* Create a workspace with both exercises and i18n-helpers.
* Build in CI as well as testing.
* Binaries must have a main function.
* No need for workspaces configuration for caching anymore.
