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.

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?

There is no gemfile, so following the contributing guide link in the README makes little sense.

Following the instructions result in this series of results:

$ bundle install
Could not locate Gemfile

And from there, continuing on, there is simply no feedback from the commands git submodule init nor from git submodule update

I don't think this is the result that was expected.

Of course all further information fails. No Rake file found, etc. I don't think this is the correct instruction set for the repository, or there is information missing.

This will ensure consistency across all the test suites and example solutions.

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 link list exercise requires a file linked_list.rb, but a class Deque.

custom-set and ocr-numbers both have tests that are being skipped in Travis

The robot-name/README.md specification states that robot name should conform to a format like

RX837 or BC811

That is, two letters and then three digits. Yet, the code that tests for this pattern is /\w{2}\d{3}/, which allows a string such as 0.2542346345724565 to pass the test.
I've checked how the tests for this exercise are implemented in a few other languages (perl5, haskell, lua) and they do enforce the two-letters-three-digits format, mostly by using [a-zA-Z] instead of \w.
I believe this is important because the tests should formalize the general idea provided by the README, where the specification is really not very specific, prompting learners to submit code that is unchallenging like my first submission to this exercise.

I'd like to open this as a discussion before I attempt to fix it, because I'm not sure how pedantic we need to be with this.

In the 'scale generator' exercise:

• There's no universal standard for accidentals in chromatic scales. A lot of sources print ascending scales with sharps and descending with flats; fewer stipulate that the accidentals should follow the direction of the starting note's major key signature. I feel this test should accept a number of variations.
• The F# Major scale should be %w(F# G# A# B C# D# E#), not %w(F# G# A# B C# D# F). Similarly, Gb major has a Cb and not a B. There are no tests for these, but the given example does not generate these correctly.
• The d harmonic minor scale is %w(D E F G A Bb C# D), not %w(D E F G A Bb Db D). This may seem like a minor quibble (har har), but the definition of a harmonic minor scale is that the seventh note is raised one half-step, resulting in a rare case of a key signature with both sharps and flats.

So: a big issue is that this exercise becomes quite a bit more complicated to implement for the huge lumbering historical morass of music theory rules instead of a 'good enough' approach — is this worth pursuing?

Reported in exercism/exercism#1441 by @patbl

I can't figure out why one of the tests in this exercise is failing (the other tests pass). I even tested it with the example solution:

# gigasecond.rb
class Gigasecond

  attr_reader :born_at
  def initialize(date_of_birth)
    @born_at = date_of_birth.to_time
  end

  def date
    (born_at + 1_000_000_000).to_date
  end

end

# gigasecond_test.rb
def test_2
  gs = Gigasecond.new(Date.new(1977, 6, 13))
  assert_equal Date.new(2009, 2, 19), gs.date
end

# output
  1) Failure:
GigasecondTest#test_2 [gigasecond_test.rb:15]:
--- expected
+++ actual
@@ -1 +1 @@
-#<Date: 2009-02-19 ((2454882j,0s,0n),+0s,2299161j)>
+#<Date: 2009-02-18 ((2454881j,0s,0n),+0s,2299161j)>

Verify that each test suite has an example file that passes it.

Depends on #1

Not sure if this is the right place to make this issue but I'm see a lot of automated nitpicks with:

Rubyists tend to prefer enumerable methods over for loops. This isn't
a rule, it's more of a strong cultural preference.

Which isn't a 100% true, there is a reason why most don't use for...in and it's because it does not create a closure. i.e.

x = 0
for x in (0..4)
end
x #=> 4

Which can cause some weird bugs.

exercism restore in the CLI doesn't update the following exercises correctly or at all:

-beer-song
-binary-search
-custom-set
-food-chain (outdated test file)
-house
-triangles (no test file?)

Removed require 'delegate' line

In clojure, haskell, et. al the expectation for "Madness, and then illumination." is "msemo aanin dnin ndla etlt shui", but in ruby it is 'msemo aanin dninn dlaet ltshu i'. This is due to the tests falsely expecting the result to not be a transposition of the input with spaces, but the flattened transposition separated into chunks the same size as the row length.

The tests for this exercise test a lot of the helper methods. I think given that it's this late in the path, it isn't needed. Also, it takes away a lot of freedom from the implementer. I think the tests should be guiding more by functionality needed than by methods defined.

Please see the following shell session:

$ ruby -rminitest -e "puts Minitest::VERSION"
5.5.1

