trackler 2.0.8.8 → 2.0.8.9
Sign up to get free protection for your applications and to get access to all the features.
- 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)
|