Re: Propose to discontinue supporting Apache MXNet on Windows 7

[Barber, Christopher]

FWIW, my company is only beginning to transition to Windows 10 now, and my past 
experience would lead me to believe that many enterprises stick with old 
versions of Windows long past when you think they would.

Seems to me that if you are unwilling to deprecate python 2.7, then continuing 
to support Windows 7 is a no-brainer. You are more likely to get users to 
switch to python 3 than you are to get them to install a new operating system.

And do you really want to drop support for platforms that your competitors 
still support? Given MXNet's market share, I wouldn't dream of dropping a 
platform until after the more popular frameworks have already done so.

I also believe that it is possible to install more recent versions of Visual 
Studio on Windows 7. 

On 9/2/18, 1:57 AM, "kellen sunderland"  wrote:

Google analytics are sadly probably the best numbers we're going to get.
Of course these numbers are likely to over-represent windows usage, as I'm
sure many people are looking up documentation on a windows machine while
ssh'd into a cloud instance or IoT device.

What's the trend over time for these numbers Mu?  Is Windows 7 usage
relatively stable over the last year?

On Sun, Sep 2, 2018 at 1:58 AM Mu Li  wrote:

> According to google analytics, ~12% users who visited mxnet's website are
> using Windows 7. It's a significant number. Even though we cannot conclude
> that all of these users will run MXNet on Windows 7, I suggest we still
> support win7.
>
> BTW, anyone who can access mxnet's google analytics report can verify this
> number by following this instruction:
>
> 
https://stackoverflow.com/questions/1340778/detecting-windows-7-with-google-analytics
>
>
>
> On Sat, Sep 1, 2018 at 1:55 PM Steffen Rochel 
> wrote:
>
> > I support a data driven decision. Any suggestions how we can obtain
> insight
> > about OS usage of the MXNet user community?
> > Can we get such information from pip install statistics or should we
> > perform a user poll on the discussion forum?
> > On the other hand the lack of data should not prevent us from moving
> > forward and dropping support for outdated OS.
> > In any case we would have to announce dropping a platform support at
> least
> > a release in advance.
> > Steffen
> >
> > On Thu, Aug 30, 2018 at 12:21 PM Sheng Zha  wrote:
> >
> > > Hi Kellen,
> > >
> > > Thanks for the explanation. Unfortunately, I don't have the usage 
data,
> > so
> > > I refrained from voting. If any of the voters have such data I'd love
> to
> > > see it too.
> > >
> > > -sz
> > >
> > > On 2018/08/30 14:58:09, kellen sunderland  >
> > > wrote:
> > > > I haven't spoken to anyone about the decision (as I'm currently on 
an
> > > > island in the med) but to me the quick +1s are likely a result of
> this
> > > > being a fairly straightforward decision.  The factors that went into
> my
> > > > thinking were (1) prioritizing growing platforms rather than
> shrinking
> > > > platforms (i.e. thinking long term rather than shirt term) and (2)
> > > earning
> > > > our customers' trust.  Claiming support for a platform when we can't
> > > > realistically deliver it would lose us trust.  I'd prefer to over
> > deliver
> > > > and under promise when it come to windows 7 for this reason.
> > > >
> > > > Now on the flip side one thing I would see as valuable is to try and
> > get
> > > > windows builds working with clang.  This could be beneficial in the
> > sense
> > > > that it would be easy to maintain for mxnet devs and allow us to use
> > > modern
> > > > cpp on older windows machines without using vs 2013(which I consider
> a
> > > > non-starter with our codebase).
> > > >
> > > > You have peaked my curiousity though Sheng.  How many win7 users 
does
> > > MXNet
> > > > have relative to macos/Linux?
> > > >
> > > > On Thu, Aug 30, 2018, 8:51 AM Sheng Zha  wrote:
> > > >
> > > > > Hi Yuan,
> > > > >
> > > > > No problem. This is an issue that's worth having a clear
> definition,
> > so
> > > > > there's nothing wrong about your proposal, and thanks for bringing
> > > this up.
> > > > >
> > > > > I'm more concerned about the seemingly unanimous votes on dropping
> > > support
> > > > > on a platform without seeing the supporting evidence that it's the
> > > right
> > > > > thing. It is as if everyone who participated in the vote are
> already
> > > on the
> > > > > same page, and somehow I'm the only one that's not. But the only
> > > argument I
> > > > > hear so far is that it's technically not straightforward to
> continue
> > > the
> > > > > support, which, coming from Amazon folks, 

Re: [VOTE] Subscribe dev@ to Github Activities

[Barber, Christopher]

You should explicitly tell potential contributors what you expect of them. Here 
is what you document:

https://github.com/apache/incubator-mxnet/blob/master/docs/community/contribute.md

There is nothing there that tells contributors to discuss proposals on dev 
first. It sounds like that needs to be fixed.

On 7/18/18, 1:21 PM, "Chris Olivier"  wrote:

to know about github discussions, you’d need to scan all issues and prs
constantly which isn’t a reasonable expectation. dev is where discussions
are supposed to happen in a apache, PERIOD.

Apache isn’t dmlc. I wish some people would stop trying to turn Apache
conventions into dmlc conventions.  seems this is a constant push from day
one.


On Wed, Jul 18, 2018 at 9:39 AM Sheng Zha  wrote:

