When erlware_commons logs to the command_line, it assumes the
environment has common modern capabilities and color display. In
general, this is not the case and then color codes are sent verbatim
to the terminal.
This patch introduces a new field in #state_t{}, term_cap, encoding
if the terminal runs with 'full' or 'dumb' capabilities. In the latter case,
color display is suppressed. Initialization of the #state_t{} record queries
the environment once for the TERM variable in order to figure out what
it supports. The default is 'full' capability to be fully backwards compatible.
v17 does not have the leading 'R'
```
erl -noshell -eval 'io:format("~p", [erlang:system_info(otp_release)]), erlang:halt(0).'
"17"
```
So the dialyzer wouldn't run in the Travis builds.
And a minor spec fix to appease v17's dialyzer.
This patch makes erlware_commons easier to include as a dependency by
removing depedencies that are not needed at run time.
The top-level Makefile creates a .DEV_MODE marker file which is
detected by rebar.config.script. When the marker file is present, the
development only dependencies proper and neotoma are included and a
macro 'DEV_ONLY' is defined. The macro is used to only enable the
proper tests for development mode.
The ec_semver_parser.peg is now located in priv/ and is moved into
src/ by the Makefile. The generated ec_semver_parser.erl is now under
version control; it need not be rebuilt by all projects wishing to
include erlware_commons. It will be rebuilt, as before this change, on
every make invocation.
This started with just trying to parse the date format:
December 21st, 2013 7:00pm, which was failing with a bad_date error.
The solution involved setting up "Hinted Months", which was just a term
I used to indicate that a month was specified by name (ie "December"),
rather than by number (ie, "12"). Previously, named months were simply
replaced by their respective numbers in the parser. This tags those
named months so that the parser will unambiguously parse them correctly.
A tagged "Hinted Month" is simply a tuple with the tag `?MONTH_TAG`. For
example: "December" gets converted to `{?MONTH_TAG, 12}`
For example: "Aug 12" and "12 Aug". It's clear to the *reader* what is
meant, but when converted to simply 8 and 12, the parser has no way of
knowing which is which.
Doing this was aided with the addition of some macros to help it
along, since doing just straight comparisons with the hinted months was
yielding unexpected results. For example: `{mon, 1} > 31` returns
true, so changing that comparison to an ?is_year/1 macro that does:
`is_integer(Y) andalso Y > 31`.
It might not be a bad idea to help the parser be *very* unambiguous by
putting these macros on all comparisons.
Signed-off-by: Jordan Wilberding <diginux@gmail.com>