swarm-game/swarm
1
1
Fork 0
mirror of https://github.com/swarm-game/swarm.git synced 2024-09-11 22:58:21 +03:00
Code Issues Projects Releases Wiki Activity
ca4a2b809d
swarm/swarm.cabal

965 lines
24 KiB
Plaintext
Raw Normal View History

autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
cabal-version: 3.8
name: swarm
version: 0.5.0.0
synopsis: 2D resource gathering game with programmable robots
description:
Swarm is a 2D programming and resource gathering
game. Program your robots to explore the world and
collect resources, which in turn allows you to
build upgraded robots that can run more
interesting and complex programs. See the
<https://github.com/swarm-game/swarm/blob/main/README.md README>
for more information and instructions on how to
play or contribute!
== Module organization
For developers getting oriented, Swarm's modules are organized into
Update sublibrary graph generation script & cabal description (#1849) As a follow-up to #1834: - Update the sublibrary graph generation script so it works with the no-longer-linear graph - Regenerate the actual image - Update the `.cabal` description to match
2024-05-13 20:25:00 +03:00
sublibraries. Roughly in order from inner to outer, they are:
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
Update sublibrary graph generation script & cabal description (#1849) As a follow-up to #1834: - Update the sublibrary graph generation script so it works with the no-longer-linear graph - Regenerate the actual image - Update the `.cabal` description to match
2024-05-13 20:25:00 +03:00
* swarm-util: miscellaneous utilities
* swarm-lang: parsing, typechecking, etc. for the Swarm language
* swarm-scenario: scenario descriptions, parsing, & processing
* swarm-engine: game simulation
* swarm-doc: generating documentation
* swarm-tui: textual user interface
* swarm-web: web interface
* swarm: the swarm executable
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
<<docs/image/sublibrary-graph.svg>>
Update sublibrary graph generation script & cabal description (#1849) As a follow-up to #1834: - Update the sublibrary graph generation script so it works with the no-longer-linear graph - Regenerate the actual image - Update the `.cabal` description to match
2024-05-13 20:25:00 +03:00
See the [Swarm module guide](https://github.com/swarm-game/swarm/wiki/Module-guide)
for a more in-depth guide to the codebase.
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
license: BSD-3-Clause
license-file: LICENSE
author: Brent Yorgey
maintainer: byorgey@gmail.com
bug-reports: https://github.com/swarm-game/swarm/issues
copyright: Brent Yorgey 2021
category: Game
Support GHC 9.8, bump upper bounds, and update CI (#1828) Make sure Swarm builds with the most recent versions of dependencies. The only one that is still lagging is `filepath`, but `servant` doesn't support `filepath-1.5` so Swarm can't either. The only real update needed was due to some breaking changes in `aeson-2.2`, but the necessary changes were very minor. Also fixed a few places where GHC 9.8 is generating additional warnings. Also update our CI: `haskell-ci` recently dropped support for `hlint`, in favor of projects defining their own standalone `hlint` workflows.
2024-05-10 22:43:41 +03:00
tested-with: ghc ==9.2.8 || ==9.4.8 || ==9.6.5 || ==9.8.2
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
extra-source-files:
CHANGELOG.md
editors/emacs/*.el
editors/vim/*.lua
editors/vim/*.vim
editors/vscode/syntaxes/*.json
example/*.sw
extra-doc-files: docs/image/sublibrary-graph.svg
data-dir: data/
data-files:
*.txt
*.yaml
scenarios/**/*.sw
scenarios/**/*.txt
scenarios/**/*.yaml
test/language-snippets/**/*.sw
worlds/*.world
initial exploration
2021-08-22 02:18:07 +03:00
clean up .cabal file and add LICENSE
2021-08-27 05:05:46 +03:00
source-repository head
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
type: git
location: git://github.com/swarm-game/swarm.git
clean up .cabal file and add LICENSE
2021-08-27 05:05:46 +03:00
Add ghc-options and ci flags to prevent compilation warnings
2021-09-25 16:47:49 +03:00
flag ci
description: Make warnings error
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
default: False
manual: True
Add ghc-options and ci flags to prevent compilation warnings
2021-09-25 16:47:49 +03:00
common common
if flag(ci)
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
ghc-options: -Werror
ghc-options:
-Wall
-Wcompat
-Widentities
-Wincomplete-uni-patterns
-Wincomplete-record-updates
-Wno-star-is-type
-Wpartial-fields
Add ghc-options and ci flags to prevent compilation warnings
2021-09-25 16:47:49 +03:00
default-language: Haskell2010
generate HIE files for stan
2021-09-04 17:20:42 +03:00
common stan-config
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
ghc-options:
-fwrite-ide-info
-hiedir=.hie
generate HIE files for stan
2021-09-04 17:20:42 +03:00
Make GHC2021 extensions default (#520) - closes #419
2022-07-01 12:07:41 +03:00
-- Harmless extensions from GHC2021
common ghc2021-extensions
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
ghc-options:
-Wprepositive-qualified-module
-Wunused-packages
default-extensions:
-- Note we warn on prequalified
-- Not GHC2021, but until we get \cases we use \case a lot
Replace `unification-fd` with a custom implementation of unification (#1802) Closes #1661; towards #154. `unification-fd` is very powerful, and extremely fast, but it was written a long time ago and its age shows. It was not possible to incorporate it into our effects system in a nice way, necessitating the use of concrete monad transformers in the typechecking code. In addition it is impossible to customize, and we have been contemplating new type system features such as #153 and #154 that turn out to require hooking into the way the unification algorithm works (see https://github.com/swarm-game/swarm/issues/154#issuecomment-1822877487 for more details). This PR thus removes the dependency on `unification-fd` and implements our own version of unification. It is not quite as fast as `unification-fd` but I consider the slowdown acceptable in order to gain e.g. recursive types. And of course there is also room to optimize it. The custom `UTerm` from `unification-fd` is replaced with the standard `Free` (free monad) construction from the `free` package, and the custom `Fix` from `unification-fd` is replaced with the one from `data-fix`. We also get rid of the `unifyCheck` function, which used to be a quick short-circuiting way to check whether two types definitely did not unify or might unify, allowing us to give better error messages more quickly. Now, the `=:=` unification operator itself just does this.
2024-04-28 00:52:31 +03:00
BangPatterns
DeriveAnyClass
DeriveDataTypeable
DeriveFunctor
DeriveGeneric
DeriveTraversable
ExplicitForAll
FlexibleContexts
FlexibleInstances
GADTSyntax
ImportQualifiedPost
LambdaCase
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
MultiParamTypeClasses
Replace `unification-fd` with a custom implementation of unification (#1802) Closes #1661; towards #154. `unification-fd` is very powerful, and extremely fast, but it was written a long time ago and its age shows. It was not possible to incorporate it into our effects system in a nice way, necessitating the use of concrete monad transformers in the typechecking code. In addition it is impossible to customize, and we have been contemplating new type system features such as #153 and #154 that turn out to require hooking into the way the unification algorithm works (see https://github.com/swarm-game/swarm/issues/154#issuecomment-1822877487 for more details). This PR thus removes the dependency on `unification-fd` and implements our own version of unification. It is not quite as fast as `unification-fd` but I consider the slowdown acceptable in order to gain e.g. recursive types. And of course there is also room to optimize it. The custom `UTerm` from `unification-fd` is replaced with the standard `Free` (free monad) construction from the `free` package, and the custom `Fix` from `unification-fd` is replaced with the one from `data-fix`. We also get rid of the `unifyCheck` function, which used to be a quick short-circuiting way to check whether two types definitely did not unify or might unify, allowing us to give better error messages more quickly. Now, the `=:=` unification operator itself just does this.
2024-04-28 00:52:31 +03:00
NumericUnderscores
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
RankNTypes
ScopedTypeVariables
StandaloneDeriving
TupleSections
TypeApplications
Replace `unification-fd` with a custom implementation of unification (#1802) Closes #1661; towards #154. `unification-fd` is very powerful, and extremely fast, but it was written a long time ago and its age shows. It was not possible to incorporate it into our effects system in a nice way, necessitating the use of concrete monad transformers in the typechecking code. In addition it is impossible to customize, and we have been contemplating new type system features such as #153 and #154 that turn out to require hooking into the way the unification algorithm works (see https://github.com/swarm-game/swarm/issues/154#issuecomment-1822877487 for more details). This PR thus removes the dependency on `unification-fd` and implements our own version of unification. It is not quite as fast as `unification-fd` but I consider the slowdown acceptable in order to gain e.g. recursive types. And of course there is also room to optimize it. The custom `UTerm` from `unification-fd` is replaced with the standard `Free` (free monad) construction from the `free` package, and the custom `Fix` from `unification-fd` is replaced with the one from `data-fix`. We also get rid of the `unifyCheck` function, which used to be a quick short-circuiting way to check whether two types definitely did not unify or might unify, allowing us to give better error messages more quickly. Now, the `=:=` unification operator itself just does this.
2024-04-28 00:52:31 +03:00
TypeOperators
Make GHC2021 extensions default (#520) - closes #419
2022-07-01 12:07:41 +03:00
move 'Swarm.Language.*' modules to sublibrary (#1704)
2024-01-05 00:21:02 +03:00
library swarm-lang
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
import: stan-config, common, ghc2021-extensions
visibility: public
-- cabal-gild: discover src/swarm-lang
exposed-modules:
Replace `unification-fd` with a custom implementation of unification (#1802) Closes #1661; towards #154. `unification-fd` is very powerful, and extremely fast, but it was written a long time ago and its age shows. It was not possible to incorporate it into our effects system in a nice way, necessitating the use of concrete monad transformers in the typechecking code. In addition it is impossible to customize, and we have been contemplating new type system features such as #153 and #154 that turn out to require hooking into the way the unification algorithm works (see https://github.com/swarm-game/swarm/issues/154#issuecomment-1822877487 for more details). This PR thus removes the dependency on `unification-fd` and implements our own version of unification. It is not quite as fast as `unification-fd` but I consider the slowdown acceptable in order to gain e.g. recursive types. And of course there is also room to optimize it. The custom `UTerm` from `unification-fd` is replaced with the standard `Free` (free monad) construction from the `free` package, and the custom `Fix` from `unification-fd` is replaced with the one from `data-fix`. We also get rid of the `unifyCheck` function, which used to be a quick short-circuiting way to check whether two types definitely did not unify or might unify, allowing us to give better error messages more quickly. Now, the `=:=` unification operator itself just does this.
2024-04-28 00:52:31 +03:00
Swarm.Effect.Unify
Swarm.Effect.Unify.Common
Swarm.Effect.Unify.Fast
Swarm.Effect.Unify.Naive
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
Swarm.Language.Capability
Swarm.Language.Context
Swarm.Language.Elaborate
Insert parsed comments back into the AST and pretty-print with comments (#1845) 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 .
2024-05-14 14:32:03 +03:00
Swarm.Language.Format
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
Swarm.Language.Key
Represent types with applications of type constructors (#1873) 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).
2024-05-29 01:52:11 +03:00
Swarm.Language.Kindcheck
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
Swarm.Language.LSP
Swarm.Language.LSP.Hover
Swarm.Language.LSP.VarUsage
Swarm.Language.Module
Split the parser into submodules (#1841) 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.
2024-05-12 04:31:54 +03:00
Swarm.Language.Parser
Insert parsed comments back into the AST and pretty-print with comments (#1845) 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 .
2024-05-14 14:32:03 +03:00
Swarm.Language.Parser.Comment
Split the parser into submodules (#1841) 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.
2024-05-12 04:31:54 +03:00
Swarm.Language.Parser.Core
Swarm.Language.Parser.Lex
Swarm.Language.Parser.QQ
Swarm.Language.Parser.Record
Swarm.Language.Parser.Term
Swarm.Language.Parser.Type
Swarm.Language.Parser.Util
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
Swarm.Language.Pipeline
Swarm.Language.Pipeline.QQ
Swarm.Language.Pretty
Swarm.Language.Requirement
Swarm.Language.Syntax
Split syntax module to reduce compilation time (#1852) Hello, Splitting `Swarm.Language.Syntax` into submodules reduces the compilation time quite a bit. Currently, it takes the most of time out of all the modules. Here's a chart: ![CleanShot 2024-05-17 at 17 09 38@2x](https://github.com/swarm-game/swarm/assets/15181803/fc2672ea-4032-4140-93e7-16d9d4aaea69) That's ~20s for simplifier (with overall compilation time of 4.3 mins) Just taking out the types and functions related to `Constants` and putting them in a separate module results in: ![CleanShot 2024-05-17 at 17 11 45@2x](https://github.com/swarm-game/swarm/assets/15181803/ac4c57e9-af46-4861-b305-8540c1b01bab) Thats ~8.5 seconds for simplifier (with overall compilation time of 3.9 mins) Just for added info, timings taken on a 2019 macbook with i7 processor (6 core and 32 GB RAM) Changes include: - `Swarm.Language.Syntax` split into the following modules: - `Swarm.Language.Syntax.Comments` - Types for working with comments. - `Swarm.Language.Syntax.Type` - Core types (`Syntax'`, `Term'` and `DelayType`) - `Swarm.Language.Syntax.Pattern` - Pattern synonyms for untyped terms - `Swarm.Language.Syntax.Loc` - Types for working with location in source code (`SrcLoc` and related types) - `Swarm.Language.Syntax.Util` - Helper functions (Eg: `mkTuple`, `freeVarsS` etc) Compilation chart after the split: ![CleanShot 2024-05-18 at 15 20 17@2x](https://github.com/swarm-game/swarm/assets/15181803/b6a138dd-c0a3-416f-a620-2d82cb418c7d) `Swarm.Language.Syntax` is no longer the most time taking module. Closes #1844
2024-05-18 15:57:37 +03:00
Swarm.Language.Syntax.AST
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
Swarm.Language.Syntax.CommandMetadata
Split syntax module to reduce compilation time (#1852) Hello, Splitting `Swarm.Language.Syntax` into submodules reduces the compilation time quite a bit. Currently, it takes the most of time out of all the modules. Here's a chart: ![CleanShot 2024-05-17 at 17 09 38@2x](https://github.com/swarm-game/swarm/assets/15181803/fc2672ea-4032-4140-93e7-16d9d4aaea69) That's ~20s for simplifier (with overall compilation time of 4.3 mins) Just taking out the types and functions related to `Constants` and putting them in a separate module results in: ![CleanShot 2024-05-17 at 17 11 45@2x](https://github.com/swarm-game/swarm/assets/15181803/ac4c57e9-af46-4861-b305-8540c1b01bab) Thats ~8.5 seconds for simplifier (with overall compilation time of 3.9 mins) Just for added info, timings taken on a 2019 macbook with i7 processor (6 core and 32 GB RAM) Changes include: - `Swarm.Language.Syntax` split into the following modules: - `Swarm.Language.Syntax.Comments` - Types for working with comments. - `Swarm.Language.Syntax.Type` - Core types (`Syntax'`, `Term'` and `DelayType`) - `Swarm.Language.Syntax.Pattern` - Pattern synonyms for untyped terms - `Swarm.Language.Syntax.Loc` - Types for working with location in source code (`SrcLoc` and related types) - `Swarm.Language.Syntax.Util` - Helper functions (Eg: `mkTuple`, `freeVarsS` etc) Compilation chart after the split: ![CleanShot 2024-05-18 at 15 20 17@2x](https://github.com/swarm-game/swarm/assets/15181803/b6a138dd-c0a3-416f-a620-2d82cb418c7d) `Swarm.Language.Syntax` is no longer the most time taking module. Closes #1844
2024-05-18 15:57:37 +03:00
Swarm.Language.Syntax.Comments
Swarm.Language.Syntax.Constants
Swarm.Language.Syntax.Loc
Swarm.Language.Syntax.Pattern
Swarm.Language.Syntax.Util
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
Swarm.Language.Text.Markdown
Swarm.Language.Typecheck
Swarm.Language.Typed
Swarm.Language.Types
Swarm.Language.Value
other-modules: Paths_swarm
autogen-modules: Paths_swarm
build-depends:
aeson,
base,
commonmark >=0.2 && <0.3,
commonmark-extensions >=0.2 && <0.3,
containers,
Replace `unification-fd` with a custom implementation of unification (#1802) Closes #1661; towards #154. `unification-fd` is very powerful, and extremely fast, but it was written a long time ago and its age shows. It was not possible to incorporate it into our effects system in a nice way, necessitating the use of concrete monad transformers in the typechecking code. In addition it is impossible to customize, and we have been contemplating new type system features such as #153 and #154 that turn out to require hooking into the way the unification algorithm works (see https://github.com/swarm-game/swarm/issues/154#issuecomment-1822877487 for more details). This PR thus removes the dependency on `unification-fd` and implements our own version of unification. It is not quite as fast as `unification-fd` but I consider the slowdown acceptable in order to gain e.g. recursive types. And of course there is also room to optimize it. The custom `UTerm` from `unification-fd` is replaced with the standard `Free` (free monad) construction from the `free` package, and the custom `Fix` from `unification-fd` is replaced with the one from `data-fix`. We also get rid of the `unifyCheck` function, which used to be a quick short-circuiting way to check whether two types definitely did not unify or might unify, allowing us to give better error messages more quickly. Now, the `=:=` unification operator itself just does this.
2024-04-28 00:52:31 +03:00
data-fix >=0.3 && <0.4,
deriving-compat >=0.6 && <0.7,
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
extra,
Replace `unification-fd` with a custom implementation of unification (#1802) Closes #1661; towards #154. `unification-fd` is very powerful, and extremely fast, but it was written a long time ago and its age shows. It was not possible to incorporate it into our effects system in a nice way, necessitating the use of concrete monad transformers in the typechecking code. In addition it is impossible to customize, and we have been contemplating new type system features such as #153 and #154 that turn out to require hooking into the way the unification algorithm works (see https://github.com/swarm-game/swarm/issues/154#issuecomment-1822877487 for more details). This PR thus removes the dependency on `unification-fd` and implements our own version of unification. It is not quite as fast as `unification-fd` but I consider the slowdown acceptable in order to gain e.g. recursive types. And of course there is also room to optimize it. The custom `UTerm` from `unification-fd` is replaced with the standard `Free` (free monad) construction from the `free` package, and the custom `Fix` from `unification-fd` is replaced with the one from `data-fix`. We also get rid of the `unifyCheck` function, which used to be a quick short-circuiting way to check whether two types definitely did not unify or might unify, allowing us to give better error messages more quickly. Now, the `=:=` unification operator itself just does this.
2024-04-28 00:52:31 +03:00
free >=5.2 && <5.3,
fused-effects,
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
hashable,
lens,
Support GHC 9.8, bump upper bounds, and update CI (#1828) Make sure Swarm builds with the most recent versions of dependencies. The only one that is still lagging is `filepath`, but `servant` doesn't support `filepath-1.5` so Swarm can't either. The only real update needed was due to some breaking changes in `aeson-2.2`, but the necessary changes were very minor. Also fixed a few places where GHC 9.8 is generating additional warnings. Also update our CI: `haskell-ci` recently dropped support for `hlint`, in favor of projects defining their own standalone `hlint` workflows.
2024-05-10 22:43:41 +03:00
lsp >=2.4 && <2.7,
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
megaparsec,
mtl,
parser-combinators,
prettyprinter,
split,
syb >=0.7 && <0.8,
template-haskell,
Insert parsed comments back into the AST and pretty-print with comments (#1845) 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 .
2024-05-14 14:32:03 +03:00
terminal-size >=0.3 && <1.0,
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
text,
text-rope >=0.2 && <0.3,
vector,
vty,
witch,
yaml,
build-depends: swarm:swarm-util
hs-source-dirs: src/swarm-lang
default-language: Haskell2010
default-extensions:
-- Avoid unexpected unevaluated thunk buildup
-- See discussion in #415
StrictData
move 'Swarm.Language.*' modules to sublibrary (#1704)
2024-01-05 00:21:02 +03:00
topography sublibrary (#1836) 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.
2024-06-02 23:53:34 +03:00
library swarm-topography
import: stan-config, common, ghc2021-extensions
visibility: public
-- cabal-gild: discover src/swarm-topography
exposed-modules:
Swarm.Game.Location
Swarm.Game.Scenario.Topography.Area
Swarm.Game.Scenario.Topography.Navigation.Waypoint
Swarm.Game.Scenario.Topography.Placement
Swarm.Game.Scenario.Topography.Structure.Assembly
Swarm.Game.Scenario.Topography.Structure.Overlay
Swarm.Game.Scenario.Topography.Structure.Recognition
Swarm.Game.Scenario.Topography.Structure.Recognition.Log
Swarm.Game.Scenario.Topography.Structure.Recognition.Registry
Swarm.Game.Scenario.Topography.Structure.Recognition.Symmetry
Swarm.Game.Scenario.Topography.Structure.Recognition.Type
Swarm.Game.Scenario.Topography.Structure.Type
Swarm.Game.Universe
other-modules: Paths_swarm
autogen-modules: Paths_swarm
build-depends:
AhoCorasick >=0.0.4 && <0.0.5,
aeson >=2.2 && <2.3,
base >=4.14 && <4.20,
containers >=0.6.2 && <0.8,
extra >=1.7 && <1.8,
lens,
linear >=1.21.6 && <1.24,
nonempty-containers >=0.3.4 && <0.3.5,
servant-docs >=0.12 && <0.14,
text >=1.2.4 && <2.2,
yaml >=0.11 && <0.11.12.0,
build-depends:
swarm:swarm-util
hs-source-dirs: src/swarm-topography
default-language: Haskell2010
default-extensions:
-- Avoid unexpected unevaluated thunk buildup
-- See discussion in #415
StrictData
split scenario construction into separate sublibrary (#1719) 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`.
2024-01-25 00:11:14 +03:00
library swarm-scenario
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
import: stan-config, common, ghc2021-extensions
visibility: public
-- cabal-gild: discover src/swarm-scenario
exposed-modules:
Swarm.Constant
Swarm.Game.Achievement.Definitions
Capability exercise cost (#1777) Closes #1684 Closes #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 ![Screenshot from 2024-03-01 22-39-12](https://github.com/swarm-game/swarm/assets/261693/03fc0e4f-d219-4aa1-8775-cb5112eb0b90) # 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.
2024-04-25 22:39:54 +03:00
Swarm.Game.Device
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
Swarm.Game.Display
Swarm.Game.Entity
Swarm.Game.Entity.Cosmetic
Swarm.Game.Entity.Cosmetic.Assignment
Swarm.Game.Failure
Capability exercise cost (#1777) Closes #1684 Closes #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 ![Screenshot from 2024-03-01 22-39-12](https://github.com/swarm-game/swarm/assets/261693/03fc0e4f-d219-4aa1-8775-cb5112eb0b90) # 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.
2024-04-25 22:39:54 +03:00
Swarm.Game.Ingredients
extensible terrain (#1775) 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 ![Screenshot from 2024-02-22 16-51-53](https://github.com/swarm-game/swarm/assets/261693/1d263c8b-4e9c-40bf-bdc8-bf5ba8e33c4d) # 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
2024-02-29 09:22:21 +03:00
Swarm.Game.Land
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
Swarm.Game.Recipe
Swarm.Game.ResourceLoading
Swarm.Game.Robot
whitelist walkable entities (#1721) 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"'
2024-03-10 04:31:35 +03:00
Swarm.Game.Robot.Walk
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
Swarm.Game.Scenario
Swarm.Game.Scenario.Objective
Swarm.Game.Scenario.Objective.Graph
Swarm.Game.Scenario.Objective.Logic
Swarm.Game.Scenario.Objective.Validation
Swarm.Game.Scenario.RobotLookup
Swarm.Game.Scenario.Style
Swarm.Game.Scenario.Topography.Cell
Swarm.Game.Scenario.Topography.Center
Swarm.Game.Scenario.Topography.EntityFacade
Swarm.Game.Scenario.Topography.Navigation.Portal
Swarm.Game.Scenario.Topography.Structure
Swarm.Game.Scenario.Topography.Structure.Recognition.Precompute
Swarm.Game.Scenario.Topography.WorldDescription
Swarm.Game.Scenario.Topography.WorldPalette
Swarm.Game.State.Config
Swarm.Game.State.Landscape
Swarm.Game.Terrain
Swarm.Game.World
Swarm.Game.World.Abstract
Swarm.Game.World.Compile
Swarm.Game.World.Coords
Swarm.Game.World.Eval
Swarm.Game.World.Gen
Swarm.Game.World.Interpret
Swarm.Game.World.Load
Swarm.Game.World.Modify
Swarm.Game.World.Parse
Swarm.Game.World.Render
Swarm.Game.World.Syntax
Swarm.Game.World.Typecheck
Swarm.Util.Content
other-modules: Paths_swarm
autogen-modules: Paths_swarm
build-depends:
AhoCorasick >=0.0.4 && <0.0.5,
JuicyPixels >=3.3 && <3.4,
Support GHC 9.8, bump upper bounds, and update CI (#1828) Make sure Swarm builds with the most recent versions of dependencies. The only one that is still lagging is `filepath`, but `servant` doesn't support `filepath-1.5` so Swarm can't either. The only real update needed was due to some breaking changes in `aeson-2.2`, but the necessary changes were very minor. Also fixed a few places where GHC 9.8 is generating additional warnings. Also update our CI: `haskell-ci` recently dropped support for `hlint`, in favor of projects defining their own standalone `hlint` workflows.
2024-05-10 22:43:41 +03:00
aeson >=2.2 && <2.3,
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
array >=0.5.4 && <0.6,
Support GHC 9.8, bump upper bounds, and update CI (#1828) Make sure Swarm builds with the most recent versions of dependencies. The only one that is still lagging is `filepath`, but `servant` doesn't support `filepath-1.5` so Swarm can't either. The only real update needed was due to some breaking changes in `aeson-2.2`, but the necessary changes were very minor. Also fixed a few places where GHC 9.8 is generating additional warnings. Also update our CI: `haskell-ci` recently dropped support for `hlint`, in favor of projects defining their own standalone `hlint` workflows.
2024-05-10 22:43:41 +03:00
base >=4.14 && <4.20,
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
boolexpr >=0.2 && <0.3,
bytestring >=0.10 && <0.13,
clock >=0.8.2 && <0.9,
colour >=2.3.6 && <2.4,
Support GHC 9.8, bump upper bounds, and update CI (#1828) Make sure Swarm builds with the most recent versions of dependencies. The only one that is still lagging is `filepath`, but `servant` doesn't support `filepath-1.5` so Swarm can't either. The only real update needed was due to some breaking changes in `aeson-2.2`, but the necessary changes were very minor. Also fixed a few places where GHC 9.8 is generating additional warnings. Also update our CI: `haskell-ci` recently dropped support for `hlint`, in favor of projects defining their own standalone `hlint` workflows.
2024-05-10 22:43:41 +03:00
containers >=0.6.2 && <0.8,
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
directory >=1.3 && <1.4,
either >=5.0 && <5.1,
extra >=1.7 && <1.8,
filepath >=1.4 && <1.5,
fused-effects >=1.1.1.1 && <1.2,
hashable >=1.3.4 && <1.5,
hsnoise >=0.0.3 && <0.1,
Support GHC 9.8, bump upper bounds, and update CI (#1828) Make sure Swarm builds with the most recent versions of dependencies. The only one that is still lagging is `filepath`, but `servant` doesn't support `filepath-1.5` so Swarm can't either. The only real update needed was due to some breaking changes in `aeson-2.2`, but the necessary changes were very minor. Also fixed a few places where GHC 9.8 is generating additional warnings. Also update our CI: `haskell-ci` recently dropped support for `hlint`, in favor of projects defining their own standalone `hlint` workflows.
2024-05-10 22:43:41 +03:00
lens >=4.19 && <5.4,
linear >=1.21.6 && <1.24,
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
megaparsec >=9.6.1 && <9.7,
murmur3 >=1.0.4 && <1.1,
palette >=0.3 && <0.4,
parser-combinators >=1.2 && <1.4,
prettyprinter >=1.7.0 && <1.8,
random >=1.2.0 && <1.3,
servant-docs >=0.12 && <0.14,
simple-enumeration >=0.2 && <0.3,
tagged >=0.8 && <0.9,
text >=1.2.4 && <2.2,
vector >=0.12 && <0.14,
vty >=6.1 && <6.3,
witch >=1.1.1.0 && <1.3,
yaml >=0.11 && <0.11.12.0,
build-depends:
swarm:swarm-lang,
topography sublibrary (#1836) 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.
2024-06-02 23:53:34 +03:00
swarm:swarm-topography,
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
swarm:swarm-util,
hs-source-dirs: src/swarm-scenario
default-language: Haskell2010
default-extensions:
-- Avoid unexpected unevaluated thunk buildup
-- See discussion in #415
StrictData
split scenario construction into separate sublibrary (#1719) 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`.
2024-01-25 00:11:14 +03:00
library swarm-engine
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
import: stan-config, common, ghc2021-extensions
visibility: public
-- cabal-gild: discover src/swarm-engine
exposed-modules:
Swarm.Effect
Swarm.Effect.Time
Swarm.Game.Achievement.Attainment
Swarm.Game.Achievement.Description
Swarm.Game.Achievement.Persistence
Swarm.Game.CESK
Swarm.Game.Exception
Swarm.Game.Robot.Activity
Swarm.Game.Robot.Concrete
Swarm.Game.Robot.Context
Swarm.Game.Scenario.Objective.WinCheck
Swarm.Game.Scenario.Scoring.Best
Swarm.Game.Scenario.Scoring.CodeSize
Swarm.Game.Scenario.Scoring.ConcreteMetrics
Swarm.Game.Scenario.Scoring.GenericMetrics
Swarm.Game.Scenario.Status
Swarm.Game.Scenario.Topography.Navigation.Util
Swarm.Game.Scenario.Topography.Structure.Recognition.Tracking
Swarm.Game.ScenarioInfo
Swarm.Game.State
Swarm.Game.State.Robot
Swarm.Game.State.Runtime
Swarm.Game.State.Substate
Swarm.Game.Step
Swarm.Game.Step.Arithmetic
Swarm.Game.Step.Combustion
Swarm.Game.Step.Const
Swarm.Game.Step.Flood
Swarm.Game.Step.Path.Cache
Swarm.Game.Step.Path.Cache.DistanceLimit
Swarm.Game.Step.Path.Finding
Swarm.Game.Step.Path.Type
Swarm.Game.Step.Path.Walkability
Swarm.Game.Step.RobotStepState
Swarm.Game.Step.Util
Swarm.Game.Step.Util.Command
Swarm.Game.Step.Util.Inspect
refactor to remove `swarm-tournament` dep from `swarm-integration` (#1809) 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`.
2024-04-29 05:34:56 +03:00
Swarm.Game.Step.Validate
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
Swarm.Game.Tick
Swarm.Game.Value
Swarm.Log
Swarm.Version
other-modules: Paths_swarm
autogen-modules: Paths_swarm
build-depends:
AhoCorasick >=0.0.4 && <0.0.5,
SHA >=1.6.4 && <1.6.5,
Support GHC 9.8, bump upper bounds, and update CI (#1828) Make sure Swarm builds with the most recent versions of dependencies. The only one that is still lagging is `filepath`, but `servant` doesn't support `filepath-1.5` so Swarm can't either. The only real update needed was due to some breaking changes in `aeson-2.2`, but the necessary changes were very minor. Also fixed a few places where GHC 9.8 is generating additional warnings. Also update our CI: `haskell-ci` recently dropped support for `hlint`, in favor of projects defining their own standalone `hlint` workflows.
2024-05-10 22:43:41 +03:00
aeson >=2.2 && <2.3,
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
array >=0.5.4 && <0.6,
astar >=0.3 && <0.3.1,
Support GHC 9.8, bump upper bounds, and update CI (#1828) Make sure Swarm builds with the most recent versions of dependencies. The only one that is still lagging is `filepath`, but `servant` doesn't support `filepath-1.5` so Swarm can't either. The only real update needed was due to some breaking changes in `aeson-2.2`, but the necessary changes were very minor. Also fixed a few places where GHC 9.8 is generating additional warnings. Also update our CI: `haskell-ci` recently dropped support for `hlint`, in favor of projects defining their own standalone `hlint` workflows.
2024-05-10 22:43:41 +03:00
base >=4.14 && <4.20,
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
boolexpr >=0.2 && <0.3,
bytestring,
clock >=0.8.2 && <0.9,
Support GHC 9.8, bump upper bounds, and update CI (#1828) Make sure Swarm builds with the most recent versions of dependencies. The only one that is still lagging is `filepath`, but `servant` doesn't support `filepath-1.5` so Swarm can't either. The only real update needed was due to some breaking changes in `aeson-2.2`, but the necessary changes were very minor. Also fixed a few places where GHC 9.8 is generating additional warnings. Also update our CI: `haskell-ci` recently dropped support for `hlint`, in favor of projects defining their own standalone `hlint` workflows.
2024-05-10 22:43:41 +03:00
containers >=0.6.2 && <0.8,
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
directory >=1.3 && <1.4,
extra >=1.7 && <1.8,
filepath >=1.4 && <1.5,
fused-effects >=1.1.1.1 && <1.2,
fused-effects-lens >=1.2.0.1 && <1.3,
githash,
hashable >=1.3.4 && <1.5,
http-client >=0.7 && <0.8,
http-client-tls >=0.3 && <0.4,
http-types >=0.12 && <0.13,
Support GHC 9.8, bump upper bounds, and update CI (#1828) Make sure Swarm builds with the most recent versions of dependencies. The only one that is still lagging is `filepath`, but `servant` doesn't support `filepath-1.5` so Swarm can't either. The only real update needed was due to some breaking changes in `aeson-2.2`, but the necessary changes were very minor. Also fixed a few places where GHC 9.8 is generating additional warnings. Also update our CI: `haskell-ci` recently dropped support for `hlint`, in favor of projects defining their own standalone `hlint` workflows.
2024-05-10 22:43:41 +03:00
lens >=4.19 && <5.4,
linear >=1.21.6 && <1.24,
Parse comments (#1838) 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.
2024-05-12 03:32:21 +03:00
megaparsec >=9.6 && <9.7,
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
mtl >=2.2.2 && <2.4,
nonempty-containers >=0.3.4 && <0.3.5,
prettyprinter >=1.7.0 && <1.8,
random >=1.2.0 && <1.3,
servant-docs >=0.12 && <0.14,
text >=1.2.4 && <2.2,
Support GHC 9.8, bump upper bounds, and update CI (#1828) Make sure Swarm builds with the most recent versions of dependencies. The only one that is still lagging is `filepath`, but `servant` doesn't support `filepath-1.5` so Swarm can't either. The only real update needed was due to some breaking changes in `aeson-2.2`, but the necessary changes were very minor. Also fixed a few places where GHC 9.8 is generating additional warnings. Also update our CI: `haskell-ci` recently dropped support for `hlint`, in favor of projects defining their own standalone `hlint` workflows.
2024-05-10 22:43:41 +03:00
time >=1.9 && <1.15,
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
transformers >=0.5 && <0.7,
transformers >=0.5.6.2 && <0.6.2.0,
unordered-containers >=0.2.14 && <0.3,
warp,
witch >=1.1.1.0 && <1.3,
yaml >=0.11 && <0.11.12.0,
build-depends:
swarm:swarm-lang,
swarm:swarm-scenario,
topography sublibrary (#1836) 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.
2024-06-02 23:53:34 +03:00
swarm:swarm-topography,
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
swarm:swarm-util,
hs-source-dirs: src/swarm-engine
default-language: Haskell2010
default-extensions:
-- Avoid unexpected unevaluated thunk buildup
-- See discussion in #415
StrictData
extract game engine sublibrary (#1714) Towards #1043 Extracts `Swarm.Game.*` modules to their own sublibrary. There was already pretty good separation along this boundary; just had to move three functions into a new module `Swarm.Util.Content`.
2024-01-05 21:26:06 +03:00
library swarm-web
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
import: stan-config, common, ghc2021-extensions
visibility: public
-- cabal-gild: discover src/swarm-web
exposed-modules:
Swarm.Web
Swarm.Web.Worldview
other-modules: Paths_swarm
autogen-modules: Paths_swarm
build-depends:
aeson,
base,
brick,
bytestring,
colour,
commonmark,
containers,
http-types,
lens,
nonempty-containers,
palette,
servant-docs,
servant-server >=0.19 && <0.21,
text,
wai >=3.2 && <3.3,
Support GHC 9.8, bump upper bounds, and update CI (#1828) Make sure Swarm builds with the most recent versions of dependencies. The only one that is still lagging is `filepath`, but `servant` doesn't support `filepath-1.5` so Swarm can't either. The only real update needed was due to some breaking changes in `aeson-2.2`, but the necessary changes were very minor. Also fixed a few places where GHC 9.8 is generating additional warnings. Also update our CI: `haskell-ci` recently dropped support for `hlint`, in favor of projects defining their own standalone `hlint` workflows.
2024-05-10 22:43:41 +03:00
wai-app-static >=3.1.8 && <3.2,
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
warp,
witch,
build-depends:
Split out `swarm-doc` and `swarm-tui` sublibraries (#1834) Split the final remaining default library into `swarm-doc` and `swarm-tui`. Closes #1043 .
2024-05-11 05:08:49 +03:00
swarm:swarm-doc,
swarm:swarm-engine,
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
swarm:swarm-lang,
Split out `swarm-doc` and `swarm-tui` sublibraries (#1834) Split the final remaining default library into `swarm-doc` and `swarm-tui`. Closes #1043 .
2024-05-11 05:08:49 +03:00
swarm:swarm-scenario,
topography sublibrary (#1836) 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.
2024-06-02 23:53:34 +03:00
swarm:swarm-topography,
Split out `swarm-doc` and `swarm-tui` sublibraries (#1834) Split the final remaining default library into `swarm-doc` and `swarm-tui`. Closes #1043 .
2024-05-11 05:08:49 +03:00
swarm:swarm-tui,
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
swarm:swarm-util,
hs-source-dirs: src/swarm-web
default-language: Haskell2010
default-extensions:
-- Avoid unexpected unevaluated thunk buildup
-- See discussion in #415
StrictData
extract game engine sublibrary (#1714) Towards #1043 Extracts `Swarm.Game.*` modules to their own sublibrary. There was already pretty good separation along this boundary; just had to move three functions into a new module `Swarm.Util.Content`.
2024-01-05 21:26:06 +03:00
Upload and parse scenarios (#1798) 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?)
2024-04-25 23:11:11 +03:00
library swarm-tournament
import: stan-config, common, ghc2021-extensions
visibility: public
-- cabal-gild: discover src/swarm-tournament
exposed-modules:
Implement GitHub authentication (#1856) 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
2024-05-22 03:27:21 +03:00
Swarm.Web.Auth
Upload and parse scenarios (#1798) 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?)
2024-04-25 23:11:11 +03:00
Swarm.Web.Tournament
Swarm.Web.Tournament.Database.Query
Swarm.Web.Tournament.Type
Swarm.Web.Tournament.Validate
Swarm.Web.Tournament.Validate.FailureMode
Swarm.Web.Tournament.Validate.Upload
other-modules: Paths_swarm
autogen-modules: Paths_swarm
build-depends:
SHA,
aeson,
base,
bytestring,
commonmark,
containers,
Implement GitHub authentication (#1856) 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
2024-05-22 03:27:21 +03:00
cookie,
exceptions,
Upload and parse scenarios (#1798) 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?)
2024-04-25 23:11:11 +03:00
extra,
fused-effects,
Implement GitHub authentication (#1856) 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
2024-05-22 03:27:21 +03:00
http-client,
http-client-tls >=0.3.6.3 && <0.3.7,
Upload and parse scenarios (#1798) 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?)
2024-04-25 23:11:11 +03:00
http-types,
lens,
mtl,
servant-docs,
servant-multipart,
servant-server >=0.19 && <0.21,
Use sqlite and static binary (#1837) 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.
2024-05-12 23:45:08 +03:00
sqlite-simple >=0.4.19.0 && <0.4.20,
Upload and parse scenarios (#1798) 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?)
2024-04-25 23:11:11 +03:00
text,
time,
transformers,
Implement GitHub authentication (#1856) 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
2024-05-22 03:27:21 +03:00
utf8-string,
Upload and parse scenarios (#1798) 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?)
2024-04-25 23:11:11 +03:00
wai >=3.2 && <3.3,
Support GHC 9.8, bump upper bounds, and update CI (#1828) Make sure Swarm builds with the most recent versions of dependencies. The only one that is still lagging is `filepath`, but `servant` doesn't support `filepath-1.5` so Swarm can't either. The only real update needed was due to some breaking changes in `aeson-2.2`, but the necessary changes were very minor. Also fixed a few places where GHC 9.8 is generating additional warnings. Also update our CI: `haskell-ci` recently dropped support for `hlint`, in favor of projects defining their own standalone `hlint` workflows.
2024-05-10 22:43:41 +03:00
wai-app-static >=3.1.8 && <3.2,
Upload and parse scenarios (#1798) 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?)
2024-04-25 23:11:11 +03:00
wai-extra,
warp,
yaml,
build-depends:
swarm:swarm-engine,
swarm:swarm-lang,
swarm:swarm-scenario,
swarm:swarm-util,
hs-source-dirs: src/swarm-tournament
default-language: Haskell2010
extract game engine sublibrary (#1714) Towards #1043 Extracts `Swarm.Game.*` modules to their own sublibrary. There was already pretty good separation along this boundary; just had to move three functions into a new module `Swarm.Util.Content`.
2024-01-05 21:26:06 +03:00
library swarm-util
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
import: stan-config, common, ghc2021-extensions
visibility: public
-- cabal-gild: discover src/swarm-util
exposed-modules:
Control.Carrier.Accum.FixedStrict
Data.BoolExpr.Simplify
topography sublibrary (#1836) 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.
2024-06-02 23:53:34 +03:00
Swarm.Language.Syntax.Direction
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
Swarm.Util
Move effect utils to `swarm-util` (#1872) 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.
2024-05-28 21:36:10 +03:00
Swarm.Util.Effect
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
Swarm.Util.Erasable
Update `FromJSON TickNumber` instance to match `ToJSON` instance (#1870) Fixes #1868.
2024-05-28 06:10:53 +03:00
Swarm.Util.JSON
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
Swarm.Util.Lens
Swarm.Util.OccurrenceEncoder
Swarm.Util.ReadableIORef
Swarm.Util.RingBuffer
Swarm.Util.UnitInterval
Swarm.Util.WindowedCounter
Swarm.Util.Yaml
other-modules: Paths_swarm
autogen-modules: Paths_swarm
build-depends:
Support GHC 9.8, bump upper bounds, and update CI (#1828) Make sure Swarm builds with the most recent versions of dependencies. The only one that is still lagging is `filepath`, but `servant` doesn't support `filepath-1.5` so Swarm can't either. The only real update needed was due to some breaking changes in `aeson-2.2`, but the necessary changes were very minor. Also fixed a few places where GHC 9.8 is generating additional warnings. Also update our CI: `haskell-ci` recently dropped support for `hlint`, in favor of projects defining their own standalone `hlint` workflows.
2024-05-10 22:43:41 +03:00
aeson >=2.2 && <2.3,
base >=4.14 && <4.20,
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
boolexpr >=0.2 && <0.3,
clock >=0.8.2 && <0.9,
Support GHC 9.8, bump upper bounds, and update CI (#1828) Make sure Swarm builds with the most recent versions of dependencies. The only one that is still lagging is `filepath`, but `servant` doesn't support `filepath-1.5` so Swarm can't either. The only real update needed was due to some breaking changes in `aeson-2.2`, but the necessary changes were very minor. Also fixed a few places where GHC 9.8 is generating additional warnings. Also update our CI: `haskell-ci` recently dropped support for `hlint`, in favor of projects defining their own standalone `hlint` workflows.
2024-05-10 22:43:41 +03:00
containers >=0.6.2 && <0.8,
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
directory >=1.3 && <1.4,
either >=5.0 && <5.1,
Move effect utils to `swarm-util` (#1872) 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.
2024-05-28 21:36:10 +03:00
extra >=1.7 && <1.8,
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
filepath >=1.4 && <1.5,
fused-effects >=1.1.1.1 && <1.2,
topography sublibrary (#1836) 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.
2024-06-02 23:53:34 +03:00
hashable >=1.3.4 && <1.5,
Support GHC 9.8, bump upper bounds, and update CI (#1828) Make sure Swarm builds with the most recent versions of dependencies. The only one that is still lagging is `filepath`, but `servant` doesn't support `filepath-1.5` so Swarm can't either. The only real update needed was due to some breaking changes in `aeson-2.2`, but the necessary changes were very minor. Also fixed a few places where GHC 9.8 is generating additional warnings. Also update our CI: `haskell-ci` recently dropped support for `hlint`, in favor of projects defining their own standalone `hlint` workflows.
2024-05-10 22:43:41 +03:00
lens >=4.19 && <5.4,
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
minimorph >=0.3 && <0.4,
mtl >=2.2.2 && <2.4,
servant-docs >=0.12 && <0.14,
Support GHC 9.8, bump upper bounds, and update CI (#1828) Make sure Swarm builds with the most recent versions of dependencies. The only one that is still lagging is `filepath`, but `servant` doesn't support `filepath-1.5` so Swarm can't either. The only real update needed was due to some breaking changes in `aeson-2.2`, but the necessary changes were very minor. Also fixed a few places where GHC 9.8 is generating additional warnings. Also update our CI: `haskell-ci` recently dropped support for `hlint`, in favor of projects defining their own standalone `hlint` workflows.
2024-05-10 22:43:41 +03:00
template-haskell >=2.16 && <2.22,
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
text >=1.2.4 && <2.2,
transformers >=0.5 && <0.7,
vector >=0.12 && <0.14,
witch >=1.1.1.0 && <1.3,
Move effect utils to `swarm-util` (#1872) 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.
2024-05-28 21:36:10 +03:00
witherable >=0.4 && <0.5,
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
yaml >=0.11 && <0.11.12.0,
hs-source-dirs: src/swarm-util
default-language: Haskell2010
default-extensions:
-- Avoid unexpected unevaluated thunk buildup
-- See discussion in #415
StrictData
extract game engine sublibrary (#1714) Towards #1043 Extracts `Swarm.Game.*` modules to their own sublibrary. There was already pretty good separation along this boundary; just had to move three functions into a new module `Swarm.Util.Content`.
2024-01-05 21:26:06 +03:00
Split out `swarm-doc` and `swarm-tui` sublibraries (#1834) Split the final remaining default library into `swarm-doc` and `swarm-tui`. Closes #1043 .
2024-05-11 05:08:49 +03:00
library swarm-doc
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
import: stan-config, common, ghc2021-extensions
Split out `swarm-doc` and `swarm-tui` sublibraries (#1834) Split the final remaining default library into `swarm-doc` and `swarm-tui`. Closes #1043 .
2024-05-11 05:08:49 +03:00
visibility: public
-- cabal-gild: discover src/swarm-doc
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
exposed-modules:
Swarm.Doc.Command
Split out `swarm-doc` and `swarm-tui` sublibraries (#1834) Split the final remaining default library into `swarm-doc` and `swarm-tui`. Closes #1043 .
2024-05-11 05:08:49 +03:00
Swarm.Doc.Gen
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
Swarm.Doc.Keyword
Swarm.Doc.Pedagogy
Split out `swarm-doc` and `swarm-tui` sublibraries (#1834) Split the final remaining default library into `swarm-doc` and `swarm-tui`. Closes #1043 .
2024-05-11 05:08:49 +03:00
Swarm.Doc.Schema.Arrangement
Swarm.Doc.Schema.Parse
Swarm.Doc.Schema.Refined
Swarm.Doc.Schema.Render
Swarm.Doc.Schema.SchemaType
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
Swarm.Doc.Util
Split out `swarm-doc` and `swarm-tui` sublibraries (#1834) Split the final remaining default library into `swarm-doc` and `swarm-tui`. Closes #1043 .
2024-05-11 05:08:49 +03:00
Swarm.Doc.Wiki.Cheatsheet
Swarm.Doc.Wiki.Matrix
Swarm.Doc.Wiki.Util
build-depends:
aeson >=2.2 && <2.3,
base >=4.14 && <4.20,
containers >=0.6.2 && <0.8,
directory >=1.3 && <1.4,
dotgen >=0.4 && <0.5,
extra >=1.7 && <1.8,
filepath >=1.4 && <1.5,
fused-effects >=1.1.1.1 && <1.2,
lens >=4.19 && <5.4,
mtl >=2.2.2 && <2.4,
pandoc >=3.0 && <3.2,
pandoc-types >=1.23 && <1.24,
scientific >=0.3.6 && <0.3.8,
servant-docs >=0.12 && <0.14,
text >=1.2.4 && <2.2,
transformers >=0.5 && <0.7,
vector >=0.12 && <0.14,
build-depends:
swarm:swarm-engine,
swarm:swarm-lang,
swarm:swarm-scenario,
swarm:swarm-util,
hs-source-dirs: src/swarm-doc
default-language: Haskell2010
default-extensions:
-- Avoid unexpected unevaluated thunk buildup
-- See discussion in #415
StrictData
library swarm-tui
import: stan-config, common, ghc2021-extensions
actually move all `swarm-tui` modules into a `swarm-tui` subfolder (#1840) #1834 created a `swarm-tui` sublibrary for the remaining source modules that weren't in a sublibrary of their own, but I forgot to actually move them all into a `swarm-tui` folder.
2024-05-12 02:10:54 +03:00
visibility: public
-- cabal-gild: discover src/swarm-tui
Split out `swarm-doc` and `swarm-tui` sublibraries (#1834) Split the final remaining default library into `swarm-doc` and `swarm-tui`. Closes #1043 .
2024-05-11 05:08:49 +03:00
exposed-modules:
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
Swarm.TUI.Border
Swarm.TUI.Controller
Swarm.TUI.Controller.Util
Swarm.TUI.Editor.Controller
Swarm.TUI.Editor.Json
Swarm.TUI.Editor.Masking
Swarm.TUI.Editor.Model
Swarm.TUI.Editor.Palette
Swarm.TUI.Editor.Util
Swarm.TUI.Editor.View
Swarm.TUI.Inventory.Sorting
Swarm.TUI.Launch.Controller
Swarm.TUI.Launch.Model
Swarm.TUI.Launch.Prep
Swarm.TUI.Launch.View
Swarm.TUI.List
Swarm.TUI.Model
Swarm.TUI.Model.Goal
Swarm.TUI.Model.Menu
Swarm.TUI.Model.Name
Swarm.TUI.Model.Repl
Swarm.TUI.Model.StateUpdate
Swarm.TUI.Model.Structure
Swarm.TUI.Model.UI
Swarm.TUI.Panel
Swarm.TUI.View
Swarm.TUI.View.Achievement
Swarm.TUI.View.Attribute.Attr
Swarm.TUI.View.Attribute.CustomStyling
Swarm.TUI.View.Attribute.Util
Swarm.TUI.View.CellDisplay
Swarm.TUI.View.Logo
Swarm.TUI.View.Objective
Swarm.TUI.View.Structure
Swarm.TUI.View.Util
other-modules: Paths_swarm
autogen-modules: Paths_swarm
build-depends:
Support GHC 9.8, bump upper bounds, and update CI (#1828) Make sure Swarm builds with the most recent versions of dependencies. The only one that is still lagging is `filepath`, but `servant` doesn't support `filepath-1.5` so Swarm can't either. The only real update needed was due to some breaking changes in `aeson-2.2`, but the necessary changes were very minor. Also fixed a few places where GHC 9.8 is generating additional warnings. Also update our CI: `haskell-ci` recently dropped support for `hlint`, in favor of projects defining their own standalone `hlint` workflows.
2024-05-10 22:43:41 +03:00
aeson >=2.2 && <2.3,
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
array >=0.5.4 && <0.6,
Support GHC 9.8, bump upper bounds, and update CI (#1828) Make sure Swarm builds with the most recent versions of dependencies. The only one that is still lagging is `filepath`, but `servant` doesn't support `filepath-1.5` so Swarm can't either. The only real update needed was due to some breaking changes in `aeson-2.2`, but the necessary changes were very minor. Also fixed a few places where GHC 9.8 is generating additional warnings. Also update our CI: `haskell-ci` recently dropped support for `hlint`, in favor of projects defining their own standalone `hlint` workflows.
2024-05-10 22:43:41 +03:00
base >=4.14 && <4.20,
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
brick >=2.1.1 && <2.4,
brick-list-skip >=0.1.1.2 && <0.2,
bytestring >=0.10 && <0.13,
clock >=0.8.2 && <0.9,
colour >=2.3.6 && <2.4,
Support GHC 9.8, bump upper bounds, and update CI (#1828) Make sure Swarm builds with the most recent versions of dependencies. The only one that is still lagging is `filepath`, but `servant` doesn't support `filepath-1.5` so Swarm can't either. The only real update needed was due to some breaking changes in `aeson-2.2`, but the necessary changes were very minor. Also fixed a few places where GHC 9.8 is generating additional warnings. Also update our CI: `haskell-ci` recently dropped support for `hlint`, in favor of projects defining their own standalone `hlint` workflows.
2024-05-10 22:43:41 +03:00
containers >=0.6.2 && <0.8,
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
extra >=1.7 && <1.8,
filepath >=1.4 && <1.5,
fused-effects >=1.1.1.1 && <1.2,
fuzzy >=0.1 && <0.2,
githash >=0.1.6 && <0.2,
Support GHC 9.8, bump upper bounds, and update CI (#1828) Make sure Swarm builds with the most recent versions of dependencies. The only one that is still lagging is `filepath`, but `servant` doesn't support `filepath-1.5` so Swarm can't either. The only real update needed was due to some breaking changes in `aeson-2.2`, but the necessary changes were very minor. Also fixed a few places where GHC 9.8 is generating additional warnings. Also update our CI: `haskell-ci` recently dropped support for `hlint`, in favor of projects defining their own standalone `hlint` workflows.
2024-05-10 22:43:41 +03:00
lens >=4.19 && <5.4,
linear >=1.21.6 && <1.24,
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
mtl >=2.2.2 && <2.4,
murmur3 >=1.0.4 && <1.1,
natural-sort >=0.1.2 && <0.2,
nonempty-containers >=0.3.4 && <0.3.5,
palette >=0.3 && <0.4,
servant-docs >=0.12 && <0.14,
split >=0.2.3 && <0.3,
tagged >=0.8 && <0.9,
text >=1.2.4 && <2.2,
text-zipper >=0.10 && <0.14,
Support GHC 9.8, bump upper bounds, and update CI (#1828) Make sure Swarm builds with the most recent versions of dependencies. The only one that is still lagging is `filepath`, but `servant` doesn't support `filepath-1.5` so Swarm can't either. The only real update needed was due to some breaking changes in `aeson-2.2`, but the necessary changes were very minor. Also fixed a few places where GHC 9.8 is generating additional warnings. Also update our CI: `haskell-ci` recently dropped support for `hlint`, in favor of projects defining their own standalone `hlint` workflows.
2024-05-10 22:43:41 +03:00
time >=1.9 && <1.15,
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
transformers >=0.5 && <0.7,
transformers >=0.5.6.2 && <0.6.2.0,
vector >=0.12 && <0.14,
vty >=6.1 && <6.3,
warp >=3.2 && <3.5,
witch >=1.1.1.0 && <1.3,
word-wrap >=0.5 && <0.6,
yaml >=0.11 && <0.11.12.0,
build-depends:
swarm:swarm-engine,
swarm:swarm-lang,
swarm:swarm-scenario,
topography sublibrary (#1836) 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.
2024-06-02 23:53:34 +03:00
swarm:swarm-topography,
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
swarm:swarm-util,
actually move all `swarm-tui` modules into a `swarm-tui` subfolder (#1840) #1834 created a `swarm-tui` sublibrary for the remaining source modules that weren't in a sublibrary of their own, but I forgot to actually move them all into a `swarm-tui` folder.
2024-05-12 02:10:54 +03:00
hs-source-dirs: src/swarm-tui
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
default-language: Haskell2010
default-extensions:
-- Avoid unexpected unevaluated thunk buildup
-- See discussion in #415
StrictData
refactor: split out Swarm.AST
2021-08-23 21:31:57 +03:00
new name: swarm
2021-08-23 19:47:04 +03:00
executable swarm
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
import: stan-config, common
main-is: Main.hs
other-modules: Swarm.App
build-depends:
-- Imports shared with the library don't need bounds
base,
Allow blaze-html-0.9.2 (#1789)
2024-03-08 22:15:39 +03:00
blaze-html >=0.9.1 && <0.10,
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
brick,
fused-effects,
githash >=0.1.6 && <0.2,
lens,
optparse-applicative >=0.16 && <0.19,
prettyprinter,
servant >=0.19 && <0.21,
Split out `swarm-doc` and `swarm-tui` sublibraries (#1834) Split the final remaining default library into `swarm-doc` and `swarm-tui`. Closes #1043 .
2024-05-11 05:08:49 +03:00
swarm:swarm-engine,
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
swarm:swarm-lang,
Split out `swarm-doc` and `swarm-tui` sublibraries (#1834) Split the final remaining default library into `swarm-doc` and `swarm-tui`. Closes #1043 .
2024-05-11 05:08:49 +03:00
swarm:swarm-scenario,
swarm:swarm-tui,
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
swarm:swarm-util,
swarm:swarm-web,
terminal-size >=0.3 && <1.0,
text,
vty,
vty-crossplatform >=0.4 && <0.5,
hs-source-dirs: app
default-language: Haskell2010
ghc-options: -threaded
default-extensions: ImportQualifiedPost
Add parser test and fix missing semicolon between defs (#86)
2021-09-28 05:39:39 +03:00
extract scene renderer to its own binary (#1752) 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 ![output](https://github.com/swarm-game/swarm/assets/261693/e2df3aad-3b65-46bf-8485-352facdffc76)
2024-01-29 21:01:56 +03:00
executable swarm-scene
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
import: stan-config, common, ghc2021-extensions
main-is: Main.hs
build-depends:
base,
optparse-applicative >=0.16 && <0.19,
topography sublibrary (#1836) 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.
2024-06-02 23:53:34 +03:00
build-depends:
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
swarm:swarm-scenario,
topography sublibrary (#1836) 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.
2024-06-02 23:53:34 +03:00
swarm:swarm-topography,
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
hs-source-dirs: app/scene
default-language: Haskell2010
ghc-options: -threaded
default-extensions: ImportQualifiedPost
extract scene renderer to its own binary (#1752) 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 ![output](https://github.com/swarm-game/swarm/assets/261693/e2df3aad-3b65-46bf-8485-352facdffc76)
2024-01-29 21:01:56 +03:00
extract doc generator to separate executable (#1671) 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
2023-12-04 06:45:07 +03:00
executable swarm-docs
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
import: stan-config, common, ghc2021-extensions
main-is: Main.hs
other-modules:
build-depends:
-- Imports shared with the library don't need bounds
base,
optparse-applicative >=0.16 && <0.19,
Split out `swarm-doc` and `swarm-tui` sublibraries (#1834) Split the final remaining default library into `swarm-doc` and `swarm-tui`. Closes #1043 .
2024-05-11 05:08:49 +03:00
swarm:swarm-doc,
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
text,
hs-source-dirs: app/doc
default-language: Haskell2010
ghc-options: -threaded
default-extensions: ImportQualifiedPost
extract doc generator to separate executable (#1671) 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
2023-12-04 06:45:07 +03:00
Upload and parse scenarios (#1798) 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?)
2024-04-25 23:11:11 +03:00
executable swarm-host-tournament
import: stan-config, common, ghc2021-extensions
main-is: Main.hs
build-depends:
base,
optparse-applicative >=0.16 && <0.19,
Implement GitHub authentication (#1856) 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
2024-05-22 03:27:21 +03:00
sqlite-simple,
Upload and parse scenarios (#1798) 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?)
2024-04-25 23:11:11 +03:00
transformers,
warp,
Implement GitHub authentication (#1856) 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
2024-05-22 03:27:21 +03:00
yaml,
Upload and parse scenarios (#1798) 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?)
2024-04-25 23:11:11 +03:00
build-depends:
swarm:swarm-engine,
swarm:swarm-tournament,
hs-source-dirs: app/tournament
default-language: Haskell2010
ghc-options: -threaded
default-extensions: ImportQualifiedPost
Add parser test and fix missing semicolon between defs (#86)
2021-09-28 05:39:39 +03:00
test-suite swarm-unit
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
import: stan-config, common, ghc2021-extensions
main-is: Main.hs
type: exitcode-stdio-1.0
other-modules:
TestBoolExpr
TestCommand
TestEval
TestInventory
TestLSP
TestLanguagePipeline
TestNotification
TestOrdering
structure grid expansion (#1826) 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 ```
2024-05-26 04:25:54 +03:00
TestOverlay
Parse comments (#1838) 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.
2024-05-12 03:32:21 +03:00
TestParse
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
TestPedagogy
TestPretty
TestRecipeCoverage
Refine unit test dependencies (#1804) 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?
2024-04-25 22:20:31 +03:00
TestRepl
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
TestScoring
TestUtil
build-depends:
-- Imports shared with the library don't need bounds
Support GHC 9.8, bump upper bounds, and update CI (#1828) Make sure Swarm builds with the most recent versions of dependencies. The only one that is still lagging is `filepath`, but `servant` doesn't support `filepath-1.5` so Swarm can't either. The only real update needed was due to some breaking changes in `aeson-2.2`, but the necessary changes were very minor. Also fixed a few places where GHC 9.8 is generating additional warnings. Also update our CI: `haskell-ci` recently dropped support for `hlint`, in favor of projects defining their own standalone `hlint` workflows.
2024-05-10 22:43:41 +03:00
QuickCheck >=2.14 && <2.16,
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
aeson,
base,
boolexpr,
containers,
filepath,
hashable,
lens,
Parse comments (#1838) 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.
2024-05-12 03:32:21 +03:00
megaparsec,
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
mtl,
tasty >=0.10 && <1.6,
tasty-expected-failure >=0.12 && <0.13,
tasty-hunit >=0.10 && <0.11,
tasty-quickcheck >=0.10 && <0.11,
text,
time,
vty,
witch,
Refine unit test dependencies (#1804) 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?
2024-04-25 22:20:31 +03:00
build-depends:
Split out `swarm-doc` and `swarm-tui` sublibraries (#1834) Split the final remaining default library into `swarm-doc` and `swarm-tui`. Closes #1043 .
2024-05-11 05:08:49 +03:00
swarm:swarm-doc,
Refine unit test dependencies (#1804) 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?
2024-04-25 22:20:31 +03:00
swarm:swarm-engine,
swarm:swarm-lang,
swarm:swarm-scenario,
topography sublibrary (#1836) 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.
2024-06-02 23:53:34 +03:00
swarm:swarm-topography,
Split out `swarm-doc` and `swarm-tui` sublibraries (#1834) Split the final remaining default library into `swarm-doc` and `swarm-tui`. Closes #1043 .
2024-05-11 05:08:49 +03:00
swarm:swarm-tui,
Refine unit test dependencies (#1804) 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?
2024-04-25 22:20:31 +03:00
swarm:swarm-util,
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
hs-source-dirs: test/unit
default-language: Haskell2010
ghc-options: -threaded
Add parser test and fix missing semicolon between defs (#86)
2021-09-28 05:39:39 +03:00
Test example `.sw` files to see if they type check (#233) Closes #180 Add `Integration.hs` which reads files from `example` folder and runs `processTerm` on the contents. The test passes if creating a term is successful. Currently only one example i.e. `zigzag.sw` is failing.
2021-10-19 05:49:32 +03:00
test-suite swarm-integration
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
import: stan-config, common, ghc2021-extensions
main-is: Main.hs
type: exitcode-stdio-1.0
build-depends:
-- Imports shared with the library don't need bounds
base,
containers,
filepath,
fused-effects,
lens,
mtl,
tasty >=0.10 && <1.6,
tasty-hunit >=0.10 && <0.11,
text,
witch,
yaml,
Split out `swarm-doc` and `swarm-tui` sublibraries (#1834) Split the final remaining default library into `swarm-doc` and `swarm-tui`. Closes #1043 .
2024-05-11 05:08:49 +03:00
build-depends:
swarm:swarm-doc,
swarm:swarm-engine,
swarm:swarm-lang,
swarm:swarm-scenario,
swarm:swarm-tui,
swarm:swarm-util,
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
hs-source-dirs: test/integration
default-language: Haskell2010
ghc-options: -threaded
Add some benchmark (#129) Add a benchmark measuring the time it takes to run 1000 ticks of the growing 10, 20, or 30 trees.
2021-10-01 14:59:34 +03:00
Upload and parse scenarios (#1798) 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?)
2024-04-25 23:11:11 +03:00
test-suite tournament-host
import: stan-config, common, ghc2021-extensions
main-is: Main.hs
type: exitcode-stdio-1.0
build-depends:
SHA,
base,
bytestring,
http-client,
http-types,
nonempty-containers,
tasty,
tasty-hunit,
warp,
build-depends:
swarm:swarm-engine,
swarm:swarm-tournament,
hs-source-dirs: test/tournament-host
default-language: Haskell2010
ghc-options: -threaded
Add some benchmark (#129) Add a benchmark measuring the time it takes to run 1000 ticks of the growing 10, 20, or 30 trees.
2021-10-01 14:59:34 +03:00
benchmark benchmark
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
import: stan-config, common, ghc2021-extensions
main-is: Benchmark.hs
Add wave program to benchmarks (#1576) * 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.
2023-10-09 07:45:27 +03:00
hs-source-dirs: test/bench
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
type: exitcode-stdio-1.0
build-depends:
base,
containers,
extra,
lens,
mtl,
topography sublibrary (#1836) 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.
2024-06-02 23:53:34 +03:00
tasty-bench >=0.3.1 && <0.4,
text,
build-depends:
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
swarm:swarm-engine,
swarm:swarm-lang,
swarm:swarm-scenario,
topography sublibrary (#1836) 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.
2024-06-02 23:53:34 +03:00
swarm:swarm-topography,
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
swarm:swarm-util,
Add some benchmark (#129) Add a benchmark measuring the time it takes to run 1000 ticks of the growing 10, 20, or 30 trees.
2021-10-01 14:59:34 +03:00
default-language: Haskell2010
autoformat cabal file (#1769) Closes #1709.
2024-02-19 23:07:15 +03:00
ghc-options:
-threaded
-with-rtsopts=-A32m
-fproc-alignment=64
Reference in New Issue Copy Permalink