> Thanks, I hear the concerns and it's not my intention to push people off
> the list. On the other hand, I think github discussions are no more
> "artificial" than discussions on dev list, and the good and important
> discussions warrant the same amount of attention. With this vote, I intend
> to make contributors' life easier by decoupling the recognized forum from
> the technology they use, and that github contributors can easily
> communicate with the community on the list.
>
> -sz
>
> On Wed, Jul 18, 2018 at 9:05 AM, Barber, Christopher <
> christopher.bar...@analog.com> wrote:
>
> > Can't you simply tell contributors to discuss changes on dev before
> > submitting a PR? Since the contribution guidelines don't tell developers
> to
> > post to dev, why would you expect them to do that?
> >
> > Is there an easy way to just subscribe to PR notifications or will
> someone
> > have to write a filter to avoid spamming dev with all GitHub
> notifications?
> > I think that if dev gets too much traffic, then people with casual
> interest
> > may find it easier to unsubscribe than to set up filters. Once someone
> > unsubscribes, they probably won't be coming back soon, so you should be
> > very careful with this.
> >
> > I don't see why artificially increasing the traffic on dev will do
> > anything to grow the community in any case.
> >
> > - C
> >
> > On 7/18/18, 11:17 AM, "Indhu"  wrote:
> >
> > Some mentors/contributors/committees feel that the amount of
> > discussions in
> > dev list is too less given the amount of commits that happen and 
more
> > discussions need to happen in the dev list to grow the community.
> >
> > In response some committees feel discussions actually happen in
> GitHub
> > PRs.
> > If the policy says "if it didn't happen in dev, it didn't happen",
> > let's
> > forward all GitHub discussions to dev so those discussions would
> count.
> > That's the motivation for this vote.
> >
> > I think when people say there needs to be more discussions in the 
dev
> > list,
> > I assume they mean the kind of discussions that happen *before* a PR
> is
> > created or even before someone starts working on anything. I don't
> > think
> > people are asking an email for every activity on GitHub. The correct
> > way to
> > address the problem would be for committees/contributors to stop
> > communicating in private channels (like Amazon or DMLC communication
> > channels) and do those discussions in the dev list instead.
> >
> > Indu
> >
> >
> > On Wed, Jul 18, 2018, 5:51 AM Barber, Christopher <
> > christopher.bar...@analog.com> wrote:
> >
> > > Can't people already subscribe to github notifications? I think it
> > is safe
> > > to assume that developers are already smart enough to figure out
> how
> > to do
> > > that if they want. What problem are you really trying to solve
> here?
> > >
> > > On 7/18/18, 4:49 AM, "Chris Olivier" 
> wrote:
> > >
> > > -1.  (changed from -0.9)
> > >
> > > seems more like a strategy (whether intentional or on 
accident)
> > to
> > > *not*
> > > have design discussions on dev by flooding it with noise and
> > then later
> > > claim it was discussed, even though you would have to sif

Re: [VOTE] Subscribe dev@ to Github Activities

[Barber, Christopher]

Can't you simply tell contributors to discuss changes on dev before submitting 
a PR? Since the contribution guidelines don't tell developers to post to dev, 
why would you expect them to do that?

Is there an easy way to just subscribe to PR notifications or will someone have 
to write a filter to avoid spamming dev with all GitHub notifications? I think 
that if dev gets too much traffic, then people with casual interest may find it 
easier to unsubscribe than to set up filters. Once someone unsubscribes, they 
probably won't be coming back soon, so you should be very careful with this.

I don't see why artificially increasing the traffic on dev will do anything to 
grow the community in any case.

- C

On 7/18/18, 11:17 AM, "Indhu"  wrote:

Some mentors/contributors/committees feel that the amount of discussions in
dev list is too less given the amount of commits that happen and more
discussions need to happen in the dev list to grow the community.

In response some committees feel discussions actually happen in GitHub PRs.
If the policy says "if it didn't happen in dev, it didn't happen", let's
forward all GitHub discussions to dev so those discussions would count.
That's the motivation for this vote.

I think when people say there needs to be more discussions in the dev list,
I assume they mean the kind of discussions that happen *before* a PR is
created or even before someone starts working on anything. I don't think
people are asking an email for every activity on GitHub. The correct way to
address the problem would be for committees/contributors to stop
communicating in private channels (like Amazon or DMLC communication
channels) and do those discussions in the dev list instead.

Indu


On Wed, Jul 18, 2018, 5:51 AM Barber, Christopher <
christopher.bar...@analog.com> wrote:

> Can't people already subscribe to github notifications? I think it is safe
> to assume that developers are already smart enough to figure out how to do
> that if they want. What problem are you really trying to solve here?
>
> On 7/18/18, 4:49 AM, "Chris Olivier"  wrote:
>
> -1.  (changed from -0.9)
>
> seems more like a strategy (whether intentional or on accident) to
> *not*
> have design discussions on dev by flooding it with noise and then 
later
> claim it was discussed, even though you would have to sift through
> thousands of emails to find it.
>
>
>
> On Wed, Jul 18, 2018 at 12:42 AM Rahul Huilgol  >
> wrote:
>
> > I pulled up some more stats so we can make an informed decision.
> >
> > Here are some popular Apache projects and the number of emails to
> their
> > dev@
> > list in the last 30 days
> > Apache Flink: 540 mails
> > ​Apache Spark: 249 mails
> > Apache Hive: 481 mails
> > Apache HBase: 300 mails
> >
> > Current dev list for MXNet: 348 mails
> > Current commits list for MXNet: 5329 mails
> > Making the proposed dev list for MXNet to be ~5677 mails.
> >
> > Sheng, even going by your comments that 1 of of those 4 mails are
> relevant
> > for dev@, that's still a really high number of emails. (130 email
> lists
> > doesn't say anything if we ignore the actual number of emails in
> those
> > lists, especially when the 131st sends these many mails :) ). People
> are
> > already talking about setting up filters here. Doesn't that defeat
> the
> > purpose by making people filter out the discussion on Github? People
> can
> > subscribe to commits@ if they find it more convenient to follow
> Github
> > activity over email rather than Github.com.
> >
> > We should strive to maintain dev@ as a place for high quality
> discussion.
> > It's upto the contributors to bring up something to dev@ if they
> believe
> > it
> > deserves a focused discussion in the community. That discussion may
> be
> > started by the person who proposes code changes, or a reviewer who
> believes
> > that a particular code change warrants further discussion.
> >
> > Regards,
> > Rahul
> >
>
>
>

Re: [VOTE] Subscribe dev@ to Github Activities

[Barber, Christopher]

Can't people already subscribe to github notifications? I think it is safe to 
assume that developers are already smart enough to figure out how to do that if 
they want. What problem are you really trying to solve here?

On 7/18/18, 4:49 AM, "Chris Olivier"  wrote:

-1.  (changed from -0.9)

seems more like a strategy (whether intentional or on accident) to *not*
have design discussions on dev by flooding it with noise and then later
claim it was discussed, even though you would have to sift through
thousands of emails to find it.



On Wed, Jul 18, 2018 at 12:42 AM Rahul Huilgol 
wrote:

