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.
The `Keyword` type evolved to become more general: we now use the one
type for both :regular and :name/spaced keywords. This changes
reflects the new generality.
This uses a `SELECT *` from an inner subselect to filter potentially `NULL` aggregates.
The alternative is to handle `NULL` values throughout the projector, which is simple but loses a valuable invariant: Mentat SQL queries produce values that are not `NULL`.
* Add an IntelliJ section to gitignore
* Add Android SDK sample project which exercises mentat SDK
* Symlink libmentat_ffi.so in Android SDK to the generated --release files
* README files for Android SDK and mentat_ffi
* Include the namespace-separating solidus in NamespaceableName.
* Use type annotations when deciding how to process ambiguous ground input.
* Include simple patterns in the type extraction phase of pattern application. (#705)
* Review comment.
* Add a test.
`CacheDirection` enum is used only on the Android side to provide a usable interface. FFI calls are more explicit.
Tests ensure that a cached query is faster than the uncached one.
`CacheDirection` enum is used only on the Swift side to provide a usable interface. FFI calls are more explicit.
Tests ensure that a cached query is faster than the uncached one.
This exposes an FFI function for each direction of caching, `Forward`, `Reverse` and `Both`. This is to make is as clear as possible to consumers which direction they are caching their attributes in. The original implementation exposed the `CacheDirection` enum over FFI and it made mistakes very easy to make. This is more explicit and therefore less prone to error.
