Although this isn't _exactly_ a user-supplied string, it is still
somewhat under their control. Better safe than sorry.
Thanks to @mintsoft for the suggestion.
We're not actually getting a test count from test_zci. Someday soon this
will reconcile exactly with the number of `test_zci` calls you make, but
it clearly does not today (see the extra 2 factor).
Rather than try to predict which version is running these tests, remove
the plan for now.
- Cache by default; only turn off for "scrambled" results.
- Simplify `calc_freq` slightly.
- Remove "length" argument, as it doesn't make sense with anagrams.
- Cache letter frequency info as dictionary words are examined.
- Allow for multi-word queries to match single word anagrams.
This still does not allow for multi-word anagrams. Although it
would be nice to do so, it adds significant computational complexity.
- Add filler_words list which can be stripped from the query before
trying to parse date strings.
- Anchor datestring_regex so as to allow for only date left in query
after clean-up.
- Improve guard against empty strings and `undef` in Dates role parsers.
Fixes#661.
- New date outputs with per-calendar months.
- More standardized CSS.
I'm less than excited that you can't enter the other calendars with
month names, but that'll have to be ok for now.
- Point to metadata docs to help fill out section.
- Reorganize metadata into same order as docs.
- Remove "icon_url" and "source" which do not generally apply to
Goodies.
- Better example strings for the `attribution` section.
- Use "guard" before "work" in example code.
This explicity sets the caching behavior for all goodies. Goodies which
did not have caching behavior set in their package have had it added.
Similarly for the tests.
This resulted in a number of changes for caching behavior, mostly
moving towards more frequent caching.
I identified three cases where goodies should not be cached. They are when
the result depends upon:
- some random element,
- the time of day or year (as with relative dates), or
- the location of the requesting user
In all other cases, I presumed that the goodies were sufficiently
deterministic in their output to warrant caching.