> I pulled up some more stats so we can make an informed decision.
>
> Here are some popular Apache projects and the number of emails to their
> dev@
> list in the last 30 days
> Apache Flink: 540 mails
> ​Apache Spark: 249 mails
> Apache Hive: 481 mails
> Apache HBase: 300 mails
>
> Current dev list for MXNet: 348 mails
> Current commits list for MXNet: 5329 mails
> Making the proposed dev list for MXNet to be ~5677 mails.
>
> Sheng, even going by your comments that 1 of of those 4 mails are relevant
> for dev@, that's still a really high number of emails. (130 email lists
> doesn't say anything if we ignore the actual number of emails in those
> lists, especially when the 131st sends these many mails :) ). People are
> already talking about setting up filters here. Doesn't that defeat the
> purpose by making people filter out the discussion on Github? People can
> subscribe to commits@ if they find it more convenient to follow Github
> activity over email rather than Github.com.
>
> We should strive to maintain dev@ as a place for high quality discussion.
> It's upto the contributors to bring up something to dev@ if they believe
> it
> deserves a focused discussion in the community. That discussion may be
> started by the person who proposes code changes, or a reviewer who 
believes
> that a particular code change warrants further discussion.
>
> Regards,
> Rahul
>

Re: users@mxnet

[Barber, Christopher]

Whatever you do, make sure to list all these information sources in one 
easy-to-find place. For instance, it may not be very obvious to anyone that 
they can read the dev mailing list on lists.apache.org. It is bad if users 
aren't even aware that other channels exist.

On 6/18/18, 2:45 PM, "Yasser Zamani"  wrote:



On 6/18/2018 9:18 PM, Jim Jagielski wrote:
> IMO, that is the wrong way to look at it.
> 
> A users@ mailing list is a great, easy, low-cost and low-overhead way of 
*increasing* the user community and providing an extra level of support. Unless 
there is "strong evidence" that this is NOT the case, I would recommend we 
create the list.


As an already Apache Committer of Struts, I also prefer mail list like Jim.

I fell in love with MXNet and I'm still learning hard to being able to
have contributions one day. It was somehow hard for me to also register
and daily monitor another system (your user forum). My feel was same as
your current feel about a new mail list, but, I remembered one rule in
Apache Way: "At Apache, deciders are who do the work". And as I didn't
have any contribution till that time, then I thought I must respect your
decision, so I registered there!

However, I personally still recommend sticking together with Apache
INFRA under Apache Way umbrella as much as possible. I think these help
us to standardize things, understanding each other better and finally
get a graduation from Apache Incubator. Anyway, finally, you who have
done or do the work, are deciders :)

Best Regards.

Re: users@mxnet

[Barber, Christopher]

I don't understand why you would want a users mailing list when you already 
have discussion forums. Users that want to be notified of new posts on the 
forum can configure their notification preferences appropriately. The traffic 
on the forums is already pretty low. I would think you would not want to dilute 
that further.

Christopher 

On 6/18/18, 1:27 PM, "Jim Jagielski"  wrote:

users@ mailing lists have great societal advantages that one shouldn't 
ignore...

And it's not like this is the only project with "multiple" communication 
choices for users. Most, if not all, projects have users@in addition to such 
supplemental methods as IRC channels, a forum, etc... It's about making it easy 
to have as many users as possible and as many potential ways for users to 
communicate. It's not confusing; it's empowering :)

> On Jun 18, 2018, at 1:19 PM, Tianqi Chen  wrote:
> 
> The problem of having multiple separate channels of communication is that
> users get confused, and the cost of maintenance goes up(people have to
> watch both). As the current community was at discuss forum and many users
> prefer it, having a mail-list is only a burden we will bring
> 
> Tianqi
> 
> On Mon, Jun 18, 2018 at 9:48 AM, Jim Jagielski  wrote:
> 
>> IMO, that is the wrong way to look at it.
>> 
>> A users@ mailing list is a great, easy, low-cost and low-overhead way of
>> *increasing* the user community and providing an extra level of support.
>> Unless there is "strong evidence" that this is NOT the case, I would
>> recommend we create the list.
>> 
>>> On Jun 16, 2018, at 12:28 AM, Tianqi Chen 
>> wrote:
>>> 
>>> So unless there is a strong evidence that our community users prefers 
the
>>> mail-list, I would recommend we keep the current way
>>> 
>>> Tianqi
>>> 
>>> On Fri, Jun 15, 2018 at 9:25 PM, Sergio Fernández 
>> wrote:
>>> 
 Are we targeting just Seattle as our community? I really hope we are
 thinking a bit beyond that...
 
 On Fri, Jun 15, 2018, 21:22 Tianqi Chen 
>> wrote:
 
> I remember last time during the mxnet meetup in Seattle, we did a
>> survey,
> and most users preferred the current discuss forum. So I would say we
 stick
> with that given the user community prefers that
> 
> Tianqi
> 
> On Fri, Jun 15, 2018 at 9:13 PM, Sergio Fernández 
> wrote:
> 
>> Then, if everybody agree, let's request the mailing list creation to
> INFRA
>> ;-)
>> 
>> Marco, I wouldn't do that. Typically developers are also subscribed
> there,
>> since they may be the most informed people for answering users'
> questions.
>> But the topics discussed there may not be of the interest for pure
>> development purposes. Some discussions will jump from users@ to dev@,
> but
>> at a different level. So I wouldn't forward one mailing list to the
> other.
>> 
>> On Fri, Jun 15, 2018, 21:01 Marco de Abreu
>>  wrote:
>> 
>>> I think nobody was opposed to it in the past, right?
>>> 
>>> I'd propose that all emails automatically get copied to dev@ to
 ensure
>>> high
>>> visibility initially. What do you think?
>>> 
>>> Sebastian  schrieb am Fr., 15. Juni 2018, 20:51:
>>> 
 I have already proposed this many times in the past and would
> strongly
 encourage it.
 
 -s
 
 On 15.06.2018 21:56, Sergio Fernández wrote:
> Hi,
> 
> is there any good reason why the podling doesn't have a users@
>> mailing
 list
> yet?
> 
> Honestly speaking, I'm not a big fan of the other tools the
 podling
>> is
> using. Slack and Web forums a cool tools, and I used them a lot
 in
>>> other
> contexts. But when it comes to transparency and community,
 mailing
>>> lists
> play a crucial role in the Apache Way.
> 
> Users are the most important asset a project can have. Even more
> than
> developers, believe me. So I think it's time to create a users@
>>> mailing
> list for to helping MXNet grow its community beyong the core
 team.
> 
> Cheers,
> 
 
>>> 
>> 
> 
 
>> 
>> 

Re: MXNet Name Change?

[Barber, Christopher]

Yes, I think it is kind of late to try to get people to say "mix-net" and it 
makes it seem like yet another complex technology that no one even knows how to 
pronounce (e.g. LaTeX). Most English speakers are going to say "em-ex-net". If 
you really want people to say "mix-net" then you should spell it that way, IMO.

