We now build a docker base container based on debian sid (where the very
latest packages are available). That base container is updated once a
month, or whenever travis-build.Dockerfile or debian/control change, but
re-used for subsequent travis runs. While the initial build might take
up to 15 minutes, subsequent builds typically run in a minute or two.
All the different steps that we run on travis are now factored into
separate scripts in the travis/ directory.
Switching to docker should also help with issue #2174.
Change the name of structs CommandResult and ConfigResult to
CommandResultIR and ConfigResultIR to show they are an intermediate
representation used during parsing.
…determining the next state within a function like cfg_criteria_pop() by
passing next_state in the ConfigResult (or CommandResult) and using it
after calling.
e.g. pressing Mod1+x when having the following in your configfile:
bindsym Mod1+x some invalid command
will lead to an i3-nagbar instance popping up, offering you to view the
error log (which will contain parser errors from this commit on).
This change has two implications:
1) tree_render() will now be called precisely once for input which consists of
multiple commands (like "focus left; focus right"). Also, the caller of
parse_command() has to call it. This makes us able to fix tickets such as
ticket #608 (where multiple tree_render() calls are noticable).
2) The output of a command is now a JSON array of return values of the
individual subcommands. In the case of "focus left; focus right", this is:
[{"success":true}, {"success":true}]
While this is incompatible with what i3 returned before, the return value of
commands was undocumented and therefore not subject to our API stability.
On the rationale of using a custom parser instead of a lex/yacc one, see this
quote from src/commands_parser.c:
We use a hand-written parser instead of lex/yacc because our commands are
easy for humans, not for computers. Thus, it’s quite hard to specify a
context-free grammar for the commands. A PEG grammar would be easier, but
there’s downsides to every PEG parser generator I have come accross so far.
This parser is basically a state machine which looks for literals or strings
and can push either on a stack. After identifying a literal or string, it
will either transition to the current state, to a different state, or call a
function (like cmd_move()).
Special care has been taken that error messages are useful and the code is
well testable (when compiled with -DTEST_PARSER it will output to stdout
instead of actually calling any function).
During the migration phase (I plan to completely switch to this parser before
4.2 will be released), the new parser will parse every command you send to
i3 and save the resulting call stack. Then, the old parser will parse your
input and actually execute the commands. Afterwards, both call stacks will be
compared and any differences will be logged.
The new parser works with 100% of the test suite and produces identical call
stacks.
