From issue exercism/exercism#1867

Wikipedia says the Hamming distance is not defined for strings of different length.

I am not saying the problems cannot be different, but for such a well-defined concept it would make sense to stick to one definition, especially when the READMEs provide so little information about what is expected from the implementation.

Let's clean this up so that we're using the official definition.

Hi there

I am wondering about the choice to use scala 2.10.3 in all the projects. First of all, the latest bug fix release in scala 2.10 is 2.10.5. Apart from that, 2.11 has been out for over a year now and is already on version 2.11.6. Also scala 2.12 is only about half a year away.

Is there any particular reason for staying with 2.10?

P.S. Exercism is addictive 😄

We need a short, friendly introduction to Scala for the website as specified here. This is especially important given overall misconceptions about Scala as a difficult language for beginners.

The answer to the question "What types of problems does it solve really well?" should reference strong support for concurrency and parallelism.

An ABOUT.md file should be made and put into docs/.

This is a good candidate for 24pullrequests.

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

A duration of a gigasecond should be measured in seconds, not
days.

The gigasecond problem has been implemented in a number of languages,
and this issue has been generated for each of these language tracks.
This may already be fixed in this track, if so, please make a note of it
and close the issue.

There has been some discussion about whether or not gigaseconds should
take daylight savings time into account, and the conclusion was "no", since
not all locations observe daylight savings time.

The metadata for this problem has been simplified, and it might be worth changing the test suite and example so that theres no mention of RNA or uracil.

I've also changed the API of the problem in Ruby so that there is no error checking in the object itself, only in the factory that creates it: https://github.com/exercism/xruby/blob/master/nucleotide-count/example.rb#L2-L8

I don't know if this is relevant or idiomatic in Scala.

Test case "there is no zeroth prime" is missing in our test suite.
And then it makes sense to change Prime.nth to return an Option[Int] instead of just Int.

While being at it: Perhaps also change all other test descriptions to be the same as in canonical-data.json?

On a side note: There are more exercises out of sync with x-common. How can we handle this? There is an issue on the Haskell track for this.

In other tracks, there is a file that people can use to write their code (whether bob.el or bob.rb or bob.ex). In the Scala track, currently, that file does not exist, so we have to guess what the file name is supposed to be.

This issue tracks the exercises that still need to be updated. No checkmark means the exercise still needs to be updated.

• Hello World
• Bob
• Hamming
• Word Count
• Pangram
• Anagram
• Nucleotide Count
• Phone Number
• Grade School
• Robot Name
• Leap
• Etl
• Meetup
• Space Age
• Grains
• Gigasecond
• Scrabble Score
• Difference Of Squares
• Accumulate
• Sublist
• Rna Transcription
• Triangle
• Binary
• Roman Numerals
• Prime Factors
• Raindrops
• Allergies
• Atbash Cipher
• Bank Account
• Crypto Square
• Kindergarten Garden
• Robot Simulator
• Queen Attack
• Binary Search Tree
• Hexadecimal
• Largest Series Product
• Luhn
• Clock
• Matrix
• House
• Minesweeper
• Ocr Numbers
• Octal
• Trinary
• Wordy
• Food Chain
• Linked List
• Custom Set
• Nth Prime
• Palindrome Products
• Pascals Triangle
• Pig Latin
• Pythagorean Triplet
• Saddle Points
• Say
• Secret Handshake
• Series
• Sieve
• Simple Cipher
• Connect
• Parallel Letter Frequency
• Acronym
• Forth

Most exercises have their own favorable solutions and characteristic pitfalls.
To give people some guidance and avoid writing repetitive or similar code comments again and again
we should add a HINTS.md file to any exercise where it makes sense.

Especially the first couple of exercises should have such a file to assist beginners.
Another case is exercises dealing with special features of the language like Option or Either.

Here is a first short list of exercises that should contain hints. Please add more if you feel the need.
And add the checkmark to the respective exercise if you have added the hints.