On 4/11/18, 4:59 PM, "Rahul Huilgol"  wrote:

Even changing the pronunciation is not an easy thing to do IMHO. As someone
who has been working on MXNet for the last 8 months, this thread is the
first time I am reading that MXNet is supposed to be pronounced 'mix-net'.
We risk losing the momentum even if we try to steer the pronunciation
towards something which is not popular currently.

I agree Gluon is a friendlier/cooler name. But since we are trying to
present Gluon as an interface which multiple frameworks can implement, I'm
not sure if we should try to shift the focus away from MXNet and towards
Gluon.

As far as adoption goes, I agree with Christopher that public benchmarks or
blog posts about how MXNet is better or more usable than other frameworks
would be worth spending effort on. Rebranding in a way to not lose the
existing momentum honestly sounds more difficult than this :)

By the way, we had some talk of a new friendlier logo sometime back. What
happened to that?

On Wed, Apr 11, 2018 at 1:43 PM, Aaron Markham 
wrote:

> Changing branding is hard as we already have some momentum under the
> current name. It's not impossible, and if someone has a fantastic idea
> and marketing plan for it, it's worth considering.
>
> Aside from that, updating the pronunciation could be useful if you
> like having those gif vs jif debates, but at least people would be
> talking about it. I personally like the sound of "mix-net" over
> "em-ex-net". Since we're just starting Youtube videos, I think it's a
> great idea to establish the pronunciation right away in those videos.
>
>
>
> On Wed, Apr 11, 2018 at 1:33 PM, Chris Olivier 
> wrote:
> > Just curious why you think it’s a bad idea — you didn’t say?
> >
> > On Wed, Apr 11, 2018 at 12:49 PM Chen HY  wrote:
> >
> >> At least people needs a way to speak it.
> >> Just define its pronunciation as "mix-net" or "m-x-net" and use the
> agreed
> >> one everywhere helps a lot.
> >> Changing name is a bad idea.
> >>
> >> 2018-04-11 20:29 GMT+01:00 Mu Li :
> >>
> >> > Agree that MXNet, the combination of Minerva and CXXNet, which can be
> >> > interpreted as mixed-net, is hard to be pronounced. But rebranding a
> name
> >> > is a very big decision. We need a very carefully designed marketing
> plan
> >> > for it.
> >> >
> >> > A choice is that we can gradually refer MXNet as a backend, and talk
> more
> >> > about the frontend Gluon.
> >> >
> >> > On Wed, Apr 11, 2018 at 12:16 PM, Thomas DELTEIL <
> >> > thomas.delte...@gmail.com>
> >> > wrote:
> >> >
> >> > > FWIW Brainscript is actually a network definition language:
> >> > > https://docs.microsoft.com/en-us/cognitive-toolkit/
> >> > > BrainScript-Network-Builder
> >> > >
> >> > >
> >> > >
> >> > > Thomas
> >> > >
> >> > >
> >> > > 2018-04-11 12:13 GMT-07:00 Chiyuan Zhang :
> >> > >
> >> > > > IIRC CNTK renamed to something like brainscript which does not
> seem
> >> to
> >> > be
> >> > > > very successful publicity campaign?
> >> > > >
> >> > > > Chiyuan
> >> > > >
> >> > > > On Wed, Apr 11, 2018 at 10:18 AM Chris Olivier <
> >> cjolivie...@gmail.com>
> >> > > > wrote:
> >> > > >
> >> > > > > Should we consider renaming MXNet to something more "friendly"?
> >> > > > >
> >> > > > > IMHO, I think this may be related to adoption problems.
> >> > > > >
> >> > > > > MXNet, CMTK -- both seem sort of sterile and hard to use, don't
> >> they?
> >> > > > >
> >> > > > > Tensorflow, PyTorch, Caffe -- sound cool.
> >> > > > >
> >> > > > --
> >> > > > Semt ftom m ipohne
> >> > > >
> >> > >
> >> >
> >>
> >>
> >>
> >> --
> >> Chen Hanyang 陈涵洋
> >> Software School Fudan University
> >> +86-138-1881-7745
> >>
>



-- 
Rahul Huilgol

Re: MXNet Name Change?

[Barber, Christopher]

While the name could be better, I would instead focus on (1) making mxnet much 
more extensible (e.g. support ability to dynamically load operators from 
external shared libraries), (2) feature parity with tensorflow, (3) support for 
non-NVIDIA GPUs, (4) clearly demonstrating and publicizing better performance 
for large models. 

On 4/11/18, 1:18 PM, "Chris Olivier"  wrote:

Should we consider renaming MXNet to something more "friendly"?

IMHO, I think this may be related to adoption problems.

MXNet, CMTK -- both seem sort of sterile and hard to use, don't they?

Tensorflow, PyTorch, Caffe -- sound cool.

Re: [VOTE] Change Scala namespace from dmlc to org.apache

[Barber, Christopher]

If you were to have two implementations you would want to annotate the old one 
as deprecated immediately. I don't think you would want to commit to supporting 
it for more than a couple of months. How many users of the Scala MXNet 
interface are there in any case? And do they really view the Scala API as a 
mature stable product? 

Sometimes it is better to bite the bullet and force people to switch. Think how 
much time has been wasted on python 2.7/3.x compatibility years after 2.7 
should have been long forgotten.

On 3/13/18, 12:26 PM, "Chris Olivier" <cjolivie...@gmail.com> wrote:

I'm not taking a side here, but just please consider that if you have two
separate implementations for awhile, the newer one will start to diverge
and over time, it will become harder and harder for the user to port his
code.  You may find yourself supporting the old code for much longer than
you anticipated (especially if changed go into the old implementation).

On Tue, Mar 13, 2018 at 9:11 AM, Barber, Christopher <
christopher.bar...@analog.com> wrote:

