trackler 2.2.1.99 → 2.2.1.100

data/tracks/python/exercises/say/say_test.py

@@ -63,7 +63,7 @@ class SayTest(unittest.TestCase):
                                 "three hundred and twenty-one thousand "
                                 "one hundred and twenty-three"))
 
-    def test_number_to_large(self):
+    def test_number_too_large(self):
         with self.assertRaisesWithMessage(ValueError):
             say(1e12)
 

data/tracks/ruby/README.md

@@ -7,20 +7,20 @@ Exercism Exercises in Ruby
 
 ## Setup
 
-You'll need a recent (2.1+) version of Ruby, but that's it. Minitest ships with
-the language, so you're all set.
+You'll need a recent (2.1+) version of Ruby, but that's it. Minitest ships
+with the language, so you're all set.
 
 ## Anatomy of an Exercise
 
 The files for an exercise live in `exercises/<slug>`. The slug for an exercise
-is a unique nickname composed of a-z (lowercase) and -, e.g. `clock` or
+is a unique nickname composed of a-z (lowercase) and -, e.g.  `clock` or
 `atbash-cipher`. Inside its directory, each exercise has:
 
 * a test suite, `<exercise_name>_test.rb`
 * an example solution, `.meta/solutions/<exercise_name>.rb`
 
-where `<exercise_name>` is the underscored version of the exercise's slug, e.g.,
-`clock` or `atbash_cipher`.
+where `<exercise_name>` is the underscored version of the exercise's slug,
+e.g., `clock` or `atbash_cipher`.
 
 If the exercise has a test generator, the directory will also contain:
 
@@ -33,42 +33,42 @@ A few exercises use a custom test template:
 
 ### BookKeeping::VERSION
 
