master, it is using 1.4.1.
On Thu, Jun 20, 2019 at 6:17 PM Lai Wei wrote:
> Could you share which test failed and what’s the crash? How to reproduce
> I was able to install sockeye and run all tests passed. Using
> python setup.py test
> I h
I was able to reproduce a crash with the commit
09202f7f261954383aa387144524d38f83f18d06 but not with the commit
On Thu, Jun 20, 2019 at 3:53 PM Lai Wei wrote:
> Hi Przemyslaw,
> Is there an issue with more details to track th
are impacted by certain issues, we should just bump up the
version and stop support for 10.0.
Would like to hear more from Nvidia folks (on this particular case of CUDA
10.0 vs CUDA 10.1 and what are the recommendations for existing customers).
On Mon, Jun 3, 2019 at 4:21 PM Dick Carter wrote
ing default lists, and the later
use case may be rare.
On Thu, May 30, 2019 at 3:25 PM Sheng Zha wrote:
> Given that we're swtiching from the practice of failing the AMP related
> test to warning, I intend to merge #15085 soon if no objection.
> On 2019/05/30 19:
a long time before developer realizes
that he has to do this,
thats why I suggested we need to reduce the time it takes for him to
realize that something was missed.
On Tue, May 28, 2019 at 4:57 PM Sheng Zha wrote:
> This is driving people away exactly because they don't know this is wha
Also, this will be very important once we move the feature out of contrib.
On Tue, May 28, 2019 at 3:52 PM Marco de Abreu
> I'm generally in favour of these kind of tests since they make developers
> aware of changes they have to make which they would usually
ught early at the statement "import mxnet".
On Tue, May 28, 2019 at 2:32 PM Przemysław Trędak
> Dear Community,
> One of the recently merged features of the 1.5 release, AMP (Automatic
> Mixed Precision) support (PR , design doc ), introduced a requirement
>From the discussion I had with Nvidia offline they are targeting on pushing
the required changes today.
Since this is important feature for the release, if this gets delayed and
cannot be merged by 05/17/2019,
the code freeze date may need to be changed.
On Wed, May 15, 2
t to build a healthy community.
On Wed, May 15, 2019 at 12:03 AM Junru Shao wrote:
> Hi Pedro,
> I really appreciate that a diligent and talented engineer eagerly wants to
> improve our system, and am very thankful that you have done so much for our
> community. However,
On Wed, May 8, 2019 at 6:43 AM Sem wrote:
> Requesting slack access
reviews will take longer than May 17th.
On Mon, May 6, 2019 at 11:49 PM Sheng Zha wrote:
> While 1.4.1 vote on general@incubator is still on going, I’d like to
> propose that we start preparing 1.5.0 release.
> 1.5.0 will include changes that dates
No worries, maybe its just something with my setup.
Moving my vote to +0, pending someone else check.
On Fri, May 3, 2019 at 11:39 PM Junru Shao wrote:
> Hi Anirudh,
> Thanks for reporting this!
> I verified on my EC2 machine for the second time. It perfectly builds with
I am on v1.4.x , and my dmlc-core commit is this one :
On Fri, May 3, 2019 at 8:30 PM Junru Shao wrote:
> Hey Anirudh,
> Although the vote has been closed, I am very interested i
undefined reference to `testing::internal::DeathTest::Create(char const*,
testing::internal::RE const*, char const*, int,
collect2: error: ld retu
I covered in the doc that it is specifically about inference. I can add
another section in FAQ to mention why INT8 quantization is not included.
On Tue, Apr 30, 2019 at 7:59 AM Lv, Tao A wrote:
> Thank you Anirudh! I'm just a little surprised that when we talk about
On Mon, Apr 29, 2019 at 2:22 PM Anirudh Subramanian
> Hi Zach,
> You raise an interesting point. Thank you for the pointer!
> Incorporating CSE pass comes with its own cost, and the advantage it
> brings is to make the ReducePrecision nnvm pass more
ing it. I will check to see if CSE pass can benefit
other NNVM pass also like quantization pass apart from ReducePrecision, and
will get back.
On Mon, Apr 29, 2019 at 11:18 AM Zach Kimberg
> I have one suggestion. In the current design, there are the additional maps
> from e
Also, when we move quantize_model APIs outside contrib we can consider
adding them under AMP namespace. The challenge would then be to educate
users on difference between "quantize" and "convert".
On Mon, Apr 29, 2019 at 7:45 AM Lv, Tao A wrote:
Lets say users want to save converted mixed precision model used for
inference to disk. It will save both, the symbol with the amp_cast and
amp_multicast operators and the params (which are casted if necessary).
On Mon, Apr 29, 2019 at 6:55 AM Lv, Tao A wrote:
> Thank you
I have created a doc for conversion from FP32 to Mixed Precision Models:
I look forward to your feedback on the same.
frontend which is not yet merged to the
repo but in its own repo, these repos should also be considered consumers
of MXNet API.
On Thu, Apr 11, 2019 at 12:12 PM Marco de Abreu
> Good point about the adoption speed for the different frontends, Anirudh.
> While this is a quite
their own pace.
On Thu, Apr 11, 2019 at 10:58 AM Jun Wu wrote:
> I'm not sure about whether C APIs should fall under semver. This is the
> discussion we would like to have with the community.
> My thinking on this:
> 1. In most of the cases, C APIs only serve as
I was under the impression that C API does fall under semver. Has this been
discussed somewhere before ? Is this also the case for C Predict API ?
On Thu, Apr 11, 2019, 8:08 AM Marco de Abreu
> In case only changes to the c-api are being made, it doesn't fall under our
://github.com/QuantStack/xtensor ) can also be a candidate here.
On Fri, Apr 5, 2019 at 7:03 PM Pedro Larroy
> Some developers have noticed that working in mshadow is cumbersome as
> it's a 3rdparty subrepo.
> Since mshadow is a bunch of headers whi
There was a conversation on this some time back here -
On Mon, Apr 1, 2019 at 12:19 PM Zach Kimberg
> As part of the current MXNet release process, the R-pack
Yes, that is the error, need to dig deeper why that URL is not working.
On Mon, Mar 25, 2019 at 10:40 AM kellen sunderland <
> Is this the error?
> "test_model.R:129: error: Fine-tune
> cannot open URL
On Mon, Mar 25, 2019 at 7:34 AM Per da Silva wrote:
> Dear community,
> I'm working on a PR <https://github.com/apache/incubator-mxnet/pull/14513>
> to update CI GPU jobs to be based on CUDA v10. However, for some reason,
> amongst oth
I have also faced this problem, when talking to someone external( at
meetups etc.. ) using two names like gluon and mxnet gets confusing and
people usually have not heard of gluon.
I get around it by referring to gluon as "gluon-mxnet" while talking to
anyone outside the community.
wiggle room there.
MXNet needs HPO functionality and instead of building something from
scratch we could just use existing open source projects. Would like to hear
more from the community.
active PMC members.
Just my 2 cents.
On Wed, Mar 6, 2019 at 7:10 AM Isabel Drost-Fromm wrote:
> Am 2. März 2019 15:13:23 MEZ schrieb Carin Meier :
> >I wanted to kickoff a discussion about community building. There was an
> >excellent blog post from the
into which these breaking
changes get introduced, and this branch can later be merged into master
prior to v2.0 release.
On Thu, Feb 28, 2019 at 1:35 PM Wen-Yang Chu wrote:
> I have raised an issue:
> mx.nd.Crop does not support FP16 and decpreciate
undefined reference to `testing::internal::DeathTest::Create(char const*,
testing::internal::RE const*, char const*, int,
collect2: error: ld returned 1 exit status
On Mon, Feb 4, 2019 at
On Sat, Feb 2, 2019, 3:27 PM Tianqi Chen Dear Community:
> Please join me to welcome Lin Yuan(@apeforest) as a new committer of
> Apache(incubating) MXNet!
> He has contributed to various improvements, including better compatibility
> of larger arrays across the codebase.
On Thu, Dec 20, 2018, 1:56 PM Lin Yuan Hi Anirudh,
> Thanks a lot for your clarifications! I have some followup
> 1) Which guideline should we follow when updating the UI in MXNet
> A) MXNet follows semantic versioning, so breakin
was created for ops for which we provide limited guarantees with respect to
backward compatibility, interface changes, testing etc.
On Thu, Dec 20, 2018 at 1:00 PM Lin Yuan wrote:
> Dear Community,
> As a contributor, I would like to know the current pol
in good faith in most cases) on how many approvals to
wait for before merging would be good.
And having these in one place in the cwiki would be convenient.
On Fri, Dec 14, 2018 at 11:59 AM Carin Meier wrote:
> Thanks Steffen,
> I had remembered reading that but
I have created a PR to cherry pick the change to v1.4.x branch:
On Mon, Dec 3, 2018 at 11:29 AM Steffen Rochel
> Thanks Haibin. Anirudh - please add PR for v1.4.x for
once again before we do include it.
On Sun, Dec 2, 2018 at 3:22 PM Steffen Rochel
> Hi KK - I'm going through the release checklist
On Thu, Nov 29, 2018 at 4:29 PM Marco de Abreu
> I think it's worth a discussion to do a sanity check. While generally these
> instructions are standardized, we also made the experience with ARM that
> the theory and reality sometimes don't match. Thus, it's al
On Thu, Nov 29, 2018 at 2:38 PM Alex Zai wrote:
> What are people's thoughts on having AMD machines tested on the CI? AMD
> machines are now available on AWS.
if this is going
to happen anytime soon (It would be nice if you can obtain some timeline
from MKLDNN team on this). As long as the PIP still has two different
packages for mkl and without mkl my vote is +1 for adding it as a default.
On Tue, Nov 27, 2018 at 5:04 AM Lv, Tao A wrote:
> Hi Anir
it be possible
to do a patch release for it or maintain a release branch for it ?
On Sun, Nov 25, 2018 at 5:03 PM Lv, Tao A wrote:
> Hi Steffen,
> I think all the commits on MKL-DNN master branch are well tested for
> MKL-DNN development team. If we really want to have a re
Thanks for the quick response and mitigation!
On Wed, Nov 21, 2018 at 3:55 PM Marco de Abreu
> today, CI had some issues and I had to cancel all jobs a few minutes ago.
> This was basically caused by the high load that is currently being put on
> our CI system due to the
On Wed, Nov 21, 2018 at 9:31 AM Marco de Abreu
> Please notice that the "continuous-integration/jenkins/pr-merge" currently
> is overlapping with the new pipelines. Please make sure all checks pass
> (also the non-required ones) before merging t
Sorry for the delay, but here is the design spec for the API -
Look forward to feedback from the community.
On Tue, Sep 25, 2018 at 2:15 PM kellen sunderland <
Thanks for doing this.
On Nov 13, 2018 5:25 PM, Sheng Zha wrote:
Oh, I see. I was moving the other 80 or so, so it was probably a
Anyway, thanks for being eager to help.
On Tue, Nov 13, 2018 at 5:24 PM Naveen Swamy wrote:
> done now, removed the feature la
This issue was raised before here -
We need someone with committer privileges to fix it.
On Tue, Nov 13, 2018 at 4:36 PM Lin Yuan wrote:
> Dear Commun
I am curious to know how you will write tests for these things.
Looking forward to seeing the design of this test bed/framework.
On Fri, Nov 9, 2018 at 2:39 PM Marco de Abreu
> Hello Ankit,
> that's a great idea! Using the tutorial tests as
Thanks for the reply Aaron. Once the existing Sphinx errors are fixed and
codebase is cleaned up, lets definitely revisit this and try to add a
Sphinx build into the CI pipeline so that we can prevent MXNet
documentation from breaking.
On Thu, Nov 8, 2018 at 5:16 PM Aaron Markham
to have a
mapping of error codes from backend to frontend to communicate what kind of
exception it is.
2. Handling of std::exception.
On Sun, Nov 4, 2018 at 2:54 AM Lieven Govaerts wrote:
> Hi MXNet devs,
> I'd like some feedback on the following proposal before I start
to the CI?
strangers on the
2. Also you seem to have linked a document that goes to an internal
amazon website, please remove that.
[image: Screen Shot 2018-11-01 at 2.31.13 PM.png]
On Thu, Oct 18, 2018 at 1:51 PM Harsh Patel
> After having my PR
ually find the reviews from non-committer super helpful, and they
> >> >> help the committer to catch problems that are otherwise overlooked.
> >> >>
> >> >> However, it is very hard to get contributors to do code reviews
> >> we
On Mon, Oct 22, 2018 at 8:28 AM Qing Lan wrote:
> Let's have a reviewer list somewhere with a certain format: such as C++,
> Gluon, Scala/Java based on language or some other category. etc. In the
> future, label bot would automatically assign reviewers based
from the PyPi package itself, instead of cloning the repo.
I was thinking of converting the tool into an API call under the mx.io
package. I will send the API design shortly. I wanted to know what the
community thinks of this change.
-1 Considering that using fp16 with gluon is much easier than the
alternative where you need access to the model code, this fix is really
useful. I understand the pain of doing mxnet release and appreciate Roshani
and Shengs efforts, but this seems like something we should fix.
On Thu, Sep 6,
+1 for discontinuing.
On Tue, Aug 28, 2018 at 4:11 PM Naveen Swamy wrote:
> +1 to stop supporting Win7
> On Tue, Aug 28, 2018 at 3:54 PM Lin Yuan wrote:
> > Dear Community,
> > Currently, our MXNet installation guide for Windows does not work for
> > Windows 7. e.g. Microsoft
Thank for the reply and the clarification, Haibin.
On Tue, Jul 24, 2018 at 2:31 PM Haibin Lin wrote:
> Hi Anirudh,
> Thanks for asking this on dev@. I looked at the doc for sample_uniform and
> random_uniform, and found that the API is different. For sample_uniform,
> the ty
ith TensorRT enabled, would it
> be possible to get that image pushed to the MXNet Dockerhub repo by a
> On Sun, Jul 22, 2018 at 3:57 PM Anirudh Acharya
> > @Naveen No, I meant in general, for all bindings. Irrespective of whether
> > we use a p
distributions, but the behavior of the operators is not different.
Is sample_op.cc being retained for legacy reasons or backward
compatibility? Can it be deprecated or EOLed? Correct me if I am wrong here.
> I think it's a good idea Anirudh. It should help users easily get MXNet up
> and running whether they're running services, following tutorials, etc.
> On Sun, Jul 22, 2018 at 8:10 AM Naveen Swamy wrote:
> > I
Yes, correct cu90 is indeed there, thanks for pointing it.
So the question, should we be publishing to Docker Hub as part of the
release process so that bindings other than python are also published and
there is a policy on what cuda versions we publish?
On Sat, Jul 21, 2018
The python binding that is actively maintained is
Other versions that use CUDA like mxnet-cu and mxnet-cumkl are not
On Sat, Jul 21, 2018 at 9:09 PM Mu Li wrote:
> Surprisingly only the python binding is actively maintained. I remem
of use and access to our
users. Is this something that should be included as part of the release
process? What does the community think?
The Apache MXNet (incubating) Community announces the availability of
Apache MXNet (incubating) 1.2.1!
Apache MXNet (incubating) is a deep learning framework designed for
both efficiency and flexibility. It allows you to mix symbolic and
imperative programming to maximize efficiency
@sandeep krishnamurthy the bug fixes in the
R-package is something we have just begun, there will not be anything
significant to announce before the v1.3 code freeze.
On Wed, Jul 18, 2018 at 10:08 PM Steffen Rochel
> To make it easier to find the discussions related to project proposals
On Tue, Jul 17, 2018 at 9:58 AM Anirudh wrote:
> Its not foregoing transparency since people can easily subscribe to the
> github activities individually. dev@ has been used till now for design
> discussions, other project discussions,
> votes etc. After we subscribe dev@ to al
and it is redundant for most purposes.
On Tue, Jul 17, 2018 at 9:26 AM, Sheng Zha wrote:
> Hi Anirudh,
> 1. You need exactly one filter to filter out all the github notifications
> on PRs and issues: "from:notificati...@github.com", and you'd get your S/N
For concerns regarding signal and noise, I think we can get around that by
setting up the right kind of filters in the mail client.
Signal and Noise can be different for different people.
On Thu, Jul 12, 2018 at 3:34 PM Haibin Lin wrote:
> Agree. +1 for more transpare
On Thu, Jul 12, 2018 at 11:51 AM Piyush Ghai wrote:
> > On Jul 12, 2018, at 11:50 AM, Tianqi Chen
> > +1
> > On Thu, Jul 12, 2018 at 11:10 AM, Sheng Zha wrote:
> >> Hi all,
> >> Should we subscribe dev list to github updates on mxnet repo? Both
een these two labels.
It would make sense to merge the "Feature" label into "Feature Request".
On Wed, Jun 27, 2018 at 3:50 PM Hagay Lupesko wrote:
> Thank you everyone for your suggestions.
> I will work with a committer to get this updated ASAP.
@ or summarized the discussion and
sought more opinions from the community on dev@.
I ask mentors and community members to suggest any areas of improvement we
can incorporate in such situations to minimize the time spent by community.
On Mon, Jul 2, 2018 at 8:21 PM, Sergio
access the R API.
On Tue, Jul 3, 2018 at 2:48 AM Marco de Abreu
> do we have a release process for our R frontend? I noticed the issue at 
> and it seems like we're only publishing to an S3 bucket which is not under
> Apache. Is there
After an offline discussion, the current decision is to block the 1.2.1
release, improve the warning message for save_params usage here:
cut a new RC and then restart the voting process.
I have opened a PR for adding new content to 1.2.1 release notes:
Please help review. Once this PR is approved I will be cutting the release.
On Tue, Jun 26, 2018 at 7:10 PM, Chris Olivier
> On Tu
f you have any thoughts, questions or suggestions.
On Mon, Jun 25, 2018 at 10:44 PM, Anirudh wrote:
> Hi Mu,
> Thanks for bringing this up and hopefully this should answer Sheng's
> Thomas pointed out something similar in the PR here for the warning
1.2.1 (load_params) is backward compatible with 1.1.0 not with 1.2.0.
It does not adhere exactly with semver but it had to be made, to quickly
help our customers who were using the APIs incorrectly.
On Mon, Jun 25, 2018 at 5:42 PM, Sheng Zha wrote:
> save_parameters didn't ex
The warining currently printed is "save_params is deprecated. Please use
Isn't this similar to what you are suggesting ?
On Mon, Jun 25, 2018 at 3:47 PM, Mu Li wrote:
> v1.2.1 will print a deprecating warning message when calling
Does PMC in this page mean IPMC :
Also, does this mean we need three IPMC votes to pass this release on dev
On Fri, Jun 22, 2018 at 9:15 PM, Sergio Fernández wrote:
> Just wanted to refresh what
Apologies for replying instead of sending out a new email.
This vote has passed with 6 +1s:
I will proceed with the vote on general@.
Thanks a lot for checking the release. This vote has passed with:
On Fri, Jun 22, 2018 at 8:00 AM, sandeep krishnamurthy <
> Lai (https://gi
Thanks for checking the release. We need one more binding +1. I would
request committers to help out here so that we can get the vote started on
On Thu, Jun 21, 2018 at 3:06 PM, Pedro Larroy
> I already changed my vote to +1 I don't think this a big is
> > +1
> > Built from source with CUDA on Ubuntu.
> > Ran example/gluon/word_language_model/train.py
> > Best,
> > Haibin
> > On Thu, Jun 21, 2018 at 11:08 AM, Anirudh wrote:
I have seen this with the DEBUG flag on, not without it.
I opened an issue here some time back:
On Thu, Jun 21, 2018 at 12:16 PM, Pedro Larroy wrote:
> Got it. Sorry to bring this up, and the deja-vu :-) . Makes se
On Thu, Jun 21, 2018 at 11:56 AM, Hagay Lupesko wrote:
> Hey community,
> I was going over the open GitHub issues for MXNet, and noticed that we have
> two labels for the CPP API: "CPP package", "C++"
> Wanted to suggest we rem
missed reviewing all the known issue of 1.2.0 and add it to 1.2.1 release
notes. I will do that now.
On Thu, Jun 21, 2018 at 10:42 AM, Pedro Larroy wrote:
> I think I have fixed this before, I will check if the patch didn't make it
> to the branch.
> On Thu, Jun 21, 2018 at 10:
Please help with the testing and voting for 1.2.1 release.
On Mon, Jun 18, 2018, 6:52 PM Anirudh wrote:
> This is the vote to release Apache MXNet (incubating) version 1.2.1.
> Voting will start now and close Thursday June 21st 7:00 PM PDT.
(Note: The README.md points to the 1.2.1 tag and does not work at the
Please remember to test first before voting accordingly.
+1 = approve
+0 = no opinion
-1 = disapprove (provide reason)
Since there are some issues with publishing scala package to maven, the
1.2.1 vote doesn't have to be blocked for the Scala package release.
I will create the vote for 1.2.1.rc0 soon.
On Mon, Jun 18, 2018 at 1:27 PM, Anirudh wrote:
> Hi Sina,
> RC is available he
RC is available here:
https://github.com/apache/incubator-mxnet/releases/tag/1.2.1.rc0 . We are
waiting to publish scala package to maven before we start the vote. Naveen,
Qing and Andrew are working on this.
On Mon, Jun 18, 2018 at 1:18 PM, Afrooze, Sina
python user base
getting the release early for the scala user base.
On Thu, May 31, 2018 at 7:27 AM, Naveen Swamy wrote:
> All, I have created a guide to maven publish process here;
the rules which we set for other
If the argument is that users depend on the change since it has been
introduced a few days ago, then the assumption with depending on the master
is always that it is bleeding edge and things can break.
On Fri, Jun 15, 2018 at 3:10 PM, Mu
We have one last PR before code freeze:
On Thu, Jun 14, 2018 at 11:46 AM, Anirudh wrote:
> Waiting on CI for the PRs: #11236, #11210, #11267
> Other PRs have been merged.
> On Wed, Jun 13, 2018 at 10
Waiting on CI for the PRs: #11236, #11210, #11267
Other PRs have been merged.
On Wed, Jun 13, 2018 at 10:50 PM, Anirudh wrote:
> Thanks Tao! Yes, this shouldn't be a blocker for 1.2.1.
> On Wed, Jun 13, 2018 at 10:46 PM, Lv, Tao A wrote:
>> Yes, #10311 is onl
> On windows tests a segfault is indicated by "If -764728474728". I have
> also seen it happen on Ubuntu, there are probably some links in the issue
> (on my phone right now).
> Anirudh schrieb am Mi., 13. Juni 2018, 22:16:
> > By segfaulting test do y
By segfaulting test do you mean : test_gru_bidirectional. I don't see the
segfault in the logs. Can you point me to the test.
Also, this seems to be specific to the master and not in 1.2:
On Wed, Jun 13, 2018 at 10:00 PM, Marco de
breaking on windows:
On Tue, Jun 12, 2018 at 11:59 AM, Anirudh wrote:
> Hi all,
> Here are the PRs that are being tracked for 1.2.1 release:
> Related to the save_params backwards incompatible change: #11127 (In
1 - 100 of 191 matches
Mail list logo