[pop-count] Implementing New Exercise

Programming R
1

Hi!
I’m aiming for implementing new exercise. I’ve chosen preliminary “pop-count” aka “Eliud’s Eggs”. Is it okay for you?
First I’m gonna solve it for Python to get familiar with it.
Then I will watch and read how to generally implement exercises and will start implementing them.

2

Hi Tomasz! Yes sure, happy for you to work on a PR to implement pop-count in the R track. As mentioned in the other thread I have pretty limited capacity at the moment but am going to try and give priority to PR’s for 48in24

Just be aware that since pop-count is still quite far out I might not prioritise until later on if there’s still lots of other stuff to work on and review in the pipeline. But will certainly do my best to facilitate a PR for this.

Let us know here if you need further help once you’ve reviewed the contributing docs and looked at some more examples, otherwise feel free to open a PR when you’re ready.

1 Like
3

Hey!

In R track in README.md there is a link to contributing guide (I guess more general one) which is broken: https://github.com/exercism/docs/blob/master/contributing-to-language-tracks/README.md
What should be the proper one? I searched for a while but I’m not certain.

4

Apologies the ReadMe for the R track is pretty dated and needs to be reworked. We haven’t had many new contributors in recent years :wink:

You should refer to the Excercism building docs and in particular the docs for adding practice exercises as your primary guide, and then look at one or more PR’s adding practice exercises to R like this one for reverse-string.

There aren’t too many R specifics to know other than what applies to the .R files and how testing is done. If you’re familiar with R and {testthat}, the implementation and testing conventions should hopefully be relatively self-evident by looking at the above referenced PR (and/or a few others).

Shout if this isn’t clear or if you need further clarification - I’m sure @colinleach can weigh in too if there’s something I’ve overlooked.

This would also be a really good opportunity (between you, @colinleach and I) to update the ReadMe for the R track as needed.

5

The long answer:

I’m assuming you have already done these steps, standard for creating any PR:

  • Fork the R repo on GitHub.
  • Clone your fork to your local computer.
  • Create a branch with some meaningful name, such as pop-count Practice Exercise and checkout that branch.

Let us know if you need help with those. Otherwise, please excuse me stating the obvious at great length: I am trying to document everything in case other people also need it.

There is a utility called bin/fetch-configlet that works on *nix systems (Linux, Mac, etc).
Windows may be more tricky but I’m not sure - maybe others could advise.

Assuming you have Bash or similar, cd to the cloned repo’s top-level directory and run these commands:

bin/fetch-configlet
bin/configlet create --practice-exercise pop-count

The ability to create practice exercises this way is new (within the last couple of weeks) and very convenient, but the documentation hasn’t caught up yet.

A new directory exercises/practice/pop-count will be created with some files and hidden directories.

You need to fill in:

  • test_pop-count with tests matching the canonical data shared across tracks. Sometimes specific tests have to be excluded because they are incompatible with R, but pop-count shouldn’t be a problem.
  • .meta/example.R with a working solution that can be used to validate the tests.
  • .meta/config.json, where you need to add yourself to authors.
  • pop-count.R will end up containing just a solution stub. I tend to work out my solution there, temporarily, but before submitting it is important to move your code to meta/example.R and leave pop-count.R with just a function stub.

As Jon says, the most recent exercise to be merged was reverse-string, so that is a good one to look at for current best-practice examples.

Submitting a PR is pretty standard. In case you’ve not done it before:

  • Push your changes to GitHub.
  • The GH website will ask if you want to create a PR. Take another look at the files, and if you’re happy give it a title and a short explanation, and submit.

The PR may auto-close, but no need to get offended. Just let us know on this forum and someone will reopen it.

Linting is pretty strict on this track, and I often get caught out. The CI tests will catch this, or read the old README.md for advice that I think is still current. Mostly, 2 spaces indent and max 80 characters per line.

1 Like
6

Hey!

I’ve just added the PR for pop-count: Pop count - Added practice exercise by Nerwosolek · Pull Request #317 · exercism/r · GitHub
Thanks @colinleach and @jonmcalder for great tips!
I did as you suggested, it was great exercise to get me started in adding more exercises - I feel warmed up :slight_smile:

At first I wanted to read and watch everything to be sure I know how to contribute perfectly but then I killed my inner perfectionist and also was assured by @colinleach steps that I’m going in the right direction ;)

7

The PR has been merged. Thanks again!

1 Like
8

One question @colinleach - How do you make commit to the PR I requested?
Did you git clone my fork or somehow else?
I mainly used git using repos directly not via forks so I am not familiar?

9

Only you can change your fork, so I didn’t touch that.

When you submit a PR, GitHub sends a diff with all the changes from your fork to the upstream repo, so PRs are reviewed on exercism/r. Track maintainers with the right permissions can commit changes to this upstream repo during their review. In this case, I edited directly in the browser.

Note that merging the PR to exercism/r will leave your fork out of date. If you look at it on the GH website, there will be a comment near the top of the Code tab saying "This branch is xx commits behind exercism/r:main and a button labelled “Sync fork”. Before you submit more PRs, it’s useful to update manually with that button, then pull the latest version down to the clone on your local PC.

At least, that’s how I do it - I’m sure there are alternatives. GitHub is big and complex and confusing, and most of us struggle with it (while admiring the few superstar programmers who seem totally in control).

10

Thanks for that. I wonder how would you do such commit locally from command line.

11

This from Github might be a good place to start.

I don’t know how you’ve set up your local clone, but this is my update process when I work with a fork + local clone (the local clone being a clone of the fork, not the source repo):

  1. Having previously set a remote for my fork and branches, I switch to main and run git fetch --all. Here is an example for the Python repo from my machine:

    git fetch --all
Fetching origin
Fetching upstream
remote: Enumerating objects: 14, done.
remote: Counting objects: 100% (14/14), done.
remote: Compressing objects: 100% (6/6), done.
remote: Total 14 (delta 9), reused 12 (delta 8), pack-reused 0
Unpacking objects: 100% (14/14), done.
From https://github.com/exercism/python
   f3016b0c..7eae72e8  main                            -> upstream/main
 * [new branch]        rename-pop-count-to-eliuds-eggs -> upstream/rename-pop-count-to-eliuds-eggs
 * [new ref]           refs/pull/3613/head             -> upstream/pr/3613
 * [new ref]           refs/pull/3614/head             -> upstream/pr/3614
 * [new ref]           refs/pull/3615/head             -> upstream/pr/3615

  2. After everything updates, I run git rebase upstream/main to rebase my local main onto the updates fetched from the upstream repo. There are instructions from Github that go over merging updates, but this then creates a change that requires a PR or other shenanigans I don’t like.

    git rebase upstream/main
First, rewinding head to replay your work on top of it...
Fast-forwarded main to upstream/main.

  3. Then I run git status, to check the status of my local main. This typically results in a message like this:

    On branch main
Your branch is ahead of 'origin/main' by 1 commit.
  (use "git push" to publish your local commits)

  4. I then use git push to update my fork on github from the changes made to my (forked) local main.

After this, I can locally create a new brach for bug fixing or features, and know that it has all the changes committed in the upstream (source) repo already incorporated.

There is also the github desktop tool that can handle this stuff through a GUI, but I tend not to use it for local work unless I am having to edit a PR I am reviewing.

12

Editing PRs (as a reviewer in the way Colin describes) from the command line is a different story. It is do-able, but complicated.

For that scenario, I use GitHub desktop, or sometimes the web interface if it is small and I am in a hurry. The command-line version is just way too error prone and fiddly for me to put up with.