Re: segmentation fault in master using mkdlnn

PM, Pedro Larroy <pedro.larroy.li...@gmail.com> wrote: > Hi Da > > Reproduction instructions: > > On the host: > > Adjust core pattern: > > $ echo '/tmp/core.%h.%e.%t' > /proc/sys/kernel/core_pattern > > > Use the following patch: > >

Re: segmentation fault in master using mkdlnn

ll me How you reproduce the error? > > On 5/3/18, 7:45 AM, "Pedro Larroy" <pedro.larroy.li...@gmail.com> wrote: > > Looks like a problem in mkl's same_shape > > the pointer to mkldnn::memory::desc looks invalid. > > (More stack frames follow...) >

Re: segmentation fault in master using mkdlnn

C++ unit > tests. Not sure it'll cover all memory errors we want. > > Best, > Da > > On 5/3/18, 6:50 AM, "Pedro Larroy" <pedro.larroy.li...@gmail.com> wrote: > > It's very difficult to reproduce, non-deterministic. We were also > running > w

Re: segmentation fault in master using mkdlnn

) [0x7f7fefbeffc1] [bt] (9) /work/mxnet/python/mxnet/../../lib/libmxnet.so(mxnet::engine::ThreadedEngine::ExecuteOprBlock(mxnet::RunContext, mxnet::engine::OprBlock*)+0xcb5) [0x7f7ff01b1f65] ok On Thu, May 3, 2018 at 3:57 PM, Pedro Larroy <pedro.larroy.li...@gmail.com> wrote: > @Chris seem

Re: segmentation fault in master using mkdlnn

@Chris seems intel inspector requires purchasing right? maybe some of us already owns a license and can execute the test that fails intermittently? test_module.py:test_forward_reshape On Thu, May 3, 2018 at 3:49 PM, Pedro Larroy <pedro.larroy.li...@gmail.com> wrote: > It's very

Re: segmentation fault in master using mkdlnn

t;> On Wed, May 2, 2018 at 2:14 PM, Zheng, Da <dzz...@amazon.com> > wrote: > > > >> > There might be a race condition that causes the memory error. > > > >> > It might be caused by this PR: > > > >> > https://github.com/apache/incu

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

-1 nondeterminisitc failures on CI master: https://issues.apache.org/jira/browse/MXNET-396 Was able to reproduce once in a fresh p3 instance with DLAMI can't reproduce consistently. On Wed, May 2, 2018 at 9:51 PM, Anirudh wrote: > Hi all, > > As part of RC2 release, we

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 <pedro.larroy.li...@gmail.com>

Re: The New Scala API

apache/mxnet/SymbolMacro.scala#L147 > > Thanks, > Qing > > On 5/2/18, 3:50 AM, "Pedro Larroy" <pedro.larroy.li...@gmail.com> wrote: > > Hi > > I had a brief look and I have some comments: > > 1 - Excessive use of Option: Having an opt

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: 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

ging this "https://github.com/dmlc/mshadow/pull/319 " > > > > I am curious how are we tracking the sub-modules's PRs which are really > > important for MXNet? > > This PR has been waiting to merge for almost 4 months. > > > > > > > > On Mon, Apr

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

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

-1 We should merge this and update mshadow before the next release: https://github.com/dmlc/mshadow/pull/319 so we compile cuda for Volta. On Sat, Apr 28, 2018 at 12:53 AM, Steffen Rochel wrote: > Hi Chris - acknowledge that building the docs is not as good as it

Re: MXNet meetup in Seattle April 24th

Thanks a lot for organizing the meetup, and great food choice, definitely better than most meetups I attended.  On Thu, Apr 26, 2018 at 7:57 AM, Steffen Rochel wrote: > Thank you all for participating and contributing to the MXNet Seattle > meetup. Slides and partial

Re: Tutorial tests in the CI

Nice contribution, thanks Thomas! Very cool to have the tutorials running on CI. On Mon, Apr 23, 2018 at 2:36 PM, Thomas DELTEIL wrote: > Hi all, > > I have updated the CI to make sure all tutorials run in python2 and python3 > on GPU, thanks Marco for the help. > >

Re: join slack?

