trackler 2.0.6.10 → 2.0.6.11

data/common/exercises/variable-length-quantity/canonical-data.json

@@ -0,0 +1,147 @@
+{
+  "#": [
+    "JSON doesn't allow hexadecimal literals.",
+    "All numbers are given as decimal literals instead.",
+    "It is highly recommended that your track's test generator display all numbers as hexadecimal literals."
+  ],
+  "encode": {
+    "description": ["Encode a series of integers, producing a series of bytes."],
+    "cases": [
+      {
+        "description": "zero",
+        "input": [0],
+        "expected": [0]
+      },
+      {
+        "description": "arbitrary single byte",
+        "input": [64],
+        "expected": [64]
+      },
+      {
+        "description": "largest single byte",
+        "input": [127],
+        "expected": [127]
+      },
+      {
+        "description": "smallest double byte",
+        "input": [128],
+        "expected": [129, 0]
+      },
+      {
+        "description": "arbitrary double byte",
+        "input": [8192],
+        "expected": [192, 0]
+      },
+      {
+        "description": "largest double byte",
+        "input": [16383],
+        "expected": [255, 127]
+      },
+      {
+        "description": "smallest triple byte",
+        "input": [16384],
+        "expected": [129, 128, 0]
+      },
+      {
+        "description": "arbitrary triple byte",
+        "input": [1048576],
+        "expected": [192, 128, 0]
+      },
+      {
+        "description": "largest triple byte",
+        "input": [2097151],
+        "expected": [255, 255, 127]
+      },
+      {
+        "description": "smallest quadruple byte",
+        "input": [2097152],
+        "expected": [129, 128, 128, 0]
+      },
+      {
+        "description": "arbitrary quadruple byte",
+        "input": [134217728],
+        "expected": [192, 128, 128, 0]
+      },
+      {
+        "description": "largest quadruple byte",
+        "input": [268435455],
+        "expected": [255, 255, 255, 127]
+      },
+      {
+        "description": "smallest quintuple byte",
+        "input": [268435456],
+        "expected": [129, 128, 128, 128, 0]
+      },
+      {
+        "description": "arbitrary quintuple byte",
+        "input": [4278190080],
+        "expected": [143, 248, 128, 128, 0]
+      },
+      {
+        "description": "maximum 32-bit integer input",
+        "input": [4294967295],
+        "expected": [143, 255, 255, 255, 127]
+      },
+      {
+        "description": "two single-byte values",
+        "input": [64, 127],
+        "expected": [64, 127]
+      },
+      {
+        "description": "two multi-byte values",
+        "input": [16384, 1193046],
+        "expected": [129, 128, 0, 200, 232, 86]
+      },
+      {
+        "description": "many multi-byte values",
+        "input": [8192, 1193046, 268435455, 0, 16383, 16384],
+        "expected": [192, 0, 200, 232, 86, 255, 255, 255, 127, 0, 255, 127, 129, 128, 0]
+      }
+    ]
+  },
+  "decode": {
+    "description": ["Decode a series of bytes, producing a series of integers."],
+    "cases": [
+      {
+        "description": "one byte",
+        "input": [127],
+        "expected": [127]
+      },
+      {
+        "description": "two bytes",
+        "input": [192, 0],
+        "expected": [8192]
+      },
+      {
+        "description": "three bytes",
+        "input": [255, 255, 127],
+        "expected": [2097151]
+      },
+      {
+        "description": "four bytes",
+        "input": [129, 128, 128, 0],
+        "expected": [2097152]
+      },
+      {
+        "description": "maximum 32-bit integer",
+        "input": [143, 255, 255, 255, 127],
+        "expected": [4294967295]
+      },
+      {
+        "description": "incomplete sequence causes error",
+        "input": [255],
+        "expected": null
+      },
+      {
+        "description": "incomplete sequence causes error, even if value is zero",
+        "input": [128],
+        "expected": null
+      },
+      {
+        "description": "multiple values",
+        "input": [192, 0, 200, 232, 86, 255, 255, 255, 127, 0, 255, 127, 129, 128, 0],
+        "expected": [8192, 1193046, 268435455, 0, 16383, 16384]
+      }
+    ]
+  }
+}

