Added resistor-color exercise. Updated README.

README.md

@@ -91,122 +91,18 @@ The `bin/` subdirectory contains several scripts to help you contribute exercise
 - `bin/run-test.sh` runs the tests for a specific exercise, or for all exercises if no exercise name is provided.
 - `bin/verify-exercises` checks the integrity of all exercises, including tests.
   It is used by the build system whenever new code is pushed to the repository.
-- `bin/gen-exercise.sh` can be used to generate a new exercise. More details follow below.
+- `bin/configlet` can be used to generate a new exercise. More details follow below.
 
 ### Creating a New Exercise
-1. Edit `config.json` to include the information about the new exercise. Add a new entry into the
-   `exercises` dictionary, either under `concept` or `practice`. You'll need the unique identifier
-   (`uuid`) which is best lifted from another track. This can also be used to populate the slug,
-   name, difficulty, and other fields that should typically be similar between tracks.
-2. Run `bin/gen-exercise.sh <slug>` to automatically generate the exercise skeleton in the
-   `exercises/practice/<slug>/` directory.
-3. Edit `exercises/practice/<slug>/.meta/config.json` and populate the `files.solution`,
-   `files.test`, and `files.example` arrays to point to the generated files. Add your Exercism
-   username to the `authors` array.
-4. `exercises/practice/<slug>/<slug>_test.odin` will already contain stubs for a minimum number of
-   standard tests for the exercise, but will likely need editing to invoke the right function in the
-   solution, and to correctly test the output. It is strongly recommended that you look at the tests
-   from a reference track (e.g. C or Zig) and include a more thorough set of tests.
-
-## TODO
-- Let `bin/gen-exercise.sh` automatically configure `.meta/config.json` when a new exercise skeleton
-  is generated.
-- Figure out how to build an Odin test runner (currently using bash script for this)
-- [Highlight.js support for Odin](https://github.com/highlightjs/highlight.js/blob/main/SUPPORTED_LANGUAGES.md)
-
-## Odin Docs
-
-- [Odin website](http://odin-lang.org)
-- [Odin GitHub](https://github.com/odin-lang/Odin)
-- [Odin examples](https://github.com/odin-lang/examples)
-- [Odin language server](https://github.com/DanielGavin/ols)
-
-## Exercism Docs
-
-- https://exercism.org/docs/building/tracks/new/request-new
-- https://exercism.org/docs/building/tracks/new/add-first-exercise
-- https://exercism.org/docs/building/tracks/new/add-initial-exercises
-- https://exercism.org/docs/building/tracks/new/setup-continuous-integration
-- https://exercism.org/docs/building/tooling/test-runners
-- https://github.com/exercism/generic-track
-- https://github.com/exercism/problem-specifications
-
-## Example Nix Config
-
-```nix
-{ pkgs }:
-let
-  inherit (pkgs) lib;
-
-  # TODO: Building odinfmt requires the nighly build of Odin itself
-  new_pkgs = import
-    (pkgs.fetchFromGitHub {
-      owner = "NixOS";
-      repo = "nixpkgs";
-      rev = "ef66aec42b5f9035a675496e9a7fe57b63505646";
-      # sha256 = lib.fakeSha256;
-      sha256 = "1j1ywwk1wzcd60dbam3pif8z0v695ssmm8g4aw9j01wl36pds31a";
-    })
-    { };
-
-  odin = new_pkgs.odin;
-in
-{
-  deps = [
-    odin
-    pkgs.ruby
-    pkgs.gh
-    pkgs.just
-    pkgs.jq
-  ];
-}
-```
-
-*Below is the previous generic track readme; will modify later.*
-
----
-
-# Exercism Odin Track
-
-[![Configlet](https://github.com/exercism/odin/actions/workflows/configlet.yml/badge.svg)](https://github.com/exercism/odin/actions/workflows/configlet.yml) [![.github/workflows/test.yml](https://github.com/exercism/odin/actions/workflows/test.yml/badge.svg)](https://github.com/exercism/odin/actions/workflows/test.yml)
-
-Exercism exercises in Odin.
-
-## Testing
-
-To test the exercises, run `./bin/test`.
-This command will iterate over all exercises and check to see if their exemplar/example implementation passes all the tests.
-
-### Track linting
-
-[`configlet`](https://exercism.org/docs/building/configlet) is an Exercism-wide tool for working with tracks. You can download it by running:
-
-```shell
-./bin/fetch-configlet
-```
-
-Run its [`lint` command](https://exercism.org/docs/building/configlet/lint) to verify if all exercises have all the necessary files and if config files are correct:
-
-```shell
-$ ./bin/configlet lint
-
-The lint command is under development.
-Please re-run this command regularly to see if your track passes the latest linting rules.
-
-Basic linting finished successfully:
-- config.json exists and is valid JSON
-- config.json has these valid fields:
-    language, slug, active, blurb, version, status, online_editor, key_features, tags
-- Every concept has the required .md files
-- Every concept has a valid links.json file
-- Every concept has a valid .meta/config.json file
-- Every concept exercise has the required .md files
-- Every concept exercise has a valid .meta/config.json file
-- Every practice exercise has the required .md files
-- Every practice exercise has a valid .meta/config.json file
-- Required track docs are present
-- Required shared exercise docs are present
-```
+- Run `bin/configlet create --practice-exercise <slug>` to automatically generate the exercise skeleton in the `exercises/practice/<slug>/` directory and to update `config.json` to reference the new exercise.
+  You can add `--author <your_exercism_username>` as option to mark yourself as the creator of this exercise (or add it later in the exercise's `.meta/config.json` file.)
+- Add a solution stub at the exercise's `<slug>.odin` file.
+  This is what users will start with when solving the exercise.
+- Add tests to `<slug>_test.odin`.
+  Verify that the slug solution would fail _all_ tests.
+  Consider adding an error return enumeration such as `NotImplemented` to ensure that the stub solution's return values are invalid for all test cases.
+- Implement a reference solution at `.meta/<slug>_example.odin`.
+- Use `bin/run_test.sh <slug>` to verify that your reference solution passes.
 
 [being-a-good-community-member]: https://github.com/exercism/docs/tree/main/community/good-member
 [chestertons-fence]: https://github.com/exercism/docs/blob/main/community/good-member/chestertons-fence.md

config.json

@@ -58,6 +58,14 @@
         "practices": [],
         "prerequisites": [],
         "difficulty": 2
+      },
+      {
+        "slug": "resistor-color",
+        "name": "Resistor Color",
+        "uuid": "ea5eb0a7-4a4a-4f08-b2e4-87a52bd64ce0",
+        "practices": [],
+        "prerequisites": [],
+        "difficulty": 1
       }
     ]
   },

exercises/practice/resistor-color/.docs/instructions.md

@@ -0,0 +1,39 @@
+# Instructions
+
+If you want to build something using a Raspberry Pi, you'll probably use _resistors_.
+For this exercise, you need to know two things about them:
+
+- Each resistor has a resistance value.
+- Resistors are small - so small in fact that if you printed the resistance value on them, it would be hard to read.
+
+To get around this problem, manufacturers print color-coded bands onto the resistors to denote their resistance values.
+Each band has a position and a numeric value.
+
+The first 2 bands of a resistor have a simple encoding scheme: each color maps to a single number.
+
+In this exercise you are going to create a helpful program so that you don't have to remember the values of the bands.
+
+These colors are encoded as follows:
+
+- black: 0
+- brown: 1
+- red: 2
+- orange: 3
+- yellow: 4
+- green: 5
+- blue: 6
+- violet: 7
+- grey: 8
+- white: 9
+
+The goal of this exercise is to create a way:
+
+- to look up the numerical value associated with a particular color band
+- to list the different band colors
+
+Mnemonics map the colors to the numbers, that, when stored as an array, happen to map to their index in the array:
+Better Be Right Or Your Great Big Values Go Wrong.
+
+More information on the color encoding of resistors can be found in the [Electronic color code Wikipedia article][e-color-code].
+
+[e-color-code]: https://en.wikipedia.org/wiki/Electronic_color_code

exercises/practice/resistor-color/.meta/config.json

@@ -0,0 +1,19 @@
+{
+  "authors": [
+    "gvrooyen"
+  ],
+  "files": {
+    "solution": [
+      "resistor_color.odin"
+    ],
+    "test": [
+      "resistor_color_test.odin"
+    ],
+    "example": [
+      ".meta/resistor_color_example.odin"
+    ]
+  },
+  "blurb": "Convert a resistor band's color to its numeric representation.",
+  "source": "Maud de Vries, Erik Schierboom",
+  "source_url": "https://github.com/exercism/problem-specifications/issues/1458"
+}

exercises/practice/resistor-color/.meta/tests.toml

@@ -0,0 +1,22 @@
+# This is an auto-generated file.
+#
+# Regenerating this file via `configlet sync` will:
+# - Recreate every `description` key/value pair
+# - Recreate every `reimplements` key/value pair, where they exist in problem-specifications
+# - Remove any `include = true` key/value pair (an omitted `include` key implies inclusion)
+# - Preserve any other key/value pair
+#
+# As user-added comments (using the # character) will be removed when this file
+# is regenerated, comments can be added via a `comment` key.
+
+[49eb31c5-10a8-4180-9f7f-fea632ab87ef]
+description = "Color codes -> Black"
+
+[0a4df94b-92da-4579-a907-65040ce0b3fc]
+description = "Color codes -> White"
+
+[5f81608d-f36f-4190-8084-f45116b6f380]
+description = "Color codes -> Orange"
+
+[581d68fa-f968-4be2-9f9d-880f2fb73cf7]
+description = "Colors"