Towards #1043.
The eventual goal of this sublibrary split is to have a self contained library that can compose 2D grids of arbitrary content (perhaps colored pixels, or boolean values). This could be useful outside of the `swarm` game.
I would also like to write unit tests for the structure recognizer that are independent of the `Entity` type.
# Major Changes
## Direction module
* Moved `Swarm.Language.Syntax.Direction` to `swarm-util`, since both `swarm-lang` and `swarm-topology` depend on it, but not on each other.
* Removed the re-export of direction things from `Swarm.Language.Syntax`
## Structure module
The `Swarm.Game.Scenario.Topography.Structure` module has been split into two:
* `Swarm.Game.Scenario.Topography.Structure`
* `Swarm.Game.Scenario.Topography.Structure.Type`
The former retains the YAML parsing logic. The latter is agnostic of `Enitiy` type and the palette .
At some future point, I might want to move the YAML parsing to this sublibrary while still retaining independence of `Entity` type.
## Structure recognizer
The structure recognizer is independent of the content of Cells (i.e. it does not need to know what an `Entity` is), except:
1. during initialization
2. when retrieving the original cell content after recognition
Type parameters for three kinds of data have been added to the recognizer:
1. `Cell`/`PCell`
2. `Entity`
3. `EntityName`
Eventually it may be possible to eliminate one or two of these type parameters, with some refactoring.
Adds type synonym declarations to the language, like so:
```
tydef Maybe a = Unit + a end
def lookdown : Cmd (Maybe Text) = scan down end
> lookdown
it2 : Maybe Text = inl ()
```
`tydef` behaves very similarly to `def` except that it defines a new (parameterized) type instead of a new term.
Note that higher-kinded types are not yet supported; for example we cannot say `tydef Foo f = Unit + f Int` (in fact this would be a syntax error since type variables cannot be at the head of an application). However there is nothing stopping us from adding that in the future; I just wanted to keep things simple for now.
If you know of any scenario code that would be a good candidate for using type synonyms, let me know --- it would be nice to update a few scenarios as a better stress test of type synonyms before merging this.
Closes#153.
Fixes#1625.
Before: `path : Unit + Int -> Int * Int + Text -> Cmd (Unit + Dir * Int)`
After: `path : (Unit + Int) -> ((Int * Int) + Text) -> Cmd (Unit + (Dir * Int))`
We essentially consider sum, product, and arrow to all have the same precedence level; but arrows still associate to the right.
We used to represent types with a different constructor for each different sort of type, e.g. there was a constructor `TyFunF` which took two types as arguments, etc. This refactoring creates a new type `TyCon` which has things like `TCFun` and `TCBase` and represents various types as an application of a `TyCon` to some arguments. For example function type `t1 -> t2` would be represented no longer as `TyFunF t1 t2` but instead as `TyConApp TCFun [t1, t2]`.
This is slightly more roundabout, and it does make parsing slightly trickier, but it greatly simplifies and shortens code for e.g. unification, extracting free variables, etc. (because what used to be many essentially identical cases now turn into a single case). It also paves the way for #1865, so we have a way to represent new type constructors defined by the user. E.g. if the user defined `tydef Maybe a = Unit + a` then we would represent the type `Maybe Int` as something like `TyConApp (TCUser "Maybe") [TyBase BInt]`.
This also means that types like `Int Unit` are no longer a parse error, so we need kind checking to rule out applications of type constructors to the wrong number of arguments; this PR adds such kind checking as well. Having some sort of kind checking is unavoidable when allowing the user to define their own new type constructors (with an arbitrary number of arguments).
There were a bunch of fused-effects related utils that lived in a module in `swarm-scenario`; but all of them were completely generic except for the `simpleErrorHandle` function which is specific to `SystemFailure`. So, this PR:
- Moves `simpleErrorHandle` to `Swarm.Game.Failure`
- Moves the rest of the module into the `swarm-util` package so it can be used elsewhere.
This is another refactoring in preparation for #1865.
Closes#1533
# Demo
```
scripts/test/run-tests.sh --test-options '--pattern "sow"'
```
or
```
scripts/play.sh -i data/scenarios/Testing/1533-sow-command.yaml --autoplay
```
## Other changes
* Introduced the `ChildInheritance` type to specify how the `Display` attribute is inherited by built child robots.
* Introduce the `mature` property of `growth`. For example, it doesn't make much sense to plant an `acorn` and call the resulting, fully-grown plant also an `acorn`. Instead, an `acorn` matures into an `oak`.
Closes#1780.
This change allows "child" structures to be placed outside of the bounds of their "parent" map. Until now, any child structures that exceed the bounds of their parent were simply truncated.
# Demo
```
scripts/play.sh -i data/scenarios/Testing/1780-structure-merge-expansion/structure-composition.yaml
```
Closes#1847.
## Demo
### Production
https://swarmgame.net/list-games.html
### Local testing
```
tournament/scripts/demo/server-native.sh
```
and
```
scripts/test/run-tests.sh swarm:test:tournament-host
```
## Authentication flow
1. Users are represented by a GitHub username (primary key) and an "authentication cookie" in the SQLite database.
2. Site prompts user to login when the client's cookie is nonexistent or does not match any user in the database.
3. GitHub flow:
1. Clicking the "Login" link redirects user to the GitHub login page.
2. GitHub sends a `code` to our callback URL.
3. use that `code` to get an "access token"
4. use the "access token" to look up the username of the person who is logging in.
5. generate and store a new cookie in the database row for that username
6. set the cookie value on the user's client.
4. As long as the client keeps sending the cookie value known to the server, all uploads/activity will be attributed to their GitHub username.
## New features
* Login/Logout
* All uploaded content is attributed to an authenticated GitHub user
* Separate pages for scenario lists and solution lists
* Download a solution file
This is a followup on top of #1583 which turns `swarm format` into a tool for porting existing Swarm code into the newest syntax, via an extra `--v0.5` argument. In particular, this PR:
- Generalizes the parser to take a configuration record, which among other things contains the language version being parsed.
- Adds code to allow the parser to parse either the current syntax or one version ago (when types did not start with capital letter) depending on the version in the configuration.
- The idea is to have the parser always support the current version and one older version, so we can always upgrade version n to version n+1.
- Adds a new flag `--v0.5` to the `format` subcommand which causes the input to be parsed in v0.5 mode. However, the output of `format` will always use the latest syntax. Thus, `swarm format --v0.5` reads code in v0.5 format and prints it in the latest format, so this can be used to automatically port existing `.sw` files.
This PR also makes a few minor improvements to pretty-printing.
Closes#1547 , which was caused by misspelled/nonexistent types being interpreted as type variables. In #1550 I proposed one solution to the problem, namely, to stop implicitly quantifying types and require explicit `forall` on any polymorphic type. This PR represents an alternative solution: to keep implicit quantification but require all types to start with an uppercase letter, as in Haskell. I think I like this one better but I'm open to feedback.
Specifically, with this PR:
- All built-in type constructors (`Int`, `Cmd`, `Unit`, etc.) must start with a capital letter
- Type variables:
- Must start with a lowercase letter or underscore
- May not be named a lowercase version of a type constructor, *e.g.* `int`
- This is important so that old code with lowercase types is not silently accepted by parsing the former types as implicitly quantified type variables; even in cases where old code no longer typechecks, this will give better error messages.
- Term variables:
- May start with upper- or lowercase
- May be named lowercase versions of type names, *e.g.* `let f : Int -> Int = \int. int + 1` is fine
This PR obviously represents a bigger breaking change. Once we merge this we might consider adding an option to `swarm format` to be able to parse old code with lowercase types and then reformat it with uppercase, to aid in porting code.
Once this is merged I will also regenerate the wiki pages that mention types.
Closes#1550.
This PR does three main things:
1. Insert parsed comments into the AST
2. Extend pretty-printing to include comments
3. Extend the `format` subcommand with a few additional options and move the code to `Swarm.Language.Format`.
The pretty-printed code-with-comments is OK but not great. It does a reasonable job with comments in standard-ish places; for example, it turns
```
// This function increments a number
def incr : int -> int =
\n. n + 1
end
/* This command does some stuff. It is super
cool and important. */
def stuff : cmd unit =
move;
move;
move; // the third move is important
move;
end
```
into
```
// This function increments a number
def incr: int -> int = \n. n + 1 end;
/* This command does some stuff. It is super
cool and important. */
def stuff: cmd unit =
move;
move;
move // the third move is important
;
move
end
```
which is good other than the fact that it moves the inline comment after `move;` to before the semicolon.
However, it turns this:
```
// This function does a cool math thing
def foo : int -> int = // This is an optional type signature
// pre
\n. n + 1 // add one
end
/* This is a
block comment which
spans multiple lines */
def bar : int -> int // Another type signature, = on the next line
= \x. foo /* very important to use foo here */ (foo x) // very cool implementation
end
def baz : cmd unit =
move;
move;
turn left; // don't forget to turn left!
move
end
// And one last thing
```
into this:
```
// This function does a cool math thing
def foo: int -> int
= \n.
n + 1 // add one
end // This is an optional type signature
;
/* This is a
block comment which
spans multiple lines */
def bar: int -> int
= \x.
foo /* very important to use foo here */ (
foo x // very cool implementation
)
end // Another type signature, = on the next line
```
which has several obvious problems. I think I know what the problem is in most cases; it will just require more engineering and special cases to get the output to look nicer, but I honestly don't really want to spend more time on this right now. I'm hoping we can merge this as is (since it is still better than the status quo, namely, deleting all comments) and continue to improve it in the future.
The important point is that I ran the code formatter on every single `.sw` file in the repository and then re-ran the test suite; all the tests passed. So at least `swarm format` does not seem to break anything even if the output does not look the best.
Closes#1467 .
This is a rework of #1798 to facilitate a simpler web stack.
# Demo
View http://swarmgame.net/
NOTE: Requires IPv6
# Motivation
Hosting cost is a main motivation. Cost per month for an EC2 instance, RDS, and the requisite other services approaches >$50 per month. In contrast, the lowest-tier Lightsail instance is $3.50/month.
The deployment process is of course simplified.
An incidental benefit to using SQLite is reduced latency of web requests; we no longer need to fetch credentials from an AWS API to connect to Postgres.
## Changes
Major changes:
* Use `sqlite` instead of `postgres`
* Use Docker to build a statically-linked deployable binary, rather than deploying the app within a Docker image
Fortunately, the API of `sqlite-simple` is near-identical to that of `postgresql-simple`, so most of the code change there is just to rip out AWS-specific stuff and Postgres connection info. I have no hesitation to delete this code since if we ever want to use the previous stack again, we can just look at #1798.
I noticed the parser was getting kind of unwieldy, and I'm going to be adding even more code to it as part of #1467, so I decided to take the opportunity to refactor first.
This PR introduces no behavior changes, it is purely refactoring.
Towards #1467. This is incomplete but I thought it would be useful to split up the work into multiple PRs to avoid having a really massive one at the end.
This PR accomplishes a few things:
- Creates a new data type `Comment` to record the text of a comment, along with a bit of metadata giving its source location, whether it is a line or block comment, and whether it was on a line by itself or at the end of a line with some other non-comment tokens (this information will be used to decide which AST node to associate the comment with).
- Adds a field to store comments in every `Syntax'` node. Note this is currently unused, since we haven't yet implemented the logic to insert comments into appropriate AST nodes (that will come in a later PR).
- Note it's a bit annoying that the number of fields of each `Syntax'` node is growing. I did look into consolidating and generalizing `Syntax'` to just have a single field for arbitrary annotations, but the changes required seemed annoying enough that I didn't want to bother.
The only reason the `swarm-integration` test had `swarm-tournament` as a dependency was because of a few validation functions in `Swarm.Web.Tournament.Validate`. However, this seemed to me like a strange place for those validation functions to live, since they had nothing to do with running a tournament in particular, and it meant that running the integration tests required having postgresql installed even though no databases are used in the integration tests at all.
This PR moves those validation functions to two more generic places: the first function to extract text from a sequence of log messages now lives in `Swarm.Log`, and the other two functions to check for bad errors and run a `GameState` to completion now live in a new module `Swarm.Game.Step.Validate`.
Also, fix a bug---it didn't work before if an appearance string of length 5 was given.
Closes#1230.
I don't know how to write an automated test for this, but you can see it working by *e.g.*:
- Start a creative game
- Execute e.g. `appear "DNESW" (inr "rock")`
- Observe that the base now looks like a rock-colored `N`
- Now do some `turn` commands (including `turn down`) and observe the appearance changing to e.g. `S` when facing south
Towards #1797
Hosts an online repository of scenarios, against which solutions may be submitted. This is the foundational layer that may support more structured "tournaments", scenario ranking, or other social activity.
# Demo
## Live server
http://swarmgame.net/list-games.html
One can use the [`submit.sh`](https://github.com/swarm-game/swarm/pull/1798/files#diff-450877e3442a0ec1c5cbe964808a263d67f1e680d3aa3c3bf9ae6f51eca682fb) script and see valid uploads reflected live on the website.
## Local testing
### Automated tests
These are database-agnostic.
scripts/run-tests.sh swarm:test:tournament-host
### Manual tests
These test database interactions. It requires first setting up a local Postgres server.
1. Start `tournament/scripts/demo/server-native.sh` in one console
2. Run `tournament/scripts/demo/client/test-cases/local/good-submit.sh` in another
# Features
* Upload and validates scenarios
* Download scenarios with solution redacted
* Submit, validate, execute, and score solutions
# Key components
* Servant server
* Hosted on AWS in a Docker container
* Stores to a Postgres database in Amazon RDS
* Shares some code with the integration tests for evaluating scenarios and solutions
The production database uses IAM to manage logins. The web app uses the AWS API to fetch a "token" which can be used to log in instead of a password. This avoids having to store a password on the server.
# TODO
- [ ] User authentication (GitHub OpenID?)
Closes#1684Closes#1262
# Demo
A simple "puzzle" that makes use of consumables:
scripts/play.sh -i data/scenarios/Testing/1777-capability-cost.yaml --autoplay
Demo of enabled commands and costs display in left pane:
scripts/play.sh -i data/scenarios/Testing/1262-display-device-commands.yaml
# In this PR
* Supports specifying capabilities both as plain lists and as maps from capabilities to ingredients in YAML
* JSON Schema support for both capability specification styles
* New integration test
* Removed redundant `tshow` implementation from `Swarm.Doc.Util`
# Entity lookup approaches
The cost of exercising a capability in terms of "ingredients" is specified by the `_entityCapabilities` field within an `Entity` definition. Each ingredient itself is an entity, specified by name.
For many purposes, having ingredients just of type `EntityName` is sufficient. But for `Swarm.Game.Recipe.findLacking` in particular, the ingredients list must be actual `Entity` objects, not just names of entities. So at some point the names need to be looked up in the global entity map to be promoted to `Entity` objects.
The full list of entities is not available at `Entity` parse time to look up an ingredient entity by name, so we cannot store ingredients lists of type `(Count, Entity)` within a parent `Entity` object.
Approaches considered were:
* Store a copy of the `entityMap` in `RobotR`, for use by the `equippedDevices` lens
* Introduce a type parameter to `Entity` representing a "parse phase"
* **Allow a redundant "entity lookup" (and validation) at command execution time**
## Store `entityMap` in `RobotR`
One approach explored was to add a field to `RobotR`:
```
, _globalEntityMap :: EntityMap
```
This allowed the `equippedDevices` lens implementation to promote the `EntityName`s to `Entity`s when setting the value of the `_robotCapabilities` field. However, it was rather invasive as it entailed threading the `EntityMap` through many new code paths.
## `Entity` type parameter
Currently, `Entity` has a field:
```
_entityCapabilities :: SingleEntityCapabilities EntityName
```
This would entail a huge refactoring, with:
```
data Entity e = Entity
...
, _entityCapabilities :: SingleEntityCapabilities e
```
At initial parse time we would obtain a list of `Entity EntityName`, but somewhere later during `Scenario` parse time, we can do another pass to obtain `Entity Entity` objects.
This would at least have the advantage of doing the entity lookup/validation on ingredient lists in exactly one place, at parse time.
## Defer `EntityName -> Entity` promotion to command execution time
This is what is implemented in this PR. The global set of capability costs is validated at scenario parse time. But it is also redundantly validated in the `payExerciseCost` function, which is not ideal.
This is a random refactoring that does two things:
* Improves speed of `scripts/gen/render-sublibrary-dependencies.sh` script
* Refine imports of the `TestModel.hs` (renamed to `TestRepl.hs`) unit test
It appears that the only reason that the `swarm-unit` test suite imports the entire `swarm` sublibrary (hence the `brick` package), is due to `TestRepl`, which (now) imports `Swarm.TUI.Model.Repl`. Perhaps it would make sense to separate these at some point?
Prerequisite to #1798
## Changes
* Pass the final `TickNumber` count as a member of `Won` constructor so that it can be used in scoring submitted solutions
* Extract a helper function `codeMetricsFromSyntax` that can be reused by tournament server
* `ToJSON` instance for `ScenarioMetadata`
* New script `list-sublibraries.sh` to list the sublibraries defined in a package
Towards #1797
Combines `TerrainEntityMaps` and `WorldMap` into a single record, `ScenarioInputs`.
Establishes a Matroska-style arrangement of records to represent various scopes of state, eliminating several redundant fields.
Fixes#1598
## Demo
Illustrates immediate (same-tick) reaction to a change of a `watch`ed cell:
scripts/play.sh -i data/scenarios/Testing/1598-detect-entity-change.yaml --autoplay --speed 1
## Background
Robots can be **scheduled** to wakeup from a `watch` by the `wakeWatchingRobots` function.
Robots may be **actually awakened** by the `wakeUpRobotsDoneSleeping` function.
Previously, `wakeWatchingRobots` would only ever schedule wakeups at `currentTick + 1`. Then, once the next tick is reached, in `wakeUpRobotsDoneSleeping` only robots that had been scheduled to wake on precisely the **current tick** could actually be awakened.
But this made it impossible for one robot to cause another robot, which had been sleeping, to actually wake up within the same tick that scheduling of the wakeup is performed.
The importance of this comes into play for system robots that are `watch`ing a cell and intended to react instantaneously to player actions (usually by running code in an `instant` block).
During each "tick", every active robot gets exactly one "turn" to execute code. Given the following ID assignments:
| Robot ID | Robot name |
| --- | --- |
| `0` | `base` |
| `1` | `systemBot` |
the `systemBot` will always execute *after* the `base` robot in a given tick.
If the `systemBot` is `watch`ing a given cell, a modification of that cell by the `base` will schedule a wakeup of the `systemBot`. If the scheduled wakeup tick is `currentTick + 1`, then the `base` will have **another execution turn** before the `systemBot` gets an opportunity to react to the `base`'s action at the current tick, causing the `systemBot` to overlook actions that may be relevant to a goal condition.
## Solution
In contast, if we schedule the `systemBot` wakeup for `currentTick` instead of `currentTick + 1`, then it should have an opportunity to wake, run, and react to the `base`'s action before the `base`'s next turn.
But in the status quo, the selection of which robots to run in a given tick is made only once, before iteration over those robots begins. We need instead to update the robots-to-run pool dynamically, after each iteration on an individual robot. The most appropriate data structure for the iteration pool is probably a [Monotone priority queue](https://en.wikipedia.org/wiki/Monotone_priority_queue), but we approximate this with an `IntSet` of `RID`s and the [`minView`](https://hackage.haskell.org/package/containers-0.7/docs/Data-IntSet.html#v:minView) function.
Being able to alter the list of active robots in the middle of a given tick's robot iteration has required a change to the `runRobotIDs` function. Instead of using a `forM_` to iterate over a static list of `RIDs`, we have a custom iteration function `iterateRobots` to handle the dynamic set.
## Performance
Benchmarks were performed locally with `stack` and GHC 9.6.
I had tested the replacement of the `forM_` loop with `iterateRobots` in isolation, and it had zero effect on benchmarks. But some other trivial changes tested in isolation, such as the addition of docstrings, yielded a +6% increase in benchmarks. So there seems to be some instability in the ability of the compiler to perform certain optimizations.
With this PR, increases in benchmark times ranging from 7% to 11% were observed. The obvious culprit is that `wakeUpRobotsDoneSleeping` is now called N times per tick, rather than once per tick, where N is the number of robots that are initially (or become) active during that tick.
### Mitigating with an "awakened" set
In the common case (i.e. when there are *no* watching robots), the `wakeUpRobotsDoneSleeping` that is now executed `N` times per tick (instead of once per tick) incurs a `Map` lookup, which is `O(log M)` in the number of distinct future wakeup times across all robots.
However, those extra `N` invocations only exist to serve the purpose of `watch`ing robots that may need to wake up at the current tick. It may be more efficient to have a dedicated `Set` in the `GameState` for such robots that gets populated parallel to this insertion:
ad5c58917e/src/swarm-engine/Swarm/Game/State/Robot.hs (L387)
Then if this set remains `null`, we can avoid paying for an additional `O(N * log M)` operations entailed by the `Map` lookups into `internalWaitingRobots`.
#### Result
Indeed, storing awakened bots in a new `currentTickWakeableBots` set restored the benchmarks nearly to the baseline. Instead of the regressions in the 10-20% range observed before, now only a few benchmarks had at most 3-4% increases.
### CI regressions
In CI, (`snake`, `powerset`, and `word-search`) exceeded their timeout thresholds in GHC 9.2 and GHC 9.4. No regressions were observed with GHC 9.6. To accommodate the lowest common denominator, I bumped the thresholds for those three scenarios to get a passing build.
I don't believe it is worth further effort or investigation to optimize for GHC 9.4, since such efforts will be moot for GHC 9.6 and onward.
Test invocation:
cabal test swarm-integration --test-show-details streaming --test-options '--color always --pattern "word-search"'
| **Scenario** | GHC 9.4.8 | GHC 9.4.8 | GHC 9.6.4 | GHC 9.6.4 |
| --- | --- | --- | --- | --- |
| | Before | **After** | Before | **After**
| `snake` | 1.84s | **5.38s** | 1.62s | **1.67s** |
| `powerset` | 1.66s | **5.09s** | 1.56s | **1.66s** |
| `word-search` | 0.56s | **1.91s** | 0.44s | **0.48s** |
### Potential improvements
#### `TickNumber` as `Map` key
`waitingRobots` is of type `Map TickNumber [RID]`. Instead of `Map`, we could have a `newtype` that encapsulates a `IntMap` to make lookups by `TickNumber` more efficient.
A walkability "blacklist" had already been implemented in #1536. The whitelist shall **only** permit walking on the specified entities; blank cells become unwalkable.
This feature would allow use of the `path` command to check for "connectivity" by way of a "trail" of entities.
## Use cases
* system robots or goal conditions can use this to check whether the player has connected two points with a road, cable, aqueduct, etc.
* monkeys, which can only move along `tree`s
* sea life, which should only be able to move in `water`
## Testing
scripts/run-tests.sh --test-arguments '--pattern "walkable-entities"'
Closes#1641
The `data/terrain.yaml` file is now the authoritative source of terrains, though `BlankT` is still a hard-coded special case.
I have not changed the underlying integer representation of terrain in the world function, which means that the `terrainIndexByName` Map in the `TerrainMap` record is needed for translating between `Int` and `TerrainType`.
# Demo
scripts/play.sh -i data/scenarios/Testing/1775-custom-terrain.yaml
# Changes
* There used to be a function called `integrateScenarioEntities` that combined the `EntityMap` stored in the `Scenario` record with the global entity map. However, the global entity map is accessible at parse time of the `Scenario`, so we do the combining there and only ever store the combined map in the `Scenario` record.
* JSON Schema for terrain
* Removed the distinction between "World" attributes and "Terrain" attributes
* Unit tests for scenario-defined terrain and related validations
* Validate existence of referenced terrain at scenario parse time
* Validate attributes referenced by terrains at parse time
scripts/play.sh -i data/scenarios/Challenges/gallery.yaml --autoplay
## Code changes
In addition to the new scenario, this PR includes a code change to allow the order of items returned by the `tagmembers` to be specified by the scenario author.
In support of #1598 (for #1739).
Runs the `idle` benchmark for many more ticks and with many more robots to try to emphasize the effect of regressions and mitigate jitter.
Also factors out common code from the `benchmark-against-parent.sh` script.
Closes#1715
Extract scene renderer to its own binary with `swarm-scenario` as its only dependency.
This was mainly enabled by moving the `Landscape` sub-record out of the `swarm-engine` sublibrary and into `swarm-scenario`, and refactoring rendering functions to only depend on `Landscape` rather than the entire `GameState`.
# Demo
stack build --fast swarm:swarm-scene && stack exec swarm-scene -- data/scenarios/Fun/horton.yaml --png -w 180 -h 150
Measures the volume of an enclosed space.
A useful alternative to the `path` command for goal checking.
## Demo
scripts/play.sh -i data/scenarios/Testing/1747-volume-command.yaml --autoplay --speed 2
Closes#1741
Remaining blocker was to move logging to concrete robot.
Most notably, the `swarm-scenario` sublibrary has been purged of its temporal component, corroborated by the removal of the `time` package dependency.
Towards #1715 and #1043
Creates a new `swarm-scenario` sublibrary intended for scenario data that is independent of game state.
# Planned follow-ups
This PR is already pretty large, but there is still more that can be done regarding sublibrary reorganization/splitting.
* May want to pare-down a sublibrary exclusively for world-generation without all the other baggage of scenarios.
* `Swarm.Game.ScenarioInfo`, `Swarm.Game.Tick`, and `Swarm.Game.Scenario.Status` could probably be moved from `swarm-scenario` to `swarm-engine`.
Continuation of #1731.
Towards #1715 and #1043.
This refactoring step is a prerequisite for #1719 to extricate references to the `CESK` module from the base `RobotR` definition.
# In this PR:
* Extracts the `RobotContext` type to a new module
* Introduces a type family for the `RobotContext` field
# Motivation
Want to remove dependence of `TRobot` on the `RobotContext` record. However, a lens `trobotContext` had been added in #817 to fix#394.
# Test
scripts/run-tests.sh --test-arguments '--pattern "394-build-drill"'
Towards #1715 and #1043.
This refactoring step is a prerequisite for #1719 to extricate references to the `CESK` module from the base `RobotR` definition.
In this PR:
* `Swarm.Game.CESK` is imported qualified to more easily track usages
* A new `RobotMachine` type family is added to parameterize the `_machine` field.
* `CESK` is a new parameter to `addTRobot`
Closes#1644.
The `"recognize"` property in scenario `.yaml` files is changed from a boolean to a list of "up" directions.
The structure recognizer adds a rotated copy of each supported orientation to its automaton. Rotational symmetry is accounted for to avoid duplicate work in the recognizer.
Also in this PR:
* Add cardinal directions to the JSON schema
* Tetromino packing challenge scenario
## Demos
scripts/run-tests.sh --test-arguments '--pattern "1644-rotated"'
### Structures dialog
### Tetromino packing
scripts/play.sh -i data/scenarios/Challenges/pack-tetrominoes.yaml --autoplay
Closes#1443.
Also added `-Wunused-packages` to clean up dependencies.
## Demo
This still works as usual:
stack run
Output editor keywords:
stack run swarm-docs -- editors --emacs
This is a continuation of #1652.
Most of the sub-records are bundled into `Swarm.Game.State.Substate`, but we create a `Swarm.Game.State.Robot` module just for robots.
We introduce a `zoomRobots` function so that applicable functions can operate directly on `Robots` state instead of `GameState`.
## Size comparison
### Before
| File | Lines |
| --- | --- |
| `State.hs` | 1569 |
### After
| File | Lines |
| --- | --- |
| `State.hs` | 812 |
| `Substate.hs` | 497 |
| `Robot.hs` | 395 |
| `Config.hs` | 21 |
## For follow-up PR:
- [ ] Remove exports of `_viewCenter` and `_focusedRobotID` from `Swarm.Game.State.Robot`
