mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marco de Abreu <marco.g.ab...@googlemail.com.INVALID>
Subject Re: The operator check for Scala Package
Date Tue, 19 Jun 2018 18:54:19 GMT
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
approach?

Also, at which step would developers be notified of the change? I'd propose
that we make this check a nightly job to prevent it from blocking a PR and
forcing contributors who are not familiar with Scala having to make a
change to the Scala package. This would allow us to follow up
asynchronously but still provide actionable events that one can be
subscribed to.

Best regards,
Marco

On Tue, Jun 19, 2018 at 11:00 AM Qing Lan <lanking520@live.com> wrote:

> 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 the generated API document. It will check the signature of all
> the operators during Scala CI testing. The reason I am doing this is to
> make sure Scala developers will always be reminded if there is an operator
> name/argument changes happened in different PRs. More detailed info
> explained in here:
>
> https://cwiki.apache.org/confluence/display/MXNET/MXNet+Scala+API+Usability+Improvement
>
> Pros:
> This method will always help us keep backwards compatibility of operators
> for Scala
> Cons:
> Require update on the FILEHASH with new contents when there is an operator
> change. Developers who changed the operator should `make scalapkg` to
> update that file.
>
> Please leave any thoughts you may have for this design and feel free to
> review the code.
>
> Thanks,
> Qing
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message