• hello-world
• hamming
• nucleotide-count
• roman-numerals
• bank-account
• phone-number
• robot-name
• leap
• gigasecond
• wordy
• parallel-letter-frequency
• sgf-parsing
• zipper
• forth
• lens-person

There is an interesting edge case in the meetup problem:
some months have five Mondays.

March of 2015 has five Mondays (the fifth being March 30th), whereas
February of 2015 does not, and so should produce an error.

Thanks, @JKesMc9tqIQe9M for pointing out the edge case.
See exercism.io#2142.

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.

Change exercise does not have a main/scala directory

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.

Some exercises require a class even though they don't have any internal state.
So they should be changed into an object.

• allergies
• atbash-cipher
• crypto-square
• queen-attack
• raindrops

Hello,

in the exercise "Connect", the 4th test case is:

test("convoluted path") {
    val lines = List(". X X . ."
                    ," X . X . X"
                    ,"  . X . X ."
                    ,"   . X X . ."
                    ,"    O O O O O")
    Connect(mkBoard(lines)).result should be (Some(Color.Black))
  }

There are 9 X's but only 5 O's. Then the X player (Black) must have cheated! A cheater should not win.

The 5th test case is:

test("rectangle - black wins") {
    val lines = List(". O . ."
                    ," O X X X"
                    ,"  O X O ."
                    ,"   X X O X"
                    ,"    . O X .")
    Connect(mkBoard(lines)).result should be (Some(Color.Black))
  }

There are 8 X's but only 6 O's. The player X must have cheated. In addition, there are 5 rows but only 4 columns. The numbers of the rows and the columns should be the same to be fair for the two players. The 6th test case has the same problem with 5 rows but 4 columns:

 test("rectangle - white wins") {
    val lines = List(". O . ."
                    ," O X X X"
                    ,"  O O O ."
                    ,"   X X O X"
                    ,"    . O X .")
    Connect(mkBoard(lines)).result should be (Some(Color.White))
  }

By the way, with the current unreasonable test cases, I have still written my code by the rules to pass all of the tests. But these are unfair games.

I really appreciate all of your kind efforts to establish and maintain this wonderful website. I have learned a lot by doing the exercises and from other programmers' comments.

This is a very Java-ish test suite and the implementation follows. There are probably better ways to implement this in Scala... Should the test suite be updated?

@sgrif I'm in the process of extracting all the exercises, putting each language in its own repository.

I'm creating a separate api (http://github.com/exercism/x-api) which includes all the language repositories as git submodules.

Do you have time to set up the Travis build for the scala repository?

Shall we upgrade to Scala 2.12, perhaps in Q1 2017 ?
This includes ScalaTest and other libraries like Monocle, of course.
A problem could be scala-parser-combinators?

Would be great if we find a way to simplify this for the future, ideally by just having to change only a single file?

I can't remember the history of this, but we ended up with a weird non-biological thing in the RNA transcription exercise, where some test suites also have tests for transcribing from RNA back to DNA. This makes no sense.

If this track does have tests for the reverse transcription, we should remove them, and also simplify the reference solution to match.

If this track doesn't have any tests for RNA->DNA transcription, then this issue can be closed.

See exercism/problem-specifications#148

The standard in exercism is to have each test suite have all but the first test marked "pending", allowing a clean output when running the tests in a TDD fashion.

A number of the tests in the Scala track do not have that keyword. This issue tracks the exercises that still need to be updated. No checkmark means the exercise still needs to be updated.

To fix an exercise:

1. Choose an exercise from the list. Let us say you want to fix "accumulate".
2. Go to the test file, which will be under the path exercises/accumulate/src/test/scala/accumulate_test.scala in this repository. The paths for all exercises follow a similar convention.
3. Edit the file, and add the keyword pending as the first line for all tests except the first one.
4. In your commit message, on the first line, write something like "Added pending keyword to accumulate test". In the next paragraph, write "Work on #133".
5. Open a pull request and tag me ( @Trevoke ) in it, so that I can update this list when the PR gets merged in

FAQ

