| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
It turns out persist does support these, they're just not mentioned in
the yesod book.
(for future reference, the syntax is defined in Database.Persist.Quasi,
which does include some documentation [1])
[1] https://hackage.haskell.org/package/persistent-2.14.6.1/docs/Database-Persist-Quasi.html
|
| |
|
|
|
|
|
|
| |
A simple way to have "announcements" available via API, and otherwise
distinct from the service announcements which show up in Gtfs Realtime.
These are meant to go e.g. be embedded on the operator's website, or in
other places where it's not as easy to display per-trip specific messages.
|
| |
|
|
|
|
|
|
| |
now takes all potential stops along each trip into account when guessing
tickets; also checks if a ticket is still likely in case the tracker
switched its direction. This should solve many cases where a tracker is
accidentally turned off or falls asleep halfway before the last station
of one trip, then wakes up in the middle of the next.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This should hopefully be the final (major) part of the restructuring: a
tracker no longer has to know which trip it is on (and indeed it has no
idea for now), instead the server keeps state about which trips are
currently running and will insert incoming pings in a hopefully
reasonable manner, based on their geoposition & time.
There's lots of associated TODO items here (especially there should be
manual overrides for all this logic in the web ui), but that's work for
a future me.
(incidentally, this also adds support for sending all log messages out
via ntfy-sh)
|
| |
|
|
| |
now mostly independent of the gtfs, but still no live-reloading of it.
|
| |
|
|
|
|
| |
this is mostly meant to guard against the gtfs changing under
tracktrain, and not yet complete (e.g. a ticket does not yet save its
expected stops, which it probably should).
|
| |
|
|
|
| |
jumps to GHC2021 as default language, adds in some fields, moves the old
org mode glossary to markdown, etc.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
most of it deals with timezones, and all the weird implications that has
|
| |
|
|
| |
(also some database schema changes, for good measure)
|
| |
|
|
| |
still basic, but works pretty well overall
|
| |
|
|
| |
aka use something meant for webapps to write the webapp
|
| | |
|
| |
|
|
| |
(it can do useful stuff! but it also still breaks on some things!)
|
| |
|
|
|
|
| |
tbh i've kinda lost track at what has all been changed in this, but the
control room form handling now works, and i can write announcements into
the database. Now on to making it do useful things!
|
| | |
|
| |
|
|
|
|
| |
(or at least something that looks like it might be correct — though
it carries very little information, and lacks things like what the next
stop along the route is)
|
| |
|
|
| |
(kinda barebones, but the important things should be there)
|
| |
|
|
|
| |
unfortunately, this makes some responses pretty large. Let's see if it
works this way or if i have to find some way to break them up instead.
|
| |
|
|
|
| |
might eventually be needed; until then they're just scaffolding so I
don't loose sight of things
|
| |
|
|
|
|
| |
(and they can be useful, too!)
Also, documentation & deleting imports / extensions that aren't used.
|
|
|
(at least for a few simple things)
Also, more modules!
|
