trackler 2.0.8.8 → 2.0.8.9

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
checksums.yaml CHANGED
@@ -1,7 +1,7 @@
1
1
  ---
2
2
  SHA1:
3
- metadata.gz: e62546727fedd95973681d450fffd9b90c5c3ede
4
- data.tar.gz: fd0387e4ccf20d919d388471d2f4c26b83f04129
3
+ metadata.gz: 75ec4d39c8404045c3da176d93716bc5cf367589
4
+ data.tar.gz: 8d17aded91294036f476f3a855aa5fdc64bd1396
5
5
  SHA512:
6
- metadata.gz: 2429ecbe7c6f1b7b0b9e389ee3ae0e5171057abb43f425fb20d1fb66b5077a9177f2b58d0fd1cbfc0f0d29e2026f511753e59b03b23f734cfaaa598ea92a6cdf
7
- data.tar.gz: 7969ad1d115aa1d2a0dd93292009745b7d94b4f5d68e2d349123b6d8abff9743794e6003a4a2823e94e6e8d1d07577d6d668c605c33a78125b60b36438879e41
6
+ metadata.gz: f37eaab777c5319aba8d031584ca08b2d2607c8d00c676a57f79f391dea404f8e59a0e4acd3b06e3661804c0cf89bc0908675ea41bec0130b8e94f763b0f1c6d
7
+ data.tar.gz: bdc3fa7c2353b15319cd5090877b00a8fe54c72e9bef99444add6f6fc7fbf181219659976ed5ce857d5db1339436bab959b7dca63fbc0ea0fd8acd27b4e2e5d4
@@ -1,3 +1,3 @@
1
1
  module Trackler
2
- VERSION = "2.0.8.8"
2
+ VERSION = "2.0.8.9"
3
3
  end
@@ -1,6 +1,6 @@
1
1
  ## Testing Exercises
2
2
 
