* OperatorBase should not store OpDesc because not All op contains an
OpDesc and not all ops create from OpDesc.
* Networks do not contain OpDesc and are not created by OpDesc
* Do not register Network to OpRegistry.
* The network is directly created by the user in Python. Not from
registry.
* Correctly handle the `inputs` and `outputs` of a Network.
* Add CompleteAddOp() methods
* Remove `AddOp(OpDesc&)` in net-op. All op are added by OperatorPtr.
* Rewrite unit test for truly tested what networks do.
* optimise operator_test
Add OperatorBase.
issue: https://github.com/PaddlePaddle/Paddle/issues/2790
Paddle design the Operator with Kernel. OperatorBase has no type and device information when create, One operator can have multiple kernels, Operator will choose a kernel to run according to context. The kernel should be bind to Operator before or during Operator running.
* Move static variable defined in .cc
We cannot define static variable in .h, because it will be multi-defined
errors.
Also fix some cpp syntax, like:
* Prefer to use algorithm not manually for-loop, to make code more
readable.
* Remove unused `()`.
* Enforce take a bool. It is no need `xxx==true`.
* Use range-based for-loop iterator from op_desc.attrs
* Fix a protential static variable init order error
* init op_registry.h
* dev op_registry.h
* add 'attr_checker.h', which is a draft of op attribute checker.
* rename some macro parameters
* 1. Use `Attribute` and `AttributeMap` instead of `OpDesc`. `AttributeMap` is a unordered_map of <string, Attribute>, and `Attribute` is a boost::variant object to hold multiple types of attribute value.
2. Use `PADDLE_ENFORCE` to print checkers' fail message.
3. Abstract default value operations to a new function: `DefaultChecker`.
* rename DefaultChecker to DefaultValueSetter
ZZ
* Finish op_registry
1. Complete the development of interfaces between OpRegistry and
Protobuf.
2. Add unit test for op_registry.h
* Add demo and test of custome checker
* fix merge conflict
Python should be able to manipulate Protobuf message because:
1. Python's `create_op_creation_methods` take the `OpProto` array to
generate all `op_creation_methods` in RunTime.
2. All `op_creation_methods` will create an `OpDesc` and pass it to
Paddle C++ method `CreateOp` and return the Op handle.
Here is the list of what is added in this commit:
* Add `protobuf_generate_python` if it is not defined.
* Before cmake 3.4, `protobuf_generate_python` is not defined. Just
copy the implementation of that function in `protobuf.cmake`
* Add `py_proto_compile` function in `cmake/generic.cmake`.
* It follows bazel's API interface.
* https://github.com/pubref/rules_protobuf#rules
* Add an empty package named `paddle.v2.framework`, all python code of
`paddle::framework` will be in that package.
* Generate protobuf's python module `__init__.py` by `touch` while
compiling.
* Change setup.py.in, make `paddle.v2.framework.proto` uses the
generated protobuf pythons.
* add op_desc.proto
In Operator design, we need a proto message to describe an Operator.
Third-party language such as python can build this proto message and use
AddOp(const OpDesc& op_desc) of Paddle core to construct an Op in the
Network.
It will fix#2728.
Maybe it is silly to `target_link_libraries` for static library,
because a static library do not need to link other libraries. But
it will tell cmake how to propagate dependencies.
The solution comes from
[here](http://floooh.github.io/2016/01/12/cmake-dependency-juggling.html).
* Also change op_proto_test DEPS for testing this fix works.
OpProto is a proto message that helps 3rd-party language bindings, e.g.
`Python`, to generate operator creation methods. The operator creation
method is the low-level API for 3rd-party language bindings. Op creation
methods take the user's input in that language, and convert users inputs
into `OpDesc` message, then passing that `OpDesc` message to Paddle's
C++ core and create an operator.
* A separated `attr_type.proto` is added, because that file wound
be included by `op_desc.proto` in future.