Hi Denisa You can go through the docs folder to understand the general architecture of MXNet, depending what you want to contribute. You can also pick a low hanging fruit from the issues, add a comment saying that you are working on it and try to solve it. I think this is also we could do is

Re: Quick question about a submodule file’s license

Hi Meghna. Are you sure the DevGuide of googletest is a problem? Check this out: https://www.apache.org/legal/resolved.html#cc-sa Pedro. On Thu, Apr 5, 2018 at 2:59 AM, Meghna Baijal wrote: > Hello Everyone, > There was a suggestion during the 1.1 release vote

Re: MXNet C++ package improvements

such as MinGW are really something that is used in production, I always thought they were quite hacky and limited, but maybe I'm wrong. On Mon, Mar 26, 2018 at 1:47 PM, Pedro Larroy <pedro.larroy.li...@gmail.com> wrote: > Thank you for your feedback and comments on the document. Seem

Re: MXNet C++ package improvements

Thank you for your feedback and comments on the document. Seems we have to iterate more. I want to point out that using the pimpl idiom we wouldn't have the problem of breaking backward compatibility, since the internal C++ API is not really exposed. Only the public facing one of the pimpl facade

Re: call for contributions to next MXNet release

. > > > > This is a PR to fix this issue, https://github.com/apache/incubator- > > mxnet/pull/10075 > > The issue will be gone after this PR is merged. > > > > For the whole logic, we are investigating now and maybe propose a new > > approach for Mak

Re: call for contributions to next MXNet release

Hi Can you please fix the build logic? https://github.com/apache/incubator-mxnet/blob/master/CMakeLists.txt#L158 https://github.com/apache/incubator-mxnet/issues/10072 It wrongly assumes that you have MKL installed, MKLDNN needs to check if MKL is available before, or be disabled by default,

Re: [VOTE] Disconnect all non-C API's from mxnet versioning

-1 . for the reasons already mentioned, specially bad user experience. On Tue, Mar 13, 2018 at 3:20 PM, Nan Zhu wrote: > -1, I cannot think about a significant benefit comparing to the headache of > the user > > still take Spark as an example > > if PySpark is in a

Re: Cython Document iteration

Nice document! I think it would be good to have a comparison to pybind11 without going through the C API. Is the complexity of adding the Cython code generation and compilation step considered? Will it work in all platforms? what are the pitfalls and tradeofs. Isn't it simpler to just hook up in

Re: move entirely to CMakefiles for building MXNet, drop Makefiles

o it. > > > > > > > > As far as I know, it's just a matter of someone putting in the work > to > > > add > > > > more functionality to cmake or to fuse the two builds. > > > > > > > > One solution for the short term might incl

Re: Following semantic versioning

This is a good point. What additional blockers would there be for linking against a user provided library with custom operators? On Tue, Mar 6, 2018 at 5:16 PM, Barber, Christopher < christopher.bar...@analog.com> wrote: > To avoid this kind of problem, you really need to support features that

Re: Refactoring docker handling on CI and locally

This is also part of clearing the path to integrate IoT devices into the testing environment. In addition we have too much logic in the Jenkinsfile which is an anti-pattern. Most of what CI does will be reproducible locally with a simple command, which I think is very good to test PRs or local

Apache MXNet meetup in Seattle on the week of the April 23th to 27th

Hi folks. Please vote for your preferred time slot for the MXNet meetup in Seattle so we can organize: https://doodle.com/poll/yfzmerx87tf4pce8 Everyone is welcome, it's not restricted to Amazon employees. Pedro.

Meetup in Seattle

Hi folks It would be nice to organize an MXNet community meet up in Seattle around the 26th of April, since some of us will be around due to an ML conference happening in those dates. For example going for some drinks / dinner. Would anyone from the list be interested in joining? Pedro.

discuss how to help thread

Hi I think it would be a good idea to create a pinned "help needed" thread in discuss to list things that could get some love and contributions from the community. Also a category with "help wanted" could be useful. Who is the admin of discuss which can help with this? Pedro.

Re: Regarding joining slack channel

