Yes it is starting with Scala APIs, but the APIs themselves are generated
from the backend. I am not sure how it is handled for the Python but it
will more likely be impacting all language bindings.
On Thu, Jun 21, 2018 at 10:50 AM, Hao Jin wrote:
> Can you elaborate on how this change is bringi
Can you elaborate on how this change is bringing "alignment on the
modifications to the operators across language bindings"? Seems like this
PR is generating a hash from the scala files instead of the backend apis,
how would this benefit other language bindings?
Hao
On Thu, Jun 21, 2018 at 10:44 A
Thank you all for your input, I want to reiterate that this work is not to
burden anyone but to bring alignment on the modifications to the operators
across language bindings. I agree with Marco/Qing and we'll start off as a
nightly runs and identify changes, we can discuss further later after we
g
Thanks Jun for your clarification. I think one of the advantages for MXNet is
it's language binding. Although the number of customers using Scala is great
less than Python, it is still one important language we need to support.
About the first question, I would say we all in. At least all break
We should reach an agreement on the responsibility/ownership before moving
forward.
1. Who will take the ownership of fixing Scala build failure if an operator
is changed/added in C++?
2. What is the expected turn around time of fixing the scala build failure.
3. What if we are short of resources
Hi All,
Thank you all for your feedback. This changes do influence a lot on the PRs
related to operator changes. I will take what Marco proposed to place that in
the nightly build rather than every CI we runs.
Thanks,
Qing
On 6/20/18, 8:40 PM, "Hao Jin" wrote:
I don't think we should k
I don't think we should keep this hash check thing. As Qing stated before
on this thread, if there's any change in documentation the hash value is
also changed and then flagged as a problem, how will that break any user's
code? I would go for something like Marco's proposal: moving this to an
async
Agreed, for new APIs we can turn into a nightly job and report on dev@. The
goal here is not to burden anyone but to catch changes on the backend
before it propagates and break user's code and co-ordinate changes across
language bindings which IMO is essential, so I would like to keep for
changes o
I think we should go with an asychronous approach using a nightly job that
detects the changes and reports them accordingly. We could then send out a
report if there is a mismatch.
I agree with the already stated points that we should not put the burden of
adding frontend API bindings to somebody
I understand the concerns here. However the problem here is that since the
Scala APIs are generated using Macros and we do not(may not ever) have full
test coverage on each of the APIs, we will not know for example if an
operator/API changes on the backend and that propagates to Scala users,
their
Hi Qing,
What is the exact risk of changing / adding operators? could you
provide an example? I also feel the way you proposed is little bit too
heavy to developers, and not quite friendly to new contributors.
On Wed, Jun 20, 2018 at 10:22 AM Haibin Lin wrote:
>
> I appreciate the effort and under
I appreciate the effort and understand the motivation. However, I'm
concerned that it basically means merging operator PRs becomes sequential.
Developers who work on operators have to update their PR every time a new
operator is merged to master, the burden becomes significant if there're 20
ONNX/s
I don't think it's reasonable to fail on purpose in Scala when changing
documentation or adding operators in C++. At least, it should follow the
same behavior as we have for Python binding.
On Wed, Jun 20, 2018 at 10:13 AM Qing Lan wrote:
> Hi Haibin,
>
> The operator change is any changes on th
Hi Haibin,
The operator change is any changes on the operator on C++ side. Trigger the
check failed?
- change the documentation of operator in C Yes
- change the documentation such as README.md No
- add/remove/modify operator
Could you elaborate what you mean by operator change? Does it check the
operator interface? Would updated operator documentation fail the check?
Would adding a new operator fail this check?
On Wed, Jun 20, 2018 at 9:48 AM, Qing Lan wrote:
> Hi Macro,
>
> Thanks for your feedback! I believe thi
Hi Macro,
Thanks for your feedback! I believe this should not be a block for contributor
in most of the cases.
Firstly, this would only be triggered if there is an operator changes (Only
general operators).
Secondly, it is simple to go through. Just need to change 1 line of code would
make th
Okay, thanks for elaborating. I definitely see your point there and we
definitely don't want these changes to pile up.
I don't feel strongly about this and won't stand in the way, I just want to
express my concern that this could lead to people having to touch all
language interfaces although they
Marco,
Qing and I are working together on this. The idea is that we fail the build
if there is a operator change on the backend and have not synced to the
Scala API. We want to catch this before breaking the user's code which will
be a pretty bad experience.
On Tue, Jun 19, 2018 at 11:54 AM, Ma
Hi Qing,
thank you for working on improving the compatibility of our APIs!
Your linked proposal does not describe the mentioned FILEHASH. Could you
elaborate a bit? Would this be a hash of the entire file, some hash created
based on the signature of the underlying C++ methods or maybe a different
Hi all,
I am one of the maintainer for MXNet Scala package. Currently I am building up
a hash-check system on the generated API through C. The PR is in this URL:
https://github.com/apache/incubator-mxnet/pull/11239
A file named FILEHASH will be added to the Scala that created the MD5 string of
20 matches
Mail list logo
