How about including a .gitignore in each exercise containing tests.out?

This will ensure that none of our example code fails to pass tests

While looking into what was happening with #58, I noticed that the default Makefile being copied around doesn't actually use the long list of CFLAGs. (It may also be a reason why the Travis tests are failing in that PR, so we probably need to fix this first.)

In the exercises I checked, enabling it broke the build due to the -Werror flag. So rather than just enabling it everywhere, I think we should first agree on which flags we should actually include, and then update the exercises 1 by 1 in case they need changes.

Here are the current flags in the file with a few of my own comments.

CFLAGS = -std=c99
CFLAGS += -Wall
CFLAGS += -Wextra
CFLAGS += -Werror
CFLAGS += -Wpointer-arith   # Enabled by pedantic
CFLAGS += -Wcast-align  # Might be useful(?) I don't know
CFLAGS += -Wwrite-strings  # Helps for enforcing const char*
CFLAGS += -Wswitch-default  # Maybe, it breaks some of my own code
CFLAGS += -Wunreachable-code  # Removed from GCC
CFLAGS += -Winit-self  # Good (C++ enables this in Wall, but not C)
CFLAGS += -Wmissing-field-initializers  # In -Wextra
CFLAGS += -Wno-unknown-pragmas  # May be good for allowing other compiler pragmas
CFLAGS += -Wstrict-prototypes  # Forces people to use foo(void) instead of foo(), potentially confusing
CFLAGS += -Wundef  # Probably don't need that
CFLAGS += -Wold-style-definition  # In -Wextra

I think we should include the following:

CFLAGS = -std=c99
CFLAGS += -Wall
CFLAGS += -Wextra
CFLAGS += -Wpedantic
CFLAGS += -Werror

And it might be a good idea to include some (or all) of these.

CFLAGS += -Wwrite-strings  # Helps for enforcing const char*
CFLAGS += -Winit-self  # Good (C++ enables this for Wall, but not C)
CFLAGS += -Wstrict-prototypes  # Forces people to use foo(void) instead of foo(), potentially confusing

What do you all think? I don't usually mess around with warnings outside of -Wall -Wextra -Wpedantic.

If you need to look up the warning options, here are GCC's

As per title, should solutions be checked by valgrind for memory leaks, overrruns and possibly also thread errors (if any examples are added that use thread).

Per the discussion in exercism/discussions#128 we
will be installing the probot/stale integration on the Exercism organization on
April 10th, 2017.

By default, probot will comment on issues that are older than 60 days, warning
that they are stale. If there is no movement in 7 days, the bot will close the issue.
By default, anything with the labels security or pinned will not be closed by
probot.

If you wish to override these settings, create a .github/stale.yml file as described
in https://github.com/probot/stale#usage, and make sure that it is merged
before April 10th.

If the defaults are fine for this repository, then there is nothing further to do.
You may close this issue.

This was my bad. In #83, the "allergies" exercise was placed before the "hello world" exercise in config.json. Thus, "Hello World" will not be the first exercise that everyone gets. This is probably not what we want.

Especially since the tests pass the length as a magic number.

All-your-base exercise has a couple of unit tests that assign negative numbers to uint data types.
example:

void test_first_base_is_negative(void)
{
   int8_t input[] = { 1 };
   int8_t expected[] = { 0 };
   test_rebase(-2, input, LENGTH(input), 10, expected, 0);
}

test_rebase is defined in the test case as:

void test_rebase(uint16_t input_base, int8_t input_digits[],
                 size_t input_length, uint16_t output_base,
                 int8_t expected_digits[], size_t expected_length)

We should either just delete those test cases or change the function prototype to allow negative bases.
I think deleting the test case is more C like, allowing negative numbers there seems like a Java thing.