, 2018 at 5:45 PM, Sebastian <s...@apache.org> wrote: > It took us quite some effort to move everyone to the ASF supported slack > channel, so I don't see the point of moving away from that. > > -s > > > On 15.02.2018 13:26, Pedro Larroy wrote: >> >> What's the sit

Re: Regarding joining slack channel

What's the situation with slack vs gitter? Should we just move all the discussion to gitter? there was never any significant traffic in the slack channel anyway. On Mon, Feb 5, 2018 at 10:20 PM, Chris Olivier wrote: > invited > > On Mon, Feb 5, 2018 at 1:10 PM, Chen HY

Re: MXNet package

t; > Sounds like a great idea! Please also consider the issues labelled as Cpp >> > package on GitHub. >> > >> > -Marco >> > >> > Am 14.02.2018 6:48 nachm. schrieb "Pedro Larroy" < >> > pedro.larroy.li...@gmail.com>: >&

Re: MXNet and Cython

ly that it's convenient in passing data back and forth.* > > *Is it claimed somewhere that it is especially fast?* > > On Wed, Feb 14, 2018 at 10:45 AM, Pedro Larroy <pedro.larroy.li...@gmail.com >> wrote: > >> Why Cython and not just C++ with simple python bindings

Re: JIRA notifications on dev@

Is there a new alias to subscribe to get the Jira notifications? On Wed, Feb 7, 2018 at 7:10 PM, Marco de Abreu wrote: > Ticket is available at > https://issues.apache.org/jira/plugins/servlet/mobile#issue/INFRA-15997 > > -Marco > > Am 07.02.2018 7:09 nachm. schrieb

MXNet package

Hi We would like to use MXNet from C++ without Python. Currently the cpp package depends on additional MXNet headers, nnvm and dmlc. As far as I know we don't have a standalone package of MXNet with library + headers. I would like to create a deb package of MXNet for example which has the

Re: MXNet and Cython

Why Cython and not just C++ with simple python bindings like https://github.com/pybind/pybind11 ? What's the motivation? Have we considered the trade offs between maintainability, speed and tooling? Also this Cython code is not going to be portable as it would be in C++, and has some learning

Outstanding PR

Hi Can some of the admins please merge the following PR? I can't stand this warning on nvcc flooding my compilation anymore: https://github.com/dmlc/mshadow/pull/322 Thank you so much.

Re: Please help update/review pending PRs

I would like to get these merged for the release, is it too late? https://github.com/dmlc/mshadow/pull/322 https://github.com/dmlc/dmlc-core/pull/357 On Mon, Jan 22, 2018 at 9:01 PM, Haibin Lin wrote: > Hi everyone, > > We still have a long list of outstanding PRs on

cuda CUDNN auto tune, optimal parameters of cuda kernels

Hi We have identified that cuda cudnn autotune produces a significant spike of ram usage when finding the best convolution algorithm. As far as we understand this is inside the cudnn library. But in platforms like the TX1 where we only have 4G this is problematic as the spike is close to 4G.

Re: Proposal for treating warnings as errors in Linux & Clang builds (-Werror)

would be good if >> > we can >> > filter most warnings during PR-stage and risk that some are getting >> > into >> > the master branch due to a different compiler version. A reduction of >> > (for >> > example) 95%

Re: Proposal for treating warnings as errors in Linux & Clang builds (-Werror)

Mon, Jan 15, 2018 at 9:43 AM, Marco de Abreu < > marco.g.ab...@googlemail.com> wrote: > >> +1 >> >> On Mon, Jan 15, 2018 at 6:27 PM, Pedro Larroy < >> pedro.larroy.li...@gmail.com> >> wrote: >> >> > Hi >> > >> > I wo

Proposal for treating warnings as errors in Linux & Clang builds (-Werror)

Hi I would like to propose to compile in CI with warnings as errors for increased code quality. This has a dual purpose: 1. Enforce a clean compilation output. Warnings often indicate deficiencies in the code and hide new warnings which can be an indicator of problems. 2. Warnings can surface

Re: Reduce 99% of your memory leaks with this simple trick!

> exceptions. >> > > when you do LOG(FATAL) or CHECK is caught at the C API boundary, which >> > > translates to return code -1 and an error is thrown on the python >> side. >> > > Throwing exception from another thread is a more tricky

