These are all minor and uncontroversial enough it just felt gross
making multiple commits.
- Adds marseymummified.
- Changes the new `raise ValueError(...)` in badge_grant to
an `assert`.
- Expands assetcache to a convenient grab bag of JS files.
First, the apparent errors with >= 9 and 99 in the Marseys and
referrals code after the refactor are not actually bugs: they were
bug fixes mixed in with the refactor to fix an off-by-one.
Next, instead of failing silently on the `not user` branch in
badge_grant, we throw a ValueError. This retains the current
behavior where users get 500s to report while also enforcing the
assertion near the edge of the function.
Despite being very fun, this fixes the recently discovered bug where
placing '#' or '!' within the 'pat:' suffix of a patted emoji causes
the enclosing <span> to not be given the proper CSS `display` or
`position`, leading to the hand being sized relative to the comment
bounding box rather than the emoji box.
This should be backward compatible. The only posts it wont fix are
existing ones with the giant hands. Main example being:
https://rdrama.net/h/slackernews/post/76302/
grant_lottery_tickets_to_user incorrectly deposited the full ticket
value into manager account, not just the net value.
Additionally, royalty rate has been set to zero because Chapose won
the first lottery and grifting 8% that could instead go into the
prize pool seems unwarranted given that.
Prior to this comment, the every-1d cron.py command was broken due
to lack of proper stats import. However, while refactoring this, it
was convenient to move other recurring tasks that had been stuffed in
odd places--not least `stats(...)`--into the new cron system. This
entailed a number of refactorings of other things.
1. Move stats(...) from static.py to helpers/stats.py.
2. Move hole inactivity purge task from stats(...) to routes/subs.py.
3. Move bot award timer checks from stats(...) to helpers/awards.py.
4. Unify award timer logic formerly in routes/front.py into the new
helpers/awards.py.
h/t @official-techsupport again for finding another optimization.
We are now cumulatively at about 70% speedup over original.
It remains one of the hottest paths of the codebase in relative
terms, but its absolute performance demands have decreased enough
to buy us potentially substantial time on it.
h/t @official-techsupport for digging into the regex performance and
coming up with one that greatly reduces backtracking. We see an
approximately 2x speedup under typical loads, which proves to be a
major overall savings in performance. Previously, censor_slurs was,
second to ORM DB accesses, by far the most time-consuming function
in the codebase under typical loads. It's still not ideal, but it is
much better.
Future options to improve this critical path further would be:
1) Precompute a slur-replaced HTML, rather than recomputing
each pageload. Storage is cheap.
2) Tokenize the HTML and replace plaintext words using O(1)
exact-match lookups to a dict.