data/lib/trackler/version.rb

@@ -1,3 +1,3 @@
 module Trackler
-  VERSION = "2.0.6.10"
+  VERSION = "2.0.6.11"
 end

data/tracks/ceylon/.gitignore

@@ -2,3 +2,4 @@
 .DS_Store
 bin/configlet
 bin/configlet.exe
+modules/

data/tracks/ceylon/.travis.yml

@@ -1,5 +1,10 @@
 language: bash
 
-script:
+install:
   - bin/fetch-configlet
+  - curl -s https://get.sdkman.io | bash
+  - source $HOME/.sdkman/bin/sdkman-init.sh
+  - sdk install ceylon
+script:
   - bin/configlet .
+  - bin/test-all-exercises

data/tracks/ceylon/README.md

@@ -2,13 +2,152 @@
 
 Exercism problems in Ceylon.
 
-## TODO
-
-_Document how to contribute to the Ceylon track._
+[![Build Status](https://travis-ci.org/exercism/xceylon.svg?branch=master)](https://travis-ci.org/exercism/xceylon)
 
 ## Contributing Guide
 
-Please see the [contributing guide](https://github.com/exercism/x-api/blob/master/CONTRIBUTING.md#the-exercise-data)
+### Asking for help
+
+If you're ever unsure about how to help, don't worry!
+You can just ask in the [Exercism Gitter support](https://gitter.im/exercism/support) channel or by creating an issue [for the Ceylon track](https://github.com/exercism/xceylon/issues/new) and we are happy to help you!
+
+### How to contribute
+
+The Exercism-wide [contributing guide](https://github.com/exercism/x-common/blob/master/CONTRIBUTING.md) covers topics relevant to contributing to the entire Exercism project, including but not limited to the Ceylon track.
+
+* To report a bug or ask a question, [create an issue](https://help.github.com/articles/creating-an-issue/).
+* If you already have a fix for a bug, you could [create a pull request](https://help.github.com/articles/creating-a-pull-request-from-a-fork/).
+
+Depending on what your contribution deals with, you may have to direct it at a certain repository:
+
+* If your contribution deals with the README for a problem, it should go to [x-common](https://github.com/exercism/x-common).
+* Otherwise, it probably deals with matters specific to the Ceylon track, in which case it goes to this repository.
+* If you're not sure, you can try here and we will let you know if it should go in x-common.
+
+#### Porting an exercise
+
+The Exercism site provides a list of [exercises not on the Ceylon track](http://exercism.io/languages/ceylon/todo).
+A possible contribution would be to choose one of these exercises and add it to this track.
+The common contributing guide has a [section on porting an exercise](https://github.com/exercism/x-common/blob/master/CONTRIBUTING.md#porting-an-exercise-to-another-language-track).
+
+Note that you will need to add the problem to the `exercises` section in `config.json` as well, otherwise it will not be available via `exercism fetch` (or any other means, other than by cloning the repository).
+
+The order in which the exercises are listed in `config.json` is the order in which they will be served by default by `exercism fetch ceylon`.
+
+For the Ceylon track, the files needed to port an exercise are described in the next section about [exercise structure](#exercise-structure).
+
+### Exercise structure
+
+Each exercise is located in the `exercises` directory, in a directory with the same name as its slug (the `leap` exercise will be at `exercises/leap`, etc.).
+This directory should contain the following files and directories, where `<slug>` is the slug of the exercise with all hyphens deleted, and `<Slug>` is the CamelCased version:
+
+* `source/<slug>/module.ceylon`: the [module descriptor](https://ceylon-lang.org/documentation/tour/modules/#dependencies_and_module_descriptors).
+  * This file declares the module and any dependencies.
+  * Typically, the only dependency will be on [`ceylon.test`](https://herd.ceylon-lang.org/modules/ceylon.test) at the current Ceylon version.
+  * We don't expect to declare any other dependencies in this module descriptor.
+  * The student is of course free to add any dependencies here if the student's individual submission requires them.
+* `source/<slug>/<Slug>.ceylon`: the stub solution.
+  * This file provides just the type signatures needed to make the tests compile.
+  * The implementations for all functions should all be `return nothing;`, which will intentionally fail the tests.
+* `source/<slug>/<Slug>Test.ceylon`: The test file.
+  * If there is an `exercises/<slug>/canonical-data.json` in the `x-common` repository, the test cases should typically be those described in that file.
+  * If you believe a case should be added or removed, try discussing it in the `x-common` repository to see if it would apply to all tracks.
+  * If a modification to the cases only makes sense for the Ceylon track, please note the change in the test file.
+  * If no JSON file is present, you may use the same tests as other languages implementing that exercise.
+  * Typically, we like to use [parameterized tests](https://ceylon-lang.org/blog/2016/02/22/ceylon-test-new-and-noteworthy/#parameterized_tests) to express the tests with minimal duplication in test code.
+* `example/<Slug>.ceylon`: An example solution that passes the tests.
+  * This will not be served to students (all paths containing `example` are not served).
+  * Instead, it is used in our [Travis CI run](.travis.yml) to make sure that the exercise is solvable and that the tests make sense.
+* *optional*: `example/module.ceylon`: The module descriptor for the example solution.
+  * This is necessary only if the example solution has dependencies other than `ceylon.test`.
+  * Wherever possible, the dependencies should be limited to modules under the `ceylon.*` namespace, to avoid burdening Travis CI with having to fetch many external dependencies.
+  * We may consider adding external dependencies for an example solution if the exercise would be unnecessarily difficult and/or cumbersome without those particular dependencies.
+* *optional*: `example/*.ceylon`
+  * Other files may be included in the `example/` directory if appropriate.
+
+As a reminder, the README does not need to be added to this track - it is automatically created using the data in [x-common](https://github.com/exercism/x-common).
+However, if there is any Ceylon-specific information that you would like appended to the README, place this in a `HINTS.md` file in the exercise directory (`exercises/<slug>/HINTS.md`).
+
+### Running the tests
+
+As mentioned, [Travis CI](https://travis-ci.org/exercism/xceylon) runs our tests to ensure that our exercises are solvable.
+The tests are run on all pull requests (PRs), and we should strive to only merge PRs for which the tests are passing.
+
+It is possible to run these tests locally as well.
+In particular, the [`bin/test-exercise`](bin/test-exercise) will test just one exercise:
+
+```bash
+bin/test-exercise exercises/leap
+```
+
+This script automates the process of moving the example files in, running the tests, and then moving the example files back.
+This is useful when changing an exercise in this repository.
+The test can be run locally to make sure everything is working without having to wait for Travis CI.
+
+### Style and conventions
+
+Various choices were made in the past to get the repository to the state it is in now.
+These choices aren't set in stone; they could be changed at a later date.
+But the rationale behind the current choices made will be noted here.
+
+#### Style
+
+At the time of writing, the current maintainer of the Ceylon track was not able to find any commonly-accepted style guide for Ceylon.
+Nor did the maintainer find automatic linter or formatter.
+Thus, the maintainer was forced to just figure one out and try to be consistent.
+For example, all indents are two spaces because that's the default in the maintainer's editor.
+
+The maintainer is not intent on any particular style as long as all the code in the repository is consistent.
+If in the future there happened to be a widely-accepted style guide and/or an automatic formatter, the maintainer would not be opposed to reformatting all code in this repository to comply.
+
+#### Idiomatic Ceylon
+
+All example code should be idiomatic Ceylon, to set a good example for anyone who might look at this repository for solutions to the exercises.
+The current maintainer may have trouble with this point, since the current maintainer is only a Ceylon beginner and may not be familiar enough with the language to tell what is idiomatic or not.
+Help in this area is especially appreciated.
+
+#### Project structure
+
+The current maintainer finds it regrettable that the exercise slug must be repeated so many times: `exercises/<slug>/source/<slug>/<Slug>.ceylon`.
+
+* `exercises/<slug>` is required by Exercism, otherwise the exercise cannot be served.
+* `source/<slug>` is because the exercise files are placed in a module with the same name as the exercise slug.
+  * It doesn't seem possible to run [`ceylon test`](https://ceylon-lang.org/documentation/reference/tool/ceylon/subcommands/ceylon-test.html) without a module, since that is one of the arguments it requires.
+  * They could all be named `main` or something similarly nondescript, but perhaps that would get confusing.
+* `<Slug>.ceylon` is not required for any particular reason.
+  * Then again, what else would it be named?
+  * Again, `Main.ceylon` seems a bit too confusion-prone.
+
+The current maintainer wishes there was less duplication, but does not really see a good way out.
+Any ideas here are welcome.
+
+#### Stubs
+
+We provide the stubs with signatures included because we felt it was not a sufficiently interesting learning experience to make students have to puzzle out the expected signatures by just looking at the tests.
+
+Because Ceylon is a statically-typed language, the entire test suite must type-check before it can be run at all.
+Thus, not providing the type signatures forces the students to figure out the types for all the functions being tested, rather than being able to focus on just one at a time.
+
+The Ceylon track is not the only track that had to make this decision.
+[Other tracks have discussed this as well](https://github.com/exercism/discussions/issues/114), and come to various conclusions.
+
+If students suggest that they would like to have the challenge of figuring out type signatures, we would gladly change our minds on this point.
+They might suggest this on the exercism.io site, or on this repository via issues.
+It's likely that the latter is more often monitored.
+
+#### Parameterized tests versus one test at a time
+
+As mentioned above, we used parameterized tests since this avoids test code duplication.
+
+Unfortunately, since by default all cases are enabled, this runs counter to the usual Exercism style in which only a *single test case* is enabled, and the student enables one more test case after making the previous one pass, taking an iterative process.
+
+The [ignore annotation](https://modules.ceylon-lang.org/repo/1/ceylon/test/1.3.1/module-doc/api/index.html#ignore) does not seem like it can be applied to individual cases of a parameterized test.
+
+One possible solution to this would be to comment out all cases except the first.
+If this solution were taken, students would need to be aware of this, and be informed that they need to uncomment the cases.
+The Travis CI run would need to uncomment the cases as well (without uncommenting any actual comments, which would probably cause syntax errors!).
+
+The current maintainer does not have a good solution to this, so ideas here are welcome.
 
 ## License
 

data/tracks/ceylon/bin/test-all-exercises

@@ -0,0 +1,13 @@
+#!/bin/sh
+
+test_one=$(dirname $0)/test-exercise
+exercises=$(dirname $(dirname $0))/exercises
+status=0
+
+for d in $exercises/*/; do
+  if ! $test_one $d; then
+    status=1
+  fi
+done
+
+exit $status

data/tracks/ceylon/bin/test-exercise

@@ -0,0 +1,30 @@
+#!/bin/sh
+
+if [ $# -eq 0 ]; then
+  echo "usage: $0 exercise-slug"
+  exit 1
+fi
+
+dir=$1
+exercise=$(basename $dir)
+module=$(echo $exercise | tr -d -)
+sourcedir="source/$module"
+backupext=testbak
+
+cd $dir
+
+for f in example/*; do
+  target="$sourcedir/$(basename $f)"
+  cp $target $target.$backupext
+  cp $f $target
+done
+
+ceylon test --compile=force $module
+status=$?
+
+for f in example/*; do
+  target="$sourcedir/$(basename $f)"
+  mv $target.$backupext $target
+done
+
+exit $status

data/tracks/ceylon/config.json

@@ -3,9 +3,39 @@
   "language": "Ceylon",
   "repository": "https://github.com/exercism/xceylon",
   "active": false,
-  "test_pattern": "TODO",
-  "problems": [
-
+  "exercises": [
+    {
+      "slug": "leap",
+      "difficulty": 1,
+      "topics": [
+        "Integers"
+      ]
+    },
+    {
+      "slug": "sieve",
+      "difficulty": 3,
+      "topics": [
+        "Filtering",
+        "Mathematics"
+      ]
+    },
+    {
+      "slug": "anagram",
+      "difficulty": 4,
+      "topics": [
+        "Strings",
+        "Filtering"
+      ]
+    },
+    {
+      "slug": "bracket-push",
+      "difficulty": 6,
+      "topics": [
+        "Parsing",
+        "Stacks",
+        "Strings"
+      ]
+    }
   ],
   "deprecated": [
 

data/tracks/ceylon/exercises/anagram/example/Anagram.ceylon

@@ -0,0 +1,8 @@
+{String*} anagrams(String subject, {String*} candidates) {
+  value lower = subject.lowercased;
+  value chars = sort(lower);
+  return candidates.filter((c) {
+    value lowerCandidate = c.lowercased;
+    return lower != lowerCandidate && chars == sort(lowerCandidate);
+  });
+}

data/tracks/ceylon/exercises/anagram/source/anagram/Anagram.ceylon

@@ -0,0 +1,3 @@
+{String*} anagrams(String subject, {String*} candidates) {
+  return nothing;
+}

data/tracks/ceylon/exercises/anagram/source/anagram/AnagramTest.ceylon

@@ -0,0 +1,47 @@
+import ceylon.test { ... }
+
+{[String, {String*}, {String*}]*} cases =>
+  {
+    // no matches
+    ["diaper", {"hello", "world", "zombies", "pants"}, {}],
+    // detects simple anagram
+    ["ant", {"tan", "stand", "at"}, {"tan"}],
+    // does not detect false positives
+    ["galea", {"eagle"}, {}],
+    // detects multiple anagrams
+    ["master", {"stream", "pigeon", "maters"}, {"stream", "maters"}],
+    // does not detect anagram subsets
+    ["good", {"dog", "goody"}, {}],
+    // detects anagram
+    ["listen", {"enlists", "google", "inlets", "banana"}, {"inlets"}],
+    // detects multiple anagrams
+    [
+      "allergy",
+      {"gallery", "ballerina", "regally", "clergy", "largely", "leading"},
+      {"gallery", "regally", "largely"}
+    ],
+    // does not detect identical words
+    ["corn", {"corn", "dark", "Corn", "rank", "CORN", "cron", "park"}, {"cron"}],
+    // does not detect non-anagrams with identical checksum
+    ["mass", {"last"}, {}],
+    // detects anagrams case-insensitively
+    ["Orchestra", {"cashregister", "Carthorse", "radishes"}, {"Carthorse"}],
+    // detects anagrams using case-insensitive subject
+    ["Orchestra", {"cashregister", "carthorse", "radishes"}, {"carthorse"}],
+    // detects anagrams using case-insensitive possible matches
+    ["orchestra", {"cashregister", "Carthorse", "radishes"}, {"Carthorse"}],
+    // does not detect a word as its own anagram
+    ["banana", {"Banana"}, {}],
+    // does not detect a anagram if the original word is repeated
+    ["go", {"go Go GO"}, {}],
+    // anagrams must use all letters exactly once
+    ["tapper", {"patter"}, {}],
+    // capital word is not own anagram
+    ["BANANA", {"Banana"}, {}]
+  };
+
+test
+parameters(`value cases`)
+void testAnagram(String subject, {String*} candidates, {String*} expected) {
+  assertEquals(sort(anagrams(subject, candidates)), sort(expected));
+}