this is a proposal for the affine-cipher to replace the atbash problem #173
Conversation
|
I just realized I left my backup test in there as well as well in addition to not editing the config.json. I can fix those things later today and submit a new pull request. |
|
Sorry for the flurry of commits. I am new to json. Fixed all but the fact that it doesn't have a uuid. I have no idea what the uuid should be. |
|
I did finally learn about configlet. I am attempting to install it. |
|
Finally got past Travis. I felt like it was more appropriate to add affine-cipher at the end with atbash-cipher as a prerequisite. I defer entirely to the maintainers judgement regarding how it should be folded into the existing exercises. Thank you for taking the time to review my submission. |
|
Hello @guygastineau, thanks for submitting this pull requests. When we discussed I thought you wanted to implement an existing exercise to our bash track, but looks like I misunderstood, sorry about that. For adding new exercises to exercism, we need to use: https://github.com/exercism/problem-specifications. Please open a new issue here: https://github.com/exercism/problem-specifications/issues, and we can discuss about that. Here is an example of somebody doing just that: exercism/problem-specifications#906 I'll close this PR since we can't merge it, but we can reopen it when the problem-specification will have this exercise. Let me know if you need any help. |
|
Thanks, this email answered the questions I had in my other email. Thanks
for your help. I'm pretty busy this weekend but I'll try and getting
started opening ng up problem specification.
…On Fri, Jul 13, 2018, 5:41 AM Bud (Mugur) Chirica ***@***.***> wrote:
Hello @guygastineau <https://github.com/guygastineau>, thanks for
submitting this pull requests.
When we discussed I thought you wanted to implement an existing exercise
to our bash track, but looks like I misunderstood, sorry about that.
For adding new exercises to exercism, we need to use:
https://github.com/exercism/problem-specifications.
Please open a new issue here:
https://github.com/exercism/problem-specifications/issues, and we can
discuss about that.
Here is an example of somebody doing just that:
exercism/problem-specifications#906
<exercism/problem-specifications#906>
I'll close this PR since we can't merge it, but we can reopen it when the
problem-specification will have this exercise.
Let me know if you need any help.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#173 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AkdbZUuoI43wd4Xx5HL-ZMPc-KBuSBwAks5uGGsygaJpZM4VNZcw>
.
|
Hi team,
I recently talked with budmc about adding tests for pipes and reading from a file to the atbash-cipher problem in the bash track. Since then I completed a bonafide Affine cipher and migrated the test.sh and README to accommodate an affine cipher instead of atbash. I think the affine cipher poses more interesting and challenging problems to the leanrer and would therefore be an excellent substitution for the atbash problem in the track. However, I will also admit that the atbash problem prepared me for dealing with the more complex affine cipher. Thus, while I suggest this to replace the atbash problem, I don't have a problem with them both existing in the track. I just didn't know if you all thought they would be too similar. I have included my script as example which will pass all of the tests so you all could play with the commit without having to do the problem yourselves. I am happy with my solution except for the function to check for the coprimality of a and m. I'm not really sure if there is a cleaner way to do it but it works for now.
Note: It tests to see if the solution can read from a file as an argument by comparing:
[[ "$(affine encode key affine_cipher_test.sh)" = "$(cat affine_cipher_test.sh | affine encode key)" ]]
It seemed silly to me to compare the output of the same problem, but since proper encoding and piping tests have been done before this test I figured it was sane enough. There is no guarantee that someone could not bug their way through that specific test though. I believe all of the other tests are fine. Unfortunately, bats gets the status as 2 when pipes are used after run, so I couldn't test [ "$status" = 0 ] on the test cases using pipes. Thank you for your consideration of my changes.
Reviewer Resources:
Track Policies