Re: demise of dmlc.ml domain & new Julia docs hosting
Hi, I will add +1 to the micro-site approach. Since I have tried to take the generated MD outputs from Julia's doc system, but the syntax is incompatible with the MD plugin of Sphinx. Iblis Lin 林峻頤 On 7/4/19 12:12 PM, Aaron Markham wrote: Hi dev@, In case you missed the issues with the dmlc.ml domain, it was let go or sniped and now goes to a malware site. [1] Several assets like models and the Julia documentation were hosted there. I made some progress getting the Julia docs generated as part of the regular website build flow. [2] It'll work as long as you have Julia installed and configured with MXNet. I don't imagine you can use it to build the website natively on your mac or windows box at this point because all of the CI and related instructions appear to be only for Ubuntu. That being said, I added an option to dev_menu.py so you can build the Julia docs with docker on whatever host you're on. I tried to bring in the markdown files and have the website theme applied to them. Many things were then broken - in large part due to some bugs in the website code related to post processing and injection of dom elements. This would require a rewrite of the Julia docs to workaround the existing website bugs. Rather than do this, I just took the Julia site output, which has its own look and feel and nested in Julia's API directory. This is much like how the scala docs and the java docs are - using their own look and feel as a micro-site. I feel that this is the better approach for now. The PR for the Julia docs is here: https://github.com/apache/incubator-mxnet/pull/15454 Ivy and I created several new issues to cover the broken links that will need fixing. Models that need to be recovered or recreated and uploaded to a new location. I have an s3 bucket that I've been using for some public assets like this, but I can't make progress on fixing those links when the models just don't exist. And I don't have the bandwidth to regenerate the model zoo and validate the models. Any thoughts or suggestions are appreciated. Happy 4th of July! [1] https://github.com/apache/incubator-mxnet/issues/15410 [2] https://github.com/apache/incubator-mxnet/pull/15454
Re: First class support for MxNet?
well, I'm not going to talk about technical stuffs. You can find some design concepts on doc or wiki. (https://mxnet.incubator.apache.org/versions/master/architecture/index.html) For me, working on MXNet is a rare chance to verify my ideas of a machine learning framework. During implementing MXNet Julia package, I can explicitly compare the experience of MXNet with Flux's ...and than start to complaining about them. :p I think a way to moving forward is comparison. So that's why I said I want to increase the diversity of DL tools in Julia. I like the spirit of portability in MXNet community. We welcomed all of language packages and open-minded. Although some of languages might be considered not popular in ML/DL, this community still keep polishing them day in day out. Yeah, someone has to try it, compare and gain experience from this process regardless of how the language has been evaluated in ML. The experience is valuable. (e.g. I think lack of function overloading is a disadvantage of Python; the file-based namespace does help for maintainability in Python. After I did some works in Julia, I can clearly point out pros and cons.) From a long-term view... maybe twenty years after, none of the languages we are using now will be popular. But I believe the meta-rules which extracted from experiences are still applied. So.. why not have a Rust lib? maybe Rust's macro can do something crazy, maybe. e.g. Julia package shows a more elegant way to stack a network than Python, thanks to metaprogramming. mlp = @mx.chain mx.Variable(:data) => mx.FullyConnected(name=:fc1, num_hidden=128) => mx.Activation(name=:relu1, act_type=:relu) => mx.FullyConnected(name=:fc2, num_hidden=64) => mx.Activation(name=:relu2, act_type=:relu) => mx.FullyConnected(name=:fc3, num_hidden=10) => mx.SoftmaxOutput(name=:softmax) Wondering where that leaves MxNet... Actually, I don't case about this issue. We know tools and frameworks keep changing. People learn the lesson from making and attempting. It's just the path of the human technology evolution. The point is the ideas/experiences which this community is going to surprise you at. Iblis Lin 林峻頤 On 2/11/19 12:04 PM, Zach Boldyga wrote: Those are compelling points! There's also another more recent follow-up from the Julia team:https://julialang.org/blog/2018/12/ml-language-compiler . It seems that Julia will likely have it's place in ML regardless of how other tools progress; the latest offerings from Julia/Flux are really compelling. Wondering where that leaves MxNet... Zach Boldyga Scalabull | Founder 1 (866) 846-8771 x 101
Re: First class support for MxNet?
(well, I'm a Julia programmer, my opinion might be quite bias. :p) No. I think Python is still dominating at this moment. I agree the Julia blog post about ML and PL (it also mentioned in that Swift artical): https://julialang.org/blog/2017/12/ml (Chinese version) https://julialang.org/blog/2017/12/ml https://julialang.org/blog/2017/12/ml_tw TL;DR from my view: (Quote from the blog) "Any sufficiently complicated machine learning system contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of a programming language." Runtime & Ecosystem Basically, I will say that TensorFlow/MXNet/PyTorch are different standalone programming languages for specific domain -- numerical computation. They use Python as their interfaces to build models. Where do the models get computed? In their own runtime. This runtime shares nothing with CPython's runtime. User puts "+-*/" symbols and placeholders in Python, but nothing is computed by CPython. So...what's the problem about having own runtime? In case of TF/MXNet/PyTorch, they splits and throws away the original ecosystem. For example, MXNet have its own array type 'NDArray'. This type only run on our own runtime (libmxnet). You have to abandon the great works done by scikit-learn from the ecosystem of Scipy project, which people have already devoted tons of efforts to. You need to re-write a porting for NDArray if you want something like Gaussion Process. And this builds a wall between libmxnet and numpy runtime. I feel so sorry about another example: https://mxnet.incubator.apache.org/versions/master/api/python/ndarray/linalg.html This API was added about 1 year ago (or half year ago?). It made me anxious. Tons of numerical systems have more robust and versatile linear algebra functions. But some of MXNet developers have to spend their valuable time on implement linalg stuffs again. About Julia's ecosystem (Alought selling Julia is not the point.) Let's talk about what Julia comminuty have done on integrating ecosystem. There is a package named Flux.jl[1]. It fully untilized Julia's native Array type and runtime. For a CPU run, the code is written in pure Julia, and the performance is quite competitve[2] for the case of all the code written in high-level language. So that I can do some small experiemnts on my FreeBSD desktop without compiling any C/Cpp extension. For GPU run, there is a crazy package CUDANative.jl[3] to let user write kernel code in pure Julia. It leverages LLVM's PTX backend. This package is baked by JuliaGPU[4] comminuty. About AD stuffs, it's supported by another group of poeple from JuliaDiff [5], who is doing reseaches on ODE/PDE. Flux integrates them all and become a part of ecosystem as well. If user want to use some exotic statistic distributions, just plug the another package from JuliaStats[6]. > Any plans to take an approach similar to this for the MxNet library? TBH, I'm selfish. My answer is Julia. I only care about Julia stuffs. I'm trying to make more re-use of interfaces from Julia's stdlib and runtime. It' challange. I hope the MXNet Julia package is more than a binding and connecting with the ecosystem. So... you might ask that why I'm here and work on MXNet? I want to increase the entroy of DL tools in Julia. I think freedom is the symbol in the world of open source, user should always have anothr choice on softwares. I personally dislike the state of TF -- being a huge, closed ecosystem. Many poeple is porting stuffs into TF's system and nothing fed back ( the backprop got truncated :p ). I think Julia can find a balance point between MXNet's and original ecosystem. [1] https://fluxml.ai/ [2] https://github.com/avik-pal/DeepLearningBenchmarks#cpu-used-intelr-xeonr-silver-4114-cpu--220ghz [3] https://github.com/JuliaGPU/CUDAnative.jl [4] https://github.com/JuliaGPU [5] https://github.com/JuliaDiff [6] https://github.com/JuliaStats Iblis Lin 林峻頤 On 2/10/19 4:08 AM, Zach Boldyga wrote: > Any plans to take an approach similar to this for the MxNet library? > > https://github.com/tensorflow/swift/blob/master/docs/WhySwiftForTensorFlow.md > > -Zach >
Re: [Announce] Runtime feature detection
well, in case of MXNet, it's mixed with MD and RST. The docs under dir `docs/` is written in MD. (MD is supported via sphinx plugin.) For the function docstring in Python, it's written in RST. The docstring will be rendered via a sphinx feature -- "autodoc". You can check this as an example: https://github.com/apache/incubator-mxnet/blob/master/docs/api/python/autograd/autograd.md#api-reference Iblis Lin 林峻頤 On 1/23/19 11:16 PM, Pedro Larroy wrote: I'm still refining the feature given some late feedback and that it will be public API. I guess with the help of Aaron we will get some nice documentation in, as it's not showing up in the master python API docs. I thought it would be taken automatically from the Python doc. Is this a correct source for the documentation format that we are using? I know we use sphynx but doesn't look like RST to me: http://www.sphinx-doc.org/en/master/usage/quickstart.html Pedro.
Re: Jira board and Confluence page for Julia
My Confluence wiki account: https://cwiki.apache.org/confluence/users/viewuserprofile.action?username=iblis And Jira account: https://issues.apache.org/jira/secure/ViewProfile.jspa?name=iblis Both of these accounts predate my apache account. (Are there any processes of linking them?) Iblis Lin 林峻頤 On 1/15/19 2:55 AM, Naveen Swamy wrote: Ibis, Confluence needs its own user name/password. Once you have let us know, one of us should be able to grant access. For JIRA, I am not an expert at it, I think it uses Apache Login, i'll find you and add appropriate permissions, I was able to create a board for Scala, the board also needs to be able to share with others that part is tricky, I'll try to find and let you know. -Naveen On Mon, Jan 14, 2019 at 9:18 AM Carin Meier wrote: Iblis, Thanks for taking the lead in doing this. Unfortunately, I can't help you with JIRA - but maybe someone else can. I can help you with the wiki. The Clojure package has done something similar here https://cwiki.apache.org/confluence/display/MXNET/Clojure+Release+Process. Once you are logged on you can go here: https://cwiki.apache.org/confluence/display/MXNET/ and hit "Create Page" on top. It will create a page in the tree structure it is currently in - so you can make "Julia Package" - After that you can create sub pages of the Julia package page. You should also be able to edit any other page as well. You can also "move" a page to another spot as well. Under the "..." on the right side, there is an option. Let me know if you you need any other help, Carin On Sun, Jan 13, 2019 at 9:03 PM iblis wrote: Hi, I want to create some issue for Julia on Jira board. Could we have a category for the Julia package? Also, I want to write down something like release process for Julia, maybe Confluence wiki is the right replace. How to creating a new page on this wiki? -- Iblis Lin 林峻頤
Jira board and Confluence page for Julia
Hi, I want to create some issue for Julia on Jira board. Could we have a category for the Julia package? Also, I want to write down something like release process for Julia, maybe Confluence wiki is the right replace. How to creating a new page on this wiki? -- Iblis Lin 林峻頤
Re: Julia Package Release Process
I put the note. I'm fine with leaving the issue tracker at that. On 1/8/19 1:28 AM, Chiyuan Zhang wrote: I just checked that I have ability to disable the issue tracker on dmlc/MXNet.jl. Iblis: let me know if you would like me to disable the issue (after you transferred active ones to mxnet main repo). Disabling issues makes the whole 'issues' tab disappear. I think we can also adopt clojure repo's approach, instead of closing the issues completely, put a note there to point to the main repo. Best, Chiyuan On Mon, Jan 7, 2019 at 9:13 AM Iblis Lin wrote: Yes, I have them on main repo. But for MXNet.jl, I'm repo collaborator. Anyway, I'm browsing the issues and migrating some of them. On 1/8/19 12:46 AM, Chris Olivier wrote: Do you not have write permissions on mxnet repo? On Mon, Jan 7, 2019 at 6:13 AM iblis wrote: just found that I don't have the permission to transfer issues of dmlc/MXNet.jl. Could anyone help me on this? On 1/7/19 12:16 PM, iblis wrote: okay. Before disabling the issue tracker, I'm going to transfer the issue from MXNet.jl to main repo. (via https://help.github.com/articles/transferring-an-issue-to-another-repository/ ) On 1/7/19 12:17 AM, Chris Olivier wrote: +1 for disabling issue tracker and putting a note on original repo (if it isn’t already there) that work/issue tracking has moved to mxnet (using julia label in github or Jira). m On Sun, Jan 6, 2019 at 1:19 AM iblis wrote: Before PR #10149 got merged (Oct 5, 2018) into main repo, julia code is developed and maintained in the separate repo -- dmlc/MXNet.jl. After that PR, there are no further development happened in dmlc/MXNet.jl. We work with the main repo now. But the original MXNet.jl repo is still there, it just isn't deleted or archived yet. I receive some issue ticks from this repo occasionally, maybe we should just disable the issue tracker of it. Does it work with other frameworks other than mxnet? hmm, I'm not sure what you mean. On 1/6/19 1:18 PM, Chris Olivier wrote: Curious: Why is the julia code maintained in a separate repo? I was under the impression that it was donated/permanently merged into the mxnet source tree. Does it work with other frameworks other than mxnet? On Sat, Jan 5, 2019 at 8:32 PM Iblis Lin wrote: If there is trademark issue, how about this option: 3) transferring the MXNet.jl repo ownership from DMLC to Apache. On 1/6/19 6:45 AM, Justin Mclean wrote: Hi, 1) Reuse the old repo: https://github.com/dmlc/MXNet.jl It's under DMLC. I have the committer bit of this repo. I'm not 100% sure that would be allowed from a branding/trademark perspective, any distribution owned by a 3rd party can't be called "Apache MXNet". 2) A new repo under ASF's organization? That seems preferable I think. Thanks, Justin -- Iblis Lin 林峻頤 -- Iblis Lin 林峻頤 -- Iblis Lin 林峻頤 -- Iblis Lin 林峻頤 -- Iblis Lin 林峻頤
Re: Julia Package Release Process
Yes, I have them on main repo. But for MXNet.jl, I'm repo collaborator. Anyway, I'm browsing the issues and migrating some of them. On 1/8/19 12:46 AM, Chris Olivier wrote: Do you not have write permissions on mxnet repo? On Mon, Jan 7, 2019 at 6:13 AM iblis wrote: just found that I don't have the permission to transfer issues of dmlc/MXNet.jl. Could anyone help me on this? On 1/7/19 12:16 PM, iblis wrote: okay. Before disabling the issue tracker, I'm going to transfer the issue from MXNet.jl to main repo. (via https://help.github.com/articles/transferring-an-issue-to-another-repository/ ) On 1/7/19 12:17 AM, Chris Olivier wrote: +1 for disabling issue tracker and putting a note on original repo (if it isn’t already there) that work/issue tracking has moved to mxnet (using julia label in github or Jira). m On Sun, Jan 6, 2019 at 1:19 AM iblis wrote: Before PR #10149 got merged (Oct 5, 2018) into main repo, julia code is developed and maintained in the separate repo -- dmlc/MXNet.jl. After that PR, there are no further development happened in dmlc/MXNet.jl. We work with the main repo now. But the original MXNet.jl repo is still there, it just isn't deleted or archived yet. I receive some issue ticks from this repo occasionally, maybe we should just disable the issue tracker of it. Does it work with other frameworks other than mxnet? hmm, I'm not sure what you mean. On 1/6/19 1:18 PM, Chris Olivier wrote: Curious: Why is the julia code maintained in a separate repo? I was under the impression that it was donated/permanently merged into the mxnet source tree. Does it work with other frameworks other than mxnet? On Sat, Jan 5, 2019 at 8:32 PM Iblis Lin wrote: If there is trademark issue, how about this option: 3) transferring the MXNet.jl repo ownership from DMLC to Apache. On 1/6/19 6:45 AM, Justin Mclean wrote: Hi, 1) Reuse the old repo: https://github.com/dmlc/MXNet.jl It's under DMLC. I have the committer bit of this repo. I'm not 100% sure that would be allowed from a branding/trademark perspective, any distribution owned by a 3rd party can't be called "Apache MXNet". 2) A new repo under ASF's organization? That seems preferable I think. Thanks, Justin -- Iblis Lin 林峻頤 -- Iblis Lin 林峻頤 -- Iblis Lin 林峻頤 -- Iblis Lin 林峻頤
Re: Julia Package Release Process
just found that I don't have the permission to transfer issues of dmlc/MXNet.jl. Could anyone help me on this? On 1/7/19 12:16 PM, iblis wrote: okay. Before disabling the issue tracker, I'm going to transfer the issue from MXNet.jl to main repo. (via https://help.github.com/articles/transferring-an-issue-to-another-repository/) On 1/7/19 12:17 AM, Chris Olivier wrote: +1 for disabling issue tracker and putting a note on original repo (if it isn’t already there) that work/issue tracking has moved to mxnet (using julia label in github or Jira). m On Sun, Jan 6, 2019 at 1:19 AM iblis wrote: Before PR #10149 got merged (Oct 5, 2018) into main repo, julia code is developed and maintained in the separate repo -- dmlc/MXNet.jl. After that PR, there are no further development happened in dmlc/MXNet.jl. We work with the main repo now. But the original MXNet.jl repo is still there, it just isn't deleted or archived yet. I receive some issue ticks from this repo occasionally, maybe we should just disable the issue tracker of it. Does it work with other frameworks other than mxnet? hmm, I'm not sure what you mean. On 1/6/19 1:18 PM, Chris Olivier wrote: Curious: Why is the julia code maintained in a separate repo? I was under the impression that it was donated/permanently merged into the mxnet source tree. Does it work with other frameworks other than mxnet? On Sat, Jan 5, 2019 at 8:32 PM Iblis Lin wrote: If there is trademark issue, how about this option: 3) transferring the MXNet.jl repo ownership from DMLC to Apache. On 1/6/19 6:45 AM, Justin Mclean wrote: Hi, 1) Reuse the old repo: https://github.com/dmlc/MXNet.jl It's under DMLC. I have the committer bit of this repo. I'm not 100% sure that would be allowed from a branding/trademark perspective, any distribution owned by a 3rd party can't be called "Apache MXNet". 2) A new repo under ASF's organization? That seems preferable I think. Thanks, Justin -- Iblis Lin 林峻頤 -- Iblis Lin 林峻頤 -- Iblis Lin 林峻頤
Re: Julia Package Release Process
okay. Before disabling the issue tracker, I'm going to transfer the issue from MXNet.jl to main repo. (via https://help.github.com/articles/transferring-an-issue-to-another-repository/) On 1/7/19 12:17 AM, Chris Olivier wrote: +1 for disabling issue tracker and putting a note on original repo (if it isn’t already there) that work/issue tracking has moved to mxnet (using julia label in github or Jira). m On Sun, Jan 6, 2019 at 1:19 AM iblis wrote: Before PR #10149 got merged (Oct 5, 2018) into main repo, julia code is developed and maintained in the separate repo -- dmlc/MXNet.jl. After that PR, there are no further development happened in dmlc/MXNet.jl. We work with the main repo now. But the original MXNet.jl repo is still there, it just isn't deleted or archived yet. I receive some issue ticks from this repo occasionally, maybe we should just disable the issue tracker of it. Does it work with other frameworks other than mxnet? hmm, I'm not sure what you mean. On 1/6/19 1:18 PM, Chris Olivier wrote: Curious: Why is the julia code maintained in a separate repo? I was under the impression that it was donated/permanently merged into the mxnet source tree. Does it work with other frameworks other than mxnet? On Sat, Jan 5, 2019 at 8:32 PM Iblis Lin wrote: If there is trademark issue, how about this option: 3) transferring the MXNet.jl repo ownership from DMLC to Apache. On 1/6/19 6:45 AM, Justin Mclean wrote: Hi, 1) Reuse the old repo: https://github.com/dmlc/MXNet.jl It's under DMLC. I have the committer bit of this repo. I'm not 100% sure that would be allowed from a branding/trademark perspective, any distribution owned by a 3rd party can't be called "Apache MXNet". 2) A new repo under ASF's organization? That seems preferable I think. Thanks, Justin -- Iblis Lin 林峻頤 -- Iblis Lin 林峻頤 -- Iblis Lin 林峻頤
Re: Julia Package Release Process
Before PR #10149 got merged (Oct 5, 2018) into main repo, julia code is developed and maintained in the separate repo -- dmlc/MXNet.jl. After that PR, there are no further development happened in dmlc/MXNet.jl. We work with the main repo now. But the original MXNet.jl repo is still there, it just isn't deleted or archived yet. I receive some issue ticks from this repo occasionally, maybe we should just disable the issue tracker of it. Does it work with other frameworks other than mxnet? hmm, I'm not sure what you mean. On 1/6/19 1:18 PM, Chris Olivier wrote: Curious: Why is the julia code maintained in a separate repo? I was under the impression that it was donated/permanently merged into the mxnet source tree. Does it work with other frameworks other than mxnet? On Sat, Jan 5, 2019 at 8:32 PM Iblis Lin wrote: If there is trademark issue, how about this option: 3) transferring the MXNet.jl repo ownership from DMLC to Apache. On 1/6/19 6:45 AM, Justin Mclean wrote: Hi, 1) Reuse the old repo: https://github.com/dmlc/MXNet.jl It's under DMLC. I have the committer bit of this repo. I'm not 100% sure that would be allowed from a branding/trademark perspective, any distribution owned by a 3rd party can't be called "Apache MXNet". 2) A new repo under ASF's organization? That seems preferable I think. Thanks, Justin -- Iblis Lin 林峻頤 -- Iblis Lin 林峻頤
Re: Julia Package Release Process
If there is trademark issue, how about this option: 3) transferring the MXNet.jl repo ownership from DMLC to Apache. On 1/6/19 6:45 AM, Justin Mclean wrote: Hi, 1) Reuse the old repo: https://github.com/dmlc/MXNet.jl It's under DMLC. I have the committer bit of this repo. I'm not 100% sure that would be allowed from a branding/trademark perspective, any distribution owned by a 3rd party can't be called "Apache MXNet". 2) A new repo under ASF's organization? That seems preferable I think. Thanks, Justin -- Iblis Lin 林峻頤
Re: Julia Package Release Process
On 1/6/19 5:48 AM, Carin Meier wrote: Do you know of any other Julia Apache projects? Maybe we could look and see how they are doing it. well, seems no. -- Iblis Lin
Julia Package Release Process
Hello MXNet community, After the Julia package has been imported into the main repo, the next unresolved issue is establishing the releasing process for Julia. The PR #12845, which is for upgrading Julia package to work with Julia v0.7+, is ready for review at this moment. I want to release the Julia part along with the next mxnet major release (v1.5, I think). We imported the Julia package to make it part of the CI validation chain. And merging code into main repo makes Julia release process different from normal. At first, let me describe a usual release process for a Julia package. I will try to explain it with corresponding ideas in Python. 1.Package manager in Julia: There are a module from stdlib named `Pkg` served as the package manager in Julia, like Python's `pip`. 2. The package registry and package source: The package manager will download the desired packages from a default registry. In Python, pip will conduct two actions before installing packags: (1) Search the metadata (like pkg name, version, ...etc) from the CheeseShop (a.k.a PyPI) for users. (2) Fetch them from the CheeseShop if matched. In Julia, there is a default registry to hold the packages metadata, hosted on GitHub: https://github.com/JuliaLang/METADATA.jl And where to fetch the package? The aren't a center for download packages. It's unlike Python's idea, we don't upload package to a center server in case of Julia. The package manager will fetch stuffs from the URL listed in the metadata. It should be a valid git URL for git-clone. e.g. For the package `Distributions`: https://github.com/JuliaLang/METADATA.jl/blob/metadata-v2/Distributions/url Most of the packages use GitHub for hosting code. 3. A valid package directory structure In the process of package installation, Python's pip will run `./setup.py` from unpacked package dir. This is kind of protocol between package developer and package manager. In Julia, the package manager run `./deps/build.jl` from the git-cloned dir. Here comes an issue of mxnet's main repo. The Julia package is collected under the subdir `./julia/`, so the setup script in our case is `./julia/deps/build.jl`. This breaks the protocol. Also, in runtime, there is another protocol for phase of module loading. The entry point of a module must be `./src/PackageName.jl`. In our repo, it's `./julia/src/MXNet.jl`. So, the directory structure of mxnet main repo is invalid for Julia package manager. Putting the url of main repo as package metadata will not work. The proposed solution: To provide a valid dir structure, it need a standalone git repo. We can just treat this standalone repo as the place to "upload" package code, just like uploading Python package to PyPI in every release. I want to discuss about the home of this standalone repo. 1) Reuse the old repo: https://github.com/dmlc/MXNet.jl It's under DMLC. I have the committer bit of this repo. 2) A new repo under ASF's organization? 3) Anything else? I will vote for option (1). The actual process in detail: 1) Split the julia dir out via git-subtree ``` cd /path/to/mxnet/ git subtree split -P julia -b MXNet_jl ``` 2) Push the branch `MXNet_jl` to the standalone git repo mentioned in previous section. 3) Push a new tag for MXNet.jl. The version number is same as the mxnet main repo. 4) Make a release page via GitHub release button. 5) Then, updating metadata to Julia package registry will be automated by the bot. https://github.com/attobot/attobot 6) Relax! -- Iblis Lin
RFC: Proposal for merging Julia binding (MXNet.jl) into main repo
Hi, Original discussion is here: https://github.com/apache/incubator-mxnet/pull/8727#issuecomment-368495179 The state quo: Julia binding is hosted in a separated repo `dmlc/MXNet.jl`[1], Julia binding has its own documentation hosting[2] and release cycle[3]. The problem: We ran into libmxnet internal changes breaking our testing again and again [4-7]. Julia binding isn't in the libmxnet CI validation chain. @marcoabreu proposes that merging the Julia binding source code and development into the main repo `apache/incubator-mxnet`; add Julia test cases into the CI chain. Additionally, make the `dmlc/MXNet.jl` as a mirror repo, in order to fit with Julia's package manger [10]. About the reason of hosting Julia code in another repo at the moment, Please see [8]. There are still several issues need to be discussed for this goal [11]: -How to |`git tag`| a new release? Julia binding can have different version and release cycle. - @vchuravy proposes that doing a |`git subtree|` import of MXNet.jl into `|incubator-mxnet/julia`| [9]. - Document hosting: I have no idea about any detail of Sphinx at all. Julia's doc system is |Documenter.jl|, which launches Julia compiler, collects docstring from package and render the static html as output. If Sphinx can accept some extra html files from external source, I guess most of work is done. - Committer bit: There are 3 developers own the committer bit of MXNet.jl. @pluskid, @vchuravy and me. Will this be able to migrate as well? - Quote @marcoabreu's words from [12]: > I have to check back, but since you three are putting a lot of time and > effort into supporting MXNet, I don't see many issues there. > I'm unfamiliar with the Apache process if two projects get merged, > but I'm sure we will find a solution. Please comment. -- [1] https://github.com/dmlc/MXNet.jl [2] http://dmlc.ml/MXNet.jl/latest/ [3] https://github.com/dmlc/MXNet.jl/releases [4] https://github.com/apache/incubator-mxnet/pull/9677#issuecomment-368241751 [5] https://github.com/apache/incubator-mxnet/pull/7741#discussion_r137577886 [6] https://github.com/dmlc/MXNet.jl/pull/288 [7] https://github.com/dmlc/MXNet.jl/pull/301 [8] https://github.com/apache/incubator-mxnet/pull/9677#issuecomment-368280425 [9] https://github.com/apache/incubator-mxnet/pull/8727#issuecomment-369024814 [10] https://github.com/apache/incubator-mxnet/pull/8727#issuecomment-368586177 [11] https://github.com/apache/incubator-mxnet/pull/8727#issuecomment-368709434 [12] https://github.com/apache/incubator-mxnet/pull/8727#issuecomment-369042310 -- Iblis Lin 林峻頤 GitHub: https://github.com/iblis17 signature.asc Description: OpenPGP digital signature
slack channel
Hi, May I join the slack channel? -- Iblis Lin 林峻頤
