Includes:
- quit, to quit the shell instead of having to press Cmd/Ctrl-C or Cmd/Ctrl-D
- help, to display an overview of all the commands available in watch mode.
Closes#842.
* Add "run next" to run the next unsolved exercise.
* Fix a grammar error in the message.
* Update README.md with the suggested change
Co-authored-by: marisa <mokou@fastmail.com>
* Update the README.md for "rustlings hint next".
Co-authored-by: marisa <mokou@fastmail.com>
I’ve been wanting to do this for a while, but always procrastinated on it. We’ve been using Clap since the 2.0 rewrite, but Clap is known to be a fairly heavy library. Since Rustlings is usually peoples’ first contact with a Rust compilation, I think it’s in our best interests that this complation is as fast as possible. In effect, replacing Clap with the smaller, structopt-style `argh` reduces the amount of crates needing to be compiled from 82 to 60.
I also think this makes the code way easier to read, we don’t need to use Clap’s methods anymore, but can switch over to using pure Rust methods, e.g., switches are booleans, options are Option<String>s or the like, and subcommands are just structs.
1.
`rustlings list` should now display more than just the exercise names.
Information such as file paths and exercises statuses should be displayed.
The `--paths` option limits the displayed fields to only the path names; while the `--names`
option limits the displayed fields to only exercise names.
You can also control which exercises are displayed, by using the `--filter` option, or
the `--solved` or `--unsolved` flags.
Some use cases:
- Fetching pending exercise files with the keyword "conversion" to pass to my editor:
```sh
vim $(rustlings list --filter "conversion" --paths --unsolved)
```
- Fetching exercise names with keyword "conversion" to pass to `rustlings run`:
```sh
for exercise in $(rustlings list --filter "conversion" --names)
do
rustlings run ${exercise}
done
```
2.
This should also fix#465, and will likely fix#585, as well.
That bug mentioned in those issues has to do with the way the `watch` command handler fetches the pending exercises.
Going forward, the least recently updated exercises along with all the other exercises in a pending state are fetched.
This new feature can be accessed by invoking rustlings with --nocapture.
Both unit and integration tests added.
closes#262
BREAKING CHANGES:
The following function take a new boolean argument:
* `run`
* `verify`
* `test`
* `compile_and_test`
Additionally to running clippy, also compile the exercise file so that
`rustling run clippy1` works after a successful completion of the
exercise.
closes#291
Signed-off-by: Rohan Jain <crodjer@gmail.com>
When running "compile"-mode exercises in interactive `verify` mode,
we print their output when we prompt the learner if they want to
continue. This improves the "experimentation" experience, since
trying different things does produce a visible change.
The completion message is shown only once all exercises succeed and are
not annotated with "I AM NOT DONE." The watch command will also exit
closes#251
`watch` and `verify` do prompt the user to actively move to the
next exercise. This change fixes `run` to never prompt. Previously
it was inconsistent between "test" and "compile" exercises.
BREAKING CHANGE: we again change the behavior of the `run` command
Hints are now accessible using the CLI subcommand `rustlings hint
<exercise name`.
BREAKING CHANGE: This fundamentally changes the way people interact with exercises.
BREAKING CHANGE: This changes the way you use `rustlings run` by now
requiring an abridged form of the previous filename, e.g:
`rustlings run exercises/if/if1.rs` becomes
`rustlings run if1`
If someone is sliding in and out of "watch" mode, it can make it hard
to tell which error messages are still relevant. This patch resolves
that by clearing the terminal entirely before entering watch's loop.
Fix intermittent test failure caused by race condition
First public pull request 😬
There's an intermittent integration test failure when you use multiple test threads (at least for me on a mac). I narrowed it down to two tests each spawning a process using `Command` which then try to compile the same file at the same time. If the timing doesn't work out, they both try to compile, and then one process runs `clean` before the other can run the executable - causing a panic.
You can prevent it from happening by running with a single thread (`cargo test -- --test-threads=1`), because the `Command` blocks. That's not a particularly good solution though because it's not something you can configure in `Cargo.toml`.
I considered making the affected tests just run serially, but it occurred to me that this could also happen if someone accidentally runs rustlings in watch mode in two terminals without realising it. I wound't consider this that unlikely given it's a tool for learning.
I fixed it by ensuring that the executables made from separate processes don't conflict by appending a process id to the output executable name. I also extracted the commands into a single file next to `clean` so that we don't have to repeat the generated file name everywhere and risk missing something.
Before, rustlings would panic if it wasn't in the right directory. It
took me a minute to figure out why, and this wasn't my first intro to
Rust. It would probably help new users if they saw a helpful message
instead of a stack trace.
