| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
this is still far from being supported by most libraries, but does make
it possible to remove some uses of String (though most times, there is a
conversion back to String later).
Note that using the default.nix now only works on nixpkgs-unstable for a
bit; using the newer filepath package on stable leads to broken other packages.
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
this does svg templating with hamlet. It might be better to use a
javascript library instead (templating svgs is a little confusing tbh),
but for now i'll see how far i get with this.
|
| | |
|
| |
|
|
| |
this is the initial version used during 2024's Ilztalbahn season.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
I do not really like either option, but at least the second one seems
more likely to be maintained (and a little less clunky to use, too, for
what it's worth).
|
| |
|
|
| |
this makes the nix builds /much/ nicer
|
| |
|
|
|
|
| |
this is unfortunately uffd-specific, since oauth2 is apparently sort of
a vague standard. But since it doesn't actually do much it should
probably be possible to make it fully configurable & generic if needed.
|
| | |
|
| |
|
|
| |
(apparently i didn't do that yet???)
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
works kinda well, but doesn't complain about unknown config values in
json, which is kinda hmpf tbh
|
| |
|
|
| |
most of it deals with timezones, and all the weird implications that has
|
| | |
|
| | |
|
| |
|
|
| |
still basic, but works pretty well overall
|
| |
|
|
| |
aka use something meant for webapps to write the webapp
|
| |
|
|
|
|
| |
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!
|
| |
|
|
| |
this does some GHC generics witchery, now in its own module!
|
| | |
|
| |
|
|
| |
(tough mostly untested)
|
| | |
|
| |
|
|
| |
(kinda barebones, but the important things should be there)
|
| |
|
|
|
|
|
|
| |
this adds a package for protobuf stuff, generated via hprotoc. Seems to
work kinda fine?
(the generated API is horrible though, will have to write some wrappers
for that)
|
| |
|
|
|
| |
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.
|
| |
|
