* Delete the (apparently unused) EntId
* Rename edn's Entid to EntidOrIdent to avoid confusion with the Entid that's actually an i64
* Fix travis beta bustage (This is actually unrelated to entids, but is a trivial fix nonetheless)
Steps to building docs locally:
1. Install Jekyll
2. cd docs
3. bundle exec jekyll serve --incremental
4. open local docs site at http://127.0.0.1:4000/
* basic Jekyll site
* Add docs to documentation site
* Update javadoc to allow for error free builds
* Remove docs for rust dependencies
* Better display examples, about and contributing documentation for Mentat
* Version docs
It's not possible to do meaningful clean-up (such as saving history)
if we use exit() to quit. Instead, each handled command returns a
boolean requesting exit. I elected not to allow ".exit" when
processing commands from the command line; it might be useful to
handle accept that. In general, though, REPLs that accept "-c
'commands'" on the command line exit after processing those commands,
so I'd rather think more deeply about that model than build in ".exit"
with our existing system.
I don't really understand why we were using `linefeed::Reader`
directly, but reading is not the full set of linefeed features we want
to access. I think the `linefeed::Interface` should be owned by the
`Repl`, not the `InputReader`, but it's a little awkward to share
access with that configuration, so I'm not going to lift the ownership
until I have a reason to.
I think the "--no-tty" argument might be useful for running inside
Emacs. Along the way, I made read_stdin() strip the trailing newline,
which agrees with InputReader::read_line().
What was happening is that ["[;", "]"] would get glued to "[; ]",
which of course can never complete.
It would be good to add tests of this, but the existing multi-line
`InputReader` makes that challenging and I don't want to invest the
time to improve it: I expect it to be overhauled as part of a
transition away from parsing with `combine` and toward parsing with
`rust-peg`.
This is neat, because currently at the FFI boundary we're primarily concerned
with verbalizing our errors. It doesn't matter what 'error' that's wrapped by
Result is then, as long as it can be displayed.
Once we're past the prototyping stage, it might be a good idea to formalize this.
Principally, this adds producing libmentat_ffi.a for consumption by Carthage.
To achieve this, we disable bitcode and bump the miniumum iOS version
to 11. In addition, we make things open and public so that consumers
can, well, consume.
This is a big deck-chair re-arrangement. This puts FindQuery into
query-algebrizer and puts the validation from ParsedFindQuery ->
FindQuery their as well.
Some tests were re-homed for this.
In addition, the little-used maplit crate dependency was replaced with
inline expressions.
There's an unfortunate conflation here between implementing the query
parser in `rust-peg` and moving some validation that now happens at
parse time to happen later. The result is that we introduce
`ParsedFindQuery` as a less-processed `FindQuery`, and that we only
use string errors (which is all `rust-peg` supports) instead of the
structured errors in query-parser's errors module. The next commit
will address this, on the road to removing the `query-parser` module
entirely.
This is a pre-requisite for moving the existing `combine`-based parser
to use `rust-peg` -- part of the push to use `rust-peg` for all parsing
started in https://github.com/mozilla/mentat/pull/681. We need the
types for the parsed structure "very early", and the `edn` crate is
the earliest such crate.
This is an unfortunate destruction of boundaries between parts of the
system, but it's the best way we have to achieve this right now.
This is a style choice. We supported both, perhaps for Datomic
compliance, but it's not the standard we use in our code base. In
addition, it doesn't read like lisp (which is what EDN is copying),
since [] is not function application in most lisps.
It's also a convenience: I don't want to parse brackets that have to
agree with `rust-peg`. It's not hard but it's also not worth doing.
