| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
Right now, this is capable of setting up a running instance of picarones
in a couple lines of config (both backend server and the webapp, using
nginx).
More options should still be added, especially to make the backend's port
configurable (but this requires adding features to the haskell code)
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
to prevent noticable load times when switching slides, picarones previously
loaded all slides at once, and then only displayed whichever one was applicable.
This cause problems with larger slidesets; instead, it now loads the current
slides and the two previous and next slides (wrapping around at the end/beginning).
|
| |
|
|
|
|
| |
Syntax is: https://domain-to-app#<prefix-for-slides>#<number-of-slides>
Slides must be .png image files numbered as 01.png, 02.png ...
|
| |\
| |
| |
| |
| |
| | |
git-subtree-dir: picarones-elm
git-subtree-mainline: 2ad5d413aa958a1c2fe75ce7aa155576e9a80345
git-subtree-split: f4a1ee55987b7c58745dc5865c4ecf30874a3564
|
| | |
| |
| |
| |
| | |
Somewhat basic for now, but it does build a directory with a functioning
website inside of it.
|
| | |
| |
| |
| |
| | |
(modified, to make it work again — elm2nix generates somewhat obstuse and
occasionally useless code)
|
| |
|
|
|
|
|
|
| |
Everything works, EXCEPT:
- choosing slidesets
- choosing rooms
- choosing the number of slides
at runtime.
|
| |
|
|
| |
Idea: have all components of this program in one repository
|
| |
|
|
| |
makes a derivation with a functioning server inside of it.
|
| |
|
|
|
| |
(mostly to reduce the number of record types needed, and to deal with
multiple possible types of client messages)
|
| |
|
|
|
| |
(before, the server just sent "state [n]" on state change, instead of
a properly serialised json value)
|
| |
|
|
|
|
|
|
| |
The main server state is now a `HashMap` of `Text` to `MVar Room` instead of
just `Room`. This allows for changing room states independently from the
server state, which should make the entire thing scale better on multi-core
architectures (nevermind that "switching slides" is presumably not something
in much need of multicore servers ...)
|
|
|
So far, it is fairly inefficient — for each message, the global
state of the application is changed (i.e. a read-write action
on a HashMap). Since clients can't change rooms after joining
anyways, this should probably be changed.
|
