-
Notifications
You must be signed in to change notification settings - Fork 541
declare compliance with x-common, where applicable #282
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
Conversation
List of exercises that do not have Cargo.lock in repository (so if I changed their Cargo.toml, it is expected that there is no corresponding Cargo.lock change): for i in */; do
if [ ! -f $i/Cargo.lock ]; then
echo $i
fi
done bowling/ |
Make commit:
|
We only test the last row of the 4 case, but that was intentional, it seems. We do not test the negative (since we use a u32 as input) nor nil (since we use a u32 as input).
Note that we are not yet in compliance with 1.1.0
We do not test negatives since we use unsigned integers as inputs.
Some values are different, but all cases are still being tested.
We don't test the negative case because we use u32 as input.
Rust has a few track-specific tests in addition.
Although our descriptions aren't quite as good.
Our values are different and our descriptions don't explain everything, but the same cases are being covered.
We have an extra test of overflowing u32, and also a (rather useless) test that `decode . encode` is identity.
Our tests are in slightly different orders, but they are all there. Only exception is the negative roll since we want to allow the student to use unsigned integer to avoid it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great, thanks!
A side question: do we want a tool in the repository that will show us the outdated test cases?
That would be good. We can see if exercism/discussions#133 has something useful for us, or write an equivalent. |
up to date:
we never checked whether we are in sync with a problem-specifications file:
We are in sync with an out of date file:
|
Current status (note that it has been a year since I previously did that): Up to date (25)
A version of 0.x.y means that we never assessed whether we were up to date with any particular version. Assume out-of-date (19):
We were up-to-date at a point in time, but there have been updates since (32):
|
Oh actually it's possible to make a distinction here, since in the original issue I listed the exercises where I made the explicit judgment that we do not match canonical-data.json sufficiently to put a version on. Can subtract that from the current 0.x.y list to get a list where in fact no judgments have been made. I'm not even sure if it's worth making those NAKs clear in the version file. We run into these situations only when the Rust track adds a new exercise or problem-specifications adds a new canonical-data.json file
|
Of those seven exercises above, My general attitude toward versions: It's not currently in my abilities to personally pursue the project to make the entire track up to date. There are a few exercises that I do from time to time, but I can't be relied on to do this for all exercises. I'm also not particularly interested in filing individual issues for each exercise since (selfish) it takes up too much space in my https://github.com/issues and (not as selfish) takes up space in https://github.com/exercism/rust/issues. For these issues, I would not like that since it's unknown (but guessed by me to be multiple weeks to multiple months) when such issues would actually get closed. And in general, I think it lines up the incentives better if the person filing the issue has at least a bit more desire to see it closed. A person who wishes to pursue the project might consider making just a single issue with a checklist as a possible alternative to individual issues for each exercise. |
figured I'd take stock of things after a recent spate of updates. up-to-date: 46
never up-to-date: 15
behind: 16
Well that's cool. Also leap and forth are in progress. I got most of the ones I wanted to get out of the way, so I'll probably sit back and let things get out of date for a few months again now, great huh |
up-to-date: 43
never up-to-date: 12
behind: 23
|
closes #281
Where our exercise already matches the x-common tests, this is now noted in the Cargo.* files.
Where there were small differences but I still deemed the exercise to be up to date, I noted this in a commit comment, so take note of those differences.
Out of scope for this PR: Actually changing any test suites. This PR is only for figuring out where we are already compliant. Changing test suites will come in other PRs for the respective exercises.
List of exercises that were declared up-to-date as a result (26):
List of exercises that are up-to-date with a certain x-common version, but there is nevertheless a new x-common version (1):
List of exercises that were not deemed to be up-to-date to the current (or any previously-versioned) version, therefore were not touched (21):
List of exercises that don't have a JSON file, so also were not touched (6).