RubyGems - trackler - Versions diffs - 2.1.0.27 → 2.1.0.28 - Mend

trackler 2.1.0.27 → 2.1.0.28

Files changed (130) hide show

checksums.yaml CHANGED

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: e1cea3469c06413e200a4474c5867dc75dedf961
-  data.tar.gz: 66119d1d8e808237e971dcaeb737b52adcfc227a
+  metadata.gz: 22277589d4cc0a204319b33cc82d7a7c0dac30b4
+  data.tar.gz: 97204abac4f271dbe405bd4fd0f87dea116478b2
 SHA512:
-  metadata.gz: 6557449b11d4872505295d57268867e5f4cdcb2b6aa6e13be6ac28b3ad2bf97c20cc51bb39a076425ebc0f004ef70d4d26d57b9a738e389e9d070efe6547f1cc
-  data.tar.gz: 977e03371cbdeddb0307091430f425b039be3a52705353b27a0ad0bf272e13211d10fdd246ef576c7c56d5338551e2e3810c52608a29d2a829c78f29f2841df9
+  metadata.gz: 0b5e630d56cdd344ec4b8f6e8003979a0bc82271373f95fe670d75f2ce4349e167ff6be6239492808859d29e007a502e8c1ec510a3bdafac55c38be864f7e389
+  data.tar.gz: 8a1af1baa53f7457fcb6f2c1c87448d3573328554dcaf9ccbff79dad66632d1bffb5db3598e93369efe7668470462b2e84ce1127bd4f79ef49dec402680e603d

data/common/CONTRIBUTING.md CHANGED

