Re: segmentation fault in master using mkdlnn

valgrind doesn't work with Python. also, valgrind doesn't support some CPU instructions used by MXNet (I think some instructions related to random generator). On Wed, May 2, 2018 at 8:59 PM, Bhavin Thaker wrote: > Have you tried running with valgrind to get some clues on

Re: segmentation fault in master using mkdlnn

Have you tried running with valgrind to get some clues on the root-cause? Bhavin Thaker. On Wed, May 2, 2018 at 8:55 PM Da Zheng wrote: > It might also be possible that this isn't an MKLDNN bug. > I just saw a similar memory error without MKLDNN build. > >

Re: segmentation fault in master using mkdlnn

It might also be possible that this isn't an MKLDNN bug. I just saw a similar memory error without MKLDNN build. http://jenkins.mxnet-ci.amazon-ml.com/blue/organizations/jenkins/incubator-mxnet/detail/PR-10783/1/pipeline Best, Da On Wed, May 2, 2018 at 2:14 PM, Zheng, Da

Proposed Change to Reshape Operator

Hi All, With the current Reshape operator in MXNet, it is not possible to reshape an input array when the shape is generated at runtime. I have created a github issue describing the problem with examples - https://github.com/apache/incubator-mxnet/issues/10789 Briefly stated, MXNet should

Re: segmentation fault in master using mkdlnn

There might be a race condition that causes the memory error. It might be caused by this PR: https://github.com/apache/incubator-mxnet/pull/10706/files This PR removes MKLDNN memory from NDArray. However, I don't know why this causes memory error. If someone is using the memory, it should still

[VOTE] Release Apache MXNet(incubating) version 1.2.0.RC2

Hi all, As part of RC2 release, we have addressed bugs and some concerns that were raised. I would like to propose a vote to release Apache MXNet (incubating) version 1.2.0.RC2. Voting will start now (Wednesday, May 2nd) and end at 12:50 PM PDT, Sunday, May 6th. Link to release notes:

Re: segmentation fault in master using mkdlnn

I couldn't reproduce locally with: ci/build.py -p ubuntu_cpu /work/runtime_functions.sh build_ubuntu_cpu_mkldnn && ci/build.py --platform ubuntu_cpu /work/runtime_functions.sh unittest_ubuntu_python2_cpu On Wed, May 2, 2018 at 8:50 PM, Pedro Larroy wrote: > Hi >

Re: The New Scala API

Hi Qing I didn't know about the type parser, I had a look at the code. Nice idea ! Pedro On Wed, May 2, 2018 at 8:57 PM, Qing Lan wrote: > Hi Pedro, > > Thanks for your comments! > > For the first one: please see the definition for attr here: >

Re: The New Scala API

Hi Pedro, Thanks for your comments! For the first one: please see the definition for attr here: https://mxnet.incubator.apache.org/api/python/symbol/symbol.html?highlight=attr#mxnet.symbol.Symbol.attr. It is a user defined Struct. Our old API indeed using null instead of Option + None

segmentation fault in master using mkdlnn

Hi Seems master is not running anymore, there's a segmentation fault using MKDLNN-CPU http://jenkins.mxnet-ci.amazon-ml.com/blue/organizations/jenkins/incubator-mxnet/detail/master/801/pipeline/662 I see my PRs failing with a similar error. Pedro

Re: [VOTE] Release Apache MXNet(incubating) version 1.2.0.RC1

I have to agree that the DMLC subrepos do make the development much more difficult sometimes. On 5/2/18, 3:57 AM, "Pedro Larroy" wrote: For me the situation with DMLC is problematic. I often find myself having to fix things in the DMLC subrepos.

Re: [VOTE] Release Apache MXNet(incubating) version 1.2.0.RC1

Totally agree with Henry and Pedro. On Wed, May 2, 2018 at 12:56 PM, Pedro Larroy wrote: > For me the situation with DMLC is problematic. > > I often find myself having to fix things in the DMLC subrepos. > > * These changes are impossible to test with the MXNet CI

Re: Slack access

Hi Jesse Welcome! Have you seen the "contribute" documentation? https://mxnet.incubator.apache.org/community/contribute.html Should be easy to contribute via github issues, Jira ticket and a PR. Pedro. On Wed, May 2, 2018 at 3:47 AM, jesse brizzi wrote: > Hey

Re: [VOTE] Release Apache MXNet(incubating) version 1.2.0.RC1

For me the situation with DMLC is problematic. I often find myself having to fix things in the DMLC subrepos. * These changes are impossible to test with the MXNet CI system without doing shenanigans like changing the submodules to my own forks. * Slows down development as fixes need to be

Re: The New Scala API

Hi I had a brief look and I have some comments: 1 - Excessive use of Option: Having an optional map is often not necessary. What's the semantic difference between an empty map and passing None? What about a variable argument list of Pairs like: (attr: Pair[String,Sring]*) it can be then