Re: home page highlights section updates
Thanks Aaron. I like Wireframe2. One addition I can think of is to show in a category Blogs/CaseStudy all new blogs published in Apache MXNet medium handle and other trusted sources. On Fri, Jun 1, 2018, 3:19 PM Thomas DELTEIL wrote: > Nice work, I like wireframe 2 the best, it gives structure to an otherwise > loosely structured list. > > 2018-06-01 14:57 GMT-07:00 Aaron Markham : > > > Hi everyone, happy Friday, > > > > I've mocked up a couple of modifications for the highlights on the home > > page. > > The goal is to expose more news, more tutorials, and other interesting > > things people have been working on. If you've contributed something > > interesting and want to highlight it, you should be able to suggest an > > update to the page. > > It would be great to have variety and fresh content on the site. > > > > Here are a couple of ideas with screenshots that shouldn't be to hard to > > implement: > > https://cwiki.apache.org/confluence/display/MXNET/ > > Website+Interface+Updates > > > > You can reply with feedback here or make comments on the wiki! What are > > your thoughts on: > > 1) getting fresh content on the site > > 2) highlighting contributors and their contributions > > 3) flow on changes and what kind of approvals are expected for swapping > out > > highlights > > 4) UX ideas that are not too challenging to implement or maintain and > work > > well with mobile > > > > Cheers, > > Aaron > > >
Re: Clojure Package
It is always a good thing to consider the cost with the benefit. I'll do my best to explain what I see the tradeoffs to be. First, I wanted to clarify that it took significant development effort to get the Clojure package and the interop working properly despite my simple looking design on the confluence page :) One of the advantages of MXNet over its competitors is its many language support. The Clojure package would only increase the value of this proposition and bring new users and growth into the community. However, there is a cost associated with adding this language support as you pointed out. Since the Clojure package right now is only reliant on the Scala jars from Maven, it can exist outside the main project as an independent repo but I think that would lessen the growth benefit both to the Clojure community and to the MXNet community to not be included as a first class language. I believe having first class Clojure support in MXNet is valuable, but the cost of that support is up to the community to decide. Is there a process for considering a new package in MXNet? - Carin On Fri, Jun 1, 2018 at 5:51 PM, Chen HY wrote: > Have checked the issue and the confluence page, but still curious. > Clojure and Scala are both JVM based languages. > They, as well as many JVM based languages, can share their class and method > at a certain level. > Why should the community maintain two APIs for two languages with can share > their packages with almost zero effort? > > > 2018-06-01 21:58 GMT+01:00 Carin Meier : > > > Hi all, > > > > I've been working on a Clojure package for MXNet. Since Clojure is a JVM > > language, the package leverages the great work of the existing Scala > > package. > > > > I would appreciate any feedback and testing. > > > > Here is the original issue: > > https://github.com/apache/incubator-mxnet/issues/8971 > > > > Architecture & Design: > > https://cwiki.apache.org/confluence/display/MXNET/MXNet+Clojure > > > > and the github repo for rapid testing and issue fixing before of opening > an > > official PR https://github.com/gigasquid/clojure-mxnet > > > > I'm also active in the slack channel so feel free to ping me there. > > > > Thanks, > > Carin Meier > > > > > > -- > Chen Hanyang 陈涵洋 > Software School Fudan University > +86-138-1881-7745 >
Re: Make cmake default
In light of this, maybe it is time to deprecate amalgamation? GIven there is already support for Pi, and we could use TVM to compile to javascript with WebGL Tianqi On Fri, Jun 1, 2018 at 3:24 PM, Rahul Huilgol wrote: > +1 > > Let's move to CMake. It has much better support, and it's not worth > maintaining two build systems. > If we really want we could maintain a make file which manages the > installation of cmake and calls cmake internally! It seems easy to install > cmake. There is a shell script with binary for all Linux x86_64, Windows, > Mac. For other systems as well, it's just a couple of steps. > > Regards, > Rahul > > > > On Fri, 1 Jun 2018 at 15:12 Chen HY wrote: > > > building for rpi doesn't mean you should build on a rpi... that takes > > forever. > > > > 2018-06-01 23:06 GMT+01:00 Anirudh : > > > > > +1 to using cmake and deprecating Makefile. I was able to find a > previous > > > discussion on this: > > > https://github.com/apache/incubator-mxnet/issues/8702 > > > > > > The concerns raised were > > > 1. Building on devices like raspberry pi where cmake is non existent or > > > old. > > > 2. Adding an additional dependency. > > > > > > As mentioned in the thread, if we provide good instructions on how to > > > install cmake/build cmake from source, > > > these concerns will be addressed. > > > > > > Anirudh > > > > > > On Fri, Jun 1, 2018 at 2:58 PM, Alex Zai wrote: > > > > > > > Just realized that the email lists strips aways all hyperlinks. > > Attached > > > > is a > > > > copy of my previous email with links pasted in. > > > > > > > > What are peoples' thought on requiring cmake when building from > source? > > > > Currently we have to maintain two independent build files (CMakeLists > > and > > > > Makefile) which makes it more difficult to develop (each are 600+ > > lines). > > > > Also, > > > > our current build system (in Makefile) requires that 3rdparty > > > dependencies > > > > have > > > > binaries present (or a Makefile to generate binaries) in the repo, > > which > > > > is not > > > > always the case. > > > > Generating a makefile with cmake will make our Makefile very simple > > like > > > > PyTorch'sMakefile (20 lines of code - > > > > https://github.com/pytorch/pytorch/blob/master/Makefile). Also, not > > all > > > > 3rdparty > > > > dependencies have binaries or Makefiles. For 3rdparty/mkldnn we end > up > > > > calling > > > > cmake > > > > (https://github.com/apache/incubator-mxnet/blob/master/ > > > > prepare_mkldnn.sh#L96) > > > > to generate binaries (this does not violate our 'no cmake dependency' > > as > > > > USE_MKLDNN is OFF by default). If we encounter any library in the > > future > > > > that > > > > requires us to generate artifacts with cmake, it would be better to > > make > > > > the > > > > switch now. Lastly, we already require cmake as a dependency > > forwindows' > > > > developers > > > > (https://www.dropbox.com/s/9sfnderg58z4j1l/Screenshot% > > > > 202018-06-01%2013.43.08.png?dl=0) > > > > so this would only affect linux / mac developers who do not have > cmake > > > > already. > > > > I currently have a pendingPR > > > > (https://github.com/apache/incubator-mxnet/pull/8/) that > depends > > on > > > > this > > > > change. The library does not have a Makefile or binaries present. > > Unlike > > > > mkldnn, > > > > we would want this library included by default so I cannot generate > > > > artifacts > > > > with cmake. The alternative would be to strip out only the relevant > > parts > > > > of the > > > > code we need from the library. I did this in a previous version of > myPR > > > > (https://github.com/apache/incubator-mxnet/compare/ > > > > dfdfd1ad15de8bb1b899effb0860a4e834093cfc... > > > a4267eb80488804a7f74ff01f5627c > > > > 47dd46bd78) > > > > but it is incredible messy. > > > > Please let me know your thoughts. > > > > Best, > > > > Alex > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Jun 1, 2018 2:51 PM, Alex Zai aza...@gmail.com wrote: > > > > What are peoples' thought on requiring cmake when building from > source? > > > > Currently we have to maintain two independent build files (CMakeLists > > and > > > > Makefile) which makes it more difficult to develop (each are 600+ > > lines). > > > > Also, > > > > our current build system (in Makefile) requires that 3rdparty > > > dependencies > > > > have > > > > binaries present (or a Makefile to generate binaries) in the repo, > > which > > > > is not > > > > always the case. > > > > Generating a makefile with cmake will make our Makefile very simple > > like > > > > PyTorch's Makefile (20 lines of code). Also, not all 3rdparty > > > dependencies > > > > have > > > > binaries or Makefiles. For 3rdparty/mkldnn we end up calling cmake to > > > > generate > > > > binaries (this does not violate our 'no cmake dependency' as > USE_MKLDNN > > > is > > > > OFF > > > > by default). If we encounter any library in the future that requires > us > > > to > > > > generate
Re: Make cmake default
+1 Let's move to CMake. It has much better support, and it's not worth maintaining two build systems. If we really want we could maintain a make file which manages the installation of cmake and calls cmake internally! It seems easy to install cmake. There is a shell script with binary for all Linux x86_64, Windows, Mac. For other systems as well, it's just a couple of steps. Regards, Rahul On Fri, 1 Jun 2018 at 15:12 Chen HY wrote: > building for rpi doesn't mean you should build on a rpi... that takes > forever. > > 2018-06-01 23:06 GMT+01:00 Anirudh : > > > +1 to using cmake and deprecating Makefile. I was able to find a previous > > discussion on this: > > https://github.com/apache/incubator-mxnet/issues/8702 > > > > The concerns raised were > > 1. Building on devices like raspberry pi where cmake is non existent or > > old. > > 2. Adding an additional dependency. > > > > As mentioned in the thread, if we provide good instructions on how to > > install cmake/build cmake from source, > > these concerns will be addressed. > > > > Anirudh > > > > On Fri, Jun 1, 2018 at 2:58 PM, Alex Zai wrote: > > > > > Just realized that the email lists strips aways all hyperlinks. > Attached > > > is a > > > copy of my previous email with links pasted in. > > > > > > What are peoples' thought on requiring cmake when building from source? > > > Currently we have to maintain two independent build files (CMakeLists > and > > > Makefile) which makes it more difficult to develop (each are 600+ > lines). > > > Also, > > > our current build system (in Makefile) requires that 3rdparty > > dependencies > > > have > > > binaries present (or a Makefile to generate binaries) in the repo, > which > > > is not > > > always the case. > > > Generating a makefile with cmake will make our Makefile very simple > like > > > PyTorch'sMakefile (20 lines of code - > > > https://github.com/pytorch/pytorch/blob/master/Makefile). Also, not > all > > > 3rdparty > > > dependencies have binaries or Makefiles. For 3rdparty/mkldnn we end up > > > calling > > > cmake > > > (https://github.com/apache/incubator-mxnet/blob/master/ > > > prepare_mkldnn.sh#L96) > > > to generate binaries (this does not violate our 'no cmake dependency' > as > > > USE_MKLDNN is OFF by default). If we encounter any library in the > future > > > that > > > requires us to generate artifacts with cmake, it would be better to > make > > > the > > > switch now. Lastly, we already require cmake as a dependency > forwindows' > > > developers > > > (https://www.dropbox.com/s/9sfnderg58z4j1l/Screenshot% > > > 202018-06-01%2013.43.08.png?dl=0) > > > so this would only affect linux / mac developers who do not have cmake > > > already. > > > I currently have a pendingPR > > > (https://github.com/apache/incubator-mxnet/pull/8/) that depends > on > > > this > > > change. The library does not have a Makefile or binaries present. > Unlike > > > mkldnn, > > > we would want this library included by default so I cannot generate > > > artifacts > > > with cmake. The alternative would be to strip out only the relevant > parts > > > of the > > > code we need from the library. I did this in a previous version of myPR > > > (https://github.com/apache/incubator-mxnet/compare/ > > > dfdfd1ad15de8bb1b899effb0860a4e834093cfc... > > a4267eb80488804a7f74ff01f5627c > > > 47dd46bd78) > > > but it is incredible messy. > > > Please let me know your thoughts. > > > Best, > > > Alex > > > > > > > > > > > > > > > > > > On Fri, Jun 1, 2018 2:51 PM, Alex Zai aza...@gmail.com wrote: > > > What are peoples' thought on requiring cmake when building from source? > > > Currently we have to maintain two independent build files (CMakeLists > and > > > Makefile) which makes it more difficult to develop (each are 600+ > lines). > > > Also, > > > our current build system (in Makefile) requires that 3rdparty > > dependencies > > > have > > > binaries present (or a Makefile to generate binaries) in the repo, > which > > > is not > > > always the case. > > > Generating a makefile with cmake will make our Makefile very simple > like > > > PyTorch's Makefile (20 lines of code). Also, not all 3rdparty > > dependencies > > > have > > > binaries or Makefiles. For 3rdparty/mkldnn we end up calling cmake to > > > generate > > > binaries (this does not violate our 'no cmake dependency' as USE_MKLDNN > > is > > > OFF > > > by default). If we encounter any library in the future that requires us > > to > > > generate artifacts with cmake, it would be better to make the switch > now. > > > Lastly, we already require cmake as a dependency for windows' > > > developers so this > > > would only affect linux / mac developers who do not have cmake already. > > > I currently have a pending PR that depends on this change. The library > > > does not > > > have a Makefile or binaries present. Unlike mkldnn, we would want this > > > library > > > included by default so I cannot generate artifacts with cmake. The > > > alternative
Re: home page highlights section updates
Nice work, I like wireframe 2 the best, it gives structure to an otherwise loosely structured list. 2018-06-01 14:57 GMT-07:00 Aaron Markham : > Hi everyone, happy Friday, > > I've mocked up a couple of modifications for the highlights on the home > page. > The goal is to expose more news, more tutorials, and other interesting > things people have been working on. If you've contributed something > interesting and want to highlight it, you should be able to suggest an > update to the page. > It would be great to have variety and fresh content on the site. > > Here are a couple of ideas with screenshots that shouldn't be to hard to > implement: > https://cwiki.apache.org/confluence/display/MXNET/ > Website+Interface+Updates > > You can reply with feedback here or make comments on the wiki! What are > your thoughts on: > 1) getting fresh content on the site > 2) highlighting contributors and their contributions > 3) flow on changes and what kind of approvals are expected for swapping out > highlights > 4) UX ideas that are not too challenging to implement or maintain and work > well with mobile > > Cheers, > Aaron >
Re: Make cmake default
building for rpi doesn't mean you should build on a rpi... that takes forever. 2018-06-01 23:06 GMT+01:00 Anirudh : > +1 to using cmake and deprecating Makefile. I was able to find a previous > discussion on this: > https://github.com/apache/incubator-mxnet/issues/8702 > > The concerns raised were > 1. Building on devices like raspberry pi where cmake is non existent or > old. > 2. Adding an additional dependency. > > As mentioned in the thread, if we provide good instructions on how to > install cmake/build cmake from source, > these concerns will be addressed. > > Anirudh > > On Fri, Jun 1, 2018 at 2:58 PM, Alex Zai wrote: > > > Just realized that the email lists strips aways all hyperlinks. Attached > > is a > > copy of my previous email with links pasted in. > > > > What are peoples' thought on requiring cmake when building from source? > > Currently we have to maintain two independent build files (CMakeLists and > > Makefile) which makes it more difficult to develop (each are 600+ lines). > > Also, > > our current build system (in Makefile) requires that 3rdparty > dependencies > > have > > binaries present (or a Makefile to generate binaries) in the repo, which > > is not > > always the case. > > Generating a makefile with cmake will make our Makefile very simple like > > PyTorch'sMakefile (20 lines of code - > > https://github.com/pytorch/pytorch/blob/master/Makefile). Also, not all > > 3rdparty > > dependencies have binaries or Makefiles. For 3rdparty/mkldnn we end up > > calling > > cmake > > (https://github.com/apache/incubator-mxnet/blob/master/ > > prepare_mkldnn.sh#L96) > > to generate binaries (this does not violate our 'no cmake dependency' as > > USE_MKLDNN is OFF by default). If we encounter any library in the future > > that > > requires us to generate artifacts with cmake, it would be better to make > > the > > switch now. Lastly, we already require cmake as a dependency forwindows' > > developers > > (https://www.dropbox.com/s/9sfnderg58z4j1l/Screenshot% > > 202018-06-01%2013.43.08.png?dl=0) > > so this would only affect linux / mac developers who do not have cmake > > already. > > I currently have a pendingPR > > (https://github.com/apache/incubator-mxnet/pull/8/) that depends on > > this > > change. The library does not have a Makefile or binaries present. Unlike > > mkldnn, > > we would want this library included by default so I cannot generate > > artifacts > > with cmake. The alternative would be to strip out only the relevant parts > > of the > > code we need from the library. I did this in a previous version of myPR > > (https://github.com/apache/incubator-mxnet/compare/ > > dfdfd1ad15de8bb1b899effb0860a4e834093cfc... > a4267eb80488804a7f74ff01f5627c > > 47dd46bd78) > > but it is incredible messy. > > Please let me know your thoughts. > > Best, > > Alex > > > > > > > > > > > > On Fri, Jun 1, 2018 2:51 PM, Alex Zai aza...@gmail.com wrote: > > What are peoples' thought on requiring cmake when building from source? > > Currently we have to maintain two independent build files (CMakeLists and > > Makefile) which makes it more difficult to develop (each are 600+ lines). > > Also, > > our current build system (in Makefile) requires that 3rdparty > dependencies > > have > > binaries present (or a Makefile to generate binaries) in the repo, which > > is not > > always the case. > > Generating a makefile with cmake will make our Makefile very simple like > > PyTorch's Makefile (20 lines of code). Also, not all 3rdparty > dependencies > > have > > binaries or Makefiles. For 3rdparty/mkldnn we end up calling cmake to > > generate > > binaries (this does not violate our 'no cmake dependency' as USE_MKLDNN > is > > OFF > > by default). If we encounter any library in the future that requires us > to > > generate artifacts with cmake, it would be better to make the switch now. > > Lastly, we already require cmake as a dependency for windows' > > developers so this > > would only affect linux / mac developers who do not have cmake already. > > I currently have a pending PR that depends on this change. The library > > does not > > have a Makefile or binaries present. Unlike mkldnn, we would want this > > library > > included by default so I cannot generate artifacts with cmake. The > > alternative > > would be to strip out only the relevant parts of the code we need from > the > > library. I did this in a previous version of my PR but it is incredible > > messy. > > Please let me know your thoughts. > > Best, > > Alex > > > -- Chen Hanyang 陈涵洋 Software School Fudan University +86-138-1881-7745
Re: Make cmake default
+1 Thanks for bringing this up. Maintaining two build systems is a pain. If we decide to make cmake default, please make sure all installation documentations are updated correspondingly. They're currently all using "make" if installed from source. Best, Haibin On Fri, Jun 1, 2018 at 3:06 PM, Anirudh wrote: > +1 to using cmake and deprecating Makefile. I was able to find a previous > discussion on this: > https://github.com/apache/incubator-mxnet/issues/8702 > > The concerns raised were > 1. Building on devices like raspberry pi where cmake is non existent or > old. > 2. Adding an additional dependency. > > As mentioned in the thread, if we provide good instructions on how to > install cmake/build cmake from source, > these concerns will be addressed. > > Anirudh > > On Fri, Jun 1, 2018 at 2:58 PM, Alex Zai wrote: > > > Just realized that the email lists strips aways all hyperlinks. Attached > > is a > > copy of my previous email with links pasted in. > > > > What are peoples' thought on requiring cmake when building from source? > > Currently we have to maintain two independent build files (CMakeLists and > > Makefile) which makes it more difficult to develop (each are 600+ lines). > > Also, > > our current build system (in Makefile) requires that 3rdparty > dependencies > > have > > binaries present (or a Makefile to generate binaries) in the repo, which > > is not > > always the case. > > Generating a makefile with cmake will make our Makefile very simple like > > PyTorch'sMakefile (20 lines of code - > > https://github.com/pytorch/pytorch/blob/master/Makefile). Also, not all > > 3rdparty > > dependencies have binaries or Makefiles. For 3rdparty/mkldnn we end up > > calling > > cmake > > (https://github.com/apache/incubator-mxnet/blob/master/ > > prepare_mkldnn.sh#L96) > > to generate binaries (this does not violate our 'no cmake dependency' as > > USE_MKLDNN is OFF by default). If we encounter any library in the future > > that > > requires us to generate artifacts with cmake, it would be better to make > > the > > switch now. Lastly, we already require cmake as a dependency forwindows' > > developers > > (https://www.dropbox.com/s/9sfnderg58z4j1l/Screenshot% > > 202018-06-01%2013.43.08.png?dl=0) > > so this would only affect linux / mac developers who do not have cmake > > already. > > I currently have a pendingPR > > (https://github.com/apache/incubator-mxnet/pull/8/) that depends on > > this > > change. The library does not have a Makefile or binaries present. Unlike > > mkldnn, > > we would want this library included by default so I cannot generate > > artifacts > > with cmake. The alternative would be to strip out only the relevant parts > > of the > > code we need from the library. I did this in a previous version of myPR > > (https://github.com/apache/incubator-mxnet/compare/ > > dfdfd1ad15de8bb1b899effb0860a4e834093cfc... > a4267eb80488804a7f74ff01f5627c > > 47dd46bd78) > > but it is incredible messy. > > Please let me know your thoughts. > > Best, > > Alex > > > > > > > > > > > > On Fri, Jun 1, 2018 2:51 PM, Alex Zai aza...@gmail.com wrote: > > What are peoples' thought on requiring cmake when building from source? > > Currently we have to maintain two independent build files (CMakeLists and > > Makefile) which makes it more difficult to develop (each are 600+ lines). > > Also, > > our current build system (in Makefile) requires that 3rdparty > dependencies > > have > > binaries present (or a Makefile to generate binaries) in the repo, which > > is not > > always the case. > > Generating a makefile with cmake will make our Makefile very simple like > > PyTorch's Makefile (20 lines of code). Also, not all 3rdparty > dependencies > > have > > binaries or Makefiles. For 3rdparty/mkldnn we end up calling cmake to > > generate > > binaries (this does not violate our 'no cmake dependency' as USE_MKLDNN > is > > OFF > > by default). If we encounter any library in the future that requires us > to > > generate artifacts with cmake, it would be better to make the switch now. > > Lastly, we already require cmake as a dependency for windows' > > developers so this > > would only affect linux / mac developers who do not have cmake already. > > I currently have a pending PR that depends on this change. The library > > does not > > have a Makefile or binaries present. Unlike mkldnn, we would want this > > library > > included by default so I cannot generate artifacts with cmake. The > > alternative > > would be to strip out only the relevant parts of the code we need from > the > > library. I did this in a previous version of my PR but it is incredible > > messy. > > Please let me know your thoughts. > > Best, > > Alex > > >
Re: Make cmake default
+1 to using cmake and deprecating Makefile. I was able to find a previous discussion on this: https://github.com/apache/incubator-mxnet/issues/8702 The concerns raised were 1. Building on devices like raspberry pi where cmake is non existent or old. 2. Adding an additional dependency. As mentioned in the thread, if we provide good instructions on how to install cmake/build cmake from source, these concerns will be addressed. Anirudh On Fri, Jun 1, 2018 at 2:58 PM, Alex Zai wrote: > Just realized that the email lists strips aways all hyperlinks. Attached > is a > copy of my previous email with links pasted in. > > What are peoples' thought on requiring cmake when building from source? > Currently we have to maintain two independent build files (CMakeLists and > Makefile) which makes it more difficult to develop (each are 600+ lines). > Also, > our current build system (in Makefile) requires that 3rdparty dependencies > have > binaries present (or a Makefile to generate binaries) in the repo, which > is not > always the case. > Generating a makefile with cmake will make our Makefile very simple like > PyTorch'sMakefile (20 lines of code - > https://github.com/pytorch/pytorch/blob/master/Makefile). Also, not all > 3rdparty > dependencies have binaries or Makefiles. For 3rdparty/mkldnn we end up > calling > cmake > (https://github.com/apache/incubator-mxnet/blob/master/ > prepare_mkldnn.sh#L96) > to generate binaries (this does not violate our 'no cmake dependency' as > USE_MKLDNN is OFF by default). If we encounter any library in the future > that > requires us to generate artifacts with cmake, it would be better to make > the > switch now. Lastly, we already require cmake as a dependency forwindows' > developers > (https://www.dropbox.com/s/9sfnderg58z4j1l/Screenshot% > 202018-06-01%2013.43.08.png?dl=0) > so this would only affect linux / mac developers who do not have cmake > already. > I currently have a pendingPR > (https://github.com/apache/incubator-mxnet/pull/8/) that depends on > this > change. The library does not have a Makefile or binaries present. Unlike > mkldnn, > we would want this library included by default so I cannot generate > artifacts > with cmake. The alternative would be to strip out only the relevant parts > of the > code we need from the library. I did this in a previous version of myPR > (https://github.com/apache/incubator-mxnet/compare/ > dfdfd1ad15de8bb1b899effb0860a4e834093cfc...a4267eb80488804a7f74ff01f5627c > 47dd46bd78) > but it is incredible messy. > Please let me know your thoughts. > Best, > Alex > > > > > > On Fri, Jun 1, 2018 2:51 PM, Alex Zai aza...@gmail.com wrote: > What are peoples' thought on requiring cmake when building from source? > Currently we have to maintain two independent build files (CMakeLists and > Makefile) which makes it more difficult to develop (each are 600+ lines). > Also, > our current build system (in Makefile) requires that 3rdparty dependencies > have > binaries present (or a Makefile to generate binaries) in the repo, which > is not > always the case. > Generating a makefile with cmake will make our Makefile very simple like > PyTorch's Makefile (20 lines of code). Also, not all 3rdparty dependencies > have > binaries or Makefiles. For 3rdparty/mkldnn we end up calling cmake to > generate > binaries (this does not violate our 'no cmake dependency' as USE_MKLDNN is > OFF > by default). If we encounter any library in the future that requires us to > generate artifacts with cmake, it would be better to make the switch now. > Lastly, we already require cmake as a dependency for windows' > developers so this > would only affect linux / mac developers who do not have cmake already. > I currently have a pending PR that depends on this change. The library > does not > have a Makefile or binaries present. Unlike mkldnn, we would want this > library > included by default so I cannot generate artifacts with cmake. The > alternative > would be to strip out only the relevant parts of the code we need from the > library. I did this in a previous version of my PR but it is incredible > messy. > Please let me know your thoughts. > Best, > Alex >
Re: Make cmake default
Just realized that the email lists strips aways all hyperlinks. Attached is a copy of my previous email with links pasted in. What are peoples' thought on requiring cmake when building from source? Currently we have to maintain two independent build files (CMakeLists and Makefile) which makes it more difficult to develop (each are 600+ lines). Also, our current build system (in Makefile) requires that 3rdparty dependencies have binaries present (or a Makefile to generate binaries) in the repo, which is not always the case. Generating a makefile with cmake will make our Makefile very simple like PyTorch'sMakefile (20 lines of code - https://github.com/pytorch/pytorch/blob/master/Makefile). Also, not all 3rdparty dependencies have binaries or Makefiles. For 3rdparty/mkldnn we end up calling cmake (https://github.com/apache/incubator-mxnet/blob/master/prepare_mkldnn.sh#L96) to generate binaries (this does not violate our 'no cmake dependency' as USE_MKLDNN is OFF by default). If we encounter any library in the future that requires us to generate artifacts with cmake, it would be better to make the switch now. Lastly, we already require cmake as a dependency forwindows' developers (https://www.dropbox.com/s/9sfnderg58z4j1l/Screenshot%202018-06-01%2013.43.08.png?dl=0) so this would only affect linux / mac developers who do not have cmake already. I currently have a pendingPR (https://github.com/apache/incubator-mxnet/pull/8/) that depends on this change. The library does not have a Makefile or binaries present. Unlike mkldnn, we would want this library included by default so I cannot generate artifacts with cmake. The alternative would be to strip out only the relevant parts of the code we need from the library. I did this in a previous version of myPR (https://github.com/apache/incubator-mxnet/compare/dfdfd1ad15de8bb1b899effb0860a4e834093cfc...a4267eb80488804a7f74ff01f5627c47dd46bd78) but it is incredible messy. Please let me know your thoughts. Best, Alex On Fri, Jun 1, 2018 2:51 PM, Alex Zai aza...@gmail.com wrote: What are peoples' thought on requiring cmake when building from source? Currently we have to maintain two independent build files (CMakeLists and Makefile) which makes it more difficult to develop (each are 600+ lines). Also, our current build system (in Makefile) requires that 3rdparty dependencies have binaries present (or a Makefile to generate binaries) in the repo, which is not always the case. Generating a makefile with cmake will make our Makefile very simple like PyTorch's Makefile (20 lines of code). Also, not all 3rdparty dependencies have binaries or Makefiles. For 3rdparty/mkldnn we end up calling cmake to generate binaries (this does not violate our 'no cmake dependency' as USE_MKLDNN is OFF by default). If we encounter any library in the future that requires us to generate artifacts with cmake, it would be better to make the switch now. Lastly, we already require cmake as a dependency for windows' developers so this would only affect linux / mac developers who do not have cmake already. I currently have a pending PR that depends on this change. The library does not have a Makefile or binaries present. Unlike mkldnn, we would want this library included by default so I cannot generate artifacts with cmake. The alternative would be to strip out only the relevant parts of the code we need from the library. I did this in a previous version of my PR but it is incredible messy. Please let me know your thoughts. Best, Alex
home page highlights section updates
Hi everyone, happy Friday, I've mocked up a couple of modifications for the highlights on the home page. The goal is to expose more news, more tutorials, and other interesting things people have been working on. If you've contributed something interesting and want to highlight it, you should be able to suggest an update to the page. It would be great to have variety and fresh content on the site. Here are a couple of ideas with screenshots that shouldn't be to hard to implement: https://cwiki.apache.org/confluence/display/MXNET/Website+Interface+Updates You can reply with feedback here or make comments on the wiki! What are your thoughts on: 1) getting fresh content on the site 2) highlighting contributors and their contributions 3) flow on changes and what kind of approvals are expected for swapping out highlights 4) UX ideas that are not too challenging to implement or maintain and work well with mobile Cheers, Aaron
Make cmake default
What are peoples' thought on requiring cmake when building from source? Currently we have to maintain two independent build files (CMakeLists and Makefile) which makes it more difficult to develop (each are 600+ lines). Also, our current build system (in Makefile) requires that 3rdparty dependencies have binaries present (or a Makefile to generate binaries) in the repo, which is not always the case. Generating a makefile with cmake will make our Makefile very simple like PyTorch's Makefile (20 lines of code). Also, not all 3rdparty dependencies have binaries or Makefiles. For 3rdparty/mkldnn we end up calling cmake to generate binaries (this does not violate our 'no cmake dependency' as USE_MKLDNN is OFF by default). If we encounter any library in the future that requires us to generate artifacts with cmake, it would be better to make the switch now. Lastly, we already require cmake as a dependency for windows' developers so this would only affect linux / mac developers who do not have cmake already. I currently have a pending PR that depends on this change. The library does not have a Makefile or binaries present. Unlike mkldnn, we would want this library included by default so I cannot generate artifacts with cmake. The alternative would be to strip out only the relevant parts of the code we need from the library. I did this in a previous version of my PR but it is incredible messy. Please let me know your thoughts. Best, Alex
Re: Clojure Package
Have checked the issue and the confluence page, but still curious. Clojure and Scala are both JVM based languages. They, as well as many JVM based languages, can share their class and method at a certain level. Why should the community maintain two APIs for two languages with can share their packages with almost zero effort? 2018-06-01 21:58 GMT+01:00 Carin Meier : > Hi all, > > I've been working on a Clojure package for MXNet. Since Clojure is a JVM > language, the package leverages the great work of the existing Scala > package. > > I would appreciate any feedback and testing. > > Here is the original issue: > https://github.com/apache/incubator-mxnet/issues/8971 > > Architecture & Design: > https://cwiki.apache.org/confluence/display/MXNET/MXNet+Clojure > > and the github repo for rapid testing and issue fixing before of opening an > official PR https://github.com/gigasquid/clojure-mxnet > > I'm also active in the slack channel so feel free to ping me there. > > Thanks, > Carin Meier > -- Chen Hanyang 陈涵洋 Software School Fudan University +86-138-1881-7745
Clojure Package
Hi all, I've been working on a Clojure package for MXNet. Since Clojure is a JVM language, the package leverages the great work of the existing Scala package. I would appreciate any feedback and testing. Here is the original issue: https://github.com/apache/incubator-mxnet/issues/8971 Architecture & Design: https://cwiki.apache.org/confluence/display/MXNET/MXNet+Clojure and the github repo for rapid testing and issue fixing before of opening an official PR https://github.com/gigasquid/clojure-mxnet I'm also active in the slack channel so feel free to ping me there. Thanks, Carin Meier
A proposal for unified integration with external acceleration libraries
Hello all, We would like to propose a new mechanism that unifies the integration with most of the external acceleration libraries, including TVM, MKLDNN, TensorRT and more. The main idea is to integrate with the external libraries in the level of subgraphs instead of operators. There are a few reasons in favor of the new integration: * Integration in the level of operators mixes the external library operators, such as MKLDNN, with MXNet operators and makes the implementation of the executor overcomplicated. We now have to deal with a lot of unexpected issues. (the executor needs to carefully deal with data format conversion between different operators; the operators of external libraries are subject to the same memory planning like other MXNet operaotrs, etc). * External libraries need to reconstruct the computation graph for better performance (e.g., operator fusion). Integration in the level of subgraphs allows external libraries to perform arbitrary graph transformation and computation. The proposal below provides both the design and the API for constructing subgraphs and executing subgraphs. https://cwiki.apache.org/confluence/display/MXNET/Unified+integration+with+external+acceleration+libraries Please let me know if you have any comments on this design and API. Thanks, Da