Re: [DISCUSSION] Adding labels to PRs

+1 Agree with Bhavin, Marco and Sheng. I would also like to point out good commit practices such as, keeping each individual commit small and on-topic, meaning if that you are changing whitespace and a one liner fix, it's better practice to separate those commits. Or having two separate commits

Re: Call for Help for Fixing Flaky Tests

Agree with Bhavin's arguments 100%. Please don't compromise the stability of CI with Flaky tests. Address the root cause of why these tests are failing / not deterministic as per propper engineering standards. Hence, my non-binding vote is: -1 for proposal #1 for re-enabling flaky tests. +1 for

Re: CI failure due to offline llvm.org

I think Chris is right, git clean with the right options plus proper initialization of the submodules should not make any difference versus deleting the entire workspace. Right? On Fri, Jan 12, 2018 at 8:56 AM, kellen sunderland wrote: > Doing a few searches I see

Reduce 99% of your memory leaks with this simple trick!

Hi I would like to encourage contributors to use RAII idioms in C++ whenever possible to avoid resource leaks. RAII is an ugly acronym that stands for Resource Acquisition Is Initialization, which basically means that you should almost never use explicit new and delete operators and instead use

please merge PRs that fixes C++ unit tests and CMake build

Hi Can a committer please unblock the following PRs? We would like to have C++ tests and CMake builds back in working state. This is also creating build failures when you run CLion for development. This one is blocking more PRs: https://github.com/dmlc/mshadow/pull/317

Re: Module maintainers proposal

Hi all. Great initiative with maintainers, I hope to see more maintainers for different modules. I'm happy to volunteer as well to help. My main concern is that PRs take a long time for code to get merged, even when changes are trivial. I would like to see lower turn around times for simple PRs,

Re: Commiter access to Jenkins Sevrer

Regarding the proposed permissions, I would like stricter permissions. I think a committer should be able to stop-start-cancel jobs. But I think only admins should be able to create new jobs, otherwise we run the risk of the CI becoming a mess of jobs that nobody owns and maintains. Please let's

Re: Commiter access to Jenkins Sevrer

Agree that comitters should have access to Jenkins. I would like to as ask for some patience due to the ongoing progress on the CI work and thank Amazon for providing the resources for running the new CI and the great job done by Marco and the infra team. Are there some volunteers in helping

Increase indentation limit from 100 to 120 characters

Hi Can we please increase the indent limit from 100 to 120? I find 100 too low for current standards and today's monitors. Default CLion line limit is also 120. I'm having to split some long templates and I wish we had a longer line limit. Thanks a lot. Pedro

Re: Suggestions on how to increase community involvement on Apache MXNet incubating?

Agreed with Chris and Jeff. Googling for MXNet roadmap is enlightening. Also the communication channels are disperse. I would remove suggesting "Ask questions" in issues in the README.md because this encourages inflation of issues that are just questions. We should link to the slack channel or

Re: Apache MXNet Development Processes: Proposed update

+1 to all mentioned points above What about changes that refactor code to make it more readable & maintainable? My point of view is that this is important to keep the quality of a project and maintain the codebase. While some people think "if ain't broke it don't fix it". The reality is that

NVtidia system profiler

Hi We tried with Kellen to run the system profiler on MXNet on a Jetson board was impossible due to errors along the lines of "cannot allocate CUPTI buffer" while trying to profile MXNet Has somebody run into similar issue, or somebody from NVidia can comment on this? Was somebody able to run

Re: [VOTE] Disable Appveyor

+1 Queued for 16 hours: https://ci.appveyor.com/project/ApacheSoftwareFoundation/incubator-mxnet/build/1.0.4199 https://github.com/apache/incubator-mxnet/pull/9016 On Fri, Dec 8, 2017 at 12:19 PM, Bay, Daniel wrote: > +1 > > On 07.12.17, 23:41, "Indhu"

Re: [VOTE] Disable Appveyor

