Re: Following semantic versioning

Great!! Yes, please share! On Fri, Mar 9, 2018 at 7:29 PM Can Balioglu wrote: > We found a rather "hacky" way to dynamically inject our operators and data > iterators during runtime. I can share the details if you are interested. We > also plan to send out a design

Re: Following semantic versioning

We found a rather "hacky" way to dynamically inject our operators and data iterators during runtime. I can share the details if you are interested. We also plan to send out a design proposal for a proper extensibility framework similar to TensorFlow's plugin API. -Can On Wed, Mar 7, 2018, at

Re: Publishing Scala Package/namespace change

user: “I’m having a problem with Scala API”. dev: “What version?” user: “1.4” dev: “Is that Scala API version or MXNET version?” user: “uhh... scala version, maybe?” dev: “ok, which mxnet version?” user: “i don’t know, how do I find that out?” dev : “ummm go look in blah blah directory and

Re: call for contributions to next MXNet release

Hello Patric, please be aware of the fact that there are still a lot of disabled tests, open MKLDNN issues, broken features and flaky tests that have not been addressed yet. We agreed on merging MKLDNN for the time being to allow broad testing and that we will revisit the state a bit before the

RE: call for contributions to next MXNet release

Hi Steffen, We'd like the MKL-DNN backend can be included in the next release. We (Intel engineers) and Zheng-Da (AWS engineer) can work on it. Could you help add the item in the table? Thanks, --Patric > -Original Message- > From: Steffen Rochel [mailto:steffenroc...@gmail.com] >

Re: Publishing Scala Package/namespace change

My proposal was to have separate versioning but same release cycles - having separate cycles was just an idea. So how would we approach this problem in future if there's a big improvement on one of our language bindings? Like I said previously, it might be fine for this case, but we will run into

Re: Refactoring docker handling on CI and locally

Hello, fyi, this change has just been merged to master and PRs containing modifications to Dockerfiles will have to be adopted to the new layout. I will write the documentation on Monday, the issue can be tracked at https://issues.apache.org/jira/browse/MXNET-71. Please don't hesitate to reach

Re: Publishing Scala Package/namespace change

I think last time we postpone it because the release is a minor version but actually such a change is actually affordable for a jump from 1.1 - 1.2 -1 on separate versions (not following apache rules) On Fri, Mar 9, 2018 at 2:38 PM, Chris Olivier wrote: > IMHO, I don't

Re: Publishing Scala Package/namespace change

IMHO, I don't think having separate versions and releases for the scala API will work for the following reasons: - Scala API is not its own Apache project, so we don't really have a mechanism to release it separately and not the manpower of volunteers to maintain all the BS that goes

Re: Publishing Scala Package/namespace change

I agree, separate release cycles would cause a lot of hassle and grant now visible benefit, I'd bind these to the main release cycles. But I would separate the versioning of each package. At the moment, we are bound by the least common denominator in terms of API changes and versions. While this

Re: Publishing Scala Package/namespace change

MXNet Scala APis already generate a MXNet Core Scala package based off the cpp backend already. I think customers who are building from source would love to get Maven package given that it takes so much pain. Are you suggesting we take MXNet-Scala APIs into a separate release cycle, it is

Re: Python extension module survey

I'm a bit lost here. Could you explain a bit more what you would like to do? -Marco Chris Olivier schrieb am Fr., 9. März 2018, 22:46: > If we were to distribute a python extension module, which python versions > would we need to support before requiring: > > 1) a

Re: UTF-8 Support for TextParser

Won't run entire text through converter, will just ignore the BOM character during parsing stage. Anirudh On Fri, Mar 9, 2018 at 1:12 PM, Chris Olivier wrote: > For this, are you going to run the entire text through a converter, or just > prepend the UTF-8 header to the

Re: Publishing Scala Package/namespace change

While it has never been published, there have still been releases under Apache and - as you mentioned - customers that build off the source. This would cause compatibility issues. In general I actively support the idea of enhancing the Scala package, but I think that we have to solve another

Python extension module survey

If we were to distribute a python extension module, which python versions would we need to support before requiring: 1) a recompile on the end-user host (note this may not be trivial for MSVC) 2) an automatic download of a prebuilt module from an internet repository (ie S3 or Apache FTP) at

Re: Publishing Scala Package/namespace change

+1 for changing the namespace asap. for the maven deploy, we can have it build along with pip deployment. 2018-03-09 10:15 GMT-08:00 Naveen Swamy : > Hi Guys, > > I am working on MXNet Scala Inference APIs > along with another

Re: UTF-8 Support for TextParser

For this, are you going to run the entire text through a converter, or just prepend the UTF-8 header to the file (0xEF,0xBB,0xBF)? On Fri, Mar 9, 2018 at 12:43 PM, Anirudh wrote: > Hi, > > Upon deeper understanding of customer requirement we found out that the > customer

Re: UTF-8 Support for TextParser

Hi, Upon deeper understanding of customer requirement we found out that the customer uses only ASCII data with MXNet, just that they want the files containing UTF-8 BOM at the start and files with different control characters for newline to play well. dmlc-core already supports control characters

Re: Cython Document iteration

Eric told me the current cython files "didn't work", so I have not reused any of the previous cython attempt at this time. On Fri, Mar 9, 2018 at 10:31 AM, Xingjian SHI wrote: > Great! Also, what’s the current status of Cython support in MXNet? I think > we have the

Re: Cython Document iteration

I didn't really use anything from the old cython stuff yet. Mostly setting up build and development system and doing performance testing. On Fri, Mar 9, 2018 at 10:32 AM, Tianqi Chen wrote: > The cython part was not actively maintained and currently disabled, but the

Re: Cython Document iteration

The cython part was not actively maintained and currently disabled, but the code structure can likely be reused Tianqi On Fri, Mar 9, 2018 at 10:31 AM, Xingjian SHI wrote: > Great! Also, what’s the current status of Cython support in MXNet? I think > we have the option

Re: Cython Document iteration

Great! Also, what’s the current status of Cython support in MXNet? I think we have the option to use Cython, which is added by Tianqi. Best, Xingjian Get Outlook for iOS _ From: Chris Olivier Sent: Friday, March 9, 2018

Cython Document iteration

I have generated some cython documentation based upon work so far regarding build system, profiling, development, debugging, etc. https://docs.google.com/document/d/1pvW5nYbf3pbiak95xZdqgLbrjQdvVrVGoYdiU3hNsqc -Chris

Publishing Scala Package/namespace change

Hi Guys, I am working on MXNet Scala Inference APIs along with another contributor Roshani. A while back I noticed that we haven't been publishing the scala package to Maven for a while now(last one being v0.11.1a under the dmlc namespace).

Re: Meetup in Seattle

Based on doodle looks like April 24th is the preferred date for our public meetup in Seattle. Mark the date and send suggestions what content you are interested on. More details to follow. Regards, Steffen On Thu, Mar 1, 2018 at 4:19 AM Pedro Larroy

call for contributions to next MXNet release

Hi - I would like to propose the next MXNet release. Initial draft content is listed at MXNet wiki . I would like to call to all contributors to add features you are working on and would like to see

fyi: deep learning framework mentions on arXiv over the past 3 months

https://twitter.com/fchollet/status/971863128341323776