Q: What happens if I go to the test file and there are already pending keywords?
A: Tell me in this issue so I can update the list!

Q: How do I edit the file and open a pull request?
A: You have two options. The simplest solution is to edit it straight in Github. This will do a number of things in the background, such as fork the repository for you and create a branch, and then allow you to open a pull request straight from there. The other option is more traditional: clone the repository locally, create a branch yourself, edit the file with your favorite editor, commit, push to your fork, then open a pull request from your fork.

TODO

Provide links to documentation on edit-and-PR through Github interface.

• Hello World
• Bob
• Hamming
• Word Count
• Pangram
• Anagram
• Nucleotide Count
• Phone Number
• Grade School
• Robot Name
• Leap
• Etl
• Meetup
• Space Age
• Grains
• Gigasecond
• Scrabble Score
• Difference Of Squares
• Accumulate
• Sublist
• Rna Transcription
• Triangle
• Binary
• Roman Numerals
• Prime Factors
• Raindrops
• Allergies
• Atbash Cipher
• Bank Account
• Crypto Square
• Kindergarten Garden
• Robot Simulator
• Queen Attack
• Binary Search Tree
• Hexadecimal
• Largest Series Product
• Luhn
• Clock
• Matrix
• House
• Minesweeper
• Ocr Numbers
• Octal
• Trinary
• Wordy
• Food Chain
• Linked List
• Custom Set
• Nth Prime
• Palindrome Products
• Pascals Triangle
• Pig Latin
• Pythagorean Triplet
• Saddle Points
• Say
• Secret Handshake
• Series
• Sieve
• Simple Cipher
• Connect
• Parallel Letter Frequency
• Acronym
• Forth

Update Pangram test case from cannonical data. The test suite is out of date.

• exercism/problem-specifications#741

There should be a 'main/scala' directory available for the end user.

I made a really stupid choice a while back to commit the cross-compiled
binaries for configlet (the tool that sanity-checks the config.json
against the implemented problems) into the repository itself.

Those binaries are HUGE, and every time they change the entire 4 or 5 megs get
recommitted. This means that cloning the repository takes a ridiculously long
time.

I've added a script that can be run on travis to grab the latest release from
the configlet repository (bin/fetch-configlet), and travis is set up to run
this now instead of using the committed binary.

I would really like to thoroughly delete the binaries from the entire git
history, but this will break all the existing clones and forks.

The commands I would run are:

# ensure this happens on an up-to-date master
git checkout master && git fetch origin && git reset --hard origin/master

# delete from history
git filter-branch --index-filter 'git rm -r --cached --ignore-unmatch bin/configlet-*' --prune-empty

# clean up
rm -rf .git/refs/original/
git reflog expire --all
git gc --aggressive --prune

# push up the new master, force override existing master branch
git push -fu origin master

If we do this everyone who has a fork will need to make sure that their master
is reset to the new upstream master:

git checkout master
git fetch upstream master
git reset --hard upstream/master
git push -fu origin master

We can at-mention (@) all the contributors and everyone who has a fork here in this
issue if we decide to do it.

The important question though, is: Is it worth doing?

Do you have any other suggestions of how to make sure this doesn't confuse people and break their
repository if we do proceed with this change?

Based on a chat here: http://exercism.io/submissions/879f8e697d3f401bbc5a263966d8d2b1

Why do we need to instantiate something at all, here?

The resource simplyscala.com listed in docs/RESOURCES.md doesn't exist anymore. Based on this reddit thread it might already been gone for at least ~6 months.

I just had this little discussion.
@enricospataro may have a point here?! Shall we change the test suite?

The Java track has switched from the clunky java.util.GregorianCalendar to java.time.LocalDateTime.
I think we should do the same?

Another question might be whether we should not change Gigasecond to an object as it is not really stateful?