Can somebody re-enable travis CI so we can do mac builds? currently the unit tests don't build in Mac because Mac is not tested. On Fri, Dec 8, 2017 at 12:02 PM, Pedro Larroy <pedro.larroy.li...@gmail.com> wrote: > +1 > > > > On Fri, Dec 8, 2017 at 1:02 AM, Chris Olivier &

Re: [VOTE] Disable Appveyor

+1 On Fri, Dec 8, 2017 at 1:02 AM, Chris Olivier wrote: > +1 > > On Thu, Dec 7, 2017 at 3:57 PM, kellen sunderland < > kellen.sunderl...@gmail.com> wrote: > >> It's using a fixed binary version of openblas and opencv, so the versions >> there might be different than what

Re: [ANNOUNCE] Apache MXNet (incubating) 1.0.0 Release

Congratulations, thanks for the contributions and the great work. On Tue, Dec 5, 2017 at 1:02 AM, Spisak, Joseph wrote: > Congrats > > > On 12/4/17, 4:01 PM, "Chris Olivier" wrote: > > Hello All, > > > > The Apache MXNet (incubating)

Re: Protected master needs to be turned off

ractice today is still code >> reviewing. Otherwise, such as a PR is mainly about examples, the CI often >> doesn't help so we just waste machine times. >> >> I think checking the exact code coverage is on the roadmap, but I don't >> know if we have any progress on it. >

Re: Protected master needs to be turned off

CI catches problems all the time. I don't think many of us can afford to build all the flavors and architectures in their laptops or workstations, so we have to rely on CI to catch all kinds of errors from compilation errors to bugs plus regressions, specially in a project which has so many build

Use unique_ptr on Executor creation

Hi I would like to make a minor change of the cpp package for 1.0 by returning a unique_ptr when creating Engine. This is a C++ idiom that prevents memory leaks and fixes one leak in the examples. As before it requires explicit delete as the ownership of the pointer is not clear from the API

Re: [RFQ] Deprecate amalgamation

Anybody against removing amalgamation then? emscripten build is already using CMake. On Tue, Nov 21, 2017 at 9:22 AM, Tianqi Chen <tqc...@cs.washington.edu> wrote: > Yes, you can call emscripten from CMake > > Tianqi > > On Mon, Nov 20, 2017 at 5:42 PM, Pedro Larroy <pedr

Re: [Important] Please Help make the Apache MXNet (incubating) 1.0 Release Notes Better!

Thank you Meghna Added notes about ARM & Nvidia Jetson support (beta) to the document. On Mon, Nov 20, 2017 at 2:19 PM, Meghna Baijal wrote: > Apologies. Done. > > On Mon, Nov 20, 2017 at 2:18 PM, Chris Olivier > wrote: > >> No write access :(

Re: 3rdparty packages as submodules

We could also add gtest as well for example. I would like to point out that is quite cumbersome to get your code tested and ready before sending a PR, this includes installing cpplint, pylint, gtest… Installing gtest and bootstrapping it is not completely trivial. Kind regards. On Mon, Nov

Re: [RFQ] Deprecate amalgamation

hat there is > no dedicated developer on it yet. We can talk about full deprecation after > this > > > Tianqi > > On Mon, Nov 20, 2017 at 2:47 PM, Pedro Larroy <pedro.larroy.li...@gmail.com> > wrote: > >> Hi all >> >> Given that we have working builds

[RFQ] Deprecate amalgamation

Hi all Given that we have working builds for ARM, Android, TX2 and the main architectures, and after considering how amalgamation is done. I would like to propose that we deprecate and remove amalgamation. I don't think the cost of maintaining this feature and how it's done justifies the ROI,

Re: [VOTE] A Separate CI System for Apache MXNet (incubating)

+1 for [1] (A setup separated from Apache Jenkins) On Mon, Nov 13, 2017 at 4:50 AM, sandeep krishnamurthy wrote: > +1 for [1] Jenkins (A setup separated from Apache Jenkins) - with > preferably AWS Code Build integration to reduce the size of infrastructure > we

Re: update build instructions

unit tests to get started making changes. Your feedback is welcome. And if you can please test the instructions to check they work properly and nothing was missed. Pedro. On Thu, Nov 2, 2017 at 5:07 PM, Pedro Larroy <pedro.larroy.li...@gmail.com> wrote: > Right. > > I tried now

Re: [Proposal] Stabilizing Apache MXNet CI build system

igh-quality level. > > > 10) Finally, how do we get ownership for code submitted to MXNet? When > something fails in a code segment that only a small set of folks know > about, what is the expected SLA for a response from them? When users deploy > MXNet in production environments, they

