-
-
Notifications
You must be signed in to change notification settings - Fork 674
[WIP] Implement exercise run-length-encoding #862
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
1.9 was released on 24 August 2017: https://golang.org/doc/go1.9 1.8.3 was released on 24 May 2017: https://golang.org/doc/devel/release.html#go1.8.minor This keeps up with the policy of only testing the current & previous release.
This describes the bonus test and how to run it. closes #832
@MatForsberg I see nothing in changed files? |
Closes #863
@tleen I apologize. I am new at this. I was doing my best to follow the directions on https://github.com/exercism/docs/blob/master/you-can-help/implement-an-exercise-from-specification.md . Specifically "Avoiding Duplicate Work When you decide to implement an exercise, first check that there are no open pull requests for the same exercise. Then open a "work in progress" (WIP) pull request, so others will see that you're working on it. The way to open a WIP pull request even if you haven't done any work yet is:
Once you have added the actual exercise, then you can rebase your branch onto the upstream master, which will make the WIP commit go away." I have finished the exercise but having a little trouble with the test generator since the test data has sub cases. |
Ah @MatForsberg I see what you are doing now thanks. Conventionally we have been prefixing WIPs as "[WIP]". I'll mod the title now so we don't get confused. We are requesting that anything bug bugfixes go into the Thanks for working on this one! 🎉 |
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.
Thanks @MatForsberg for this work.
The 'go test' ran locally for me, so I'm guessing that the formatting is throwing off the travis-ci test.
So, simply do:
go fmt cases_test.go
go fmt example.go
go fmt run_length_encoding_test.go
push up the additional commit for the formatting change, and perhaps the travis-ci will pass at that point. Then we can pick it up again from there.
Formatted go files and added UUID to config.json
I think the problem is i am missing the uuid for this exercise. I generated one online and added it to the config.json |
Thanks for this @MatForsberg and Welcome! 🎉
If you like we could split this into two PR's, this one to just implement the exercise, and another to implement the test generator. As @tleen mentioned Exercism is midway through a significant change, and we've got two main branches we're working with in this repo. Unfortunately we hadn't updated the documentation for this before your PR: https://github.com/exercism/go/blob/master/.github/PULL_REQUEST_TEMPLATE.md I'm going to change the base branch of this PR from
towards the end between the Thanks again, and sorry for the complications. |
@robphoenix If i understand you right i made the necessary change. I wrote over the change.json that i had with the one from the link and then put the json you suggested in between bowling and binary. Thank you all for your help. |
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.
Maybe a rebase on the nextercism branch and a force push can clear up the confusion in the change set regarding exercise robot-name files.
Other than that, dropping the stub file is the only needed change that I see.
@@ -0,0 +1,5 @@ | |||
package run_length_encoding |
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.
I thought that a stub won't be needed for run-length-encoding, since raindrops is likely before this one and raindrops is the first one without a stub. Is that correct @robphoenix and @tleen ?
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.
Not really sure yet where this will land in nextercism. But it won't be in core and probably after raindrops. It's not like we can't have stubs after that, but we may not want to. We can modify this exercise afterwards when we place 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.
I think it's best to remove the stub file. I don't think this exercise will be before raindrops
and we can see when v2 launches if we need to add any stubs to later exercises.
"math/rand" | ||
) | ||
|
||
const testVersion = 1 |
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.
Not sure why the change to this robot-name exercise is here. Base branch isn't quite right yet maybe?
exercises/robot-name/.meta/hints.md
Outdated
@@ -0,0 +1,13 @@ | |||
### Bonus exercise |
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.
robot-name exercise change ?
.travis.yml
Outdated
- 1.7.5 | ||
- 1.8 | ||
- 1.8.3 | ||
- 1.9 |
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.
I think we have picked up some weirdness in the branch here. Perhaps a rebase to nextercism is in order? config especially? These travis changes shouldn't be here. Git can be tough sometimes!
Formatted go files and added UUID to config.json
… into run-length-encoding
reverted commit with the robot and travis changes |
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.
Thanks @MatForsberg for working to try and get it straight. The content for the new exercise looks good; but the merge cannot happen as it is right now.
Don't feel bad; git is a tough nut sometimes, and all of us have had our difficulties. (And I still do at times!)
IMO, it may be easiest to resolve by using a new PR, whose branch is based on nextercism. What to you think @tleen and @robphoenix ?
Since all files but one (config.json change being the exception) are new, you could start a new branch based off upstream/nextercism, add the new files into it, and add the config.json change, and I think the changes would be clean at that point.
I know the original base branch was master instead of nextercism, and I'm not github savvy enough to know how changing the base branch works "on-the-fly" so to speak.
We need some consensus before moving forward on it.
@@ -0,0 +1,23 @@ | |||
## Exercism v2 |
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.
This file is on the master branch, but not on the nextercism branch.
I fetched your repo and checked out the branch; sure enough it has a lot of testVersion references, which have been removed from nextercism branch. That says your run-length-encoding branch isn't a fresh rebase on nextercism.
I do think that is a better approach. I got lost in the git weeds the same way too over the weekend doing a much simpler change (see #877). I ended up closing the PR and redoing it again from a clean checkout of the repo. Git is cool when it's cool, but it can get out of hand real fast! |
Hi @MatForsberg
Firstly, please, no need to apologise and be rest assured these difficulties we're dealing with trying to get this PR merged are not your fault and are ones we have all encountered, and honestly still do, as @tleen mentions. I hope this doesn't overshadow your new experience contributing to open source! And on that note, thankyou for taking the time and effort to open this PR. So, resolving the commit log to be able to merge this in...
Otherwise I able to create a clean fork of this PR: nextercism...robphoenix:pr-862 using an interactive rebase. This will enable you to drop other peoples commits and squash yours into a single one. We want to amend the last 15 commits of this branch so run the following command in your terminal within your branch for this PR:
This will open up your editor and list the last 15 commits, excluding merge commits, and look something like the following:
I did this in two steps, first dropping unwanted commits and then squashing your commits into one.
Notice the lines where
I did a
After fixing the conflicts I ran a
If we run
This is a ridiculously long comment, and I don't mind if you don't read it and just open a new PR! 🤣 tbh I just wanted to see if this could be resolved with an interactive rebase! Since I learned about interactive rebase I do it all the time to tidy up my messy git history! I have an alias for it in my global |
@@ -0,0 +1,32 @@ | |||
package run_length_encoding |
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.
While we don't have a generator for this exercise, it would be better to keep the test cases in the run_length_encoding_test.go
file. We can change this when a test generator is added.
@@ -0,0 +1,55 @@ | |||
package run_length_encoding |
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.
the package name should be changed. https://blog.golang.org/package-names
Maybe encode
?
What do you think @tleen @leenipper
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.
Yep something more Go-ish.
return output | ||
} | ||
|
||
func getEncodedOutput(count *int, i int, s string, output *string) { |
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.
As noted here, I'd change this function name. Maybe encode
?
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.
I think this function would work better if it returned the updated variables, rather than altering pointers;
func encode(count int, i int, s string, output string) (int, string) {
if count > 1 {
output += fmt.Sprintf("%d%c", count, s[i-1])
return 1, output
}
output += fmt.Sprintf("%c", s[i-1])
return 1, output
}
you could then use it like so:
count, output = encode(count, i, s, output)
It's more explicit about what it's doing, and simplifies the function itself.
|
||
func RunLengthEncode(s string) string { | ||
count := 1 | ||
output := "" |
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.
It's more idiomatic to write var output string
if you're going to initialise a variable to it's zero value
Please do not delete i am working on incorporating changes |
func RunLengthDecode(s string) string { | ||
count := 1 | ||
stringCount := "" | ||
output := "" |
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.
these two lines could be simplified:
var stringCount, output string
No worries @MatForsberg, I've left a few comments. |
No description provided.