@@ -27,11 +27,9 @@ themselves. There are other guides about contributing to other parts of the Exer
 * [Overview](#overview)
 * [Updating an Exercise Test Suite](#updating-an-exercise-test-suite)
     * [Updating a Generated Test Suite](#updating-a-generated-test-suite)
-* [Tweaking a README](#tweaking-a-readme)
 * [Porting an Exercise to Another Language Track](#porting-an-exercise-to-another-language-track)
     * [Providing Feedback on the Site for an Exercise You Implemented](#providing-feedback-on-the-site-for-an-exercise-you-implemented)
 * [Implementing a Completely New Exercise](#implementing-a-completely-new-exercise)
-* [Improving Consistency By Extracting Shared Test Data](#improving-consistency-by-extracting-shared-test-data)
 * [Track Anatomy](#track-anatomy)
 * [Starting a New Track](#starting-a-new-track)
     * [Beta-Testing a Language Track](#beta-testing-a-language-track)
@@ -43,12 +41,7 @@ themselves. There are other guides about contributing to other parts of the Exer
     * [Track configuration file (config.json)](#track-configuration-file)
     * [Track-Level Linting With Configlet](#track-level-linting-with-configlet)
     * [Git Basics](#git-basics)
-        * [Getting the Code](#getting-the-code)
-        * [Branches](#branches)
-        * [Commit Messages](#commit-messages)
-        * [Resetting `master`](#resetting-master)
-        * [Squashing](#squashing)
-        * [Resources](#resources)
+[Improving Consistency By Extracting Shared Test Data](#improving-consistency-by-extracting-shared-test-data)
 ## We Will Gladly Help You Help Us
@@ -226,69 +219,6 @@ Follow the guidelines for setting up a development environment, verifying the ch
 and submitting a pull request, as described in the [main section about updating an
 exercise test suite](#updating-an-exercise-test-suite).
-## Tweaking a README
-The Exercism exercise README treads a very fine line between useful ambiguity and confusing
-vagueness. Because the README is the same whether you're solving the problem in C++ or in Lua,
-the problem description needs to be high-level enough to allow for the syntactic, semantic, and
-philosophical differences in the various languages.
-In other words: no specific references to syntax or data structures of a specific language
-can be used to further clarify a problem.
-However, within this purposeful ambiguity might lie some opportunities for making an exercise
-description more clear. Typical issues to be attentive to:
-- poorly worded sentences
-- outdated information
-- incorrect directives
-- typos
-Each language's test suite provides the precise specification for the
-exercise, which allows the user to view the problem from a perspective that is
-interesting and idiomatic for that specific language.
-In addition, there's some language-specific content that gets woven into
-the README, usually a quick reminder about how to run the tests, and
-where to find more documentation.
-### Updating a Generic Problem Description
-[Fork this repository](https://github.com/exercism/x-common/fork).
-Each generic problem is identified by a slug. For example, the problem _Crypto
-Square_ is `crypto-square`. There are two metadata files for each problem:
-* `exercises/<slug>/description.md` which contains the generic problem description which makes up
-  the bulk of the README, and
-* `exercises/<slug>/metadata.yml` which contains a short one-line description of the problem as
-  well as other metadata, such as the source that inspired the problem in the
-  first place.
-There aren't any rules about what a good exercism problem README looks like.
-If in doubt, [open up a GitHub issue](https://github.com/exercism/x-common/issues/new)
-describing your suggestion.
-Once you've made your change [submit a pull
-request](#pull-request-guidelines).
-### Updating Language-Specific Additions
-Each language track may optionally contain a `SETUP.md` file in the root of
-the repository. This file should contain helpful, generic information about
-solving an exercism problem in the target language.
-The contents of the `SETUP.md` file gets included in the README.md that gets
-delivered along with the test suite and any supporting files when a user runs
-the `exercism fetch` command from their terminal.
-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.
-If a language track has specific expectations, these should also be documented
-here.
 ## Porting an Exercise to Another Language Track
 To get a list of all the exercises that can be ported to a track,
@@ -384,25 +314,6 @@ A problem must have a unique slug. This slug is used as
   Reference the PR in x-common if it hasn't been merged yet,
   this **must not** be merged until the exercism/x-common PR is merged.
-## Improving Consistency By Extracting Shared Test Data
-The goal is to have a file `exercises/<slug>/canonical-data.json` for each exercise in this repository. This JSON file should contain the generic (i.e. language independent) test data for that exercise. With this the quality of the tracks can be improved, e.g. fixes or new tests can be propagated to all the tracks. They can then be implemented manually or by running the test generator. (See [this issue](https://github.com/exercism/todo/issues/13) for more background info.)
-The following steps help you extracting the canonical test data.
-1. Select the exercise for which you want to create the shared test data from the [list of open todos](https://github.com/exercism/todo/issues?q=is%3Aissue+is%3Aopen+label%3Ashared-test-data)
-2. Now you need to find the existing tests. You can get a list with links to the all of those one of two ways
-  * Search for the exercise in this list http://x.exercism.io/v3/problems/data-todos (your browser might need a JSON viewer plugin/add-on to show this)
-  * Run this command in your terminal `curl http://x.exercism.io/v3/problems/data-todos | jq '.[] | map(select(.["slug"] == "accumulate"))'`. Replace `accumulate` with the name of the exercise you have chosen.
-3. Open the links in different browser tabs, navigate to the test files and read through the tests. Look for test cases that all/many of the languages have in common and identify outliers that only appear in one or two languages. It might be helpful to make some notes on your findings.
-4. Now it's time to write the canonical-data.json file. Look at examples like [the test data for hamming](https://github.com/exercism/x-common/blob/master/exercises/hamming/canonical-data.json) and check the [readme](https://github.com/exercism/x-common#test-data-format-canonical-datajson) to find out how to best structure the JSON file.
-From what you learned in step 3 decide for a sensible set of test cases. The following considerations might help with that.
-  * Try to stick to test cases that already occur in many languages so it is feasible for the track maintainers to adapt to the canonical set.
-  * All tests should be essential to the problem. Ensure people can get the first test passing easily. Then each following test should ideally add a little functionality. People should be able to solve the problem a little at a time. Avoid test cases that don't introduce any new aspect and would already pass anyway.
-  * The test cases should not require people to follow one very specific way to solve the problem, e.g. the tests should avoid checking for helper functions that might not be present in other implementations.
-  * Performance tests should not be included in the canonical test data.
-  If you are unsure about all these considerations just make a pull request with an initial proposal and ask the community for help.
 ## Track Anatomy
 Each track should have the following structure:
@@ -692,265 +603,7 @@ Optional keys:
 * `solution_pattern` - A (case sensitive) regex pattern that matches solution files in the track repository. Used by [configlet](https://github.com/exercism/configlet) to check for the presence of an example solution for each problem implemented by the track.  The default value used if this key is not present is `[Ee]xample`.
 ### Git Basics
-If you're concerned that you haven't done it right, don't worry. Submit your pull request, and we'll help you get the details sorted out.
-#### Getting the Code
-We recommend forking the project first, and then cloning the fork.
-```bash
-git clone git@github.com:<YOUR_USERNAME>/<REPO_NAME>.git
-```
-This will give you a remote repository named `origin` that points to your own copy of the project.
-In addition to this, we recommend that you add the original repository as a secondary remote.
-```bash
-git remote add upstream https://github.com/exercism/<REPO_NAME>.git
-```
-The names `origin` and `upstream` are pretty standard, so it's worth getting used to the names in your own work.
-#### Branches
-When working on your fork it tends to make things easier if you never touch the master branch.
-The basic workflow becomes:
-* check out the master branch
-* pull from `upstream` to make sure everything is up to date
-* push to `origin` so you have the latest code in your fork
-* check out a branch
-* make the changes, commit them
-* rebase onto the upstream master (and resolve any conflicts)
-* push your branch up to `origin`
-* submit a pull request
-If you're asked to tweak your work, you can keep pushing it to the branch, and it automatically updates the pull request with the new commits.
-#### Commit Messages
-Commit messages are communication and documentation. They're a log of more
-than just _what_ happened, they're about _why_ it was done.
-The longer a project is active, the more people involved, the larger the
-codebase, the more important it is to have good commit messages.
-There's an excellent lightning talk by Ryan Geary called [Do Your Commit
-Messages
-Suck?](https://www.youtube.com/watch?v=8YjSty6bfog).
-It's funny and enlightening, and you should watch it.
-Two articles that have very clear guidelines about how to write
-excellent commit messages are Tim Pope's
-[A Note About Git Commit Messages](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)
-and Chris Beams' [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/).
-Please read them.
-##### Examples
-Imagine that you're submitting a new problem called "spinning-wheel" to the Ruby track.
-Here's a fairly typical set of commits that you might end up making:
-```bash
-433a0e1 added spinning wheel tests
-1f7d4aa pass spinning wheel
-cf21737 oops
-be4c410 rename example file
-bb89a77 update config
-```
-All of these commits are about a single thing: adding a new problem. They
-should be a single commit. They don't have to start out that way (life is
-messy), but once you're done, you should squash everything into one commit,
-and rename it cohesively:
-```bash
-f4314e5 add spinning wheel problem
-```
-#### Resetting `master`
-If you've already made changes on your master so that it has diverged from the
-upstream you can reset it.
-First create a backup of your branch so that you can find any changes. Just in
-case.
-```bash
-git checkout master
-git checkout -b backup
-git checkout master
-```
-Next, fetch the most recent changes from the upstream repository and reset master to it.
-```bash
-git fetch upstream
-git reset --hard upstream/master
-```
-If you do a git log at this point you'll see that you have *exactly* the
-commits that are in the upstream repository. Your commits aren't gone, they're
-just not in master anymore.
-To put this on your GitHub fork, you'll probably need to use the `--force` flag:
-```bash
-git push --force origin master
-```
-#### Squashing
-Squashing commits into a single commit is particularly useful when the change
-happened in lots of little (sometimes confusing) steps, but it really is one
-change.
-There are a number of ways to accomplish this, and many people like to use an
-[interactive rebase](#interactive-rebase), but it can be tricky if you haven't set git up to open
-your favorite editor.
-An easier way to do this is to un-commit everything, putting it back into the
-staging area, and then committing it again.
-Using the example from above, we have 5 commits that should be squashed into one.
-```bash
-433a0e1 added spinning wheel tests
-1f7d4aa pass spinning wheel
-cf21737 oops
-be4c410 rename example file
-bb89a77 update config
-```
-To un-commit them, use the following incantation:
-```bash
-$ git reset --soft HEAD^^^^^
-```
-Notice that there are 5 carets, one for each commit that you want to
-un-commit. You could also say:
-```bash
-$ git reset --soft HEAD~5
-```
-If you do a `git status` now, you'll see all the changed files, and they're
-staged and ready to commit. If you do a `git log`, you'll see that the most
-recent commit is from someone else.
-Next, commit, as usual:
-```bash
-$ git commit -m "Add spinning wheel problem"
-```
-Now if you do a `git status` you may get a warning saying that your origin and
-your branch have diverged. This is completely normal, since the origin has 5
-commits and you have 1 (different) one.
-The next step is to force push this up to your branch, which will
-automatically update the pull request, replacing the old commits with the new
-one.
-```bash
-$ git push --force origin spinning-wheel
-```
-#### Resources
-If you're completely new to git, there are a number of resources that can help
-get you feeling more comfortable with it.
-* [Git Immersion](http://gitimmersion.com/)
-* [GitHug](https://github.com/Gazler/githug)
-* [Try GitHub](http://try.github.io)
-If you've been using git for a while, but it feels like repeating magical
-incantations (while praying that nothing goes wrong), then you may find these
-helpful:
-* [Git for Ages 4 and Up](https://www.youtube.com/watch?v=1ffBJ4sVUb4) - video of a presentation/demo
-* [Think Like a Git](http://think-like-a-git.net/)
-* [Explain Git with D3](http://www.wei-wang.com/ExplainGitWithD3) - interactive site
-* [Pro Git](http://git-scm.com/book/en/v2) - "The Book" for learning Git in detail
-* [Git Branching Tutorial](http://pcottle.github.io/learnGitBranching/) - interactive tutorial, very visual
-#### Rebasing
-You'll often be asked to rebase your branch before we merge a pull request as Exercism likes to keep a linear project commit history. This is accomplished with git rebase. It takes the current branch and places all the commits at the front of the branch that you're rebasing with.
-For example, rebasing the current branch on top of upstream/master:
-```
- git rebase upstream/master
-```
-Project commit history:
-```
-                       -- current branch --
-                      /
---- master branch ----
-```
-##### Interactive Rebase
-The rebase command has an option called `-i, --interactive` which will open an editor with a list of the commits which are about to be changed. This list accepts commands, allowing the user to edit the list before initiating the rebase action.
-Using the example from above, we have 5 commits that should be squashed into one.
-```bash
-433a0e1 added spinning wheel tests
-1f7d4aa pass spinning wheel
-cf21737 oops
-be4c410 rename example file
-bb89a77 update config
-```
-To interactively rebase, use the following incantation:
-```bash
-$ git rebase -i HEAD~5
-```
-This will bring up an editor with the following information:
-```bash
-pick 433a0e1 added spinning wheel tests
-pick 1f7d4aa pass spinning wheel
-pick cf21737 oops
-pick be4c410 rename example file
-pick bb89a77 update config
-#
-# Commands:
-#  p, pick = use commit
-#  r, reword = use commit, but edit the commit message
-#  e, edit = use commit, but stop for amending
-#  s, squash = use commit, but meld into previous commit
-#  f, fixup = like "squash", but discard this commit's log message
-#  x, exec = run command (the rest of the line) using shell
-#
-# These lines can be re-ordered; they are executed from top to bottom.
-#
-# If you remove a line here THAT COMMIT WILL BE LOST.
-#
-# However, if you remove everything, the rebase will be aborted.
-#
-# Note that empty commits are commented out
-```
-By choosing the `reword` command for the top commit and choosing the `fixup` command for the remaining commits, you will be able to squash the commits into one commit and provide a descriptive summary of the entire change
-```bash
-reword 433a0e1 added spinning wheel tests
-fixup 1f7d4aa pass spinning wheel
-fixup cf21737 oops
-fixup be4c410 rename example file
-fixup bb89a77 update config
-```
-[Further Reading](https://www.atlassian.com/git/tutorials/merging-vs-rebasing)
+See [Git Basics](https://github.com/exercism/docs/blob/master/contributing-to-language-tracks/git-basics.md) in [docs](https://github.com/exercism/docs) repository.
 ### et cetera
@@ -958,3 +611,10 @@ TODO: add more sections:
 - how to merge something locally (for example when there are conflicts, or
   if you want to fix a small thing without nagging the contributor about it)
+## Improving Consistency By Extracting Shared Test Data
+This documentation has moved [to the docs repository](https://github.com/exercism/docs/blob/master/contributing-to-language-tracks/improving-consistency-across-tracks.md).
+We are maintaining this section, since many open issues link to it.

data/common/exercises/forth/canonical-data.json CHANGED

@@ -1,6 +1,6 @@
 {
   "exercise": "forth",
-  "version": "1.0.0",
+  "version": "1.1.0",
   "comments": [
     "The cases are split into multiple sections, all with the same structure.",
     "In all cases, the `expected` key is the resulting stack",
@@ -21,12 +21,6 @@
           "property": "evaluate",
           "input": ["1 2 3 4 5"],
           "expected": [1, 2, 3, 4, 5]
-        },
-        {
-          "description": "all non-word characters are separators",
-          "property": "evaluate",
-          "input": ["1\u00002\u00133\n4\r5 6\t7"],
-          "expected": [1, 2, 3, 4, 5, 6, 7]
         }
       ]
     },

data/lib/trackler/version.rb CHANGED

@@ -1,3 +1,3 @@
 module Trackler
-  VERSION = "2.1.0.27"
+  VERSION = "2.1.0.28"
 end

data/tracks/bash/config.json CHANGED

@@ -39,6 +39,11 @@
       "slug": "bob" ,
       "difficulty": 1,
       "topics": []
+    },
+    {
+      "slug": "anagram" ,
+      "difficulty": 1,
+      "topics": []
     }
   ],
   "deprecated": [

data/tracks/bash/exercises/anagram/anagram_tests.sh ADDED

@@ -0,0 +1,99 @@
+#!/usr/bin/env bats
+@test "no matches", {
+    run bash anagram.sh "diaper" "hello world zombies pants"
+    [ "$status" -eq 0 ]
+    [ "$output" = "" ]
+}
+@test "detects simple anagram" {
+    run bash anagram.sh "ant" "tan stand at"
+    [ "$status" -eq 0 ]
+    [ "$output" = "tan" ]
+}
+@test "does not detect false positives" {
+    run bash anagram.sh "galea" "eagle"
+    [ "$status" -eq 0 ]
+    [ "$output" = "" ]
+}
+@test "detects two anagrams" {
+    run bash anagram.sh "master" "stream pigeon maters"
+    [ "$status" -eq 0 ]
+    [ "$output" = "stream maters" ]
+}
+@test "does not detect anagram subsets" {
+    run bash anagram.sh "good" "dog goody"
+    [ "$status" -eq 0 ]
+    [ "$output" = "" ]
+}
+@test "detects anagram" {
+    run bash anagram.sh "listen" "enlists google inlets banana"
+    [ "$status" -eq 0 ]
+    [ "$output" = "inlets" ]
+}
+@test "detects three anagrams" {
+    run bash anagram.sh "allergy" "gallery ballerina regally clergy largely leading"
+    [ "$status" -eq 0 ]
+    [ "$output" = "gallery regally largely" ]
+}
+@test "does not detect identical words" {
+    run bash anagram.sh "corn" "corn dark Corn rank CORN cron park"
+    [ "$status" -eq 0 ]
+    [ "$output" = "cron" ]
+}
+@test "does not detect non-anagrams with identical checksum" {
+    run bash anagram.sh "mass" "last"
+    [ "$status" -eq 0 ]
+    [ "$output" = "" ]
+}
+@test "detects anagrams case-insensitively" {
+    run bash anagram.sh "Orchestra" "cashregister Carthorse radishes"
+    [ "$status" -eq 0 ]
+    [ "$output" = "Carthorse" ]
+}
+@test "detects anagrams using case-insensitive subject" {
+    run bash anagram.sh "Orchestra" "cashregister carthorse radishes"
+    [ "$status" -eq 0 ]
+    [ "$output" = "carthorse" ]
+}
+@test "detects anagrams using case-insensitive possible matches" {
+    run bash anagram.sh "orchestra" "cashregister Carthorse radishes"
+    [ "$status" -eq 0 ]
+    [ "$output" = "Carthorse" ]
+}
+@test "does not detect a word as its own anagram" {
+    run bash anagram.sh "banana" "Banana"
+    [ "$status" -eq 0 ]
+    [ "$output" = "" ]
+}
+@test "does not detect a anagram if the original word is repeated" {
+    run bash anagram.sh "go" "go Go GO"
+    [ "$status" -eq 0 ]
+    [ "$output" = "" ]
+}
+@test "anagrams must use all letters exactly once" {
+    run bash anagram.sh "tapper" "patter"
+    [ "$status" -eq 0 ]
+    [ "$output" = "" ]
+}
+@test "capital word is not own anagram" {
+    run bash anagram.sh "BANANA" "Banana"
+    [ "$status" -eq 0 ]
+    [ "$output" = "" ]
+}