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 +4 -4
- data/lib/trackler/version.rb +1 -1
- data/tracks/factor/SETUP.md +1 -1
- data/tracks/go/README.md +107 -44
- data/tracks/lisp/config.json +0 -31
- data/tracks/lua/config.json +1 -8
- data/tracks/prolog/docs/INSTALLATION.md +2 -2
- data/tracks/prolog/docs/LEARNING.md +1 -0
- data/tracks/prolog/docs/RESOURCES.md +1 -0
- metadata +1 -4
- data/tracks/java/exercises/word-count/src/main/java/.keep +0 -0
- data/tracks/lua/exercises/accumulate/accumulate_spec.lua +0 -27
- data/tracks/lua/exercises/accumulate/example.lua +0 -7
checksums.yaml
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
SHA1:
|
|
3
|
-
metadata.gz:
|
|
4
|
-
data.tar.gz:
|
|
3
|
+
metadata.gz: 75ec4d39c8404045c3da176d93716bc5cf367589
|
|
4
|
+
data.tar.gz: 8d17aded91294036f476f3a855aa5fdc64bd1396
|
|
5
5
|
SHA512:
|
|
6
|
-
metadata.gz:
|
|
7
|
-
data.tar.gz:
|
|
6
|
+
metadata.gz: f37eaab777c5319aba8d031584ca08b2d2607c8d00c676a57f79f391dea404f8e59a0e4acd3b06e3661804c0cf89bc0908675ea41bec0130b8e94f763b0f1c6d
|
|
7
|
+
data.tar.gz: bdc3fa7c2353b15319cd5090877b00a8fe54c72e9bef99444add6f6fc7fbf181219659976ed5ce857d5db1339436bab959b7dca63fbc0ea0fd8acd27b4e2e5d4
|
data/lib/trackler/version.rb
CHANGED
data/tracks/factor/SETUP.md
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
## Testing Exercises
|
|
2
2
|
|
|
3
|
-
If you followed the [installation instructions](http://exercism.io/languages/factor
|
|
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
|
-
##
|
|
36
|
+
## xgo style
|
|
37
37
|
|
|
38
|
-
|
|
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
|
-
|
|
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
|
-
|
|
52
|
+
0 directories, 5 files
|
|
53
|
+
```
|
|
43
54
|
|
|
44
|
-
|
|
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
|
-
|
|
47
|
-
|
|
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
|
-
|
|
55
|
-
|
|
56
|
-
|
|
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
|
-
|
|
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
|
-
|
|
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
|
-
|
|
69
|
+
**leap_test.go** - This is the main test file for the exercise.
|
|
74
70
|
|
|
75
|
-
|
|
76
|
-
|
|
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
|
-
|
|
81
|
-
Go tests require an error return where other language tracks don't.
|
|
74
|
+
### Example solutions
|
|
82
75
|
|
|
83
|
-
|
|
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
|
-
|
|
86
|
-
|
|
87
|
-
|
|
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
|
-
|
|
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
|
-
|
|
92
|
-
|
|
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
|
-
|
|
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
|
|
data/tracks/lisp/config.json
CHANGED
|
@@ -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",
|
data/tracks/lua/config.json
CHANGED
|
@@ -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/
|
|
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/
|
|
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.
|
|
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)
|