exercism / tcl

Exercism exercises in Tcl.

For support, please post in the new Exercism forum. New posts here will be closed.

---

Welcome to Exercism

Where to open issues

For the time being we are triaging all issues from our forum. Please start a new topic there for your issue (presuming there isn't one already). Issues opened here will be automatically closed and you will receive a message redirecting you to the forum.

Feeling uncomfortable?

If you need to report a code of conduct violation, please email us at [email protected] and include [CoC] in the subject line. We will follow up with you as a priority.

Where to find the code

The code for the website lives in exercism/website. The code for the old website is in this repository, in the v1.exercism.io branch.

Who's behind Exercism?

Read about our Team on the site: https://exercism.org/team

tcl's Issues

[v3] Configure online editor

This issue is part of the migration to v3. You can read full details about the various changes here.

In Exercism v3, students can now choose to work on exercises directly from their browser, instead of having to download exercises to their local machine. The track-specific settings for the in-browser editor are defined in the top-level "online_editor" field in the track's config.json file. This field is defined as an object with two fields:

• "indent_style": the indent style, either "space" or "tab".
• "indent_size": the indent size, which is an integer (e.g. 4).

You can find a full description of these fields in the spec.

Goal

The "online_editor" field should be updated to correspond to the track's best practices regarding indentation.

Example

"online_editor": {
  "indent_style": "space",
  "indent_size": 4
}

Tracking

exercism/v3-launch#2

Name of test file

From what I've read, it seems the standard way to name a test file is the rootname of the tcl file being tested plus a ".test" extension

Should we follow this convention?

exercises/
├── hello-world
│   ├── hello-world.tcl
│   └── hello-world.test
└── two-fer
    ├── two-fer.tcl
    └── two-fer.test

References:

• the default configuration for tcltest
• an ancient style guide, https://core.tcl-lang.org/tips/doc/trunk/tip/352.md
• Getting Started with tcltest

style for declaring instance variables for OO tcl

I recently discovered I may not be writing idiomatic OO tcl.

These two styles both seem to work equivalently:

oo::class create Foo {
    variable bar

    constructor {input} {
        set bar $input
    }

    method twoBar {} {
        return [expr {2 * $bar}]
    }
}

and

oo::class create Foo {
    constructor {input} {
        variable bar
        set bar $input
    }

    method twoBar {} {
        my variable bar
        return [expr {2 * $bar}]
    }
}

I don't why there the my variable is not required for the first style: I've asked on StackOverflow.

While waiting for answers there, does one of those style strike you as "better"?

Maintain list of completed/in progress/pending exercises

AFter I jumped into the bash track and started porting a lot of exercises, we found that the track map needed some rearranging. While that process is still in progress, I did put together the following google spreadsheet to keep track of what we have and where we should go: https://docs.google.com/spreadsheets/d/14c1oovaMJeHvxBWpCk6BqX_XYqNBgLHfQ1WKsM-zye8/edit#gid=537059368

I think something similar would be beneficial while we are building the Tcl track. I'm thinking primarily, we'll be able to figure out:

• who will be working on them (we don't want to be working on the same ones)
• what likely tags they will have
• how they will nest in sensible groups.

If you agree, I'll create such a sheet for Tcl

robot-name exercise could use a test to check if the names are shuffled

i.e.

set r [Robot new]
set name1 [$r name]
$r reset
set name2 [$r name]
# check that name2 != name1 "+ 1"

Decide the behavior of tests that fail

When a test case fails, should it fail fast? Here are two ideas for a stub that can be placed in each test file. Deciding on this early has the advantage that we will not need to refactor files as we add more exercises. A necessary side-effect of picking a method of failure is to have the test suite exit 1 so that Travis CI will register failing tests as errors in #8.

[v3] Update status of track

This issue is part of the migration to v3. You can read full details about the various changes here.

There are several new features in Exercism v3 for tracks to build. To selectively enable these features on the Exercism v3 website, each track must keep track of the status of the following features:

• Concept Exercises have been built
• A test runner has been implemented
• A representer has been implemented
• An analyzer has been implemented

The status of these features is specified in the top-level "status" field in the track's config.json, as specified in the spec.

Goal

The "status" field in the config.json file should be updated to indicate the status of the features for this track. The list of features is defined in the spec.

Example

{
  "status": {
    "concept_exercises": true,
    "test_runner": true,
    "representer": false,
    "analyzer": false
  }
}

Tracking

exercism/v3-launch#12

Check docs are up to date

Please check if your documentation files are still up-to-date.

The key documentation files to check are:

• docs/ABOUT.md
• docs/INSTALLATION.md
• docs/LEARNING.md
• docs/RESOURCES.md
• docs/TESTS.md
• exercises/shared/.docs/help.md
• exercises/shared/.docs/tests.md

There might be more.

Link check report

To help identify invalid links, we've automatically checked the links of all *.md files in this repo.
This is the report of that check:

📝 Summary
---------------------
🔍 Total..........128
✅ Successful.....127
⏳ Timeouts.........0
🔀 Redirected.......0
👻 Excluded.........0
🚫 Errors...........1

Errors in ./notes-on-unimplemented-exercises.md
✗ https://blog.tcl.tk/515 (error sending request for url (https://blog.tcl.tk/515): error trying to connect: dns error: failed to lookup address information: Name or service not known)

Tracking

exercism/v3-launch#54

clean up booleanMatch proc in test scripts

In PR #76 I updated the booleanMatch proc to simplify it. Existing usage needs updating, as sshine points out:

• exercises/isogram/isogram.test
• exercises/armstrong-numbers/armstrong-numbers.test
• exercises/clock/clock.test

Extract track-specific test instructions from `config/exercise_readme.go.tmpl`

Each track needs a file that contains track-specific instructions on how to manually run the tests. The contents of this document are only presented to the student when using the CLI. This file lives at exercises/shared/.docs/tests.md. You almost certainly already have this information, but need to move it to the correct place.

For v2 tracks, this information was (usually) included in the readme template found at config/exercise_readme.go.tmpl. As such, tracks can extract the test instructions from the config/exercise_readme.go.tmpl file to the exercises/shared/.docs/tests.md file.

See https://github.com/exercism/csharp/pull/1557/files for an example PR.

Tracking

exercism/v3-launch#51

[v3] Add tags

This issue is part of the migration to v3. You can read full details about the various changes here.

In Exercism v3, tracks can be annotated with tags. This allows searching for tracks with a certain tag combination, making it easy for students to find an interesting track to join.

Tags are specified in the top-level "tags" field in the track's config.json file and are defined as an array of strings, as specified in the spec.

Goal

The "tags" field in the config.json file should be updated to contain the tags that are relevant to this track. The list of tags that can be used is listed in the spec.

Example

{
  "tags": [
    "runtime/jvm",
    "platform/windows",
    "platform/linux",
    "paradigm/declarative",
    "paradigm/functional",
    "paradigm/object_oriented"
  ]
}

Tracking

exercism/v3-launch#1

Language description needs improvement

Tcl casts everything into the mold of a command, even constructs like variable assignment, procedure definition and control flow. As such, it resembles both shell scripting and Lisp.

As I reread that, I interpreted the word "constructs" as a verb which makes the word "like" wrong.

An improvement might be

Tcl casts everything into commands, even variable assignments, procedure definitions and control flow.

Build Representer and Analyzer

This issue is part of the migration to v3. You can read full details about the various changes here.

Representer

In Exercism v3, we're introducing a new (optional) tool: the representer. The goal of the representer is to take a solution and returning a representation, which is an extraction of a solution to its essence with normalized names, comments, spacing, etc. but still uniquely identifying the approach taken. Two different ways of solving the same exercise must not have the same representation.

Each representer is track-specific. When a new solution is submitted, we run the track's representer, which outputs two JSON files that describe the representation.

Once we have a normalized representation for a solution, a team of vetted mentors will look at the solution and comment on it (if needed). These comments will then automatically be submitted to each new solution with the same representation. A notification will be sent for old solutions with a matching representation.

Each track should build a representer according to the spec. For tracks building a representer from scratch, we have a starting guide.

The representer is an optional tool though, which means that if a track does not have a representer, it will still function normally.

Analyzer

In Exercism v3, we are making increased use of our v2 analyzers. Analyzers automatically assess student's submissions and provide mentor-style commentary. They can be used to catch common mistakes and/or do complex solution analysis that can't easily be done directly in a test suite.

Each analyzer is track-specific. When a new solution is submitted, we run the track's analyzer, which outputs a JSON file that contains the analysis results.

In v2, analyzer comments were given to a mentor to pass to a student. In v3, the analyzers will normally output directly to students, although we have added an extra key to output suggestions to mentors. If your track already has an analyzer, the only requisite change is updating the outputted copy to be student-facing.

Each track should build an analyzer according to the spec. For tracks building an analyzer from scratch, we have a starting guide.

The analyzer is an optional tool though, which means that if a track does not have an analyzer, it will still function normally.

Goal 1

Build a representer for your track according to the spec. Check this page to help you get started with building a representer.

Note that the simplest representer is one that merely returns the solution's source code.

It can be very useful to check how other tracks have implemented their representer.

Goal 2

Build an analyzer for your track according to the spec. Check this page to help you get started with building an analyzer.

It can be very useful to check how other tracks have implemented their analyzer.

Choosing between representer and analyzer

If you want to build both, we recommend starting by building the representer for the following reasons:

• Representers are usually (far) easier to implement
• Representers can have a far bigger impact on the mentoring load than analyzers by empowering mentors
• Representers apply to all exercises, whereas analyzers usually target specific exercises or a subset

Tracking

exercism/v3-launch#8

Build analyzer

In Exercism v3, we are making increased use of our v2 analyzers. Analyzers automatically assess student's submissions and provide mentor-style commentary. They can be used to catch common mistakes and/or do complex solution analysis that can't easily be done directly in a test suite.

Each analyzer is track-specific. When a new solution is submitted, we run the track's analyzer, which outputs a JSON file that contains the analysis results.

In v2, analyzer comments were given to a mentor to pass to a student. In v3, the analyzers will normally output directly to students, although we have added an extra key to output suggestions to mentors. If your track already has an analyzer, the only requisite change is updating the outputted copy to be student-facing.

The analyzer is an optional tool though, which means that if a track does not have an analyzer, it will still function normally.

Goal

Build an analyzer for your track according to the spec. Check this page to help you get started with building an analyzer.

It can be very useful to check how other tracks have implemented their analyzer.

If your track already has a working analyzer, please close this issue and ensure that the .status.analyzer key in the track config.json file is set to true.

Choosing between representer and analyzer

There is some overlap between the goals of the representer and the analyzer. If you want to build both, we recommend starting by building the representer for the following reasons:

• Representers are usually (far) easier to implement
• Representers can have a far bigger impact on the mentoring load than analyzers by empowering mentors
• Representers apply to all exercises, whereas analyzers usually target specific exercises or a subset

Tracking

exercism/v3-launch#53

Moving from Travis to GitHub Actions

Hello 🙂

Over the last few months we've been transferring all our CI from Travis to GitHub Actions (GHA). We've found that GHA are easier to work with, more reliable, and much much faster.

Based on our success with GHA and increasing intermittent failures on Travis, we have now decided to try and remove Travis from Exercism's org altogether and shift everything to GHA. This issue acts as a call to action if your track is still using Travis.

For most CI checks this should be a transposing from Travis' syntax to GHA syntax, and hopefully quite straightforward (see this PR for an example). However, if you do encounter any issues doing this, please ask on Slack where lots of us now have experience with GHA, or post a comment here and I'll tag relevant people. This would also make a good Hacktoberfest issue for anyone interested in making their first contribution 🙂

If you've already switched this track to GHA, please feel free to close this issue and ignore it.

Thanks!

Create stub files for all exercises

We have decided to require all file-based tracks to provide stubs for their exercises.

The lack of stub file generates an unnecessary pain point within Exercism, contributing a significant proportion of support requests, making things more complex for our students, and hindering our ability to automatically run test-suites and provide automated analysis of solutions.

We believe that it’s essential to understand error messages, know how to use an IDE, and create files. However, getting this right as you’re just getting used to a language can be a frustrating distraction, as it can often require a lot of knowledge that tends to seep in over time. At the start, it can be challenging to google for all of these details: what file extension to use, what needs to be included, etc. Getting people up to speed with these things are not Exercism’s focus, and we’ve decided that we are better served by removing this source of confusion, letting people get on with actually solving the exercises.

The original discussion for this is at exercism/discussions#238.

Therefore, we’d like this track to provide a stub file for each exercise.

• If this track already provides stub files for all exercises, please close this issue.
• If this track already has an open issue for creating stubs, then my apologies. Please close one as a duplicate.
• Otherwise, please respond to this issue with useful details about what needs to be done to complete this task in this track so that people who are not familiar with the track may easily contribute.

All the test files have too much boilerplate

Students have to scroll down a page of boilerplate to find the test data. Simplify them.

Improve example solution for alphametics

The existing solution takes over a minute to test. Needs a better algorithm

Document versioning policy

Similar to https://github.com/exercism/haskell#exercise-versioning, it would be neat if we documented the practice of versioning exercises in this repository. We could similarly place it in the root README.

Purpose of .ruby_version file?

I just noticed this file lives in the root of the repo. Is it needed for CI?

Add 'rlwrap tclsh' hints to exercise readme template

Since tclsh does not have native readline support, add a hint for using rlwrap in the exercise readme template config/exercise_readme.go.tmpl like this StackOverflow Q&A. It would be necessary to subsequently regenerate README.md for all exercises.

What was it like to learn Tcl?

We’ve recently started a project to find the best way to design our tracks, in order to optimize the learning experience of students.

As a first step, we’ll be examining the ways in which languages are unique and the ways in which they are similar. For this, we’d really like to use the knowledge of everyone involved in the Exercism community (students, mentors, maintainers) to answer the following questions:

1. How was your experience learning Tcl? What was helpful while learning Tcl? What did you struggle with? How did you tackle problems?
2. In what ways did Tcl differ from other languages you knew at the time? What was hard to learn? What did you have to unlearn? What syntax did you have to remap? What concepts carried over nicely?

Could you spare 5 minutes to help us by answering these questions? It would greatly help us improve the experience students have learning Tcl :)

Note: this issue is not meant as a discussion, just as a place for people to post their own, personal experiences.

Want to keep your thoughts private but still help? Feel free to email me at [email protected]

Thank you!

[Important] The current website is about to enter maintenance mode to aid with v3 launch

TL;DR; At the end of Jan 2021, all tracks will enter v3 staging mode. Updates will no longer sync with the current live website, but instead sync with the staging website. The Tcl section of the v3 repo will be extracted and PR'd into this track (if appropriate). Further issues and information will follow over the coming weeks to prepare Tcl for the launch of v3.

Over the last 12 months, we've all been hard at work developing Exercism v3. Up until this point, all v3 tracks have been under development in a single repository - the v3 repository. As we get close to launch, it is time for us to explode that monorepo back into the normal track repos. Therefore, at the end of this month (January 2021), we will copy the v3 tracks contents from the v3 repository back to the corresponding track repositories.

As v3 tracks are structured differently than v2 tracks, the current (v2) website cannot work with v3 tracks. To prevent the v2 website from breaking, we'll disable syncing between track repositories and the website. This will effectively put v2 in maintenance mode, where any changes in the track repos won't show up on the website. This will then allow tracks to work on preparing for the Exercism v3 launch.

Where possible, we will script the changes needed to prepare tracks for v3. For any manual changes that need to be happening, we will create issues on the corresponding track repositories. We will be providing lots of extra information about this in the coming weeks.

We're really excited to enter the next phase of building Exercism v3, and to finally get it launched! 🙂

Launch Tracker 🔴

This issue is part of the migration to v3. You can read full details about the various changes here.

To get your track ready for Exercism v3, the following needs to be done:

• Configure online editor
• Add key features
• Add tags
• Update status of Concept Exercises
• Add prerequisites to Practice Exercises
• Update status of track
• Pass linting checks
• Build Test Runner
• Build Analyzer and Representer (optional)

This issue may be automatically added to over time. While track maintainers should check off completed items, please do not add/edit items in the list.

Tracking

exercism/v3-launch#7

Build representer

In Exercism v3, we're introducing a new (optional) tool: the representer. The goal of the representer is to take a solution and returning a representation, which is an extraction of a solution to its essence with normalized names, comments, spacing, etc. but still uniquely identifying the approach taken. Two different ways of solving the same exercise must not have the same representation.

Each representer is track-specific. When a new solution is submitted, we run the track's representer, which outputs two JSON files that describe the representation.

Once we have a normalized representation for a solution, a team of vetted mentors will look at the solution and comment on it (if needed). These comments will then automatically be submitted to each new solution with the same representation. A notification will be sent for old solutions with a matching representation.

The representer is an optional tool though, which means that if a track does not have a representer, it will still function normally.

Goal

Build a representer for your track according to the spec. Check this page to help you get started with building a representer.

Note that the simplest representer is one that merely returns the solution's source code.

It can be very useful to check how other tracks have implemented their representer.

If your track already has a working representer, please close this issue and ensure that the .status.representer key in the track config.json file is set to true.

Choosing between representer and analyzer

There is some overlap between the goals of the representer and the analyzer. If you want to build both, we recommend starting by building the representer for the following reasons:

• Representers are usually (far) easier to implement
• Representers can have a far bigger impact on the mentoring load than analyzers by empowering mentors
• Representers apply to all exercises, whereas analyzers usually target specific exercises or a subset

Tracking

exercism/v3-launch#52

flatten-array: add additional instructions about Tcl's lack of NULL value.

Good to have here - if it's not yet in the problem prompt (not included in this diff), it could be added there also.

Originally posted by @hiljusti in #229 (comment)

Add prerequisites to Practice Exercises

This issue is part of the migration to v3. You can read full details about the various changes here.

Exercism v3 introduces a new type of exercise: Concept Exercises. All existing (V2) exercises will become Practice Exercises.

Concept Exercises and Practice Exercises are linked to each other via Concepts. Concepts are taught by Concept Exercises and practiced in Practice Exercises. Each Exercise (Concept or Practice) has prerequisites, which must be met to unlock an Exercise - once all the prerequisite Concepts have been "taught" by a Concept Exercise, the exercise itself becomes unlocked.

For example, in some languages completing the Concept Exercises that teach the "String Interpolation" and "Optional Parameters" concepts might then unlock the two-fer Practice Exercise.

Each Practice Exercise has two fields containing concepts: a practices field and a prerequisites field.

Practices

The practices key should list the slugs of Concepts that this Practice Exercise actively allows a student to practice.

• These show up in the UI as "Practice this Concept in: TwoFer, Leap, etc"
• Try and choose 3 - 8 Exercises that practice each Concept.
• Try and choose at least two Exercises that allow someone to practice the basics of a Concept.
• Some Concepts are very common (for example strings). In those cases we recommend choosing a few good exercises that make people think about those Concepts in interesting ways. For example, exercises that require UTF-8, string concatenation, char enumeration, etc, would all be good examples.
• There should be one or more Concepts to practice per exercise.

Prerequisites

The prerequisites key lists the Concept Exercises that a student must have completed in order to access this Practice Exercise.

• These show up in the UI as "Learn Strings to unlock TwoFer"
• It should include all Concepts that a student needs to have covered to be able to complete the exercise in at least one idiomatic way. For example, for the TwoFer exercise in Ruby, prerequisites might include strings, optional-params, implicit-return.
• For Exercises that can be completed using alternative Concepts (e.g. an Exercise solvable by loops or recursion), the maintainer should choose the one approach that they would like to unlock the Exercise, considering the student's journey through the track. For example, the loops/recursion example, they might think this exercise is a good early practice of loops or that they might like to leave it later to teach recursion. They can also make use of an analyzer to prompt the student to try an alternative approach: "Nice work on solving this via loops. You might also like to try solving this using Recursion."
• There should be one or more prerequisites Concepts per exercise.

Although ideally all Concepts should be taught by Concept Exercises, we recognise that it will take time for tracks to achieve that. Any Practice Exercises that have prerequisites which are not taught by Concept Exercises, will become unlocked once the final Concept Exercise has been completed.

Goal

Practices

The "practices" field of each element in the "exercises.practice" field in the config.json file should be updated to contain the practice concepts. See the spec.

To help with identifying the practice concepts, the "topics" field can be used (if it has any contents). Once prerequisites have been defined for a Practice Exercise, the "topics" field should be removed.

Each practice concept should have its own entry in the top-level "concepts" array. See the spec.

Prerequisites

The "prerequisites" field of each element in the "exercises.practice" field in the config.json file should be updated to contain the prerequisite concepts. See the spec.

To help with identifying the prerequisites, the "topics" field can be used (if it has any contents). Once prerequisites have been defined for a Practice Exercise, the "topics" field should be removed.

Each prerequisite concept should have its own entry in the top-level "concepts" array. See the spec.

Example

{
  "exercises": {
    "practice": [
      {
        "uuid": "8ba15933-29a2-49b1-a9ce-70474bad3007",
        "slug": "leap",
        "name": "Leap",
        "practices": ["if-statements", "numbers", "operator-precedence"],
        "prerequisites": ["if-statements", "numbers"],
        "difficulty": 1
      }
    ]
  }
}

Tracking

exercism/v3-launch#6

CI: need to install Tcl Thread package

Apparently, the default Ubuntu Tcl package is not build with threads enabled. Need to find/write a GHA action for it.

Detail from the test run

*** Test exercise parallel-letter-frequency:

can't find package Thread
    while executing
"package require Thread"
    (file "parallel-letter-frequency.tcl" line 1)
    invoked from within
"source "parallel-letter-frequency.tcl""
    (file "parallel-letter-frequency.test" line 5)

Extract track-specific help instructions from `config/exercise_readme.go.tmpl`

Each track needs a file that contains track-specific instructions on how to get help. The contents of this document are only presented to the student when using the CLI. This file lives at exercises/shared/.docs/help.md. You almost certainly already have this information, but need to move it to the correct place.

For v2 tracks, this information was (usually) included in the readme template found at config/exercise_readme.go.tmpl. As such, tracks can extract the help instructions from the config/exercise_readme.go.tmpl file to the exercises/shared/.docs/help.md file.

See https://github.com/exercism/csharp/pull/1557/files for an example PR.

Tracking

exercism/v3-launch#50

The master branch will be renamed to main

In line with our new org-wide policy, the master branch of this repo will be renamed to main. All open PRs will be automatically repointed.

GitHub will show you a notification about this when you look at this repo after renaming:

In case it doesn't, this is the command it suggests:

git branch -m master main
git fetch origin
git branch -u origin/main main

You may like to update the primary branch on your forks too, which you can do under Settings->Branches and clicking the pencil icon on the right-hand-side under Default Branch:

We will post a comment below when this is done. We expect it to happen within the next 12 hours.

CI: More validation checks for exercises

• Check that for each exercise in exercises/, there's a proper entry in config.json
• Check that for each exercise in config.json, there's a directory in exercises/
• Check that exercise files have the proper file permissions

tests which expect a boolean result should expect to be true

The test body is shown to the student in the test result, and it's confusing to see the test code (e.g. expr {$a eq $b} but not see that it expects a false result.

Noticed for the robot-name exercise. A quick search shows:

$ ag -l -- '-result false'|sort
allergies/allergies.test
armstrong-numbers/armstrong-numbers.test
circular-buffer/circular-buffer.test
clock/clock.test
custom-set/custom-set.test
isbn-verifier/isbn-verifier.test
isogram/isogram.test
leap/leap.test
luhn/luhn.test
matching-brackets/matching-brackets.test
pangram/pangram.test
queen-attack/queen-attack.test
robot-name/robot-name.test
triangle/triangle.test

Decide naming and formatting scheme for unit tests

In order to document the naming and formatting decided in #9, this issue serves as a reference point if we should wish to change this at a later time.

For hello the only test is:

    {
      "description": "Say Hi!",
      "property": "hello",
      "input": {},
      "expected": "Hello, World!"
    }

If/when we should want to auto-generate tests from canonical data, I suggest that they become

test ${slug}-[incr i] {
    $description
} -body {
    $property $args
} -result $result

For hello-world this would produce:

test hello-1 {
    Say Hi!
} -body {
    hello
} -result "Hello, World!"

[v3] Add key features

This issue is part of the migration to v3. You can read full details about the various changes here.

In Exercism v3, each track must specify exactly six "key features". Exercism uses these features to highlight the most interesting, unique or "best" features of a language to a student.

Key features are specified in the top-level "key_features" field in the track's config.json file and are defined as an array of objects, as specified in the spec.

Goal

The "key_features" field in the config.json file should be updated to describe the six "key features" of this track. See the spec.

Example

{
  "key_features": [
    {
      "icon": "features-oop",
      "title": "Modern",
      "content": "C# is a modern, fast-evolving language."
    },
    {
      "icon": "features-strongly-typed",
      "title": "Cross-platform",
      "content": "C# runs on almost any platform and chipset."
    },
    {
      "icon": "features-functional",
      "title": "Multi-paradigm",
      "content": "C# is primarily an object-oriented language, but also has lots of functional features."
    },
    {
      "icon": "features-lazy",
      "title": "General purpose",
      "content": "C# can be used for a wide variety of workloads, like websites, console applications, and even games."
    },
    {
      "icon": "features-declarative",
      "title": "Tooling",
      "content": "C# has excellent tooling, with linting and advanced refactoring options built-in."
    },
    {
      "icon": "features-generic",
      "title": "Documentation",
      "content": "Documentation is excellent and exhaustive, making it easy to get started with C#."
    }
  ]
}

Tracking

exercism/v3-launch#5

[v3] Build Test Runner

This issue is part of the migration to v3. You can read full details about the various changes here.

In Exercism v3, one of the biggest changes is that we'll automatically check if a submitted solution passes all the tests.

We'll check this via a new, track-specific tool: the Test Runner. Each test runner is track-specific. When a new solution is submitted, we run the track's test runner, which outputs a JSON file that describes the test results.

The test runner must be able to run the tests suites of both Concept Exercises and Practice Exercises. Depending on the test runner implementation, this could mean having to update the Practice Exercises to the format expected by the test runner.

Goal

Build a test runner for your track according to the spec.

If you are building a test runner from scratch, we have a starting guide and a generic test runner that can be used as the base for the new test runner.

If a test runner has already been built for this track, please check if it works on both Concept Exercises and Practice Exercises.

It can be very useful to check how other tracks have implemented their test runner.

Tracking

exercism/v3-launch#4

Before going live, regenerate README files based on latest problem specifications

There have been a few problem spec PRs for descriptions.

Bootstrap Tcl track

• Update docs: #4
• Implement Hello World: #5
• CI for checking validity of example
• Set up commit hook and policy for PR-driven development
• Find json library for extracting canonical data for exercises
• Build test generator

Implement continuous integration

Implement a track test suite that can run both locally and on Travis CI. The track test suite should verify that each exercise makes sense, by running the exercise tests against the example solution.

Definition of terms

• exercise test suite: the test suite that is delivered to Exercism users as part of an Exercism exercise
• track test suite: the test suite that helps ensure that all of the exercise test suites in a language track are solvable

Background

When implementing an exercise test suite, we want to provide a good user experience for the people writing a solution to the exercise. People should not be confused or overwhelmed.

In most Exercism language tracks, we simulate Test-Driven Development (TDD) by implementing the tests in order of increasing complexity. We try to ensure that each test either

• helps triangulate a solution to be more generic, or
• requires new functionality incrementally.

Many test frameworks will randomize the order of the tests when running them. This is an excellent practice, which helps ensure that subsequent tests are not dependent on side effects from earlier tests. However, in order to simulate TDD we want tests to run in the order that they are defined, and we want them to fail fast, that is to say, as soon as the test suite encounters a failure, we want the execution to stop. This ensures that the person implementing the solution sees only one error or failure message at a time, unless they make a change which causes prior tests to fail.

This is the same experience that they would get if they were implementing each new test themselves.

Most testing frameworks do not have the necessary configuration options to get this behavior directly, but they often do have a way of marking tests as skipped or pending. The mechanism for this will vary from language to language and from test framework to test framework.

Whatever the mechanism—functions, methods, annotations, directives, commenting out tests, or some other approach—these are changes made directly to the test file. The person solving the exercise will need to edit the test file in order to "activate" each subsequent test.

Any tests that are marked as skipped will not be verified by the track test suite unless special care is taken.

Additionally, in some programming languages, the name of the file containing the solution is hard-coded in the test suite, and the example solution is not named in the way that we expect people to name their files.

We will need to temporarily (and programmatically) edit the exercise test suites to ensure that all of their tests are active. We may also need to rename the example solution file(s) in order for the exercise test suite to run against it.

Avoiding accidental git check-ins

It's important that if we rewrite files in any way during a test run, that these changes do not accidentally get checked in to the git repository.

Therefore, many language tracks write the track test suite in such a way that it copies the exercise to a temporary location outside of the git repository before editing or rewriting the exercise files during a test run.

Working around long-running track test suites

Usually as people are developing the track, they're focused on a single exercise. If running the entire track test suite against all of the exercises takes a long time, it is often worth making it possible to verify just one exercise at a time.

Example build file

The PHP track has created a Makefile. The Ruby track uses Rake, which is a tool written in Ruby, allowing the track maintainers to write custom code in the language of the track to customize the build with a Rakefile.

[v3] Update status of Concept Exercises

This issue is part of the migration to v3. You can read full details about the various changes here.

Concept Exercises can have a status specified in their "status" field in their config.json entry, as specified in the spec. This status can be one of four values:

• "wip": A work-in-progress exercise not ready for public consumption. Exercises with this tag will not be shown to students on the UI or be used for unlocking logic. They may appear for maintainers.
• "beta": This signifies active exercises that are new and which we would like feedback on. We show a beta label on the site for these exercise, with a Call To Action of "Please give us feedback."
• "active": The normal state of active exercises
• "deprecated": Exercises that are no longer shown to students who have not started them (not usable at this stage).

The "status" key can also be omitted, which is the equivalent of setting it to "active".

Goal

The "status" field of Concept Exercises in the config.json file should be updated to reflect the status of the Concept Exercises. See the spec for more information.

If your track doesn't have any Concept Exercises, this issue can be closed.

Example: removed wip status

{
  "exercises": {
    "concept": [
      {
        "uuid": "93fbc7cf-3a7e-4450-ad22-e30129c36bb9",
        "slug": "cars-assemble",
        "name": "Cars, Assemble!",
        "concepts": ["if-statements", "numbers"],
        "prerequisites": ["basics"]
      },
      ...
    ]
  }
}

Example: replaced wip status with active

{
  "exercises": {
    "concept": [
      {
        "uuid": "93fbc7cf-3a7e-4450-ad22-e30129c36bb9",
        "slug": "cars-assemble",
        "name": "Cars, Assemble!",
        "concepts": ["if-statements", "numbers"],
        "prerequisites": ["basics"],
        "status": "active"
      },
      ...
    ]
  }
}

Tracking

exercism/v3-launch#14

Pull request merge policy

Hi again Glenn.

I want to know how you feel about having a policy on merging PRs:

The GitHub's UI for PRs gives three options (merge, rebase, squash merge).

When there's only one commit, rebase and squash merge are equivalent (modulo some minor differences in the way it formats the message). In this case I'd like to avoid the extra merge commit because it clutters the commit history.

When there's more than one commit, I think all but rebase can be appropriate, depending on the situation:

1. merge: if the commits are structured "perfectly" (either on the first attempt, or by local rebasing and force-pushing), I think a merge commit provides clarity when the one change a PR submits can be divided into several steps.
2. squash merge: if the commits aren't structured so well (experimental progression, or lots of feedback that changes the PR halfway through; e.g. #14), and restructuring the commits differently seems like a hassle, I think a squash merge provides convenience.
3. rebase: because PRs should only do one thing, if that one thing is split into multiple commits, the lack of that merge commit may be confusing.

Having preference in the GitHub workflows is something I've gained very recently from participating on the Haskell and OCaml tracks. But they are just that: preferences. So let me know if you think some of the reasoning is wonky of if you have other preferences.

Pass linting checks

This issue is part of the migration to v3. You can read full details about the various changes here.

The configlet tool has a lint command that checks if a track's configuration files are properly structured - both syntactically and semantically. Misconfigured tracks may not sync correctly, may look wrong on the website, or may present a suboptimal user experience, so configlet's guards play an important part in maintaining the integrity of Exercism.

We're updating configlet to work with v3 tracks, which have a different set of requirements than v2 tracks.

The full list of rules that will be checked by the linter can be found in this spec.

⚠ Note that only a subset of the linting rules has been implemented at this moment. This means that while your track may be passing the checks at this moment, it might fail later. We thus strongly suggest you keep this issue open until we let you know otherwise.

Goal

Ensure that the track passes all the (v3 track) checks defined in configlet lint.

To help verify that the track passes all the linting rules, the v3 preparation PR has added a GitHub Actions workflow that automatically runs configlet lint.

It is also possible to run configlet lint locally by running the ./bin/fetch-configlet (or ./bin/fetch-configlet.ps1) script to download a local copy of the configlet binary. Once downloaded, you can then do ./bin/configlet lint to run the linting on your own machine.

Tracking

exercism/v3-launch#3

Launch tracking

Edit this issue to keep track of the tasks you're working on towards launch.

We have a rough guide for how to launch a track, which is a good starting point;
please ask if you have any questions or if anything is confusing!
https://github.com/exercism/docs/blob/master/language-tracks/launch/README.md

This you might consider for the exercises (test suites and code examples) in this
track. Open separate issues for the ones you wish to implement.

• Is there a style guide for Tcl?
• Are these styles encouraged or enforced?
• Are there any conventions that we should adopt on this track for the sake of consistency?
• Can we enforce these?
• Is there a linter? Are there many? Should we use one?
• Is there a common convention for filenames? If not, what should our convention be?

Once you've gotten the track into a state where others can contribute, update the
README to reflect the choices you've made and provide guidelines for contribution.

test failure: bank-account

bank-account.test: Total 15 Passed 14 Skipped 0 Failed 1

Roll out alpha

@iHiD suggested that we enable the Tcl track without linking to it on the front page.

Now that most of the core exercises are done, we could do that and get some initial feedback.

Are you up for this, @glennj?

Decide format and placement of versioning information

For #5 and #9 I've gone with set version 1.2.0.0 so that it can be extracted with:

tclsh <<< 'source test.tcl; puts $version'

and so that it is distributed with the handout files.

@glennj: In #9 you requested that .meta/version be used (instead / in addition?). Do you have an example of a track that uses .meta/version, and does this track have a mechanism for distributing it to the student? Or are you thinking ahead wrt. exercism/discussions#239?

As I understand, exercism/discussions#239 has not reached any consensus for a standard on the placement of such a version number; if this were .meta/version, @NobbZ who suggested it also said he'd have them in the Erlang dependency file.