$ ruby bob_test.rb
MiniTest::Unit::TestCase is now Minitest::Test. From bob_test.rb:4:in `<main>'
[...]

Perhaps RuboCop would be appropriate? See exercism/docs#54 for details.

The README.md states "Treat invalid input as binary 0" but then the test expects invalid input to raise an ArgumentError exception.

I can't figure out why my test is failing:

class Gigasecond

def initialize(start_date)
self.start_date = start_date
end

def date
start_date + 11574 # number of days in a gigasecond: 1000000000s / (24_60_60)
end

private
attr_accessor :start_date

end

ruby gigasecond_test.rb outputs:

1. Failure:
   GigasecondTest#test_1 [gigasecond_test.rb:10]:
   --- expected
   +++ actual
   @@ -1 +1 @@
   -# Date: 2043-01-01 ((2467251j,0s,0n),+0s,2299161j)
   +# Gigasecond:0xXXXXXX @start_date=#<Date: 2011-04-25 ((2455677j,0s,0n),+0s,2299161j)

2. Failure:
   GigasecondTest#test_2 [gigasecond_test.rb:16]:
   --- expected
   +++ actual
   @@ -1 +1 @@
   -# Date: 2009-02-19 ((2454882j,0s,0n),+0s,2299161j)
   +# Gigasecond:0xXXXXXX @start_date=#<Date: 1977-06-13 ((2443308j,0s,0n),+0s,2299161j)

3. Failure:
   GigasecondTest#test_3 [gigasecond_test.rb:22]:
   --- expected
   +++ actual
   @@ -1 +1 @@
   -# Date: 1991-03-27 ((2448343j,0s,0n),+0s,2299161j)
   +# Gigasecond:0xXXXXXX @start_date=#<Date: 1959-07-19 ((2436769j,0s,0n),+0s,2299161j)

4 runs, 3 assertions, 3 failures, 0 errors, 1 skips

I am using minitest-reporters gem to colour the test output, I think adding that would make it easier for many; any objections in submitting a pull request?

The only down side I see is that users needs to install the dependency; may have to update the instructions elsewhere.

It seems like it will be more useful in hello_world rather than hamming.
Here is the error message:

__END__

*****************************************************
You got an error, which is exactly as it should be.
This is the first step in the Test-Driven Development
(TDD) process.

The most important part of the error is

      cannot load such file

It's looking for a file named hamming.rb that doesn't
exist yet.

To fix the error, create an empty file named hamming.rb
in the same directory as the hamming_test.rb file.

Then run the test again.

For more guidance as you work on this exercise, see
GETTING_STARTED.md.
*****************************************************

I hope this is the right forum to submit bug reports on the sample dataset

First off, I am getting a warning:

Warning: you should require 'minitest/autorun' instead.
Warning: or add 'gem "minitest"' before 'require "minitest/autorun"'
From:
  /Users/wchen/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/minitest/autorun.rb:15:in `<top (required)>'
  hamming_test.rb:1:in `<main>'
MiniTest::Unit.autorun is now Minitest.autorun. From /Users/wchen/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/minitest/autorun.rb:19:in `<top (required)>'
MiniTest::Unit::TestCase is now Minitest::Test. From hamming_test.rb:4:in `<main>'

Warning message was suppressed by adding gem "minitest" to my hamming_test.rb

Second,
I believe this test has an incorrect assertion:

  def test_ignores_extra_length_on_other_strand_when_longer
    assert_equal 2, Hamming.compute('AGG', 'AAAACTGACCCACCCCAGG')
  end

Correct me if I'm wrong, but assertion should be equal to zero:

AAAACTGACCCACCCCAGG
                AGG

The new instances created by the grains exercise are all exactly alike.

Is it a better idea to make the methods class methods (instead of instance methods), and change the tests appropriately? This would keep the exercise consistent with the other exercises by testing class methods. Or am I missing the reason for having instances that are exactly the same?

If you agree with the logic of this, I can go ahead and change the exercise.

I could actually copy the answer, change the data, change some method names. I only needed to add some special logic for reverse. I would suggest removing one of them.

As a minor point, the test doesn't test the same thing as the readme describes, especially:

handshake = SecretHandshake.new "11001"

I would suggest removing it, though I do like that the source is Bert.

This will help track authors with preparing as expected to pass CI check.

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.

This will require a couple of small things:

• auto-rewriting the require statement to include example instead of the actual file name.
• getting rid of skips (either by deleting the skip lines, or requiring a file that redefines skip to be an empty method).

Fix the hierarchy for lib/disable_skip.rb

I guess I have to modify test_yourself from gigasecond_test.rb in order to pass, a comment would help to understand it

# modify the test to test your 1 Gs anniversaty
def test_yourself
  skip
  your_birthday = Date.new(year, month, day)
  gs = Gigasecond.from(your_birthday)
  assert_equal Date.new(2009, 1, 31), gs
end

Also, the hamming problem gets uploaded everytime I run 'exercism fetch'

The final spec test in Word Count looks for the use of apostrophes, which is a great idea that got me thinking.

The quiz could have one more test that included the use of apostrophes inside of contractions, but also had words in single quotes.

This would make for an interesting level of difficulty at the end of the quiz, requiring users to write something that checked how the punctuation was being used. If this seems like a good idea, I'm willing to write the pull request for it, but I didn't want to proceed unless it was something desired by others.

If creating a breaking test in a quiz that is in production isn't something that is acceptable, I understand.

In the Getting Started document it refers to hamming as an object and shows the answer to the first falling test by creating the instance method compute. In the Hamming_test.rb and example.rb both use compute as a class method which is contradicting the Getting Started document. As this is the first exercise I presume that the tests and example should be using instance methods like outlined in the Getting Started document.

None of the tests for the Circular Buffer exercise use write! with a nil argument or on a buffer that isn't full. I'm assuming that in both cases write! should perform identically to write, but many simple implementations of write! are likely to get these cases wrong.

I'd be happy to add test cases to address those issues myself!

Somewhere along the line we lost the square part of the crypto square problem, replacing the grouping with the standard groupings of 5.

The test suite should be updated to reflect the squarishness of this problem.

See exercism/problem-specifications#28

Starting with the HelloWorld exercise in PR #151 this is a little more detailed than the others will be, with an explanation regarding any Gem load error.

ruby gigasecond_test.rb outputs:

1. Failure:
   GigasecondTest#test_1 [gigasecond_test.rb:10]:
   --- expected
   +++ actual
   @@ -1 +1 @@
   -#<Date: 2043-01-01 ((2467251j,0s,0n),+0s,2299161j)>
   +#<Gigasecond:0xXXXXXX @start_date=#<Date: 2011-04-25 ((2455677j,0s,0n),+0s,2299161j)>>

2. Failure:
   GigasecondTest#test_2 [gigasecond_test.rb:16]:
   --- expected
   +++ actual
   @@ -1 +1 @@
   -#<Date: 2009-02-19 ((2454882j,0s,0n),+0s,2299161j)>
   +#<Gigasecond:0xXXXXXX @start_date=#<Date: 1977-06-13 ((2443308j,0s,0n),+0s,2299161j)>>

3. Failure:
   GigasecondTest#test_3 [gigasecond_test.rb:22]:
   --- expected
   +++ actual
   @@ -1 +1 @@
   -#<Date: 1991-03-27 ((2448343j,0s,0n),+0s,2299161j)>
   +#<Gigasecond:0xXXXXXX @start_date=#<Date: 1959-07-19 ((2436769j,0s,0n),+0s,2299161j)>>

4 runs, 3 assertions, 3 failures, 0 errors, 1 skips

I noticed that there is no transition when reading the problem README between the specific and the general.

Somewhere along the line we lost the square part of the crypto square problem, replacing the grouping with the standard groupings of 5.

The test suite should be updated to reflect the squarishness of this problem.

See exercism/problem-specifications#28

Do we want to encourage the usage of Ruby's standard Prime module for the nth-prime test?

I wanted to make a patch to prevent using the Prime module, as I would consider that to be slightly cheating and defeating the purpose of the exercise, but the example.rb seems to use it as well ...

I noticed while working on this solution that the case where a binary string is only numbers, i.e. 123 isn't covered. I noticed this while trying to determine if a string was valid I could pass the tests by doing something along the lines of:

   def to_decimal
    return 0 if n.to_i == 0
    n.reverse.each_char.with_index.map { |char, index| char.to_i * 2**index }.reduce(:+)
  end

the test for string carrot123 returns 0, which is fine, but if i put 123 as a string my method would return a value,11 in this case.

See the updated problem description

hamming_test.rb error output still refers to bob.rb and bob_test.rb

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.

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

This presumably happens on the Travis server as well, but may be automatically cleaned due to a reboot (just like on any Unix machine, if it honors traditional behavior).

However, like many traditional *nix machines, my machine can store many of these files, as the likelihood of a reboot happening for many days, perhaps many months, is slim. We should be good citizens and remove the temporary files we create, as they are meant to be temporary.

Is it possible to make the *_test.rb files executable by default and to add a hashbang in the form of #!/usr/bin/env ruby?

That way I can just type ./<Tab>, which makes running tests ever so slightly easier ;-)

I'm making this an issue because I'm not sure if this was intentional or not, but the wordy_test.rb has the test:

def test_add_then_multiply
  question = 'What is -3 plus 7 multiplied by -2?'
  assert_equal(-8, WordProblem.new(question).answer)
end

my complaint is the following:

-3 + 7 * -2 = -17

(-3 + 7) * -2 = -8

if this was intentionally built this way, can something be put as a comment to the test, or in the readme?

otherwise change to -17?

It looks as though there's a bug preventing me from submitting revisions to the grains exercise (but not others). When I try to submit my solution, I get this error:

There was an issue with your submission: Status: 400, Error: {     This attempt is a duplicate of the previous one.}

When I change my solution and resubmit, I don't get any error message, but my solution doesn't appear on the website. And if I try to resubmit the new solution, I get the previous error message.