@pminten brought up a very good point about the API of meetup being
pretty terrible (See exercism/exercism#950).

If the meetup problem has not already been fixed in this track, we should
improve the test suite and example code to give the API a better design.

We should move away from java.util.GregorianCalendar and expect a java.time.LocalDate as the return value (cf. #259).

See the respective TestSuite in the Java track.

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

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

The new test suite reorders tests so that students can get to green quickly. It also reduces the number of tests so that students can focus on solving the interesting edge cases.

More details on this change are available in the pull request

Please check if there's a test that states that a triangle with sides 2, 4, 2 is invalid. The triangle inequality states that for any triangle, the sum of the lengths of any two sides must be greater than or equal to the length of the remaining side. If this doesn't affect this track, go ahead and just close the issue.

We should move the deprecated exercises out of the exercises dir and into some other sub dir of xscala. Maybe just name the dir deprecated.

This way we can keep the deprecated exercises around, without having them polluting the live exercises dir.

There was some confusion in this exercise due to the ambiguous use of the term consecutive in the README. This could be taken to mean contiguous, as in consecutive by position, or as in consecutive numerically. The the README has been fixed (exercism/problem-specifications#200).

Please verify that the exercise is implemented in this track correctly (that it finds series of contiguous numbers, not series of numbers that follow each other consecutively).

If it helps, the canonical inputs/outputs for the exercise can be found here:
https://github.com/exercism/x-common/blob/master/largest-series-product.json

If everything is fine, go ahead and just close this issue. If there's something to be done, then please describe the steps needed in order to close the issue.

The help pages got moved as a result the link (http://help.exercism.io/getting-started-with-scala.html) in the SETUP.md (which is included in the generated README for every exercise) is broken. I guess the new link is: http://exercism.io/languages/scala

In order to reduce the amount of code required to pass incremental tests (assuming that users pass tests starting from the top), the order of the tests was modified slightly.

Since this track implements Custom Set, please take a look at the new custom-set.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 exercism/problem-specifications#257.

This may or may not be appropriate in this language. See exercism/docs#54 for details.

We should have separate tests for:

• alphabetic characters at the beginning of a valid binary number
• alphabetic characters at the end of a valid binary number
• alphabetic characters in the middle of an otherwise valid binary number
• invalid digits (e.g. 2)

If the test suite for binary has test cases that cover these edge cases, this issue can safely be closed.

See exercism/problem-specifications#95

For example, in robot-name, the filename for the spec is robot_name_test.scala.

Underscores are unusual in Scala filenames. I'd expect something like RobotNameSpec.scala.

The word multibillionaire is too long for the scrabble board. Oxyphenbutazone, on the other hand, is legal.

Please verify that there is no test for multibillionaire in the scrabble-score in this track. If the word is included in the test data, then it should be replaced with oxyphenbutazone. Remember to check the case (if the original is uppercase, then the replacement also should be).

If multibillionaire isn't used, then this issue can safely be closed.

See exercism/problem-specifications#86

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.

The readme says the code should raise an error if the triangle cannot exist, but the tests just have an Illogical type. One of the two is wrong, but I don't know which one.

Other exercises have a main/scala directory where the code can go.

The JSON file containing canonical inputs/outputs for the Clock exercise has gotten new data.

There are two situations that the original data didn't account for:

• Sometimes people perform computation/mutation in the display method instead of in add. This means that you might have two copies of clock that are identical, and if you add 1440 minutes to one and 2880 minutes to the other, they display the same value but are not equal.
• Sometimes people only account for one adjustment in either direction, meaning that if you add 1,000,000 minutes, then the clock would not end up with a valid display time.

If this track has a generator for the Clock exercise, go ahead and regenerate it now. If it doesn't, then please verify the implementation of the test suite against the new data. If any cases are missing, they should be added.

See exercism/problem-specifications#166

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!

Seems like exercise dominoes is still not available online?
Any reasons why not?

@Trevoke reported:

Just pulled the pangram exercise for Scala and no tests are pending.

There are continuous changes of existing tests in x-common.
Is there a good way to keep track and update the Scala tests?

Just to list some recent changes:

• scrabble-score
• nucleotide-count
• phone-number
• prime-factors
• etl
• secret-handshake

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.

See issue exercism/exercism#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.