rustlings icon indicating copy to clipboard operation
rustlings copied to clipboard

Idea: Add a `rustlings watch` continue flag

Open Zerotask opened this issue 3 years ago • 11 comments

Based on the idea by @panpansuannai #727 and as mentioned here https://github.com/rust-lang/rustlings/pull/727#issuecomment-826066962 rustlings could remember the last successful exercise or the next / current exercise in a simple text file.

This would offer the possibility to skip the long-taking checks by rustlings watch if you pass an additional flag, e. g. -c, --continue

Edit:

Use Case: You start with Rustlings and every day you complete some exercises. Therefore you just want to continue where you stopped.

Zerotask avatar Apr 24 '21 10:04 Zerotask

as an alternative or as an addition rustlings could skip tests for exercises that have removed the // I AM NOT DONE lines

VuiMuich avatar Apr 29 '21 20:04 VuiMuich

But rustlings have to either read every file to check that or have to run a local DB (SQLite for example) to remember which files have this line removed. Both ways are not really better than the current way.

My suggestion would be much faster since you just have to read 1 line in 1 file.

Zerotask avatar Apr 29 '21 22:04 Zerotask

I am fully aware, that having a look in each file is not as fast as just having the last successful exercise stored somewhere but I don't think an actual database might be needed, a simple progress.toml might be plenty sufficient. Both was are actually better then compiling/testing each file, but of course having to look up a single value is the quickest way.

The big downside of just looking up the last successful exercise is, that this would completely miss out on updated or added exercises.

Possibly a progress.toml could be of this structure:

[[last_successful_exercise]]
name = "exercise5.rs"

[[marked_as_done]]
exercises = ["exercise1.rs", "exercise2.rs", "exercise4.rs"]

[[successfully_tested]]
exercises = ["exercise1.rs", "exercise2.rs", "exercise3.rs",  "exercise4.rs"]

Alternatively it could be:

[[Exercise]]
name = "exercise1.rs",
marked_as_done = true,
tested_successful = true

[[Exercise]]
name = "exercise2.rs",
marked_as_done = true,
tested_successful = true

[[Exercise]]
name = "exercise3.rs",
marked_as_done = false,
tested_successful = true

[[Exercise]]
name = "exercise4.rs",
marked_as_done = true,
tested_successful = true

[[Exercise]]
name = "exercise5.rs",
marked_as_done = false,
tested_successful = false

[[Exercise]]
name = "exercise6.rs",
marked_as_done = false,
tested_successful = false

Processing such toml files should take a neglegible amount of time and basically be the same UE as only reading a single line file

VuiMuich avatar Apr 30 '21 07:04 VuiMuich

but I don't think an actual database might be needed, a simple progress.toml might be plenty sufficient.

That is a database and TOML is a data format for configurations and not for such cases. A SQLite db or a JSON file would be better here.

In that case you better list all exercises, not just the ones you've completed and separate them by sections. Then you could easily ouput a similiar (better) list than rustlings list provide as well.

Zerotask avatar Apr 30 '21 07:04 Zerotask

Ok, this was worded unclear: by "actual database" I meant to avoid rising dependencies by one or multiple crates parse and maintain a dedicated database format. I am aware that, toml is meant for config-files, but since it is already in the dependency why not use it. The suggested datastructure is simple enough to be handled in toml, i'd say. Of course it would only be reasonable to track all of the exercises here, I though it would be obvious that my example is a non-exhaustive list.

True this would allow to have rustlings list printing a nice rich list.

VuiMuich avatar Apr 30 '21 09:04 VuiMuich

Of course it would only be reasonable to track all of the exercises here, I though it would be obvious that my example is a non-exhaustive list.

Your first option doesn't represent a full list and your second option doesn't separate them by sections, as I wrote. So it's not like you can talk about something being obvious. For me it's obvious that you didn't have any idea on how to implement your suggestion from https://github.com/rust-lang/rustlings/issues/729#issuecomment-829587958 otherwise one would write more than that and describe a concret solution.

I am aware that, toml is meant for config-files, but since it is already in the dependency why not use it.

That's not how you should develop software.

Since this database suggestion would have a major impact on this project, you better create a new issue for that.

This issue should focus on the way less impactful idea of remembering the last / current / next exercise with an additional flag, as described here https://github.com/rust-lang/rustlings/issues/729#issue-866712831

Zerotask avatar May 02 '21 11:05 Zerotask

But rustlings have to either read every file to check that or have to run a local DB (SQLite for example) to remember which files have this line removed. Both ways are not really better than the current way.

My suggestion would be much faster since you just have to read 1 line in 1 file.

Checking each file for a specific line is much faster than compiling each file

0x5c avatar May 02 '21 16:05 0x5c

Checking each file for a specific line is much faster than compiling each file

Reading 1 line of 1 file is much faster than that and that is basically the idea of this issue.

Use Case: You start with Rustlings and every day you complete some exercises. Therefore you just want to continue where you stopped.

Zerotask avatar May 02 '21 16:05 Zerotask

ok, I get it, as a newbyish selftaught rustacian, I should probably stay away from the big projects and leave the field to the proper educated developers. At least for now...

VuiMuich avatar May 02 '21 18:05 VuiMuich

Another idea is to add an option to allow the user to specify which exercise to start from

kitesi avatar Jun 30 '21 03:06 kitesi

Note that just looking at the comment is a regression compared to the current behavior - right now rustlings watch doesn't proceed to the next exercise unless the current one compiles. Another option that wouldn't regress that would be to use a simple makefile (or just use mtime directly) so that you still rerun rustc on changes, and stop on earlier exercises if they no longer compile. Then you don't need a separate --continue flag, since the behavior is the same as before, it just works out of the box.

jyn514 avatar Sep 25 '23 08:09 jyn514