- Avoid using a deprecated Cabal function
- Use newer versions of proto-lens packages in stack.yaml
- Work around a new type-level warning that affects `OneOf/TensorTypes`.
Use the same trick as for `proto-lens-protoc`: hack the package description
during the `sdist` step to include the autogen directory in hs-source-dirs.
- Add LICENSE files for all packages.
- Add descriptions for packages that were missing one.
- Work around google/proto-lens#69 by symlinking third_party into
tensorflow-proto.
* Switched to lts-8.13, added custom-setup.
Our packages no longer elicit complaints like this:
Package tensorflow-foo uses a custom Cabal build, but does not use a
custom-setup stanza.
* Removed some extra-deps and explicit-setup-deps
* Removed provisions for different versions of stack lts.
We are now solidly in the 8-only territory.
Adds a new type `ListOf` which wraps a heterogeneous list; for example,
`ListOf (Tensor Value) '[Int32, Float]` represents a list of two
elements: a tensor of int32s and a tensor of floats.
Also changes the `Queue2` type (which suppored pairs of tensors) to
`Queue` (which supports arbitrary lists).
This change allows us to reenable the rest of the ResourceHandle ops, and
future-proofs us against more being added. It removes the custom logic that
assumed there was a "dtype" attribute to guess what the type parameter is
(which wasn't true in general.)
When we switch to ResourceHandle (e.g., for queues and variables) we can add
parameters to the wrapper types like "Queue" on a case-by-case basis.
- More heterogeneous list ops
- Resource ops that don't use "dtype" as the type parameter
For the latter, we may need an upstream fix, or else to change the convention
of how we can tell what the type parameter is.
We should treat such attributes as regular `DataType` values rather than type
parameters; otherwise we'll get ambiguous types. As with other attributes,
they can either set by default or passed in as an explicit argument to the op.
Allows us to reenable a couple more ops.
Also removes all the ghc-8-specific logic in the .cabal files.
ghc-8 has issues with deeply nested tuples of constraints. We can
work around it by:
- Changing TensorTypes to a regular class. This required FlexibleContexts.
(But we'll probably need it anyway when we support heterogeneous tensor
lists.)
- Specializing NoneOf for long type lists.
For more details, see: https://ghc.haskell.org/trac/ghc/ticket/12175.
Also added 'directory' to tensorflow-core-ops' dependencies since it's used
in the Setup script.
One more step towards fixing #38.
Two issues:
- The definition of `\\` was missing parentheses. It was probably a bug
that this used to worked in ghc-7.10.
- Set `-fconstraint-solver-iterations=0` to work around
https://ghc.haskell.org/trac/ghc/ticket/12175. It looks like we can
trigger that bug when defining a significantly complicated op. Specifically,
our type shenanigans ("OneOf") along with lens setters (for OpDef) seem
to confuse GHC.
Still TODO: automate testing of different ghc versions to prevent a regression.
* No longer need to hide ResourceHandle ops
* Blacklisted not supported TensorArrayV2
* Ownership of feed tensors changed (1f0c5119a0230c5160d45496175b9256f097e144)
