- Sand is now found near water. Sand regenerates immediately (like water).
- Sand can be used in a furnace to make glass.
- Glass + copper wires + 3D printer can be used to make solar panels.
- Note that with #361 I intend to start the base with a small number of 3D printers, so other robots could carry this out. But also, the base will start with a bunch of solar panels too.
- Solar panel + counter can be used to make a calculator.
* add robotNamed : string -> cmd robot
* add chess knight challenge
In challenges, it's impossible to access the robot
by its assigned number. We do however name it.
Seems reasonable to add a way to get robot by its name.
* Fix doctests
* Regenerate haskell-ci with config
- use latest haskell-ci
- configure haskell-ci to use doctest
* Update tested with compiler
- update cabal tested-with field
- update .mergify.yaml to new compiler
- restore note about mergify in haskell-ci
Generalize challenges + various modes to all be "scenarios" which are described by `.yaml` files in `data/scenarios`.
- Both challenges and classic/creative modes are now subsumed under the more general notion of "scenarios".
- A scenario describes how to set up the world etc. when starting a game; all scenarios are stored in a `.yaml` file in `data/scenarios`.
- "New game" menu item now lets the user choose a scenario.
- Some small improvements to the way seeds are handled.
See #296. This will enable #35 and #25 .
Hitting `Enter` on an inventory item pops up a dialog box with its description. For items with longer descriptions this is a convenient way to be able to see the whole description without having to scroll the info box in the lower left.
`Enter` used to try to `make` the focused item; that is now accomplished with `m`.
Lots of refining, adding more menu options, etc. that still needs to happen, but this adds a basic menu. Quitting a game now quits to the menu rather than quitting the entire application.
I initially thought this would be tricky, but it's not: all we need to
do is reprogram the salvaged robot to give the salvaging robot one
item at a time.
Closes#202.
Closes#77 . When hitting Ctrl-Q, now a dialog box opens up allowing you to confirm you want to quit or cancel. The machinery for dealing with pop-up windows is somewhat generalized as well, which should make it easy to add other similar pop-up windows as needed in the future.
It is now impossible to destroy `base`. In `Step.hs` we now always check whether the current robot is `base` (by checking whether its `robotID` is 0) before the `selfDestruct` flag is set. If it is `base` a `CmdFailed` exception is thrown instead.
This resolves#297 .
Fixes#82.
Right now it only works in classic mode. It wouldn't be too hard to
make it work with challenge mode as well, but that would require some
more careful thinking about whether every challenge is required to
have a 'base' and how we identify which robot that is, so that we run
the given file on the right robot.
See the discussion at
https://github.com/byorgey/swarm/pull/303#discussion_r817471340 .
This seems like an unqualified success: no more hacky (-1)'s, and
doing the refactoring actually uncovered a bug! Previously, we were
not actually assigning ID's to the robots that were read as part of a
challenge. This means that in a challenge with multiple robots, all
but one of them would instantly disappear since they all shared the
same ID number.
The basic idea of this change is to create a new `robot` type and use it to identify robots instead of `string` names. Internally, a `robot` value is just a (unique) `Int`.
Closes#212 .
This ended up turning into a sort of constellation of related changes.
- Add the `robot` type and change the type of various built-in functions which used to take a robot name so they now take a `robot` (`give`, `install`, `reprogram`, `view`, `upload`) and change `build` so it returns a `robot`.
- All internal data structures that store robots are now keyed by a unique (`Int`) robot ID rather than by name.
- Add a `setname` command for setting a robot's display name (which no longer needs to uniquely identify a robot).
- Import a big list of words which we can use to randomly pick names for robots, just for fun. This is why the diff says "+31,050 -265"; I did not write 31 thousand lines of code.
- Add constants `base`, `parent`, and `self` for getting a `robot` value referring to the base, one's parent, and one's self, respectively.
- Top-level binders like `r <- build {move}` now export a variable binding which can be used in later expressions entered at the REPL; additionally, unlike Haskell, a binder can now appear as the last statement in a block.
- Fix the pretty-printer for `Value` by doubling down on our current strategy of injecting `Value`s back into `Term`s and then pretty-printing the result. I am now convinced this is the Right Way (tm) to do this; it only required adding a couple additional kinds of `Term` which represent internal results of evaluation and cannot show up in the surface language (`TRef`, `TRobot`).
- Update the tutorial.
- While updating the tutorial, I noticed that #294 had introduced a bug, where the inventory display no longer updated when 0 copies of an entity are added to the inventory (as with `scan` + `upload`), so I fixed that by changing the way inventory hashes are computed.
I tried running the benchmarks both before & after this change. I was hoping that it might speed things up to be using `IntMap` and `IntSet` instead of looking things up by `Text` keys in a `Map` all the time. However, if I'm interpreting the results correctly, it seems like it didn't really make all that much difference, at least for the particular benchmarks we have.
The hash for an inventory is now the sum of the hashes of its contents. As discussed in #229 , the point of this is that inventory hashes can now be maintained incrementally, which could be a big win if there are robots with big inventories. It is less "secure" but we don't really care about that.
Closes#229.
Tuples are now parsed as parens containing terms separated by commas,
instead of just treating the comma as a binary infix operator. This
fixes#225 --- we now properly parse tuples containing lambdas.
Tuples bigger than pairs are treated as syntax sugar for right-nested
pairs, e.g. (1,2,3) is (1,(2,3)) (and also pretty-prints as the former).
Closes#241 .
This PR implements two changes:
- The error message window uses as much horizontal space as necessary now, wrapping lines when no further horizontal expansion is possible.
- The parser groups "built-in user functions" and "direction constants" under labels of the same names. This leads to more concise parse error messages.
- The user can now enter only whitespace (including comments) at the
REPL.
- A new file which is blank / only comments is no longer invalid from
the perspective of LSP.
Closes#275.
