Re: Slack access

2018-05-01 Thread Steffen Rochel
HI Jesse - added you to slack. Please use discuss.mxnet.io to raise your questions and get support from the community. Steffen On Tue, May 1, 2018 at 6:48 PM jesse brizzi wrote: > Hey everyone, > > I'm looking to get slack access and hopefully offer my help with > contributions/development. > >

Re: The New Scala API

2018-05-01 Thread Naveen Swamy
No, the implementation still comes from MXNet backend. I don't think there would be any overhead unlike C++ with virtual functions, Interface or trait is just telling you what the signature looks like. users program against interfaces and can choose a different implementation if they like. For exam

Re: The New Scala API

2018-05-01 Thread Marco de Abreu
Hey Naveen, I'm not familiar with Scala, so please correct me if I'm wrong with my assumptions. This basically sounds like we'd have an interface for the Scala API and a separate implementation, right? In general, I really like these decoupled approaches (you already highlighted the advantages)!

Slack access

2018-05-01 Thread jesse brizzi
Hey everyone, I'm looking to get slack access and hopefully offer my help with contributions/development. I work for a startup that uses Mxnet for some of our internal R&D and deep learning based services, specifically the scala and python interfaces, and have run into a few bugs/issues that we c

Re: Pre-release versions on website

2018-05-01 Thread Marco de Abreu
Hi Aaron, I think it'd be a good idea to create pip packages for the release candidates. Sheng, would it be possible to incorporate this into your build pipeline? In my opinion, we shouldn't advertise the RCs not too much on our website, so I'd say we could skip #2. #3 in combination with #1 sounds

Re: GitHub releases section used for non-releases

2018-05-01 Thread Marco de Abreu
I see, seems like this slipped through in my review. Sorry for that! Would anybody object to putting things like these in our S3 bucket? On Wed, May 2, 2018 at 3:36 AM, shiwen hu wrote: > this util is use in decompression mkldnn depend. pr is > https://github.com/apache/incubator-mxnet/pull/106

Re: GitHub releases section used for non-releases

2018-05-01 Thread shiwen hu
this util is use in decompression mkldnn depend. pr is https://github.com/apache/incubator-mxnet/pull/10629 . marcoabreu Ask me not to put it in a private repositories. If it doesn't feel right, we can discuss another plan. Now I've changed it to pre-release 2018-05-02 6:37 GMT+08:00 Hen : > Winc

Re: Pre-release versions on website

2018-05-01 Thread Aaron Markham
Hi Marco, Putting 1.2.0 was meant to allow a preview and for testing, but I see how this can cause confusion. Change the names and/or hiding the RC is possible with some refactoring of the site build scripts. I'd be happy to take a look at this. I think another solution could be: 1. create pip in

Re: GitHub releases section used for non-releases

2018-05-01 Thread Hen
Wincing at a binary of 7z being there. Seems like something to delete. On Tue, May 1, 2018 at 3:32 PM Marco de Abreu wrote: > Hello, > > I have just had a look at > https://github.com/apache/incubator-mxnet/releases > and it seems like the releases section is being used for other purposes > than

GitHub releases section used for non-releases

2018-05-01 Thread Marco de Abreu
Hello, I have just had a look at https://github.com/apache/incubator-mxnet/releases and it seems like the releases section is being used for other purposes than MXNet releases (e.g. https://github.com/apache/incubator-mxnet/releases/tag/utils). This causes MXNet 1.1.0 to not be shown as "Latest re

Pre-release versions on website

2018-05-01 Thread Marco de Abreu
Hello, we have been approached by a few users about the release status of MXNet 1.2. One thing that seems to be confusing in particular is the fact that we already show version 1.2.0 on our website. Would it be possible to blacklist (and remove) pre-release versions from website until they have be

Re: The New Scala API

2018-05-01 Thread Naveen Swamy
I think this project is going to significantly improve the usability of MXNet-Scala APIs. I had a offline discussion with Qing about this. I agree with Yizhi that keeping in the same namespace will make it easy for existing and new users to quickly lookup the APIs. Along with that I have one recom