> Personally, I believe that MXNet jumped the gun on 1.0. It is pretty clear
> that the API is still not entirely stable.
>
> Given that, I would just go with the incompatible change rather than suck
> up a lot of your development time building and supporting bridges and
> facades and potentially introducing new bugs as a result. As an
> alternative, you could just support two independent implementations using
> the two namespaces for some period of time until people can switch to the
> new one. It's not like it will be that difficult for customer's to port
> their code.
>
> But really this is up to the Scala maintainers to decide what they want to
> do.
>
> On 3/13/18, 12:01 PM, "kellen sunderland" <kellen.sunderl...@gmail.com>
> wrote:
>
> Maintaining backwards compatibility never results in the prettiest
> code,
> but it seems pretty desirable here.  There are relatively few files
> here,
> so I agree there's some risk but I don't think it would take too much
> time.  Feel free to suggest alternatives Christopher.
>
> On Tue, Mar 13, 2018 at 4:56 PM, Barber, Christopher <
> christopher.bar...@analog.com> wrote:
>
> > That sounds like a lot of work and it would be easy to get wrong if
> it is
> > even feasible.
> >
> > On 3/13/18, 11:51 AM, "kellen sunderland" <
> kellen.sunderl...@gmail.com>
> > wrote:
> >
> > I don't know about aliasing a namespace in Scala, but I wonder
> how
> > hard it
> > would be to either (1) provide a fascade from the new package to
> the
> > old
> > package or (2) keep two copies of the scala code temporarily
> along
> > with two
> > copies of the JNI entry points.  In both of these cases we could
> setup
> > @deprecated on all public calls to the old package.
> >
> > On Tue, Mar 13, 2018 at 4:47 PM, Nan Zhu <zhunanmcg...@gmail.com
> >
> > wrote:
> >
> > > re Chris: I do not have any good idea about this.
> > >
> > > On Tue, Mar 13, 2018 at 8:13 AM, Chris Olivier <
> > cjolivie...@gmail.com>
> > > wrote:
> > >
> > > > is it possible to somehow alias a namespace in scala
> > > > in order to maintain backwards compatibility?
> > > >
> > > > On Tue, Mar 13, 2018 at 7:21 AM Nan Zhu <
> zhunanmcg...@gmail.com>
> > wrote:
> > > >
> > > > > +1
> > > > >
> > > > > and additional suggestion is do it ASAP
> > > > >
> > > > > On Mon, Mar 12, 2018 at 11:21 PM, Chris Olivier <
> > cjolivie...@gmail.com
> > > >
> > > > > wrote:
> > > > >
> > > > > > not sure I understand. How could changing a java
> namespace
> > > (effectively
> > > > > > moving the files to a different location as well as
> changing
> > the
> > > > package
> > > > > > names) be backw

Re: [VOTE] Change Scala namespace from dmlc to org.apache

[Barber, Christopher]

That sounds like a lot of work and it would be easy to get wrong if it is even 
feasible.

On 3/13/18, 11:51 AM, "kellen sunderland"  wrote:

I don't know about aliasing a namespace in Scala, but I wonder how hard it
would be to either (1) provide a fascade from the new package to the old
package or (2) keep two copies of the scala code temporarily along with two
copies of the JNI entry points.  In both of these cases we could setup
@deprecated on all public calls to the old package.

On Tue, Mar 13, 2018 at 4:47 PM, Nan Zhu  wrote:

> re Chris: I do not have any good idea about this.
>
> On Tue, Mar 13, 2018 at 8:13 AM, Chris Olivier 
> wrote:
>
> > is it possible to somehow alias a namespace in scala
> > in order to maintain backwards compatibility?
> >
> > On Tue, Mar 13, 2018 at 7:21 AM Nan Zhu  wrote:
> >
> > > +1
> > >
> > > and additional suggestion is do it ASAP
> > >
> > > On Mon, Mar 12, 2018 at 11:21 PM, Chris Olivier  >
> > > wrote:
> > >
> > > > not sure I understand. How could changing a java namespace
> (effectively
> > > > moving the files to a different location as well as changing the
> > package
> > > > names) be backward-compatible?
> > > >
> > > >
> > > > On Mon, Mar 12, 2018 at 11:02 PM Steffen Rochel <
> > steffenroc...@gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > I suggest the vote should call out if the change is breaking
> backward
> > > > > compatibility or not.
> > > > > I looked through the scala name changing thread and don't see
> > > > justification
> > > > > for a backward incompatible change.
> > > > > I do agree it would be good to change the name space, but have not
> > > seen a
> > > > > reason why the change has to be made now in backward incompatible
> > way.
> > > > > Non-binding vote:
> > > > > +1 for backward compatible namespace change
> > > > > -1 for backward incompatible namespace change
> > > > >
> > > > > Suggest to explore package aliasing for a backward compatible
> change
> > -
> > > > see
> > > > > a possible idea at
> > > > >
> > > > > https://stackoverflow.com/questions/28238520/python-
> > > > like-package-name-aliasing-in-scala
> > > > >
> > > > >
> > > > > Steffen
> > > > >
> > > > > On Mon, Mar 12, 2018 at 4:04 PM, Rahul Huilgol <
> > rahulhuil...@gmail.com
> > > >
> > > > > wrote:
> > > > >
> > > > > > +1
> > > > > >
> > > > > > We need to change the namespace as soon as possible.
> > > > > >
> > > > > > On Mon, Mar 12, 2018 at 3:15 PM, Roshani Nagmote <
> > > > > > roshaninagmo...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > +1 to change the namespace
> > > > > > >
> > > > > > > On Mon, Mar 12, 2018 at 3:05 PM, Chris Olivier <
> > > > cjolivie...@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > The assumption is that it would be changed more-or-less
> > > > immediately.
> > > > > > ie.
> > > > > > > > this is like a voted PR, I guess.
> > > > > > > >
> > > > > > > > On Mon, Mar 12, 2018 at 2:53 PM, Chris Olivier <
> > > > > cjolivie...@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > It is about changing the namespace.  As far as I know, the
> > > > version
> > > > > > > number
> > > > > > > > > of the next release is not defined.
> > > > > > > > > At such point where a release is announced, one could
> > comment,
> > > > vote
> > > > > > > > > whatever on the chosen version of that release, I suppose.
> > But
> > > > > > that's
> > > > > > > > > beyond the scope of this vote, because the "next release"
> is
> > > not
> > > > > yet
> > > > > > > > > defined.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Mon, Mar 12, 2018 at 2:48 PM, Marco de Abreu <
> > > > > > > > > marco.g.ab...@googlemail.com> wrote:
> > > > > > > > >
> > > > > > > > >> Just for clarification: Is this vote about changing the
> > > > namespace
> > > > > > with
> > > > > > > > the
> > > > > > > > >> next release?
> > > > > > > > >>
> > > > > > > > >> On Mon, Mar 12, 2018 at 7:16 PM, Naveen Swamy <
> > > > mnnav...@gmail.com
> > > > > >
> > > > > > > > wrote:
> > > > > > > > >>
> > > > > > > > >> > Chris, Thanks for starting this vote.
> > > > > > > > >> > This is long pending
> > > > > > > > >> >
> > > > > > > > >> > +1 to change org.apache namespace
> > > > > > > > >> >
> > > > > > > > >> > On Mon, Mar 12, 2018 at 10:35 AM, Marco de Abreu <
> > > > > > > > >> > 