-For some, even perhaps many, of the exercises, you will find a reference
-to the `BookKeeping` module, but this is only included when tests have
-been generated; see [Generated Test Suites](#generated-test-suites).
-This `VERSION` number helps make sure exercise solvers and exercise
-reviewers know which revision of the test suite they are talking
-about, and it theoretically helps avoid reviewer feedback like 
-*"Your solution doesn't make the tests pass,"* if they are looking
-at a different version of the tests than the solver used.
+For some, even perhaps many, of the exercises, you will find a reference to
+the `BookKeeping` module, but this is only included when tests have been
+generated; see [Generated Test Suites](#generated-test-suites).  This
+`VERSION` number helps make sure exercise solvers and exercise reviewers know
+which revision of the test suite they are talking about, and it theoretically
+helps avoid reviewer feedback like *"Your solution doesn't make the tests
+pass,"* if they are looking at a different version of the tests than the
+solver used.
 
 ### Canonical Data
 
 **Most exercises can be generated from shared inputs/outputs, called canonical
-data (see [Generated Test Suites](#generated-test-suites) below).** To find out
-whether a test has canonical data, check
-the [problem-specifications repo](https://github.com/exercism/problem-specifications/tree/master/exercises).
+data (see [Generated Test Suites](#generated-test-suites) below).** To find
+out whether a test has canonical data, check the
+[problem-specifications repo](https://github.com/exercism/problem-specifications/tree/master/exercises).
 
 ## Running the Tests
 
-Run the tests using `rake`, rather than `ruby path/to/the_test.rb`. `rake` knows
-to look for the example solution and to disable skips. Just tell `rake` the name
-of your problem and you are set:
+Run the tests using `rake`, rather than `ruby path/to/the_test.rb`.  `rake`
+knows to look for the example solution and to disable skips. Just tell `rake`
+the name of your problem and you are set:
 
 ```sh
 rake test:clock
 ```
 
-To pass arguments to the test command, like `-p` for example, you can run
-the following:
+To pass arguments to the test command, like `-p` for example, you can run the
+following:
 
 ```sh
 rake test:clock -- -p
 ```
 
 To run a subset of the tests, use a regular expression. For example, if tests
-exist that are named identical_to_4_places, and identical, then we can run both
-tests with
+exist that are named identical_to_4_places, and identical, then we can run
+both tests with
 
 ```sh
 rake test:hamming -- -p -n="/identical/"
@@ -93,13 +93,16 @@ some do not. To find out whether an exercise has a generator, run
 In addition to a usage message, the `-h` flag lists all exercises with a
 generator. If a generator is available for your exercise, you can
 
-* [Regenerate the test suite](#regenerating-an-exercise) based on updated canonical data
+* [Regenerate the test suite](#regenerating-an-exercise) based on
+  updated canonical data
 * [Make changes to a generated exercise](#changing-a-generated-exercise)
 
-If not, you will need to [implement a new generator](#implementing-a-generator)
+If not, you will need to
+[implement a new generator](#implementing-a-generator).
 
-Generated exercises depend on the [the shared metadata][problem-specifications], which must be
-cloned to the same directory that contains your clone of the ruby repository:
+Generated exercises depend on the
+[the shared metadata][problem-specifications], which must be cloned to the
+same directory that contains your clone of the ruby repository:
 
 ```
 tree -L 1 ~/code/exercism
@@ -109,20 +112,21 @@ tree -L 1 ~/code/exercism
 
 #### Regenerating a Test Suite
 
-From time to time, the [canonical data](https://github.com/exercism/problem-specifications/tree/master/exercises)
-for an exercise's tests changes, and we need to keep the Ruby version's
-tests synced up.  Regenerating these tests is a quick and easy way to help
-maintain the track and get involved!
+From time to time, the
+[canonical data](https://github.com/exercism/problem-specifications/tree/master/exercises)
+for an exercise's tests changes, and we need to keep the Ruby version's tests
+synced up.  Regenerating these tests is a quick and easy way to help maintain
+the track and get involved!
 
-If it's your first time cloning/contributing to the repository, you'll
-need to install any dependencies via `bundle`:
+If it's your first time cloning/contributing to the repository, you'll need to
+install any dependencies via `bundle`:
 
 ```bash
 bundle install
 ```
 
-Be sure that you're working on the most up-to-date version of the repo.
-From the root of your copy of the repository:
+Be sure that you're working on the most up-to-date version of the repo.  From
+the root of your copy of the repository:
 
 ```bash
 # Add the exercism repo as upstream if you haven't yet:
@@ -136,14 +140,15 @@ git checkout master
 git merge upstream/master
 ```
 
-Depending on your git workflow preferences and the state of your local
-repo, you may want to do some rebasing.
+Depending on your git workflow preferences and the state of your local repo,
+you may want to do some rebasing.
 [See the rebasing documentation for more information.](https://help.github.com/articles/about-git-rebase/)
 
-The generator also depends on the presence of Exercism's `problem-specifications`
-repository (see the file tree in the section above).  Make sure you've got
-an *up-to-date* version of the specifications in a `problem-specifications`
-folder that's in a parallel directory to your local copy of the `ruby` repository.
+The generator also depends on the presence of Exercism's
+`problem-specifications` repository (see the file tree in the section above).
+Make sure you've got an *up-to-date* version of the specifications in a
+`problem-specifications` folder that's in a parallel directory to your local
+copy of the `ruby` repository.
 
 To check which problems have possibly been updated, run:
 
@@ -151,14 +156,14 @@ To check which problems have possibly been updated, run:
 bin/generate --all
 ```
 
-This will autogenerate all of the test cases for which generators exist.
-Use `git diff` (or your preferred method) to find out which test files
-have changed.  Some exercises will update because someone updated the
-description or other exercise metadata.  Others will change because the
-actual test suite has changed.  If you find that an exercise's test suite
-(i.e. the actual tests, not just the line at the test data version number
-at the top of the tests) has changed, be sure to use `generate` to update
-the [BookKeeping::VERSION](#bookkeeping-version) number by running:
+This will autogenerate all of the test cases for which generators exist.  Use
+`git diff` (or your preferred method) to find out which test files have
+changed.  Some exercises will update because someone updated the description
+or other exercise metadata.  Others will change because the actual test suite
+has changed.  If you find that an exercise's test suite (i.e. the actual
+tests, not just the line at the test data version number at the top of the
+tests) has changed, be sure to use `generate` to update the
+[BookKeeping::VERSION](#bookkeeping-version) number by running:
 
 ```bash
 bin/generate --update <exercise-slug>
@@ -166,23 +171,24 @@ bin/generate --update <exercise-slug>
 
 Once everything has been regenerated and updated, you're almost ready to
 submit your changes via pull request.  Please be sure to only update one
-exercise per pull request.  Also, please follow the guidelines in the
-[Pull Requests](#pull-requests) section, being sure to follow the pattern
-of `<slug>: Regenerate Tests`, where slug is the slug of the exercise that
-your pull request is regenerating.
+exercise per pull request.  Also, please follow the guidelines in the [Pull
+Requests](#pull-requests) section, being sure to follow the pattern of
+`<slug>: Regenerate Tests`, where slug is the slug of the exercise that your
+pull request is regenerating.
 
 #### Changing a Generated Exercise
 
-Do not edit `<slug>/<exercise_name>_test.rb`. Any changes you make will
-be overwritten when the test suite is regenerated.
+Do not edit `<slug>/<exercise_name>_test.rb`. Any changes you make will be
+overwritten when the test suite is regenerated.
 
 There are two reasons why a test suite might change:
 
-1. the tests need to change (an incorrect expectation, a missing edge case, etc)
+1. the tests need to change (an incorrect expectation, a missing edge case,
+   etc)
 1. there might be issues with the style or boilerplate
 
-In the first case, the changes need to be made to the `canonical-data.json` file for
-the exercise, which lives in the problem-specifications repository.
+In the first case, the changes need to be made to the `canonical-data.json`
+file for the exercise, which lives in the problem-specifications repository.
 
 ```
 ../problem-specifications/exercises/<slug>/
@@ -191,19 +197,19 @@ the exercise, which lives in the problem-specifications repository.
 └── metadata.yml
 ```
 
-This change will need to be submitted as a pull request to the problem-specifications
-repository. This pull request needs to be merged before you can regenerate the
-exercise.
+This change will need to be submitted as a pull request to the
+problem-specifications repository. This pull request needs to be merged before
+you can regenerate the exercise.
 
 Changes that don't have to do directly with the test inputs and outputs should
-be made to the exercise's test case generator, discussed
-in [implementing a new generator](#implementing-a-generator), next.  Then you
-can regenerate the exercise with `bin/generate <slug>`.
+be made to the exercise's test case generator, discussed in
+[implementing a new generator](#implementing-a-generator), next.  Then you can
+regenerate the exercise with `bin/generate <slug>`.
 
 #### Implementing a Generator
 
-An exercise's test case generator class produces the code that goes inside
-the minitest `test_<whatever>` methods. An exercise's generator lives in
+An exercise's test case generator class produces the code that goes inside the
+minitest `test_<whatever>` methods. An exercise's generator lives in
 `exercises/<slug>/.meta/generator/<exercise_name>_case.rb`.
 
 The test case generator is a derived class of `ExerciseCase` (in
@@ -224,27 +230,30 @@ class <ExerciseName>Case < Generator::ExerciseCase
 end
 ```
 
-where `<ExerciseName>` is the CamelCased version of the exercise's slug. This is
-important, since the generator script will infer the name of the class from
+where `<ExerciseName>` is the CamelCased version of the exercise's slug. This
+is important, since the generator script will infer the name of the class from
 `<slug>`.
 
 This class must provide the methods used by the test
 template. A
-[default template](https://github.com/exercism/ruby/blob/master/lib/generator/test_template.erb) that
-most exercises can (and do) use lives in `lib/generator/test_template.erb`. The
-base class provides methods for the default template for everything except
-`#workload`.
+[default template](https://github.com/exercism/ruby/blob/master/lib/generator/test_template.erb)
+that most exercises can (and do) use lives in
+`lib/generator/test_template.erb`. The base class provides methods for the
+default template for everything except `#workload`.
 
 `#workload` generates the code for the body of a test, including the assertion
 and any setup required. The base class provides a variety of
-[assertion](https://github.com/exercism/ruby/blob/master/lib/generator/exercise_case/assertion.rb) and
-[helper](https://github.com/exercism/ruby/blob/master/lib/generator/exercise_case.rb) methods.
-Beyond that, you can implement any helper methods that you need
-as private methods in your derived class. See below for more information
-about [the intention of #workload](#workload-philosophy)
+[assertion](https://github.com/exercism/ruby/blob/master/lib/generator/exercise_case/assertion.rb)
+and
+[helper](https://github.com/exercism/ruby/blob/master/lib/generator/exercise_case.rb)
+methods.
 
-You don't have to do anything other than implement `#workload` to use the default
-template.
+Beyond that, you can implement any helper methods that you need as private
+methods in your derived class. See below for more information about
+[the intention of #workload](#workload-philosophy)
+
+You don't have to do anything other than implement `#workload` to use the
+default template.
 
 If you really must add additional logic to the view template, you can use a
 custom template. Copy `lib/generator/test_template.erb` to
@@ -262,6 +271,7 @@ in a clear and consistent manner. Illustrate the purpose of the individual
 elements of the assertion by using meaningful variable names.
 
 Example output from the `workload` method:
+
 ```ruby
 detector = Anagram.new('allergy')
 anagrams = detector.match(["gallery", "ballerina", "regally", "clergy", "largely", "leading"])
@@ -269,7 +279,6 @@ expected = ["gallery", "largely", "regally"]
 assert_equal expected, anagrams.sort
 ```
 
-
 ## Pull Requests
 
 We welcome pull requests that provide fixes to existing test suites (missing
@@ -281,13 +290,13 @@ change.
 Please submit changes to a single problem per pull request unless you're
 submitting a general change across many of the problems (e.g. formatting).
 
-You can run (some) of the same checks that we run by running the
-following tool in your terminal:
+You can run (some) of the same checks that we run by running the following
+tool in your terminal:
 
     bin/local-status-check
 
-If you would like to have these run right before you push your commits,
-you can activate the hook by running this tool in your terminal:
+If you would like to have these run right before you push your commits, you
+can activate the hook by running this tool in your terminal:
 
     bin/setup-git-hoooks
 
@@ -295,28 +304,34 @@ Thank you so much for contributing! :sparkles:
 
 ### Style Guide
 
-We have created a minimal set of guidelines for the testing files, which
-you can take advantage of by installing the `rubocop` gem.  It will use
-the configuration file located in the root folder, `.rubocop.yml`.  When
-you edit your code, you can simply run `rubocop -D`.  It will ignore
-your example solution, but will gently suggest style for your test code.
+We have created a minimal set of guidelines for the testing files, which you
+can take advantage of by installing the `rubocop` gem.  It will use the
+configuration file located in the root folder, `.rubocop.yml`.  When you edit
+your code, you can simply run `rubocop -D`.  It will ignore your example
+solution, but will gently suggest style for your test code.
 
 The `-D` option that is suggested is provided to give you the ability to
-easily ignore the Cops that you think should be ignored.  This is easily
-done by doing `# rubocop:disable CopName`, where the `CopName` is replaced
+easily ignore the Cops that you think should be ignored.  This is easily done
+by doing `# rubocop:disable CopName`, where the `CopName` is replaced
 appropriately.
 
 For more complete information, see [Rubocop](http://batsov.com/rubocop/).
 
 While `lib/generator/exercise_case.rb` provides helper functions as discussed
-above, it remains the responsibility of an exercise's generator to interpret its
-canonical-data.json data in a stylistically correct manner, e.g. converting
-string indices to integer indices.
+above, it remains the responsibility of an exercise's generator to interpret
+its canonical-data.json data in a stylistically correct manner, e.g.
+converting string indices to integer indices.
 
 ## READMEs
 
+<<<<<<< HEAD
 All exercises must have a README.md file, but should not be created manually. The READMEs
 are constructed using shared metadata, which lives in the [problem-specifications][] repo.
+=======
+Do not add a README or README.md file to the exercise's directory. The READMEs
+are constructed using shared metadata, which lives in the
+[problem-specifications][] repo.
+>>>>>>> Whitespace and wrapping, not integral to this PR
 
 Use the `configlet` tool to generate a README from shared metadata:
 
@@ -326,15 +341,24 @@ Use the `configlet` tool to generate a README from shared metadata:
 
 ## Contributing Guide
 
-For an in-depth discussion of how exercism language tracks and exercises work, please see the
+If adding a new exercise:
+
+* a [generator](#implementing-a-generator) should be implemented.
+* a minimal, partial, solution should be able to be pushed, in order to create a
+  WIP pull request.
+
+For an in-depth discussion of how exercism language tracks and exercises work,
+please see the
 [contributing guide](https://github.com/exercism/x-api/blob/master/CONTRIBUTING.md#the-exercise-data).
 
 If you're just getting started and looking for a helpful way to get involved,
-take a look at  [regenerating the test suites](#regenerating-a-test-suite),
+take a look at
+[regenerating the test suites](#regenerating-a-test-suite),
 [porting an exercise from another language](https://github.com/exercism/docs/blob/master/you-can-help/implement-an-exercise-from-specification.md),
 or [creating an automated test generator](#implementing-a-generator).
 
 ## Ruby icon
-The Ruby icon is the Vienna.rb logo, and is used with permission. Thanks Floor Dress :)
+The Ruby icon is the Vienna.rb logo, and is used with permission. Thanks Floor
+Dress :)
 
 [problem-specifications]: https://github.com/exercism/problem-specifications

data/tracks/ruby/config/exercise_readme.go.tmpl

@@ -4,10 +4,29 @@
 {{- with .Hints }}
 {{ . }}
 {{ end }}
-{{- with .TrackInsert }}
-{{ . }}
-{{ end }}
-{{- with .Spec.Credits -}}
+* * * *
+
+For installation and learning resources, refer to the
+[exercism help page](http://exercism.io/languages/ruby).
+
+For running the tests provided, you will need the Minitest gem. Open a
+terminal window and run the following command to install minitest:
+
+    gem install minitest
+
+If you would like color output, you can `require 'minitest/pride'` in
+the test file, or note the alternative instruction, below, for running
+the test file.
+
+Run the tests from the exercise directory using the following command:
+
+    ruby {{ .Spec.SnakeCaseName }}_test.rb
+
+To include color from the command line:
+
+    ruby -r minitest/pride {{ .Spec.SnakeCaseName }}_test.rb
+
+{{ with .Spec.Credits }}
 ## Source
 
 {{ . }}

data/tracks/ruby/exercises/accumulate/README.md

@@ -54,15 +54,13 @@ If you would like color output, you can `require 'minitest/pride'` in
 the test file, or note the alternative instruction, below, for running
 the test file.
 
-In order to run the test, you can run the test file from the exercise
-directory. For example, if the test suite is called
-`hello_world_test.rb`, you can run the following command:
+Run the tests from the exercise directory using the following command:
 
-    ruby hello_world_test.rb
+    ruby accumulate_test.rb
 
 To include color from the command line:
 
-    ruby -r minitest/pride hello_world_test.rb
+    ruby -r minitest/pride accumulate_test.rb
 
 
 ## Source