One other test case was not implemented per the cannonical-data

    {
      "description": "negative digit",
      "property": "rebase",
      "input_base": 2,
      "input_digits": [1, -1, 1, 0, 1, 0],
      "output_base": 10,
      "expected": null
    },```
The `C` track is implemented with a negative base instead of a negative.  I can fix that case, or just delete it and make the arrays uint8_t[] vs int8_t[].

Let me know how you want me to proceed.

Should we use fixed-width types (e.g. stdint) exclusively or favor primitive types unless a size-guaranteed type is required for the particular exercise?

This will make it so that indent.sh does not have to be modified to be run on MacOS.

TLDR - There are issues with doing the exercises under Visual Studio (and likely other non-GCC/Clang compilers like ICC). This can be fixed by adding the following function defs to all of the test\test_*.c files.

void setUp(void) { }
void tearDown(void) { }

This is because Unity uses a non-standard method to support optional setUp and tearDown methods. GCC and Clang methods are implemented in Unity (they support __attribute__((weak)) and/or #pragma weak I think). Other compilers may do the same, but MSVC doesn't support those as far as I can tell.

Someone could fix the issue for us by patching Unity with the correct method for MSVC (you can pass comments to the linker using a pragma), but that doesn't fix it for other compilers that don't support the weak linking either.

It does work fine using the various unix implementations on Windows (WSL and MSYS) since they just use GCC.

If you change a depended-upon header and re-make it will not recompile C files that include that header. We could do this the complicated way and build dep files, or we could weasel out and just add header files as dependencies for the .o build targets. I think that I'm in favor of keeping it simple at this point. Thoughts?

atbash-cipher exercise , has valgrind errors , it does have memory leaks too , so the whole run-test fails when i ran run-test bash script locally , this will cause fail builds on travis-ci even though other exercises are valid

Currently there is some inconsistency in formatting/style for the tests and sample solutions. We should choose a style guide, document it in README.md, and ensure that it is applied consistently on the track.

The old help site was deprecated in December 2015. We now have content that is displayed on the main exercism.io website, under each individual language on http://exercism.io/languages.

The content itself is maintained along with the language track itself, under the docs/ directory.

We decided on this approach since the maintainers of each individual language track are in the best position to review documentation about the language itself or the language track on Exercism.

Please verify that nothing in docs/ refers to the help.exercism.io site. It should instead point to http://exercism.io/languages/:track_id (at the moment the various tabs are not linkable, unfortunately, we may need to reorganize the pages in order to fix that).

Also, some language tracks reference help.exercism.io in the SETUP.md file, which gets included into the README of every single exercise in the track.

We may also have referenced non-track-specific content that lived on help.exercism.io. This content has probably been migrated to the Contributing Guide of the x-common repository. If it has not been migrated, it would be a great help if you opened an issue in x-common so that we can remedy the situation. If possible, please link to the old article in the deprecated help repository.

If nothing in this repository references help.exercism.io, then this can safely be closed.

The main contributing guide explains a little about how example solutions work across the Exercism tracks, but the usage here of example.c, example.h, and the provided headers should be explicitly explained in our README.

The same patch would likely apply to the exercism/xcpp repo as well.

This basic block is included in most of the tests:

   int outputs_len = sizeof(outputs) / MAX_STR_LEN;
   qsort(outputs, outputs_len, sizeof(char) * MAX_STR_LEN, stringcmp);

   struct Vector vout = anagrams_for("Orchestra", vin);
   qsort(vout.vec, vout.size, sizeof(char) * MAX_STR_LEN, stringcmp);

   TEST_ASSERT_EQUAL(outputs_len, vout.size);
   int x;
   for (x = 0; x < vout.size; x++) {
      TEST_ASSERT_EQUAL(strlen(outputs[x]), strlen(vout.vec[x]));
      TEST_ASSERT_EQUAL_MEMORY(outputs[x], vout.vec[x], strlen(outputs[x]));
   }

We should probably refactor these tests to remove all of this noise and make it much more clear what is actually being checked.

The problem brief mentions:

• If the phone number is more than 11 digits assume that it is a bad number

But the tests do not check for this requirement.

See exercism/problem-specifications#28

See issue #2092 for an overview of operation welcome contributors.

Provide instructions on how to contribute patches to the exercism test suites
and examples: dependencies, running the tests, what gets tested on Travis-CI,
etc.

The contributing document
in the x-api repository describes how all the language tracks are put
together, as well as details about the common metadata, and high-level
information about contributing to existing problems, or adding new problems.

The README here should be language-specific, and can point to the contributing
guide for more context.

From the OpenHatch guide:

Here are common elements of setting up a development environment you’ll want your guide to address:

Preparing their computer
Make sure they’re familiar with their operating system’s tools, such as the terminal/command prompt. You can do this by linking to a tutorial and asking contributors to make sure they understand it. There are usually great tutorials already out there - OpenHatch’s command line tutorial can be found here.
If contributors need to set up a virtual environment, access a virtual machine, or download a specific development kit, give them instructions on how to do so.
List any dependencies needed to run your project, and how to install them. If there are good installation guides for those dependencies, link to them.

Downloading the source
Give detailed instructions on how to download the source of the project, including common missteps or obstacles.

How to view/test changes
Give instructions on how to view and test the changes they’ve made. This may vary depending on what they’ve changed, but do your best to cover common changes. This can be as simple as viewing an html document in a browser, but may be more complicated.

Installation will often differ depending on the operating system of the contributor. You will probably need to create separate instructions in various parts of your guide for Windows, Mac and Linux users. If you only want to support development on a single operating system, make sure that is clear to users, ideally in the top-level documentation.

The new run-test bash script seems to fail on travis-ci because of Valgrind!

The hello world exercise tests that the implementation is careful not to write out of bounds. While this is good practice, it seems excessive for a hello world. This may be someone's first exposure to C, to unit testing, and to Exercism, so it seems that we should save buffer overflows for a later topic.

I'd like to update the hello world exercise to use a comically over-sized buffer and save this topic for a later exercise. Thoughts?

Currently the tests as well as the example is implemented as checking the first character of name beeing '\0', which makes it impossible to produce the (weird) output "Hello, !".

Even if this output is weird it is valid in many other tracks, and since we are able to in C, I do also think we should resemble a behaviour which comes closer to most other tracks, and actually allow hello(dest, size, "") to fill dest with that weird string from above while hello(dest, size, NULL) will insert "World" as name.

Using NULL also does come close to other tracks that use some Maybe or Option type to achieve the behaviour described.

I've used Sarah Sharp's FOSS Heartbeat project to generate stats for each of the language track repositories, as well as the x-common repository.

The Exercism heartbeat data is published here: https://exercism.github.io/heartbeat/

When looking at the data, please disregard any activity from me (kytrinyx), as I would like to get the language tracks to a point where they are entirely maintained by the community.

Please take a look at the heartbeat data for this track, and answer the following questions:

• To what degree is the track maintained?
• Who (if anyone) is merging pull requests?
• Who (if anyone) is reviewing pull requests?
• Is there someone who is not merging pull requests, but who comments on issues and pull requests, has thoughtful feedback, and is generally helpful? If so, maybe we can invite them to be a maintainer on the track.

I've made up the following scale:

• ORPHANED - Nobody (other than me) has merged anything in the past year.
• ENDANGERED - Somewhere between ORPHANED and AT RISK.
• AT RISK - Two people (other than me) are actively discussing issues and reviewing and merging pull requests.
• MAINTAINED - Three or more people (other than me) are actively discussing issues and reviewing and merging pull requests.

It would also be useful to know if there a lot of activity on the track, or just the occasional issue or comment.

Please report the current status of the track, including your best guess on the above scale, back to the top-level issue in the discussions repository: exercism/discussions#97

Indentation was incorrect in #71 but bin/verify-indent indicated that there was no issue. When run locally bin/verify-indent did indicate that indent.sh needed to be run.

Note: the launch checklist was woefully outdated, since this got created over two years ago, so I deleted it.

If you are interested in leading the charge on getting this track launched, then comment below, and I'll help get this party started based on whatever is current at the time.

We have a launch guide that we'll keep up to date with changes here: https://github.com/exercism/docs/blob/master/language-tracks/launch/README.md

• Anagram: Fix 1 failing test
• Leap: Fix 1 failing test
• Leap: Fix 2 compiler warnings

Currently, the run-tests script does not catch a compiler error, only test failures. We need to make the script return non-zero if there is a compiler error so that Travis considers the build a failure.

In the rna-transcription exercise's test file, the test_transcription() test helper function tries to use strncmp() and free() on the result of the UUT. But, following the TDD rules, at the start of the TDD process the UUT does not allocate any memory - this means that the project is un-buildable until at least some not insignificant portion of the implementation is already achieved, thus it breaks the TDD process that is supposed to be being fostered (according to the description of the exercise at least).

The helper function should be altered so as not to prevent early iterations of the implementation from being built. This could be as simple as adding in a check for NULL. e.g:

void test_transcription(const char *dna, const char *expected)
{
   char *rna = to_rna(dna);
   if (rna != NULL) {
      TEST_ASSERT_TRUE(strncmp(rna, expected, strlen(dna)) == 0);
      free(rna);
   } else {
      TEST_FAIL();
   }
}

The JSON in the API is choking on the tests.out file, which is binary. @kdar Is this file something that needs to be shipped to the user, or would it be OK to delete it from the repository and add a gitignore for it?

This will give us (guaranteed) access to stdint types and is generally a more pleasant experience than C89. Shall we proceed to take advantage of C99 in all of our examples and tests where appropriate?

For the past three years, the ordering of exercises has been done based on gut feelings and wild guesses. As a result, the progression of the exercises has been somewhat haphazard.

In the past few months maintainers of several tracks have invested a great deal of time in analyzing what concepts various exercises require, and then reordering the tracks as a result of that analysis.

It would be useful to bake this data into the track configuration so that we can adjust it over time as we learn more about each exercise.

To this end, we've decided to add a new key exercises in the config.json file, and deprecate the problems key.

See exercism/discussions#60 for details about this decision.

Note that we will not be removing the problems key at this time, as this would break the website and a number of tools.

The process for deprecating the old problems array will be:

• Update all of the track configs to contain the new exercises key, with whatever data we have.
• Simultaneously change the website and tools to support both formats.
• Once all of the tracks have added the exercises key, remove support for the old key in the site and tools.
• Remove the old key from all of the track configs.

In the new format, each exercise is a JSON object with three properties:

• slug: the identifier of the exercise
• difficulty: a number from 1 to 10 where 1 is the easiest and 10 is the most difficult
• topics: an array of strings describing topics relevant to the exercise. We maintain
  a list of common topics at https://github.com/exercism/x-common/blob/master/TOPICS.txt. Do not feel like you need to restrict yourself to this list;
  it's only there so that we don't end up with 20 variations on the same topic. Each
  language is different, and there will likely be topics specific to each language that will
  not make it onto the list.

The difficulty rating can be a very rough estimate.

The topics array can be empty if this analysis has not yet been done.

Example:

"exercises": [
  {
    "slug": "hello-world" ,
    "difficulty": 1,
    "topics": [
        "control-flow (if-statements)",
        "optional values",
        "text formatting"
    ]
  },
  {
    "difficulty": 3,
    "slug": "anagram",
    "topics": [
        "strings",
        "filtering"
    ]
  },
  {
    "difficulty": 10,
    "slug": "forth",
    "topics": [
        "parsing",
        "transforming",
        "stacks"
    ]
  }
]

It may be worth making the change in several passes:

1. Add the exercises key with the array of objects, where difficulty is 1 and topics is empty.
2. Update the difficulty settings to reflect a more accurate guess.
3. Add topics (perhaps one-by-one, in separate pull requests, in order to have useful discussions about each exercise).

My team at work is interested in populating this track. I'm a maintainer for the Lua track and I'm happy to be a maintainer or the maintainer for this track as well.

This issue was raised by byelipk in his exercise. I don't think it applies in that case, but ran again using malloc and no error, I'm not used to Unity yet, but I think there should be one for a malloc without free. Creating the issue until I can dig deeper.

Code I ran to test:

#include "raindrops.h"
#include "stdio.h"
#include "string.h"
#include <stdlib.h>

#define PLING_FACTOR 3
#define PLANG_FACTOR 5
#define PLONG_FACTOR 7

char *convert(char *buffer, int buffer_length, int drops)
{
   memset(buffer, '\0', sizeof(char) * buffer_length);
   if ((drops % PLING_FACTOR != 0) &&
       (drops % PLANG_FACTOR != 0) && (drops % PLONG_FACTOR != 0)) {
      snprintf(buffer, buffer_length, "%d", drops);
   } else {
      snprintf
          (buffer,
           buffer_length,
           "%s%s%s",
           drops % PLING_FACTOR == 0 ? "Pling" : "",
           drops % PLANG_FACTOR == 0 ? "Plang" : "",
           drops % PLONG_FACTOR == 0 ? "Plong" : "");
   }
    char* newbuffer = malloc(sizeof(char) * buffer_length);
    memcpy(newbuffer,buffer,buffer_length);
   return newbuffer;
}

Completely unrelated to the title, but raindrops_test.c needs to be updated to check the value in the buffer, not just the return value. They should match. I can address that at the same time or with a different patch. However you want.

Normally in TDD you get one test to fail, get it to pass, refactor, start on next test. In the C track all tests run the first time you build.
We could use the macros from cpp fairly easily.

#if defined(EXERCISM_RUN_ALL_TESTS)
#endif

I happy to contribute to this effort if we want to do it. I might need some guidance on everywhere we need to change.

Each language track has documentation in the docs/ directory, which gets included on the site
on each track-specific set of pages under /languages.

We've added some general guidelines about how we'd like the track to be documented in exercism/exercism#3315
which can be found at https://github.com/exercism/exercism.io/blob/master/docs/writing-track-documentation.md

Please take a moment to look through the documentation about documentation, and make sure that
the track is following these guidelines. Pay particularly close attention to how to use images
in the markdown files.

Lastly, if you find that the guidelines are confusing or missing important details, then a pull request
would be greatly appreciated.

if we use modern c compiler, use #pragma once instead of old style #ifndef -- #endif .
macro names starting with one or two underscores, such as _HELLO_WORLD_H and __HELLO_WORLD_H, are reserved to the implementation and should not be used by the user.

#pragma once

void hello(char *buffer, const char *name);

#ifndef _HELLO_WORLD_H
#define _HELLO_WORLD_H

void hello(char *buffer, const char *name);

#endif

Whenever I try to run the test suite for raindrops, I get 17 errors: "cast to 'const char *' from smaller integer type 'int'", and they're being called from the tests themselves. I've tried re-downloading the exercise. Any guidance?

Because simply adding 1e9 seconds works for the other languages, but here it only passes 3/5 tests.

I've got issue with this exercise because I used ming32 that doesnt support time64 type. Please, remake test suite for handling time32 type. Thank you!

My recommendation is to use CMake similar to what is done in the C++ track.

Using rake to build C code is just... weird. I doubt anyone that is well steeped in C is going to be familiar with rake.

The contents of the SETUP.md file gets included in
the README.md that gets delivered when a user runs the exercism fetch
command from their terminal.

At the very minimum, it should contain a link to the relevant
language-specific documentation on
help.exercism.io.

It would also be useful to explain in a generic way how to run the tests.
Remember that this file will be included with all the problems, so it gets
confusing if we refer to specific problems or files.

Some languages have very particular needs in terms of the solution: nested
directories, specific files, etc. If this is the case here, then it would be
useful to explain what is expected.

Thanks, @tejasbubane for suggesting that we add this documentation everywhere.
See exercism.io#2198.

The ./indent.sh script seems to have stopped working. The output after executing is

: not found: 5: ./indent.sh:
./indent.sh: 6: ./indent.sh: Syntax error: word unexpected (expecting "do")

This is due to the CRLF line-endings present in the file which you can see as 0d 0a if you run $ hexdump -C ./indent.sh:

00000000  23 21 2f 62 69 6e 2f 73  68 0d 0a 23 0d 0a 23 20  |#!/bin/sh..#..# |
00000010  49 6e 64 65 6e 74 73 20  61 6c 6c 20 2e 63 20 61  |Indents all .c a|
00000020  6e 64 20 2e 68 20 66 69  6c 65 73 20 69 6e 20 74  |nd .h files in t|
00000030  68 65 20 70 72 6f 6a 65  63 74 20 74 68 61 74 20  |he project that |
00000040  61 72 65 20 6e 6f 74 20  76 65 6e 64 6f 72 20 63  |are not vendor c|
00000050  6f 64 65 20 28 69 65 3a  20 55 6e 69 74 79 29 2e  |ode (ie: Unity).|
00000060  0d 0a 23 0d 0a 0d 0a 66  6f 72 20 66 20 69 6e 20  |..#....for f in |
00000070  24 28 66 69 6e 64 20 65  78 65 72 63 69 73 65 73  |$(find exercises|
00000080  2f 20 2d 6e 6f 74 20 2d  70 61 74 68 20 27 2a 2f  |/ -not -path '*/|
00000090  76 65 6e 64 6f 72 2f 2a  27 20 2d 6e 61 6d 65 20  |vendor/*' -name |
000000a0  27 2a 2e 63 27 20 2d 6f  72 20 2d 6e 6f 74 20 2d  |'*.c' -or -not -|
000000b0  70 61 74 68 20 27 2a 2f  76 65 6e 64 6f 72 2f 2a  |path '*/vendor/*|
000000c0  27 20 2d 6e 61 6d 65 20  27 2a 2e 68 27 29 3b 20  |' -name '*.h'); |
000000d0  64 6f 0d 0a 20 20 69 6e  64 65 6e 74 20 2d 6e 62  |do..  indent -nb|
000000e0  61 64 20 2d 62 61 70 20  2d 6e 62 63 20 2d 62 62  |ad -bap -nbc -bb|

These can be removed either by editing the file or running $ cat ./indent.sh | tr -d '\r' >> ./indent_new.sh

Not sure if there is a reason this hasn't shown up until now? Maybe the issue is only present on my machine for some reason?

Including a (more or less) completed header will help set to ensure that solutions are const-correct and help to communicate all assumptions made about arguments in the tests.

Including an empty source file will help to ensure that the user can get something compiling relatively quickly.

The README.md suggests use of $ indent -linux -i3. this does not match what is produced by indent.sh however. as the CI uses indent.sh to verify the indent on files then this causes problems for those that read the readme and simply ran the indent command as suggested.

This can be seen in commit a5d8645 on which I ran $ indent -linux -i3 $(file). This found a small braces spacing issue and corrected it. Thinking all was good I commited, pushed and made the PR to start the CI. But the CI reported that verify-indent failed! To see what the issue was I tried running $ indent.sh $(file) which made another, different, spacing change. This committed as 1f32a18 and subsequently passed the CI test.

I haven't tested this out but it seems that the options used in indent.sh differ from the Linux style (as specified by man indent), not only by -i3, but also by -nut, which may possibly be where the difference is caused (I'm not really familiar with indent so mainly guessing here). If this is the case I would suggest changing either the rule in indent.sh, or the suggested command in README.md that uses the -linux option. Obviously the latter would have the least effect on the existing code, but I am unsure which of the styles was the intended one.

strptime is not available in vanilla C99 and is a Unix extension (https://www.gnu.org/software/libc/manual/html_node/Parsing-Date-and-Time.html). You need to define _GNU_SOURCE and __USE_XOPEN on Ubuntu to have time.h bring it in. We should remove this to improve compatibility across platforms.

The problems api (x-api) now supports having exercises collected in a subdirectory
named exercises.

That is to say that instead of having a mix of bin, docs, and individual exercises,
we can have bin, docs, and exercises in the root of the repository, and all
the exercises collected in a subdirectory.

In other words, instead of this:

x{TRACK_ID}/
├── LICENSE
├── README.md
├── bin
│   └── fetch-configlet
├── bowling
│   ├── bowling_test.ext
│   └── example.ext
├── clock
│   ├── clock_test.ext
│   └── example.ext
├── config.json
└── docs
│   ├── ABOUT.md
│   └── img
... etc

we can have something like this:

x{TRACK_ID}/
├── LICENSE
├── README.md
├── bin
│   └── fetch-configlet
├── config.json
├── docs
│   ├── ABOUT.md
│   └── img
├── exercises
│   ├── bowling
│   │   ├── bowling_test.ext
│   │   └── example.ext
│   └── clock
│       ├── clock_test.ext
│       └── example.ext
... etc

This has already been deployed to production, so it's safe to make this change whenever you have time.

Hi all,

New to this, so I'm sorry if I'm missing something obvious, but it seems that all the make files are missing source dependencies? Is it expected for the user to add them?

Also, it seems that it might be useful to include blank source files, especially since there are references to the required files in the Makefiles and test files. I feel like both of these would just be one less step for setting up.

Right now all of the icons used for the language tracks (which can be seen at http://exercism.io/languages) are stored in the exercism/exercism.io repository in public/img/tracks/. It would make a lot more sense to keep these images along with all of the other language-specific stuff in each individual language track repository.

There's a pull request that is adding support for serving up the track icon from the x-api, which deals with language-specific stuff.

In order to support this change, each track will need to

• create a directory named img/ at the root of this repository if it doesn't already exist, then
• find the correct icon in https://github.com/exercism/exercism.io/tree/master/public/img/tracks, and
• stick it in the img/ directory, and importantly
• name the image icon.png

In other words, at the end of it you should have the following file:

./img/icon.png

See exercism/exercism#2925 for more details.