Re: Following semantic versioning

[Barber, Christopher]

There are two separate issues: how to compile against the MXNet source and how 
to dynamically load external dynamic libraries. While it would be nice to have 
all necessary headers in the same place, it doesn't really matter that much if 
people building extensions have to have access to the entire MXNet source tree. 
The real issue is whether you support the ability to dynamically load such 
extensions. 

- Christopher

On 3/6/18, 4:12 PM, "Chris Olivier" <cjolivie...@gmail.com> wrote:

This was discussed in the past and so far, it seems possible for Unix
builds, although it’s going to be messy since the compile would generally
need access to all a large portion of the headers in the source tree, since
the “things needed to create your own op” aren’t necessarily all contained
in the include/mxnet directory.

On Tue, Mar 6, 2018 at 11:40 AM kellen sunderland <
kellen.sunderl...@gmail.com> wrote:

> Could we actually just define a mechanism so the libs could register their
> ops at runtime?  No linking required?
>
> On Tue, Mar 6, 2018, 8:36 PM Pedro Larroy <pedro.larroy.li...@gmail.com>
> wrote:
>
> > 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
> > > allow MXNet to be extended without having to resort to forking. There
> is
> > > currently no way to add C++ custom operators without forking, and no
> way
> > to
> > > share such operators across projects. This creates a perverse 
incentive
> > to
> > > try to get changes that may not belong into the main product.
> > >
> > > On 3/5/18, 6:26 PM, "Marco de Abreu" <marco.g.ab...@googlemail.com>
> > > wrote:
> > >
> > > Hello,
> > >
> > > we recently had a few cases in which it has been attempted to add
> new
> > > functionality to old branches because a customer of somebodys
> > $DAY_JOB
> > > requested it and was unable to switch to the latest release or 
that
> > > certain
> > > feature did not make it into the release. This lead to quite a lot
> of
> > > discussions and there was no clear standing within the community.
> > >
> > > Just to cite semantic versioning:
> > >
> > >1. MAJOR version when you make incompatible API changes,
> > >2. MINOR version when you add functionality in a
> > > backwards-compatible
> > >manner, and
> > >3. PATCH version when you make backwards-compatible bug fixes.
> > >
> > >
> > > We as a community agreed on following this system and I think we
> > should
> > > either stick to it or drop it entirely - exceptions to SemVer are
> > > usually
> > > discouraged. While I see that adding functionality might be a 
minor
> > > thing,
> > > I don't think that we should educate our users into expecting us 
to
> > > backport new features. The development happening on the Apache
> MXNet
> > > repository should not be influenced by something like this;
> > especially
> > > considering that whoever supports that customer on their $DAY_JOB
> can
> > > assist them at creating a fork and cherrypicking that feature. But
> I
> > > don't
> > > see much reason why we're running against best pracitices. One
> > > important
> > > thing to note here is that we're not maintaining CI on old 
branches
> > and
> > > neither are we making patch releases - so what do these users do?
> > > Compile
> > > off a stale development branch with unvalidated changes?
> > >
> > > In my opinion this whole topic is just causing trouble and
> > > fragementation
> > > on our end. If a features doesn't make it into the release (for
> > > whatever
> > > reason), so be it. But I think we should discuss this topic and
> > > emphasize a
> > > no-exceptions-rule to SemVer.
> > >
> > > Best regards,
> > > Marco
> > >
> > >
> > >
> >
>

Re: Following semantic versioning

[Barber, Christopher]

To avoid this kind of problem, you really need to support features that allow 
MXNet to be extended without having to resort to forking. There is currently no 
way to add C++ custom operators without forking, and no way to share such 
operators across projects. This creates a perverse incentive to try to get 
changes that may not belong into the main product. 

On 3/5/18, 6:26 PM, "Marco de Abreu"  wrote:

Hello,

we recently had a few cases in which it has been attempted to add new
functionality to old branches because a customer of somebodys $DAY_JOB
requested it and was unable to switch to the latest release or that certain
feature did not make it into the release. This lead to quite a lot of
discussions and there was no clear standing within the community.

Just to cite semantic versioning:

   1. MAJOR version when you make incompatible API changes,
   2. MINOR version when you add functionality in a backwards-compatible
   manner, and
   3. PATCH version when you make backwards-compatible bug fixes.


We as a community agreed on following this system and I think we should
either stick to it or drop it entirely - exceptions to SemVer are usually
discouraged. While I see that adding functionality might be a minor thing,
I don't think that we should educate our users into expecting us to
backport new features. The development happening on the Apache MXNet
repository should not be influenced by something like this; especially
considering that whoever supports that customer on their $DAY_JOB can
assist them at creating a fork and cherrypicking that feature. But I don't
see much reason why we're running against best pracitices. One important
thing to note here is that we're not maintaining CI on old branches and
neither are we making patch releases - so what do these users do? Compile
off a stale development branch with unvalidated changes?

In my opinion this whole topic is just causing trouble and fragementation
on our end. If a features doesn't make it into the release (for whatever
reason), so be it. But I think we should discuss this topic and emphasize a
no-exceptions-rule to SemVer.

Best regards,
Marco

Re: Display the master branch website in default for a period

[Barber, Christopher]

I was thinking more along the lines of benchmarks of MXNet vs TensorFlow, 
PyTorch, and Caffe2. Benchmarks of edge devices would definitely be 
interesting, but I would also want to see benchmarks of training time and 
memory use and accuracy on large models. Obviously this would be a non-trivial 
amount of work, which is why no one else is doing it, but there would be a lot 
of interest in this. Also would like to see benchmarks of ndarray, vs symbol vs 
gluon.

But yes, if you want to drive traffic to the website you should have content 
that changes frequently. I have to say I find it really strange to have the 
entire website change when I select a different version from the top tab. The 
design of the website should be independent of the code version.

- Christopher

On 3/1/18, 4:33 PM, "Marco de Abreu" <marco.g.ab...@googlemail.com> wrote:

As far as I know, there are plans to make regular benchmarks and generate
statistics. We could use that data. My personal task after CI is creating
an infrastructure to automatically perform performance and power
consumption benchmarks on edge devices (raspberry and Nvidia Jetson). It
would definitely be a good idea to share this data with the community
(especially considering the impressive performance of MXNet).

