exercism/kotlin

Exercism exercises in Kotlin.

kotlin's Issues

two-fer: update version file (v1.1.0 -> v1.2.0)

Please update the version specified in the two-fer version file from 1.1.0 to 1.2.0.

The version update has no change to tests, and is simply applying the new input policy. No tests should change as a result of this.

New tests for the Pangram problem

We have found that the Pangram tests miss edge cases allowing students to pass all of the current tests with an incorrect implementation.

To cover these cases we have added new tests to the Pangram test set. Those new tests were added in this commit

Since this track implements Pangram, please take a look at the new pangram.json file and see if your track should update its tests.

If you do need to update your tests, please refer to this issue in your PR. That helps us see which tracks still need to update their tests.

If your track is already up to date, go ahead and close this issue.

More details on this change are available in x-common issue 222.

Thank you for your help!

Verify contents and format of track documentation

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.

rna-transcription: update version file (v1.0.1 -> v1.2.0)

Please update the version specified in the rna-transcription version file from 1.0.1 to 1.2.0.

This update has been caused by the removal of some comments in the canonical-data, and also the application of a new input policy.

No tests should be changed as a result.

largest-series-product: update version file (v1.0.0 -> v1.1.0)

Please update the version specified in the sum-of-multiples version file from 1.0.0 to 1.1.0.

This update has been caused by the application of a new input policy.

No tests should be changed as a result.

Unable import project on IntelliJ

I'm having trouble to import an projetct to IntelliJ. I got that message:
Please, use JDK instead of JRE for Gradle importer.

IntelliJ version 2017.3.5

luhn: update tests and version file (v1.0.0 -> v1.2.0)

Please update the version specified in the luhn version file from 1.0.0 to 1.2.0.

This update has been caused by the application of a new input policy, and a new test being added.

Please additionally update the test suite to match the canonical-data. New test strings with non-digits is invalid should be added.

grains: update version file (v1.0.0 -> v1.1.0)

Please update the version specified in the grains version file from 1.0.0 to 1.1.0.

This update has been caused by the application of a new input policy.

No tests should be changed as a result.

Investigate track health and status of the track

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

Launch Checklist

Launch Checklist

In order to launch we should:

• Turn on Travis CI for the track
• Add Kotlin as a submodule in x-api
• Implement at least 10 problems
• Write documentation (see below)
• Find a person or (ideally) a handful of people willing to check exercism regularly (daily?) to review solutions
• Add track implementors and other designated code reviewers as mentors to the track. This gives you access to all the solutions in Kotlin whether or not you've submitted the problem to the site.
• Add a language icon or logo (see below)
• Toggle "active" to true in config.json
• Send an email to the mailing list

Documentation

The documentation lives in the docs/ directory here in this repository, and gets served to the site via the x-api. It should contain at minimim:

• INSTALLATION.md - about how to get the language set up locally.
• TESTS.md - about how to run the tests for the exercises.

Some nice to haves:

• ABOUT.md - a short, friendly blurb about the language. What types of problems does it solve really well? What is it typically used for?
• LEARNING.md - a few notes about where people might want to go to learn the language from scratch.
• RESOURCES.md - references and other useful resources.

Logo/Icon

We try to create a language icon that has the exercism colors, and is recognizably similar to the language icon. Sometimes this isn't possible due to copyright issues. See http://exercism.io/languages for all the existing icons.

The logo should live under /public/img/tracks/ in the exercism/exercism.io repository.
https://github.com/exercism/exercism.io/tree/master/public/img/tracks

Attribution goes in https://github.com/exercism/exercism.io/blob/master/ATTRIBUTION.md

If image assets are not your strong suit, just find a reasonable image to start from, along with the information about the licensing, and we'll figure out the colorization thing (I've written some scripts to help me do this part).

Some icons are the official language logo (tweaked). Where a language doesn't seem to have an official logo, or where the official logo has copyright issues, we just make something up.

Successful Launches

Some tracks have been more successful than others, and I believe the key features of the successful tracks are:

• Each submission receives feedback quickly, preferably within the first 24 hours.
• The code reviews do not direct users to do specific things, but rather ask questions challenging people to think about different aspects of their solution, or explore aspects of the language. Referencing existing blog posts and style guides seems to work well, when making specific recommendations.