3
- If you followed the [installation instructions](http://exercism.io/languages/factor#installing), just run the provided test suite against your implementation with `"exercise-name" test`.
3
+ If you followed the [installation instructions](http://exercism.io/languages/factor/installing), just run the provided test suite against your implementation with `"exercise-name" test`.
4
4
 
5
5
  ## Submitting Exercises
6
6
 
data/tracks/go/README.md CHANGED
@@ -33,66 +33,129 @@ in the x-common repository. This describes how all the language tracks are put
33
33
  the common metadata, and high-level information about contributing to existing problems and adding new problems.
34
34
  In particular, please read the [Pull Request Guidelines](https://github.com/exercism/x-common/blob/master/CONTRIBUTING.md#pull-request-guidelines) before opening a pull request.
35
35
 
36
- ## Problem Versioning
36
+ ## xgo style
37
37
 
38
- Each problem defines a `const targetTestVersion` in the test program, and validates that the solution has defined a matching value `testVersion`. Any xgo developer that changes the test program or test data increments `targetTestVersion`.
38
+ Let's walk through the `leap` exercise to see what is included in an exercise
39
+ implementation. Navigate into the *leap* directory, you'll see there are five
40
+ files there.
39
41
 
40
- The benefit of all this is that reviewers can see which test version a posted solution was written for and be spared confusion over why an old posted solution might not pass current tests.
42
+ ```sh
43
+ ~/exercism/go/leap
44
+ $ tree
45
+ .
46
+ ├── cases_test.go
47
+ ├── example_gen.go
48
+ ├── example.go
49
+ ├── leap.go
50
+ └── leap_test.go
41
51
 
42
- Notice that neither the `testVersion` nor the `targetTestVersion` is exported. This is so that golint will not complain about a missing comment. In general, adding tests for unexported names is considered an anti-pattern, but in this case the trade-off seems acceptable.
52
+ 0 directories, 5 files
53
+ ```
43
54
 
44
- ## Xgo style
55
+ This list of files can vary across exercises so let's quickly run through
56
+ each file and briefly describe what it is.
45
57
 
46
- Let's walk through the first problem in `config.json`, leap. Cd down into the leap directory now, there are two
47
- files there, example.go and leap_test.go. Example.go is a reference solution. It is a valid solution that CI can
48
- run tests against. Solvers generally will not see it though. Files with "example" in the file name are skipped
49
- by `fetch`. Because of this, there is less need for this code to be a model of style, expression and
50
- readability, or to use the best algorithm. Examples can be plain, simple, concise, even naïve, as long as they
51
- are correct. The test program though, is fetched for the solver and deserves attention for consistency and
52
- appearance.
58
+ **cases_test.go** - This file contains [generated test cases](#generating-test-cases),
59
+ and will only be present in some exercises.
53
60
 
54
- Leap_test.go uses a data-driven test. Test cases are defined as data, then a test function iterates over
55
- the data. Identifiers within the method appear in actual-expected order as described at
56
- [Useful Test Failures](https://github.com/golang/go/wiki/CodeReviewComments#useful-test-failures).
57
- Here the identifier 'observed' is used instead of actual. That's fine. More common are words 'got' and 'want'.
58
- They are clear and short. Note
59
- [Useful Test Failures](https://github.com/golang/go/wiki/CodeReviewComments#useful-test-failures) is part of
60
- [Code Review Comments](https://github.com/golang/go/wiki/CodeReviewComments). Really we like most of the
61
- advice on that page.
61
+ **example_gen.go** - This file generates the *cases_test.go* file, and will only
62
+ be present in some exercises. See [generating test cases](#generating-test-cases)
63
+ for more information.
62
64
 
63
- Also here in leap_test.go is a benchmark. We throw in benchmarks because they're interesting, and because it's
64
- idiomatic in Go to think about performance. There is no critical use for these though. Usually, like this one in
65
- leap, they will just bench the combined time to run over all the test data rather than attempt precise timings
66
- on single function calls. They are useful if they let the solver try a change and see a performance effect.
65
+ **example.go** - This is a reference solution for the exercise.
67
66
 
68
- Finally we provide the stub file `leap.go` as a starting point for solutions.
69
- Not all exercises need do this; this is most helpful in the early exercises for newcomers to Go.
70
- By convention, the stub file for an exercise with slug `exercise-slug` must be named `exercise_slug.go`.
71
- This is because CI needs to delete stub files to avoid conflicting definitions.
67
+ **leap.go** - This is a *stub file*, and will only be present in some exercises.
72
68
 
73
- ## Xgo compared
69
+ **leap_test.go** - This is the main test file for the exercise.
74
70
 
75
- We do a few things differently than the other language tracks. In Go we generally have all tests enabled and do
76
- not ask the solver to edit the test program, to enable progressive tests for example. `Testing.Fatal`, as seen
77
- in leap_test.go, will stop tests at the first problem encountered so the solver is not faced with too many errors
78
- all at once.
71
+ In some exercises there can be extra files, for instance the `series` exercise
72
+ contains extra test files.
79
73
 
80
- We like errors in Go. It's not idiomatic Go to ignore invalid data or have undefined behavior. Sometimes our
81
- Go tests require an error return where other language tracks don't.
74
+ ### Example solutions
82
75
 
83
- ## Generating test cases
76
+ *example.go* is a reference solution. It is a valid solution that [Travis](https://travis-ci.org/exercism/xgo),
77
+ the CI (continuous integration) service, can run tests against. Solvers generally
78
+ will not see it though. Files with *"example"* in the file name are skipped by
79
+ the `exercism fetch` command. Because of this, there is less need for this code
80
+ to be a model of style, expression and readability, or to use the best algorithm.
81
+ Examples can be plain, simple, concise, even naïve, as long as they are correct.
82
+ The test file though, is fetched for the solver and deserves attention for consistency
83
+ and appearance.
84
+
85
+ ### Tests
86
+
87
+ The `leap` exercise makes use of data-driven tests. Test cases are defined as
88
+ data, then a test function iterates over the data. In this exercise, as they are
89
+ generated, the test cases are defined in the *cases_test.go* file. The test function
90
+ that iterates over this data is defined in the *leap_test.go* file.
91
+
92
+ Identifiers within the test function appear in actual-expected order as described
93
+ at [Useful Test Failures](https://github.com/golang/go/wiki/CodeReviewComments#useful-test-failures).
94
+ Here the identifier `observed` is used instead of actual. That's fine. More
95
+ common are words `got` and `want`. They are clear and short. Note [Useful Test
96
+ Failures](https://github.com/golang/go/wiki/CodeReviewComments#useful-test-failures)
97
+ is part of [Code Review Comments](https://github.com/golang/go/wiki/CodeReviewComments).
98
+ Really we like most of the advice on that page.
99
+
100
+ In Go we generally have all tests enabled and do not ask the solver to edit the
101
+ test program, to enable progressive tests for example. `t.Fatalf()`, as seen
102
+ in the *leap_test.go* file, will stop tests at the first failure encountered,
103
+ so the solver is not faced with too many failures all at once.
104
+
105
+ ### Benchmarks
106
+
107
+ In most test files there will also be benchmark tests, as can be seen at the end
108
+ of the *leap_test.go* file. In Go, benchmarking is a first-class citizen of the
109
+ testing package. We throw in benchmarks because they're interesting, and because
110
+ it is idiomatic in Go to think about performance. There is no critical use for
111
+ these though. Usually they will just bench the combined time to run over all
112
+ the test data rather than attempt precise timings on single function calls. They
113
+ are useful if they let the solver try a change and see a performance effect.
114
+
115
+ ### Stub files
84
116
 
85
- Some problems that are implemented in multiple tracks use the same inputs and outputs to define the test suites.
86
- Where the [x-common](https://github.com/exercism/x-common) repository contains json files with these inputs and
87
- outputs, we can generate the test cases programmatically.
117
+ Stub files, such as `leap.go`, are a starting point for solutions. Not all exercises
118
+ need to do this; this is most helpful in the early exercises for newcomers to Go.
119
+ By convention, the stub file for an exercise with slug `exercise-slug`
120
+ must be named `exercise_slug.go`. This is because CI needs to delete stub files
121
+ to avoid conflicting definitions.
122
+
123
+ ### Problem Versioning
124
+
125
+ Each problem defines a `const targetTestVersion` in the test file, and validates
126
+ that the solution has defined a matching value `testVersion`. Any xgo developer
127
+ that changes the test file or test data must increment `targetTestVersion`.
128
+
129
+ The benefit of all this is that reviewers can see which test version a posted
130
+ solution was written for and be spared confusion over why an old posted solution
131
+ might not pass current tests.
132
+
133
+ Notice that neither the `testVersion` nor the `targetTestVersion` is exported.
134
+ This is so that golint will not complain about a missing comment. In general,
135
+ adding tests for unexported names is considered an anti-pattern, but in this
136
+ case the trade-off seems acceptable.
137
+
138
+ ### Errors
139
+
140
+ We like errors in Go. It's not idiomatic Go to ignore invalid data or have undefined
141
+ behavior. Sometimes our Go tests require an error return where other language
142
+ tracks don't.
143
+
144
+ ## Generating test cases
88
145
 
89
- See `leap/example_gen.go` for an example of how this can be done.
146
+ Some problems that are implemented in multiple tracks use the same inputs and
147
+ outputs to define the test suites. Where the [x-common](https://github.com/exercism/x-common)
148
+ repository contains json files with these inputs and outputs, we can generate
149
+ the test cases programmatically.
90
150
 
91
- Whenever the shared JSON data changes, the test cases will need to be regenerated. To do this, make sure that the
92
- x-common repository has been cloned in the same parent-directory as the xgo repository. Then `cd` to the `xgo`
93
- directory and run `go run exercises/<problem>/example_gen.go`.
151
+ See the *example_gen.go* file in the `leap` exercise for an example of how this
152
+ can be done.
94
153
 
95
- You should see that the `<problem>/test_cases.go` file has changed. Commit the change.
154
+ Whenever the shared JSON data changes, the test cases will need to be regenerated.
155
+ To do this, make sure that the **x-common** repository has been cloned in the same
156
+ parent-directory as the **xgo** repository. Then navigate into the **xgo**
157
+ directory and run `go run exercises/<problem>/example_gen.go`. You should see
158
+ that the `<problem>/test_cases.go` file has changed. Commit the change.
96
159
 
97
160
  ## Pull requests
98
161
 
@@ -3,37 +3,6 @@
3
3
  "language": "Common Lisp",
4
4
  "repository": "https://github.com/exercism/xlisp",
5
5
  "active": true,
6
- "problems": [
7
- "hamming",
8
- "leap",
9
- "grains",
10
- "gigasecond",
11
- "bob",
12
- "rna-transcription",
13
- "robot-name",
14
- "word-count",
15
- "raindrops",
16
- "grade-school",
17
- "phone-number",
18
- "etl",
19
- "beer-song",
20
- "space-age",
21
- "anagram",
22
- "nucleotide-count",
23
- "meetup",
24
- "triangle",
25
- "difference-of-squares",
26
- "roman-numerals",
27
- "scrabble-score",
28
- "binary",
29
- "allergies",
30
- "sieve",
31
- "strain",
32
- "atbash-cipher",
33
- "prime-factors",
34
- "crypto-square",
35
- "trinary"
36
- ],
37
6
  "exercises": [
38
7
  {
39
8
  "slug": "hamming",
@@ -12,13 +12,6 @@
12
12
  "optional values",
13
13
  "text formatting"
14
14
  ]
15
- }, {
16
- "slug": "accumulate",
17
- "difficulty": 2,
18
- "topics": [
19
- "arrays",
20
- "control-flow (loops)"
21
- ]
22
15
  }, {
23
16
  "slug": "hamming",
24
17
  "difficulty": 2,
@@ -620,7 +613,7 @@
620
613
  ]
621
614
  }],
622
615
  "deprecated": [
623
-
616
+ "accumulate"
624
617
  ],
625
618
  "ignored": [
626
619
  "docs"
@@ -1,8 +1,8 @@
1
1
  ##Installation
2
2
 
3
- **Mac Users**: Install using homebrew with `brew install swi-prolog`. Alternatively, download the source for your machine from the (SWI Prolog Website)[http://www.swi-prolog.org/download/stable].
3
+ **Mac Users**: Install using homebrew with `brew install swi-prolog`. Alternatively, download the source for your machine from the (SWI Prolog Website)[http://www.swi-prolog.org/download/devel].
4
4
 
5
- **Windows Users**: Download the source for your machine from the (SWI Prolog Website)[http://www.swi-prolog.org/download/stable].
5
+ **Windows Users**: Download the source for your machine from the (SWI Prolog Website)[http://www.swi-prolog.org/download/devel].
6
6
 
7
7
  **Linux Users**: Follow the instructions for your distro from (here)[http://www.swi-prolog.org/build/unix.html].
8
8
 
@@ -1,5 +1,6 @@
1
1
  ## References
2
2
  * [SWI-Prolog Getting Started](http://www.swi-prolog.org/pldoc/man?section=quickstart)
3
+ * [SWISH - An online Prolog REPL](http://swish.swi-prolog.org/)
3
4
  * [Tutorials and Resources](http://www.swi-prolog.org/Links.html)
4
5
  * [Seven Languages in Seven Weeks by Bruce A. Tate - Chapter 4](https://pragprog.com/book/btlang/seven-languages-in-seven-weeks)
5
6
  * [Learn Prolog Now](http://www.learnprolognow.org)
@@ -1,4 +1,5 @@
1
1
  ## Resources
2
2
  * [SWI Prolog Documentation](http://www.swi-prolog.org)
3
+ * [SWISH - An online Prolog REPL](http://swish.swi-prolog.org/)
3
4
  * [Prolog on Stack Overflow](https://stackoverflow.com/tags/prolog)
4
5
  * [Tutorials and Resources](http://www.swi-prolog.org/Links.html)
metadata CHANGED
@@ -1,7 +1,7 @@
1
1
  --- !ruby/object:Gem::Specification
2
2
  name: trackler
3
3
  version: !ruby/object:Gem::Version
4
- version: 2.0.8.8
4
+ version: 2.0.8.9
5
5
  platform: ruby
6
6
  authors:
7
7
  - Katrina Owen
@@ -4168,7 +4168,6 @@ files:
4168
4168
  - tracks/java/exercises/twelve-days/src/test/java/TwelveDaysTest.java
4169
4169
  - tracks/java/exercises/word-count/build.gradle
4170
4170
  - tracks/java/exercises/word-count/src/example/java/WordCount.java
4171
- - tracks/java/exercises/word-count/src/main/java/.keep
4172
4171
  - tracks/java/exercises/word-count/src/main/java/WordCount.java
4173
4172
  - tracks/java/exercises/word-count/src/test/java/WordCountTest.java
4174
4173
  - tracks/java/exercises/wordy/build.gradle
@@ -4997,8 +4996,6 @@ files:
4997
4996
  - tracks/lua/docs/RESOURCES.md
4998
4997
  - tracks/lua/docs/TESTS.md
4999
4998
  - tracks/lua/exercises/TRACK_HINTS.md
5000
- - tracks/lua/exercises/accumulate/accumulate_spec.lua
5001
- - tracks/lua/exercises/accumulate/example.lua
5002
4999
  - tracks/lua/exercises/acronym/acronym_spec.lua
5003
5000
  - tracks/lua/exercises/acronym/example.lua
5004
5001
  - tracks/lua/exercises/all-your-base/all-your-base_spec.lua
File without changes
@@ -1,27 +0,0 @@
1
- local accumulate = require('accumulate')
2
-
3
- describe('accumulate', function()
4
- local function square(x) return x * x end
5
-
6
- it('should accumulate over an empty array', function()
7
- assert.are.same({}, accumulate({}, square))
8
- end)
9
-
10
- it('should accumulate over an array with a single element', function()
11
- assert.are.same({ 4 }, accumulate({ 2 }, square))
12
- end)
13
-
14
- it('should accumulate over an array with several elements', function()
15
- assert.are.same({ 1, 4, 9 }, accumulate({ 1, 2, 3 }, square))
16
- end)
17
-
18
- it('should accumulate over an array with a different function', function()
19
- assert.are.same({ 'HELLO', 'WORLD' }, accumulate({ 'hello', 'world' }, string.upper))
20
- end)
21
-
22
- it('should not modify the input array', function()
23
- local input = { 1, 2, 3 }
24
- accumulate(input, square)
25
- assert.are.same({ 1, 2, 3 }, input)
26
- end)
27
- end)
@@ -1,7 +0,0 @@
1
- return function(xs, f)
2
- local result = {}
3
- for _, x in ipairs(xs) do
4
- table.insert(result, f(x))
5
- end
6
- return result
7
- end