Re: [Proposal] Stabilizing Apache MXNet CI build system

+1 That would be great. On Mon, Oct 30, 2017 at 5:35 PM, Hen <bay...@apache.org> wrote: > How about we ask for a new mxnet repo to store all the config in? > > On Fri, Oct 27, 2017 at 05:30 Pedro Larroy <pedro.larroy.li...@gmail.com> > wrote: > >> Just

Re: Fix slicing for 0.12

the case that they have a critical fix that > should go into 0.12.0.rc1? Hopefully the PR already passed CI or is in > master already. > > On Tue, Oct 24, 2017 at 6:31 AM, Pedro Larroy < > pedro.larroy.li...@gmail.com> > wrote: > > > Hi > > > > Can

Fix slicing for 0.12

Hi Can we get this PR in for 0.12? https://github.com/apache/incubator-mxnet/pull/8400 It's a critical fix with undefined behaviour, which shows itself specially in ARM platforms. -- Pedro.

Build failed in Jenkins: mxnet_incubator_master » ubuntu-17.04 #136

See -- Started by upstream project "mxnet_incubator_master" build number 136 originally caused by: Started by an SCM change Building in workspace

Build failed in Jenkins: mxnet_incubator_master » armv6 #136

See -- Started by upstream project "mxnet_incubator_master" build number 136 originally caused by: Started by an SCM change Building in workspace

Jenkins build is back to normal : mxnet_incubator_master » armv7 #137

See

Jenkins build is back to normal : mxnet_incubator_master » armv6 #137

See

Build failed in Jenkins: mxnet_incubator_master » cmake.ubuntu-17.04 #136

See -- Started by upstream project "mxnet_incubator_master" build number 136 originally caused by: Started by an SCM change Building in

Build failed in Jenkins: mxnet_incubator_master » android.armv7 #136

See -- Started by upstream project "mxnet_incubator_master" build number 136 originally caused by: Started by an SCM change Building in workspace

Jenkins build is back to normal : mxnet_incubator_master » ubuntu-16.04-cuda_8.0_cudnn5 #137

See

Jenkins build is back to normal : mxnet_incubator_master » arm64 #137

See

Build failed in Jenkins: mxnet_incubator_master » armv7 #136

See -- Started by upstream project "mxnet_incubator_master" build number 136 originally caused by: Started by an SCM change Building in workspace

Jenkins build is back to normal : mxnet_incubator_master » android.armv7 #137

See

Jenkins build is back to normal : mxnet_incubator_master » ubuntu-17.04 #137

See

Build failed in Jenkins: mxnet_incubator_master » arm64 #136

See -- Started by upstream project "mxnet_incubator_master" build number 136 originally caused by: Started by an SCM change Building in workspace

Re: Improving and rationalizing unit tests

> unforseen edge case failures occur in the field and not during testing". > > Is this the motivation? Seems strange to me. > > > On Mon, Oct 16, 2017 at 9:09 AM, Pedro Larroy < > pedro.larroy.li...@gmail.com> > wrote: > > > I think using a properly seede

Re: Improving and rationalizing unit tests

ch that we can make > the unit tests framework to be the rock-solid foundation for the active > development of Apache MXNet (Incubating). > > Regards, > Bhavin Thaker. > > > On Mon, Oct 16, 2017 at 5:56 AM Pedro Larroy <pedro.larroy.li...@gmail.com > <mailto:p

Improving and rationalizing unit tests

Hi Some of the unit tests are extremely costly in terms of memory and compute. As an example in the gluon tests we are loading all the datasets. test_gluon_data.test_datasets Also running huge networks like resnets in test_gluon_model_zoo. This is ridiculously slow, and straight impossible on

Slack channel

Hi Please add me to the slack channel. -- Pedro Larroy Tovar

<    1   2   3   4