For more about contributing to language tracks on exercism, check out the Problem API Contributing guide: https://github.com/exercism/x-api/blob/master/CONTRIBUTING.md

@Ignore all but the first test case?

When getting going with an exercise, it can be overwhelming to have a full suite failing all at once. JUnit provides the ability to skip tests through the @Ignore annotation. If all of the tests — save the first one — were skipped, it becomes far easier to see where to get started.

By way of example, here's hello-world, as is (removing the Gradle preamble)...

$ gradle test
...
:test

HelloWorldTest > helloSampleName FAILED
    org.junit.ComparisonFailure at HelloWorldTest.kt:25

HelloWorldTest > helloNullName FAILED
    org.junit.ComparisonFailure at HelloWorldTest.kt:20

HelloWorldTest > helloBlankName FAILED
    org.junit.ComparisonFailure at HelloWorldTest.kt:13

HelloWorldTest > helloNoName FAILED
    org.junit.ComparisonFailure at HelloWorldTest.kt:8

HelloWorldTest > helloAnotherSampleName FAILED
    org.junit.ComparisonFailure at HelloWorldTest.kt:30

5 tests completed, 5 failed
:test FAILED

And here's what it looks like with all but the first test skipped:

$ gradle test
...
:test

HelloWorldTest > helloNoName FAILED
    org.junit.ComparisonFailure at HelloWorldTest.kt:9

5 tests completed, 1 failed, 4 skipped
:test FAILED

scrabble-score: update version file (v1.0.0 -> v1.1.0)

Please update the version specified in the scrabble-score version file from 1.0.0 to 1.1.0.

This update has been caused by the application of a new input policy.

No tests should be changed as a result.

HandshakeCalculatorTest passes all tests in IDEA even when the implementation is just TODO()

Individual tests fail, but running the whole test class always passes.
I don't know enough about Gradle to help you by tracking down the cause, sorry.

Port (some) tests to spock

Do you think it would be beneficiary to the project to port the tests to Spock?
Maybe if not all (lots of them are pretty trivial and would not gain much from such a port - although the Groovy power-assert feature is pretty handy), just the ones that use parameterized tests? Those would definitely be a lot more clear using Spock.

I could easily perform the aforementioned port if you guys think it's worth it.

Thanks!

bob: Update to clarify ambiguity regarding shouted questions

TL;DR: the problem specification for the Bob exercise has been updated. Consider updating the test suite for Bob to match. If you decide not to update the exercise, consider overriding description.md.

---

Details

The problem description for the Bob exercise lists four conditions:

• asking a question
• shouting
• remaining silent
• anything else

There's an ambiguity, however, for shouted questions: should they receive the "asking" response or the "shouting" response?

In exercism/problem-specifications#1025 this ambiguity was resolved by adding an additional rule for shouted questions.

If this track uses exercise generators to update test suites based on the canonical-data.json file from problem-specifications, then now would be a good time to regenerate 'bob'. If not, then it will require a manual update to the test case with input "WHAT THE HELL WERE YOU THINKING?".

See the most recent canonical-data.json file for the exact changes.

Remember to regenerate the exercise README after updating the test suite:

configlet generate . --only=bob --spec-path=<path to your local copy of the problem-specifications repository>

You can download the most recent configlet at https://github.com/exercism/configlet/releases/latest if you don't have it.

If, as track maintainers, you decide that you don't want to change the exercise, then please consider copying problem-specifications/exercises/bob/description.md into this track, putting it in exercises/bob/.meta/description.md and updating the description to match the current implementation. This will let us run the configlet README generation without having to worry about the bob README drifting from the implementation.

pangram: update version file (v1.3.0 -> v1.4.0)

Please update the version specified in the pangram version file from 1.3.0 to 1.4.0.

This update has been caused by the application of a new input policy.

No tests should be changed as a result.

atbash-cipher: update version file (v1.0.0 -> v1.1.0)

Please update the version specified in the atbash-cipher version file from 1.0.0 to 1.1.0.

This update has been caused by the application of a new input policy.

No tests should be changed as a result.

Where are the Kotlin communities and enthusiasts?

As we move towards the launch of the new version of Exercism we are going to be ramping up on actively recruiting people to help provide feedback.

