[robot-simulator] New Practice Exercise

Programming R
1

48in24
Hi! I’m close to submit the PR on the “Robot Simulator” exercise.
We will discuss more in the PR but I need a few answers:

  1. What about adding some specific tests which test proper usage of S3 classes, so also do we need such requirement in instructions as well?
  2. There is a file tests.toml created by configlet, which has entries on tests, when adding new ones do I need to update somehow this file?
1 Like
2

You can create the file .docs/instructions.append.md to put R-specific instructions.

1 Like
3

I’m pretty sure that tests.toml is just used by configlet when you want to sync the exercise with upstream changes. Additional tests don’t need to go into tests.toml.

2 Likes
4

Thanks @glennj that helps me a lot!

5

That is correct!

1 Like
6

Here is the PR: [New practice exercise] Robot simulator by Nerwosolek · Pull Request #326 · exercism/r · GitHub
Looking forward to open it and discuss :)

7

After reopening this PR I saw there are some linter’s warnings, I went through them and some were able to address, some are unnecessary and there is a lot of warnings about deprecation:
47: The use of linters of class ‘function’ was deprecated in lintr version 3.0.0. Use linters classed as ‘linter’ (see ?Linter) instead.
Also there is an error I don’t understand: ERROR: Not lint free
I guess there should be some effort into linting process for the track, I can look into this later if the team agrees.

8

I’ve improved locally the linter, and it stopped reporting deprecation errors.

9

I pushed the changes, however I don’t like this # nolint clause, it should not be visible to student IMHO.

10

I don’t really think the #nolint comment is an issue, but I’m open to feedback / suggestions (e.g. if we think we should relax the linting strictness). I haven’t looked into too much but there are lots of old and new posts in the Git repo for the {lintr] pkg raising the issue of false positives from the object linter on (names for) generic methods due to the dots and I’m guessing that it’s probably not easy to address this robustly outside the context of package development.

11

Yes, you are right. I’ve seen the issues in lintr repo as well. So probably #nolint is the fastest thing to do now.

1 Like