Closes#845
**All changes are non-significant whitespace.** This can be verified with:
git show --ignore-all-space --ignore-blank-lines
in which the remaining changes are only elimination of manual word-wrap in descriptions.
Normalization is accomplished with this command:
scripts/normalize-all-scenarios.sh
This is an initial normalization pass that shall be a pre-requisite for #1713.
This seems to help with rebuild times, since we are specifically requesting to only build the `swarm` executable and not, say, the `swarm-docs` executable.
Both `execConst` and `stepCESK` are huge case statements. This refactor puts them in different modules.
Also many supporting functions for implementing commands in `execConst` are moved to their own modules.
Whereas `Step.hs` previously had `2931` lines, the new linecounts are:
| File | lines |
| --- | --- |
| `Step.hs` | 848 |
| `Arithmetic.hs` | 124 |
| `Const.hs` | 1687 |
| `Command.hs` | 417 |
The only tricky thing was that `execConst` is mutually recursive with `runCESK`. So to get them into different modules, I pass a wrapper of `runCESK` as an argument to `execConst`.
* add wave program and parametrise it to compare inlined/generic version
* use [`tasty-bench`](https://hackage.haskell.org/package/tasty-bench) library to show comparison
* move benchmarks to test folder as they can now share tasty code
* closes#1574
Using the recursive definition with ifs leads to a 3x slowdown:
```
wavesInlined
10: OK
361 ms ± 29 ms
20: OK
718 ms ± 35 ms
30: OK
1.066 s ± 28 ms
40: OK
1.437 s ± 37 ms
wavesWithDef
10: OK
1.052 s ± 51 ms, 2.92x
20: OK
2.117 s ± 34 ms, 2.95x
30: OK
3.144 s ± 80 ms, 2.95x
40: OK
4.191 s ± 91 ms, 2.92x
```
But if we just inline and simplify the code, we can remove the runtime overhead completely.
Closes#1436.
The schema `.json` files are now the authoritative source of truth for documentation.
Wrote a very simple parser for JsonSchema to extract the documentation from JSON.
Split the README.md into [static](c314cc50a1/data/scenarios/README.md) and [auto-generated](c314cc50a1/data/scenarios/doc-fragments/SCHEMA.md) parts.
Added a custom `"footers"` key to schema files to support inclusion of other markdown files for each object description.
# Schema doc regeneration
./scripts/regenerate-schema-docs.sh
In preparation for #1483. `LogEntry` started life as something specific to robot logs. It then evolved to be used in the system log as well (see #1039 and #652), but in a sort of hacky way. This PR refactors `LogEntry` to be more generic.
- Move `Swarm.Game.Log` -> `Swarm.Log` since it's not specific to gameplay.
- Rename `ErrorLevel` to `Severity`, add a new `Info` level, and add a top-level `leSeverity` field
- Rename `leRobotName` to just `leName`, since it was already being used to name both robots and system components anyway
- Move robot-specific fields (*e.g.* robot ID) into the new `RobotLogSource` type, and add `LogSource` to differentiate between robot and system logs
- Various other minor improvements and tweaks
Towards #872
Previously, the `GameState` record had `41` toplevel members. It now has `22`. Logical grouping of the fields makes it easier to peruse the code and paves the way to split `State.hs` into smaller modules. Some functions now may even be able to operate exclusively on subsets of the game state, rather than having to pass in `GameState` as a whole.
There is potential to go even farther, by extracting view-related and robot-related members to their own records, but I figured I'd pursue this refactoring incrementally.
Closes#1428
Since the authoritative validation of scenario files is actually performed by virtue of `swarm` parsing them, this CI job actually exists to ensure the JSON Schema descriptions are accurate. This is important for two purposes:
* Documentation is generated from the JSON Schema files (#1436)
* JSON Schema has integration with VS Code and other IDEs
# Testing
Verified that the schema checker action does indeed work by intentionally pushing an invalid scenario file in f789f81.
* use `Markdown.Document` as `entityDescription`
* add missing spaces in `chunksOf`
* fix code in `entities.yaml` (mostly types and few outdated snippets)
* add code markdown in craft tutorial
* use colours for types and entities
- closes#1408
- closes#1409
Closes#144.
This builds upon portals support (#1356)
# Demo
scripts/play.sh --scenario data/scenarios/Testing/144-subworlds/subworld-mapped-robots.yaml --autoplay --speed 2
[](https://asciinema.org/a/vC13dW8M1S8t2b1J4XkW80U1q)
# Future work
* Augment portal definitions with an optional "relative orientation" attribute, that can turn the player around when passing through the portal (#1379)
* Specify whether portal performs instant transportation or whether `move down` is required (#1368)
towards #1171
## New tests
Unit tests:
scripts/run-tests.sh --test-arguments '--pattern "Relative direction"'
Integration tests for `sniff` and `chirp` demonstrate how to home in on an item using distance and orientation, respectively.
## Efficiency
For the sake of execution time, I have capped the max "diameter" (`N`) of both commands to `200` cells. In the worst case (the entity is not present), `O(N^2)` cells are inspected, which manifests as a perceptible delay when the command is run. I came across the `getElemsInArea` function that seems to suggest that an `O(N * log N)` search may be possible. Is that the case?
Otherwise we may be able to add some new data structures to the game state for efficient entity location querying.
`stack` invocation with `--fast` to work around #1000
Example invocation:
./scripts/play.sh --scenario data/scenarios/Challenges/Ranching/gated-paddock.yaml --autoplay
Closes#936.
With this change, `stack build` should be invoked as normal, but to run tests one should invoke the new script, which will place compilation artifacts in a separate directory so as to not stomp on the previous `stack build` artifacts.
## Demo
```
stack build
./scripts/run-tests.sh
stack build
```
All perform incremental compilation rather than from-scratch.
Restyled.io uses fourmolu version `0.10.1.0`. It is not clear how it could be pegged to `0.4.0.0`. The latest I was able to install on my machine with `cabal install` was `0.9.0.0`.
fixes#888