Our goal is to get to 100%: everyone who submits a solution and wants feedback should get feedback. Good feedback. You can read more about this aspect of the new site here: http://mentoring.exercism.io/

To do this, we're going to need a lot more information about where we can find language enthusiasts.

• Is Kotlin supported by one or more large organizations?
• Does Kotlin have an official community manager?
• Do you know of specific communities (online or offline) that are enthusiastic about Kotlin? (Chat communities, forums, meetups, student clubs, etc)
• Are there popular conferences for Kotlin? (If so, what are some examples?)
• Are there any organizations who are targeted specifically at getting certain subgroups or demographics interested in Kotlin? (e.g. kids, teenagers, career changers, people belonging to various groups that are typically underrepresented in tech?)
• Are there specific groups or programs dedicated to mentoring people in Kotlin?
• Are there popular newsletters for Kotlin?
• Is Kotlin taught at programming bootcamps? (If so, what are some examples?)
• Is Kotlin taught at universities? (If so, what are some examples?)

In other words: where do people care a lot and/or know a lot about Kotlin?

This is part of the project being tracked in exercism/meta#103

Update config.json to match new specification

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).

sieve: update version file (v1.0.0 -> v1.1.0)

Please update the version specified in the grains version file from 1.0.0 to 1.1.0.

This update has been caused by the application of a new input policy.

No tests should be changed as a result.

raindrops: update version file (v1.0.0 -> v1.1.0)

Please update the version specified in the raindrops version file from 1.0.0 to 1.1.0.

This update has been caused by the application of a new input policy.

No tests should be changed as a result.

Find additional peer reviewers

It would be great to get more people to get involved with peer reviewing code, by providing suggestions on how to use Kotlin specific features to provide a more readable, understandable solution.

Anyone who is interested, please leave a comment letting us know that you are interested in doing so.

Changes to Luhn tests

We recently rewrote the test suite for the Luhn exercise. Since this track implements Luhn, please take a look at the new canonical_data.json file and see if your track should update its implementation or tests.

Details on the test changes and the motivation can be found in the PR.

Tracking of these changes is being done at the tracking issue.

Update ABOUT page to reflect significant changes in Kotlin's status

• https://blog.jetbrains.com/kotlin/2017/05/kotlin-on-android-now-official/
• https://developer.android.com/kotlin/faq.html

Proposal: update track order and exercise difficulty estimates to match xjava

Thinking:

0. Kotlin is about to receive a lot more attention now that it's a first-class language on Android; any high-leverage changes that improve the Exercism Kotlin experience are especially important at this moment in time;
1. Recent Java track order changes to incorporate estimated exercise difficulty have resulted in notably lower drop-off during the early exercises; the current order in xkotlin does not account for exercise difficulty;
2. The difficult of exercises is likely to be very similar between the two languages;
3. It's easy to refine order later on (this is an ongoing process in xjava).

secret-handshake: update version file (v1.1.0 -> v1.2.0)

Please update the version specified in the secret-handshake version file from 1.1.0 to 1.2.0.

This update has been caused by the application of a new input policy.

No tests should be changed as a result.

saddle-points: update version file (v1.0.0 -> v1.1.0)

Please update the version specified in the saddle-points version file from 1.0.0 to 1.1.0.

This update has been caused by the application of a new input policy.

No tests should be changed as a result.

Document the need to remove the `@Ignore` from other tests in each exercise

In #30, each test after the first was @Ignored with the idea that the student would remove that annotation from the remaining tests. In #30 (comment), it was mentioned that a future PR was inbound to address documenting that. I began the Kotlin track yesterday (5/17/2018) and nowhere in the TUTORIAL.md or README.md for hello-world was there a mention of removing them. I didn't even notice skipped tests until the second lesson, and only because I'm a seasoned developer familiar with testing frameworks did I think to investigate the test file and remove them.

Move exercises to subdirectory

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.

space-age: update version file (v1.0.0 -> v1.1.0)

Please update the version specified in the space-age version file from 1.0.0 to 1.1.0.

This update has been caused by the application of a new input policy.

No tests should be changed as a result.

sum-of-multiples: update version file (v1.1.0 -> v1.2.0)

Please update the version specified in the sum-of-multiples version file from 1.1.0 to 1.2.0.

