It was possible to get a runtime failure on the following before:
```
Right gs <- runExceptT $ initGameStateForScenario p Nothing Nothing
```
Should probably also turn on compiler warnings for incomplete matching.
Such subdirectories can be used to e.g. organize `.sw` files, and will be ignored when recursively loading scenarios.
This resolves an issue we noticed while reviewing #835, which uses a subdirectory to hold multiple `.sw` files for a scenario and was generating a lot of spurious warnings.
This PR consists of two commits:
1. Refactor list of capabilities to sets (continuation of #794)
2. Instead of hard-coding drill names, select equipped entities by their `drill` capability
This allows scenario authors to define their own drills.
Closes#540.
When we typecheck and capability check a new term, resulting in a `ProcessedTerm`, we already know the `Requirement`s for all the `def`s it contains. This PR simply takes all those definition requirements and adds them to `robotContext . defReqs` just before installing the new `ProcessedTerm` in the CESK machine, so that if we ever encounter the name of any of the definitions inside an argument to `build` or `reprogram`---which we capability check at runtime---we will be able to properly match up names with their requirements.
This is a hack for several reasons:
- We really shouldn't be capability-checking arguments to `build` and `reprogram` at runtime in the first place---ideally we should be able to check everything statically. But fixing that will require implementing #231 .
- We have to do this in three places in the code: when loading a new term into the base when the player hits Enter at the REPL; when executing `run`; and when running the solution from a scenario in the integration tests. Ideally, there would be only one place, but I don't have a good idea at the moment how to refactor things properly.
- Technically, the names being defined shouldn't be in scope until after their corresponding `def` runs, so it's incorrect to dump them all into the `defReqs` prior to executing any of the `def`s.
- However, doing it properly, with each name coming into scope with its requirements right after the `def` runs, is very tricky/annoying to implement for more reasons than I care to write about here (believe me, I tried, and it made my brain hurt). For starters, we don't really have access to the robot state when stepping the CESK machine.
- The only scenario where this would be a problem is if (1) there is already a name `x` defined, and then we (2) `run` a `.sw` file containing, first, a `build` command whose argument references `x`, and second, a redefinition of `x`. In that case the `build` would incorrectly decide that the `x` in the argument to `build` has the requirements of the *second* `x` (the one that will be redefined later) even though the first `x` is the one that should still be in scope. However, this seems like a very unlikely scenario (who would write a `.sw` file that depends on some specific name already being defined before it is run, but then redefines that same name later?) and I'd *much* rather have that obscure problem than the current very relevant and annoying one.
However, it's a simple hack that solves the issue and will be easy to get rid of later if and when we do something better. I'm a big believer in doing things the right way, but in this instance I definitely think we should just do the simple thing that mostly works and then continue to make it better in the future.
This makes it possible to dump the commands typed into the REPL to a text file, which makes it easier to start writing an external `.sw` script based on experiments written in the REPL.
E.g.
curl http://localhost:5357/repl/history/full | jq .[] -r
This is related to (and may be a stepping stone towards) #625.
Currently there's no (obvious?) shortcut to clear the currently typed text in the REPL.
Mapping CTRL+c to this action would be familiar to terminal users.
When none of the robot definitions are assigned explicit coordinates (i.e. all of the robots are specified via the map and palette), this allows scenario authors to determine the "base" robot via the order of definitions as they exist in the scenario file.
A comment detailing the base selection logic has also been added.
closes#790
When the inventory pane is selected (Alt+e), one can use the `;` and `:` keys to cycle sort criteria and sort direction, respectively.
This functionality is implemented in a new module to avoid exacerbating #707.
Note that `entityProperties` may be an unreliable criteria to sort, because it is a list that itself may contain duplicates or items in unpredictable order. Perhaps this field should be made a `Set` (#794).
This PR introduces an `--autoplay` flag that causes the solution stored in the `solutions` field of a scenario file (which was selected on the command line via the `--scenario` option) to be automatically run when the game starts, identically to the `--run` option.
The purpose is to:
1. more easily showcase scenarios to the community
2. facilitate a quick a sanity check that the solution text in the yaml file is correct
# Test procedure
stack run -- --scenario data/scenarios/Tutorials/conditionals.yaml --autoplay
This has the same effect as manually copying the solution stored in `conditionals.yaml` to `myfile.sw`, and then running:
stack run -- --scenario data/scenarios/Tutorials/conditionals.yaml --run myfile.sw
<a href="https://asciinema.org/a/mGB5VDKhsLLPdrItZWi3qsHUV" target="_blank"><img src="https://asciinema.org/a/mGB5VDKhsLLPdrItZWi3qsHUV.svg" width="640" /></a>
This is a pretty simple change --- we've already covered lambdas previously in the tutorial so it's annoying not to be able to use them to define things like `x4 = \c. c;c;c;c end`. But just wanted to make sure there's nothing I'm missing here.
Closes#764.
- Hint now says `[Ret] pop out` instead of `[Ret] focus`.
- `pop out` is now highlighted whenever the info panel can scroll.
- Add hints to the tutorial about popping out or scrolling entity descriptions.
- All panel-specific keys are now highlighted the same color as the focused panel.
- Added a panel-specific key hint for `f` on the World panel toggling FPS info.
Part of #549
Before this change, if the Classic scenario was started:
```
stack run -- --scenario data/scenarios/classic.yaml
```
and then "Start over" is selected from the Quit dialog, a new seed was generated.
Now, the previous seed is re-used.
Closes#757 . As discussed there:
- Default direction for robots whose parents have no direction is now `north`
- Fix the `scan` tutorial `base` to be facing north
- Clarify the text in the `build` tutorial to state that newly built robots face the same direction as their parent, which in the tutorial will always be north.
- Help modal now says "quit the current scenario" instead of "quit game" for Ctrl-q
- If you select "Keep playing" after completing a challenge scenario, it will now pop up a modal advising you to hit Ctrl-q whenever you're ready to move on.
- Added a note at the beginning of the tutorial reassuring that your progress will be saved and you can pick up where you left off from the menu.
- Improved quit dialog in a couple ways:
- Now warns that "your progress *on the current scenario* will be lost" (to emphasize that e.g. your progress on the entire tutorial won't be lost).
- Now says "quit to XXX menu" where XXX is the specific menu you will return to.
Closes#595. Closes#759.
- Never clear the `uiWorldCursor`.
- In practice it seemed annoying and glitchy to understand when it would or wouldn't clear. After clicking somewhere on the map to see the coordinates I was always afraid I was going to do the wrong thing and cause the cursor display to clear before I could make use of it.
- Pass on mouse clicks to the REPL input form
- This means you can click in the middle of the input to move the cursor
- Closes#470.
It is probably safer to have Template Haskell GitInfo in Main and not depend on it in Swarm modules.
Depending on how the build system and TH interact we were either recompiling too often or not often enough.
- if the git info was evaluated once and not again after making a commit, then it was not up to date
- if the git info was reevaluated on every commit then we would needlessly recompile dependent modules
I believe it was only the former, but this helps even in that case (any code change recompiles Main).
