Upload and parse scenarios #1798
Conversation
kostmo
force-pushed
the
feature/tournament-hosting
branch
3 times, most recently
from
321a4d1
to
3f8286d
Compare
kostmo
force-pushed
the
feature/tournament-hosting
branch
from
3f8286d
to
6da06aa
Compare
kostmo
force-pushed
the
feature/tournament-hosting
branch
4 times, most recently
from
4720e00
to
cf1baf9
Compare
kostmo
changed the base branch from
main
to
refactor/support-tournament-hosting
Prerequisite to #1798 ## Changes * Pass the final `TickNumber` count as a member of `Won` constructor so that it can be used in scoring submitted solutions * Extract a helper function `codeMetricsFromSyntax` that can be reused by tournament server * `ToJSON` instance for `ScenarioMetadata` * New script `list-sublibraries.sh` to list the sublibraries defined in a package
kostmo
changed the base branch from
refactor/support-tournament-hosting
to
main
kostmo
force-pushed
the
feature/tournament-hosting
branch
from
cf1baf9
to
c4c0546
Compare
There was a problem hiding this comment.
This is amazing! Now I know why I hadn't heard anything from @kostmo in a while. 😉
Besides a few minor comments/questions, I think the biggest issue is that we need to configure things so that by default, doing a cabal build does not build the tournament server, so it does not need to download and build servant, postgresql-simple, etc. Most people building swarm from source will not need all this so we should save them the trouble; anyone who actually wants the server can enable a flag. I think we should be able to do this by creating a flag in the .cabal file and marking relevant libraries + executable stanzas as buildable: false conditional on the flag. Or maybe there is a better way to accomplish this with modern cabal, I'm not sure.
I did not test actually building the server myself but I was able to test uploading a solution to one of the scenarios listed on swarmgame.net.
| @@ -429,6 +429,56 @@ library swarm-web | |||
| -- See discussion in #415 | |||
| StrictData | |||
|
|
|||
| library swarm-tournament | |||
There was a problem hiding this comment.
Replying to the toplevel review comment here, so that the discussion can be properly threaded.
I think the biggest issue is that we need to configure things so that by default, doing a
cabal builddoes not build the tournament server, so it does not need to download and build servant, postgresql-simple, etc. Most people buildingswarmfrom source will not need all this so we should save them the trouble; anyone who actually wants the server can enable a flag. I think we should be able to do this by creating aflagin the.cabalfile and marking relevant libraries + executable stanzas asbuildable: falseconditional on the flag. Or maybe there is a better way to accomplish this with modern cabal, I'm not sure.
Recall that the main swarm executable already includes servant, from way back in 2022.
postgresql-simple, however, is a new dependency. I think the simplest way to avoid building postgresql-simple is to pass an explicit target argument to cabal:
cabal build swarm:exe:swarm
As a convenience, we may provide a wrapper script (named build-game.sh) that makes the above invocation.
P.s. there seems to be a bug in stack that builds components/executables that are not requested on the command line. So I think our documentation should explicitly recommend cabal in any places where it doesn't already.
There was a problem hiding this comment.
Recall that the main
swarmexecutable already includesservant, from way back in 2022.
Ah, good point. But avoiding postgresql-simple when not necessary is especially important since it has external library dependencies. When I tried building I got an error about some thing that wasn't installed. Getting it to work would have required me to go figure out which OS package to install that would provide whatever thing was missing, and we definitely don't want to subject casual players to that kind of installation experience. But in any case, I think you're right that simply specifying a particular target like swarm:exe:swarm is the way to go, I had forgotten about that.
P.s. there seems to be a bug in stack that builds components/executables that are not requested on the command line.
Really? It works for me. e.g. when I do stack build swarm:exe:swarm it only builds the libraries needed for the main swarm executable. By contrast just doing stack build builds other stuff like swarm-scene and swarm-docs.
There was a problem hiding this comment.
Really? It works for me. e.g. when I do
stack build swarm:exe:swarmit only builds the libraries needed for the mainswarmexecutable. By contrast just doingstack buildbuilds other stuff likeswarm-sceneandswarm-docs.
Try the following:
- Add a newline to the end of
src/swarm-tournament/Swarm/Web/Tournament/Validate.hs - Run
stack build swarm:exe:swarm - Observe that it recompiles
swarm-tournament, despite that library not being a dependency of theswarmexecutable.
Now do the same cycle, but with cabal build swarm:exe:swarm instead, and observe Up to date is printed.
There was a problem hiding this comment.
Hmm, you're right.
I think our documentation should explicitly recommend
cabalin any places where it doesn't already.
I think I'm convinced. It just means anyone who wants to build from source has to pay more attention to what version of GHC they are using. But these days with ghcup that's pretty trivial.
kostmo
force-pushed
the
feature/tournament-hosting
branch
from
70d5e94
to
ddb28f9
Compare
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.
byorgey
added
the
CHANGELOG
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.shscript and see valid uploads reflected live on the website.Local testing
Automated tests
These are database-agnostic.
Manual tests
These test database interactions. It requires first setting up a local Postgres server.
tournament/scripts/demo/server-native.shin one consoletournament/scripts/demo/client/test-cases/local/good-submit.shin anotherFeatures
Key components
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