Re: Broken Links in Documentation

For the torch links, all torch supports have been removed in this PR: https://github.com/apache/incubator-mxnet/pull/9072/files It might because the master is not rebuilt. 2018-01-16 10:53 GMT-08:00 santhosh karuhatty : > Hello All, > > I need help for these 2 broken links.

[jira] [Updated] (MXNET-4) Performance: Refactor Random and ParallelRandom resources to use MKL for MKL builds

[ https://issues.apache.org/jira/browse/MXNET-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Olivier updated MXNET-4: -- Labels: mkl performance (was: performance) > Performance: Refactor Random and ParallelRandom resources to

[jira] [Updated] (MXNET-4) Performance: Refactor Random and ParallelRandom resources to use MKL for MKL builds

[ https://issues.apache.org/jira/browse/MXNET-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Olivier updated MXNET-4: -- Labels: performance (was: ) > Performance: Refactor Random and ParallelRandom resources to use MKL for

Broken Links in Documentation

Hello All, I need help for these 2 broken links. 1. Need the right link locations for the torch_function and torch_module below. URL - https://mxnet.incubator.apache.org/versions/master/how_to/torch.html Broken Links ─

[jira] [Commented] (MXNET-4) Performance: Refactor Random and ParallelRandom resources to use MKL for MKL builds

[ https://issues.apache.org/jira/browse/MXNET-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16327562#comment-16327562 ] Chris Olivier commented on MXNET-4: --- Sounds good. > Performance: Refactor Random and ParallelRandom

[jira] [Updated] (MXNET-4) Performance: Refactor Random and ParallelRandom resources to use MKL for MKL builds

[ https://issues.apache.org/jira/browse/MXNET-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Olivier updated MXNET-4: -- Description: Refactor Random and ParallelRandom resources to use MKL for MKL builds Things such as

[jira] [Updated] (MXNET-4) Performance: Refactor Random and ParallelRandom resources to use MKL for MKL builds

[ https://issues.apache.org/jira/browse/MXNET-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Olivier updated MXNET-4: -- Summary: Performance: Refactor Random and ParallelRandom resources to use MKL for MKL builds (was:

[jira] [Updated] (MXNET-4) [MXNET-4] Performance: Refactor Random and ParallelRandom resources to use MKL for MKL builds

[ https://issues.apache.org/jira/browse/MXNET-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Olivier updated MXNET-4: -- Summary: [MXNET-4] Performance: Refactor Random and ParallelRandom resources to use MKL for MKL builds

[jira] [Created] (MXNET-4) Performance: Refactor Random and ParallelRandom resources to use MKL for MKL builds

Chris Olivier created MXNET-4: - Summary: Performance: Refactor Random and ParallelRandom resources to use MKL for MKL builds Key: MXNET-4 URL: https://issues.apache.org/jira/browse/MXNET-4 Project:

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

I agree, you don’t want to run tests until you feel the code is ready, but stopping everything to fix warnings that aren’t likely to cause any actual problems just slows down the process. I think that sanity checking makes perfect sense, but the usual way to do that is to first run some “smoke”

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

@Christopher: I see your point, but the counter argument would be: "Why should the project run fairly expensive tests (~20 minutes on few GPU instances) for code that will require you to amend your commit anyway?" In normal circumstances I'd completely agree with you and let the full tests run

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

While you can debate the "broken windows" theory (https://en.wikipedia.org/wiki/Broken_windows_theory) I think it has relevance to code warnings: the more warnings you tolerate, the more likely you are to end up with other undesirable things in your code. My preference has always been to treat

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

I understand. What prevents you from disabling the -Werror flag on your build configuration? I don't see where's the big issue. We have already tens of flags to configure the build anyway. I have been fixing every warning that I came across so far in the main platforms that I have access. I

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

So you're proposing to have a stage AFTER test execution which would report warnings as errors? While this is a good idea, I'm afraid that a fail-fast would also have its benefits - especially considering that compilation only takes a few minutes and consumes few resources while test execution

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

Personally, I don’t like treating warnings as errors because it prevents compilation from completing and causes you to lose any ability to test the code and get any other information. Killing the build because of a failed warning for something that might not matter means that you may not find

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

I'd vote for having warnings as errors only for CI but not in general builds which are getting executed by users on their local machine. Just in case CI misses a warning due to a different version, this could block a developer from compiling MXNet locally even though it might just be a warning

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

Hi Chris I get the rationale of the point you raise, but In my opinion, and considering the complexity of C++ and the potential for difficult and expensive to track bugs, I think this should be enabled by default for both release and debug. A developer is free to disable warnings in his own

Re: Module maintainers proposal

+1 2018-01-16 9:08 GMT+01:00 Isabel Drost-Fromm : > Hi, > > > > Am 16. Januar 2018 01:40:48 MEZ schrieb Steffen Rochel < > steffenroc...@gmail.com>: > ># Anybody can add themselves or a team as additional contributors > ># to get notified about changes in a specific package. >

Re: Module maintainers proposal

Hi, Am 16. Januar 2018 01:40:48 MEZ schrieb Steffen Rochel : ># Anybody can add themselves or a team as additional contributors ># to get notified about changes in a specific package. ># See https://help.github.com/articles/about-teams how to setup teams. > >Hope we