Aaron is currently gathering requirements for recreating the website build
and publish process, so input like this is definitely helpful. This could
basically be summarized as a requirement to make the website contain static
parts (e.g. APIs and documentation) as well as dynamic parts (e.g. news,
statistics, recent papers etc).

How does that sound?

-Marco

Aaron Markham <aaron.s.mark...@gmail.com> schrieb am Do., 1. März 2018,
22:11:

> Do you have specific public benchmarks in mind?
>
    > On Mar 1, 2018 10:13, "Barber, Christopher" <christopher.bar...@analog.com
> >
> wrote:
>
> > I think one thing that could draw more users would be published
> benchmarks
> > that show that networks implemented using MXNet perform better than
> > comparable ones using other platforms using the same hardware. If you 
can
> > definitively show that MXNet is much faster and/or uses much less 
memory,
> > you will attract much more interest.
> >
> > - Christopher
> >
> > On 2/25/18, 11:53 PM, "Li, Mu" <m...@amazon.com> wrote:
> >
> > That's a great idea. The thing Simon's team is doing is publishing
> > more tutorials on both MXNet website and AWS blog, which may attract a
> lot
> > of traffics. Also Sukwon is tracking the progress of publishing news 
more
> > frequently on the homepage.
> >
> > Best,
> > Mu
> >
> > > On Feb 25, 2018, at 8:48 PM, Chris Olivier <cjolivie...@gmail.com>
> > wrote:
> > >
> > > My (probably less-than-$0.02):
> > >
> > > I have as my home page on my
> > > phone, the Google Research Blog, and they frequently release stuff
> > like
> > > data sets and models do this or that.  Usually it seems pretty
> > interesting
> > > and I am compelled to try it.
> > >
> > > Maybe we do something similar, but I’m not aware of it. I know we
> > have all
> > > sorts of examples and whatnot, but it doesn’t seem the same as 
what
> > at
> > > least appears to be something new to play with scrolling past 
every
> > couple
> > > of weeks:
> > >
> > > For example, a few days ago:
> > >
> > > “Introducing the HDR+ Burst Photography Dataset”.
> > >
> > > https://research.googleblog.com/2018/02/introducing-hdr-
> > burst-photography.html?m=1
> > >
> > > Reading that makes me want to download it and play around.
> > Obviously I
> > > would use Tensorflow by default because it’s ready to roll as-is
> > with this
> > > dataset/model.
> > >
> > >
> > > -Chris
> > >
> > >
> > >
> > >> On Sun, Feb 25, 2018 at 8:34 PM Mu Li <limu...@gmail.com> wrote:
> > >>
> > >> Not sure why the screenshot of the page view is not there, attach
> > it again:
> > >>
> > >>
> > >> Best,
> >

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

[Barber, Christopher]

y in the order of billions
> of devices. I'm sure you have your own bag of tricks. Please excuse me
> if my comments came across as questioning your development experience
> at any time. I have high regards for your development experience in
> any case.
>
>
>
>
>
>
>
>
>
> On Tue, Jan 16, 2018 at 4:55 PM, Chris Olivier <cjolivie...@gmail.com
> <mailto:cjolivie...@gmail.com>> wrote:
> Pedro,
>
> i don’t know if you’ve ever done much development or not, but during
> development, it’s quite common to comment out arbitrary lines of code,
> create a variable only for debug inspection, or other things that will
> generate warnings, but are actually intentional.  causing a compile error 
i
> this case would not be acceptable, in my opinion.
>
> as for the any compiler issue, if someone is using a newer gcc or clang,
> and while it only has 2 new warning, they appear in 200 places, are you
> saying it’s the responsibility of this poor community developer to fix all
> of those warnings? or they can open up a JIRA to your team and you will 
fix
> them?
>
>
> On Tue, Jan 16, 2018 at 7:48 AM Marco de Abreu <
> marco.g.ab...@googlemail.com<mailto:marco.g.ab...@googlemail.com>>
> wrote:
>
> 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 takes
> up most of the time and is very costly.
>
> -Marco
>
> On Tue, Jan 16, 2018 at 4:11 PM, Barber, Christopher <
> christopher.bar...@analog.com<mailto:christopher.bar...@analog.com>>
> wrote:
>
> 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
> out
> about other important test failures until much later. Better to add a
> test
> that grovels the build logs for warning messages and treat it as a test
> failure.
>
> I also prefer to only enable exactly those warnings that truly matter.
>
> On 1/16/18, 8:23 AM, "Marco de Abreu" <marco.g.ab...@googlemail.com<
> mailto:marco.g.ab...@googlemail.com>>
> wrote:
>
>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 which is not critical enough (otherwise it would be an error)
> to
>justify blocking the compilation. In my opinion, it 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% without risking to break the master branch on different
>compilers is way better in my opinion than having a 100% coverage
> which
>could block compilation - especially because we would only notice if
> a
> user
>tells us afterwards.
>
>-Marco
>
>On Tue, Jan 16, 2018 at 1:32 PM, Pedro Larroy <
> pedro.larroy.li...@gmail.com<mailto:pedro.larroy.li...@gmail.com>>
>wrote:
>
> 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 private branch, but I don't see what would be the benefit of
> this.
>
> Regarding your second point, I think this is a minor issue which is
> outweighed by the benefits. In the case you propose, the author of
> a
> PR can easily fix a bunch of warnings when CI fails as usual. For
> example in case he gets one or two warnings that his version of the
> compiler didn't catch, or if she has an additional warning of some
&

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

[Barber, Christopher]

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 out about other 
important test failures until much later. Better to add a test that grovels the 
build logs for warning messages and treat it as a test failure.

I also prefer to only enable exactly those warnings that truly matter.

On 1/16/18, 8:23 AM, "Marco de Abreu"  wrote:

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 which is not critical enough (otherwise it would be an error) to
justify blocking the compilation. In my opinion, it 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% without risking to break the master branch on different
compilers is way better in my opinion than having a 100% coverage which
could block compilation - especially because we would only notice if a user
tells us afterwards.

-Marco

On Tue, Jan 16, 2018 at 1:32 PM, Pedro Larroy 
wrote:

> 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 private branch, but I don't see what would be the benefit of this.
>
> Regarding your second point, I think this is a minor issue which is
> outweighed by the benefits. In the case you propose, the author of a
> PR can easily fix a bunch of warnings when CI fails as usual. For
> example in case he gets one or two warnings that his version of the
> compiler didn't catch, or if she has an additional warning of some
> type with a different version of GCC / Clang.
>
> This has the objective to prevent warning inflation. In practice, a
> different version of GCC might produce just a couple of new warning
> types that will be easily fixable once we upgrade the compiler in CI.
> We also get the benefit of preventing warnings on the gcc versions
> that the author is using, in the case he has a different one. Another
> option is to enable warnings as errors only on CI. I would prefer to
> have it enabled by default, for correctness. As first time users are
> not likely to compile MXNet by themselves, and also considering the
> significant complexity of compiling MXNet from scratch for newcomers.
>
> In general, the compilers that we have running on CI should be our
> reference compilers. And for practical purposes, having no warnings in
> those versions of Clang and GCC would be a positive step towards more
> code quality, clean compilation and a more mantainable code base.
> Once we have CI stable we can build a matrix of supported compilers in
> the docs, as for example there are versions of GCC which are not
> supported by the nvidia tools.
>
> Pedro.
>
>
>
>
> On Mon, Jan 15, 2018 at 7:27 PM, Chris Olivier 
> wrote:
> > If enabled, it should only cause errors in Release builds, since having
> > warnings in WIP code is not unusual.
> >
> > In addition, different developers use different gcc/clang versions. Some
> > gcc versions, for instance, generate warnings where others do not.  It
> > would not be fair to render unbuildable a developer who is using a newer
> > (or older) gcc version is different from CI.  Can this argument be tied
> to
> > a particular compiler/platform/version?
> >
> > On 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 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 bugs as has happened before.
> >> >
> >> > While this might be impractical in all 

Re: Increase indentation limit from 100 to 120 characters

[Barber, Christopher]

For languages like C++ and Java it is hard to stay within 80 columns without 
resorting to overly terse naming scheme or awkward indentation. 120 really 
makes a lot of sense for C++ and it seems easier to adopt the same standard 
throughout the codebase since it may be annoying or difficult to configure 
editors to enforce different limits on different subdirectories. I find that 
even on my laptop, I can work with two side-by-side editor panes with 
120-column code. 80 columns made perfect sense back in 1985 when most people 
were editing their code on 80-column VT terminals and frequently printing their 
code out, but at this point it is just a legacy standard.



On 1/8/18, 4:53 AM, "kellen sunderland"  wrote:

>It's probably good to have an example to help with discussion.  Here's one
>that's been bugging us, and highlights why the current line length limit in
>C++ leads to hard-to-read code:
>https://github.com/larroy/mxnet/blob/467a79c8b9f3a75ce993302c6d0c858628cb1cdc/tests/cpp/operator/batchnorm_test.cc#L963
>
>On Sat, Jan 6, 2018 at 12:00 PM, kellen sunderland <
>kellen.sunderl...@gmail.com> wrote:
>
>> Just a note that I don't think Pedro was suggesting the change for Python
>> or Scala.  How would folks feel about changing the limit for just C++?
>>
>> On Sat, Jan 6, 2018 at 6:21 AM, Tianqi Chen 
>> wrote:
>>
>>> An argument against such change would be the coding style standard is
>>> people already get used to it, and there is less benefit of making the
>>> change.
>>>
>>> PEP and Google C style suggest 80 chars as limit, I usually write with
>>> that
>>> in mind and try to break multiple arguments into multiple lines when such
>>> violation happens, and rarely sometimes have a 100 line code for code
>>> reason
>>>
>>> One potential benefit of fewer characters per line makes it easier to do
>>> split editing when you split your code into two screens (hey emacs and vim
>>> users)
>>>
>>> I am not in strong favor of either number of line limits but is
>>> comfortable
>>> with the current setting
>>>
>>>
>>> Tianqi
>>>
>>> On Fri, Jan 5, 2018 at 11:28 AM, Chris Olivier 
>>> wrote:
>>>
>>> > Thank you for the excellent reply!
>>> >
>>> > On Fri, Jan 5, 2018 at 11:25 AM, Nan Zhu 
>>> wrote:
>>> >
>>> > > wellmax line length as 100 is adopted in many projects (nearly all
>>> > > projects I have been involved or used or looked at,
>>> > > spark/flink/bahir/atlas, etc. companies which using scala intensively
>>> > also
>>> > > sets it to 100 (e.g. netflix, you can check their atlas project))
>>> > >
>>> > > one of the reasons is that all these projects are all following
>>> > > https://github.com/databricks/scala-style-guide which was published
>>> in
>>> > the
>>> > > early days of when scala is becoming popular
>>> > >
>>> > > and the behind reason might be that considering the language
>>> > > characteristics of scala, a shorter line limit would be make it more
>>> > > readable, (http://docs.scala-lang.org/style/indentation.html#line-
>>> > wrapping
>>> > > ,
>>> > > the official guide even says 80 as the limit)
>>> > >
>>> > > Also note that, scala-packages has a scala-style plugin regulating
>>> coding
>>> > > style which does not apply limits for certain cases, e.g. import, and
>>> the
>>> > > developer can turn off style checking if you are doing something
>>> special
>>> > >
>>> > >
>>> > > BTW, considering monitor-relevant concern,
>>> > http://scalameta.org/scalafmt/
>>> > > tells that 100 is good enough even for a 30'' wide monitor
>>> > >
>>> > >
>>> > >
>>> > >
>>> > > On Fri, Jan 5, 2018 at 11:10 AM, Chris Olivier >> >
>>> > > wrote:
>>> > >
>>> > > > Why -1?
>>> > > >
>>> > > > On Fri, Jan 5, 2018 at 11:03 AM, Nan Zhu 
>>> > wrote:
>>> > > >
>>> > > > > -1 for scala part
>>> > > > >
>>> > > > > On Fri, Jan 5, 2018 at 9:48 AM, Marco de Abreu <
>>> > > > > marco.g.ab...@googlemail.com
>>> > > > > > wrote:
>>> > > > >
>>> > > > > > +1
>>> > > > > >
>>> > > > > > Am 05.01.2018 5:49 nachm. schrieb "Chris Olivier" <
>>> > > > cjolivie...@gmail.com
>>> > > > > >:
>>> > > > > >
>>> > > > > > +1
>>> > > > > >
>>> > > > > > On Fri, Jan 5, 2018 at 8:00 AM, Pedro Larroy <
>>> > > > > pedro.larroy.li...@gmail.com
>>> > > > > > >
>>> > > > > > wrote:
>>> > > > > >
>>> > > > > > > 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
>>> > > > > > >
>>> > > > > >
>>> > > > >
>>> > > >
>>> > >
>>> >
>>>
>>
>>