This update has been caused by the application of a new input policy.

No tests should be changed as a result.

Fix track configuration

v3.3.0 of configlet reports:

$ configlet lint .
-> An implementation for 'build' was found, but config.json does not reference this exercise.
-> An implementation for '.gradle' was found, but config.json does not reference this exercise.
-> An implementation for '.idea' was found, but config.json does not reference this exercise.
-> The implementation for '.gradle' is missing an example solution.
-> The implementation for 'build' is missing an example solution.
-> The implementation for '.idea' is missing an example solution.
-> The implementation for '.gradle' is missing a test suite.
-> The implementation for 'build' is missing a test suite.

We should investigate these warnings.

Copy track icon into language track repository

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.

how to run this exercism ?

Unnecessary semi-colons in Kotlin snippets

Feel free to close if you think it's unnecessary or it's on purpose, but I found two redundant commas in Kotlin snippets in the TUTORIAL.md file.

The location of the commas are here and here.

:)

collatz-conjecture: update version file (v1.1.1 -> v1.2.0)

Please update the version specified in the collatz-conjecture version file from 1.1.1 to 1.2.0.

This update has been caused by the application of a new input policy.

No tests should be changed as a result.

nth-prime: update version file (v2.0.0 -> v2.1.0)

Please update the version specified in the nth-prime version file from 2.0.0 to 2.1.0.

This update has been caused by the application of a new input policy.

No tests should be changed as a result.

Override probot/stale defaults, if necessary

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.

phone-number: should it throw an exception when given a bad number?

I think a bad number should not result in "0000000000" but throw an exception

hello-world: update version file (v1.0.0 -> v1.1.0)

Please update the version specified in the hello-world version file from 1.0.0 to 1.1.0.

The version update has no change to tests, and is simply applying the new input policy. No tests should change as a result of this.

triangle: update version file (v1.0.0 -> v1.1.0)

Please update the version specified in the triangle version file from 1.0.0 to 1.1.0.

This update has been caused by the application of a new input policy.

No tests should be changed as a result.

hamming: update version file (v2.0.1 -> v2.1.0)

Please update the version specified in the hamming version file from 2.0.1 to 2.1.0.

This update has been caused by the application of a new input policy.

No tests should be changed as a result.

What is the red highlighting indicating here?

Not sure if this is a syntax highlighting error or indicative of some (whitespace?) issue with my solution:

Thanks in advance for any clarification you are able to provide 😄

acronym: update tests and version file (v1.1.0 -> v1.3.0)

Please update the version specified in the acronym version file from 1.1.0 to 1.3.0.

This update has been caused by the application of a new input policy, renaming of a test case, and removal of a redundant test case.

Please additionally update the test suite to match the canonical-data. fromAllCapsWord() test should be removed.

Generate README for rotational-cipher

perfect-numbers: update version file (v1.0.1 -> v1.1.0)

Please update the version specified in the perfect-numbers version file from 1.0.1 to 1.1.0.

This update has been caused by the application of a new input policy.

No tests should be changed as a result.

New test for the Isogram problem

We have found that the Isogram tests miss an edge case allowing students to pass all of the current tests with an incorrect implementation.

To cover these cases we have added a new test to the Isogram test set. This new test was added in pull request #265, which also describes the reason for the new test.

Since this track implements Isogram, please take a look at the new isogram.json file and see if your track should update its tests.

If you do need to update your tests, please refer to this issue in your PR. That helps us see which tracks still need to update their tests.

If your track is already up to date, go ahead and close this issue.

More details on this change are available in x-common issue 272.

Thank you for your help!

gigasecond: update version file (v1.0.0 -> v1.1.0)

Please update the version specified in the gigasecond version file from 1.0.0 to 1.1.0.

This update has been caused by the application of a new input policy.

No tests should be changed as a result.

'Kotlin Slack channel: get invite here' link not working

Hi all,

I was just browsing the Kotlin track and while reading around about the language I noticed that if you try and get an invite to the Kotlin Slack channel, it takes you to an empty Heroku page.

difference-of-squares: update version file (v1.1.0 -> v1.2.0)

Please update the version specified in the difference-of-squares version file from 1.1.0 to 1.2.0.

This update has been caused by the application of a new input policy.

No tests should be changed as a result.