-
Notifications
You must be signed in to change notification settings - Fork 10.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
output
-based exercise
#270
Comments
@jrvidal That sounds good! It's probably a good replacement for |
bors
added a commit
that referenced
this issue
Feb 26, 2020
refactor: exercise evaluation After working a bit on #270, I realized that it'd be useful to first perform a minor refactor of exercise evaluation. * Now we have standard methods to compile + execute that return `Result`s. * Success/failure messages are standardized.
shadows-withal
pushed a commit
that referenced
this issue
Apr 7, 2020
feature: adds "output" mode, resolves #270
pedantic79
pushed a commit
to pedantic79/rustlings
that referenced
this issue
Apr 11, 2020
refactor: exercise evaluation After working a bit on rust-lang#270, I realized that it'd be useful to first perform a minor refactor of exercise evaluation. * Now we have standard methods to compile + execute that return `Result`s. * Success/failure messages are standardized.
pedantic79
pushed a commit
to pedantic79/rustlings
that referenced
this issue
Apr 11, 2020
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.
pedantic79
pushed a commit
to pedantic79/rustlings
that referenced
this issue
Apr 11, 2020
feature: adds "output" mode, resolves rust-lang#270
MendelMonteiro
pushed a commit
to MendelMonteiro/rustlings
that referenced
this issue
Jun 28, 2020
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.
ppp3
pushed a commit
to ppp3/rustlings
that referenced
this issue
May 23, 2022
refactor: exercise evaluation After working a bit on rust-lang#270, I realized that it'd be useful to first perform a minor refactor of exercise evaluation. * Now we have standard methods to compile + execute that return `Result`s. * Success/failure messages are standardized.
ppp3
pushed a commit
to ppp3/rustlings
that referenced
this issue
May 23, 2022
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.
ppp3
pushed a commit
to ppp3/rustlings
that referenced
this issue
May 23, 2022
feature: adds "output" mode, resolves rust-lang#270
dmoore04
pushed a commit
to dmoore04/rustlings
that referenced
this issue
Sep 11, 2022
refactor: exercise evaluation After working a bit on rust-lang#270, I realized that it'd be useful to first perform a minor refactor of exercise evaluation. * Now we have standard methods to compile + execute that return `Result`s. * Success/failure messages are standardized.
dmoore04
pushed a commit
to dmoore04/rustlings
that referenced
this issue
Sep 11, 2022
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.
dmoore04
pushed a commit
to dmoore04/rustlings
that referenced
this issue
Sep 11, 2022
feature: adds "output" mode, resolves rust-lang#270
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I've been wondering whether it'd be useful to have a 3rd kind of exercise,
"output"
/Mode::Output
, that compares the stdout of an exercise to an expected value before moving on to the next one. This would imply a minor re-invention the#[test]
framework, since we'd need to produce our ownExpected
/Actual
output and stuff.However, I feel that it would be a good fit for some
println
-based exercises, where the user can simply manipulate the program until it generates the desired output in a way that feels more natural to me than using#[test]
. For instance, a hypothetical 0-exercise with an emptymain()
that expects you to print "Hello world". Or some of theif
-based exercises, where the user can test branches until the correct one is executed. In fact, I suspect it'd be a good fit for most of the exercises for which we get complaints about them passing too soon.@fmoko What do you think? If that sounds OK I'd be glad to send a patch.
The text was updated successfully, but these errors were encountered: