I'm fine to disable tvm op (or mark it as experimental) for now, if it does
need another 4 - 6 weeks to fully address the underlying problem, as we have
some more urgent tasks on numpy side.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or vie
@ptrendx Thanks now I got what you mean. I'm open to what you proposed. while
I think one of the major problems with the device api is the maintenance of the
random generator (and it's states).
--
You are receiving this because you are on a team that was mentioned.
Reply to this email directl
@ptrendx If I understand correctly, "static assignment" is what current mxnet
is doing, which is "ndarray on GPU" in @xidulu 's table.
--
You are receiving this because you are on a team that was mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mx
cc @apache/mxnet-committers I think we can gradually refactor current
implementation (ndarray api) by adopting this new approach.
@xidulu could you please fix the url links in your post.
--
You are receiving this because you are on a team that was mentioned.
Reply to this email directly or view
Kindly remind people take a look at the posted RFC:
https://github.com/apache/incubator-mxnet/issues/15465 and free free
to leave your questions and suggestions
--
Yizhi Liu
Bay Area, the United States
e great for the Clojure MXNet users as well.
>
> On Mon, Oct 29, 2018 at 1:39 PM YiZhi Liu wrote:
>
> > Hi,
> >
> >
> >
> > I am happy to announce that the availability of the experimental
> > nightly-build Scala package on Maven in Nexus. The nightly-b
Hi,
I am happy to announce that the availability of the experimental
nightly-build Scala package on Maven in Nexus. The nightly-builds,
currently published as 1.3.1-SNAPSHOT version, include the latest changes
from the master branch from apache/incubator-mxnet GitHub repo and refresh
every day.
e
> > > > > reviewers for example, by adding a list of names in the contributor
> > > list.
> > > > > In general, I find it is really helpful to have more code reviews.
> > > > > Recognizing good reviewers early enables us to find committer
>
7:43 PM Naveen Swamy wrote:
> Ah! we agree on something :) lets get more opinions, I am happy to go with
> it.
>
> On Sat, Sep 29, 2018 at 10:40 PM YiZhi Liu wrote:
>
> > Also sometimes people may not be at the same page when talking about
> option
> > #2. What I ins
Also sometimes people may not be at the same page when talking about option
#2. What I insist is the builder classes for each operator. Otherwise I
actually more support Naveen’s approach - not to totally separate java and
scala objects.
On Sat, Sep 29, 2018 at 7:35 PM YiZhi Liu wrote:
> No
e
> already listed my reasons, I will stop here and see what others say given
> my reasoning.
>
> -1 to #2)
>
> Also, by lecture I meant to say "I don't want to list all the problems
> with unnecessary complications and talk about how to design software"
>
> On
And if we find incorrect declaration, we fix it, not simply assuming
many of them also has problem and we cannot rely on them - otherwise
the type-safe APIs in Scala also does not make sense.
On Sat, Sep 29, 2018 at 7:10 PM YiZhi Liu wrote:
>
> It also makes sense to me if we have it
m1 : Option[Int] = None, dim2 :
> Option[Int] = None, out : Option[NDArray] = None) : NDArrayFuncReturn"
> Why is dim1 and dim2 Optional, this is an error in the declaration on the
> backend, I think there might be many of these?
>
> My answers to your other responses are below in
>
> https://travis-ci.org/apache/incubator-mxnet/builds/433172088?utm_source=github_status&utm_medium=notification
> >
> >
> https://travis-ci.org/apache/incubator-mxnet/builds/434404305?utm_source=github_status&utm_medium=notification
> >
> >
> > Thanks,
while other PRs are all good.
On Sat, Sep 29, 2018 at 2:13 PM YiZhi Liu wrote:
>
> Honestly I don't know yet. I can help to investigate. Just given the
> evidence that, travis timeout every time it gets re-triggered - 2
> times at least. Correct me if I'm wrong @ Zhennan
>
ee what aspects would cause extra runtime
> YiZhi, could you point them out?
>
> On Sat, Sep 29, 2018 at 8:46 PM YiZhi Liu wrote:
>
> > Kellen, I think this PR introduces extra runtime in CI, thus causes
> > the timeout. Which means, once merged, every PR later will see sa
each and every API?
>
> I disagree with your opinion that they are not important and would like to
> hear from others.
>
> I am curious to see how the #2 looks like compared to #1
> Andrew/Qing, can you paste the generated Apis that you have for both Scala
> and Java in a gist
d above, I think such user-experience benefits are even
greater than what we got from type-safe.
On Sat, Sep 29, 2018 at 11:41 AM YiZhi Liu wrote:
>
> Naveen, software designing is all about tradeoff, every feature we
> introduce causes more compiling time, more efforts to maintain
bator-mxnet/builds/434404305?utm_sour
> > ce=github_status&utm_medium=notification
> >
> > According to the time stamp from Travis, all passed PR are within
> > small code change, and can complete `make -j2` within 25s. But for
> > timeout case, 'make -j2'
t
> > > up in case it's helpful.
> > >
> > > - Carin
> > >
> > > On Fri, Sep 28, 2018 at 7:05 AM Davydenko, Denis > >
> > > wrote:
> > >
> > >> +1 on option #2. Having clear Java interface for NDArray, from my
> > &g
n - The biggest issue here is that we'll be
> > doubling
> > the number of macros that we've got to maintain. It'll become even more
> > overhead once we start expanding the Java API with more classes that
> > use
> > generated code like this. The advantages are that the existing Scala
> > NDArray Infer API would remain unchanged for Scala users and that the
> > new
> > macro could be optimized to give the best possible experience to the
> > Java
> > API.
> >
> > Thanks,
> > Andrew
> >
> >
> >
--
Yizhi Liu
DMLC member
Amazon Web Services
Vancouver, Canada
Timur Shenkao wrote:
> > >
> > > > +1 if my vote can be taken into account
> > > >
> > > > On Mon, Jul 16, 2018 at 4:32 AM, Sheng Zha wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I'm starting a vote on subscribing dev@ to Github activities. See
> > > > previous
> > > > > discussion thread here
> > > > > <https://lists.apache.org/thread.html/3d883f6a3cbc8e81e810962e0c0fe7
> > > > > bfd01f0b78d3cb44034f566442@%3Cdev.mxnet.apache.org%3E>
> > > > > .
> > > > >
> > > > > The vote lasts for three days and ends on 7/18/2018 at 9pm pst.
> > > > >
> > > > > -sz
> > > > >
> > > >
> > >
> >
--
Yizhi Liu
DMLC member
Amazon Web Services
Vancouver, Canada
g API
> > * Examples are fixed with full documentation to help to run them
> >
> > Cons:
> >
> > * Examples contains the memory leak issues may cause problems
> >
> > Please kindly share your ideas in this thread and I am really appreciate
> > for your help.
> >
> > Thanks,
> > Qing
> >
--
Yizhi Liu
DMLC member
Amazon Web Services
Vancouver, Canada
> > > > peers from the Clojure community to help with the review.
> > > >
> > > > If there is a committer who would like to do a complete review, I'll be
> > > > happy to step back and let you do it otherwise this PR is going in by
> > the
> > > > end of week to make it ready for 1.3.
> > > >
> > > > https://github.com/apache/incubator-mxnet/pull/11205
> > > >
> > > > Let me know
> > > >
> > > > Thanks, Naveen
> > > >
> > >
> >
--
Yizhi Liu
DMLC member
Amazon Web Services
Vancouver, Canada
:
> > > > > > https://github.com/apache/incubator-mxnet/pull/11239
> > > > > > A file named FILEHASH will be added to the Scala that
> > created
> > > the MD5
> > > > > > string of the generated API document. It will check the
> > > signature of
> > > > all
> > > > > > the operators during Scala CI testing. The reason I am
> > doing
> > > this is to
> > > > > > make sure Scala developers will always be reminded if
> > there is an
> > > > > operator
> > > > > > name/argument changes happened in different PRs. More
> > detailed
> > > info
> > > > > > explained in here:
> > > > > >
> > > > > > https://cwiki.apache.org/confluence/display/MXNET/
> > > > > MXNet+Scala+API+Usability+Improvement
> > > > > >
> > > > > > Pros:
> > > > > > This method will always help us keep backwards
> > compatibility of
> > > > operators
> > > > > > for Scala
> > > > > > Cons:
> > > > > > Require update on the FILEHASH with new contents when
> > there is an
> > > > > operator
> > > > > > change. Developers who changed the operator should `make
> > > scalapkg` to
> > > > > > update that file.
> > > > > >
> > > > > > Please leave any thoughts you may have for this design and
> > feel
> > > free to
> > > > > > review the code.
> > > > > >
> > > > > > Thanks,
> > > > > > Qing
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> >
> >
> >
--
Yizhi Liu
DMLC member
Amazon Web Services
Vancouver, Canada
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,
> > > > >>>>>>>
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>
> > > > >>>
> > > > >>
> > > >
> > > >
> > >
> >
--
Yizhi Liu
DMLC member
Amazon Web Services
Vancouver, Canada
>
> > > > > > > > Hello Anirudh,
> > > > > > > >
> > > > > > > > Could you merge the bugs below? Each of the bug fixes
> > below
> > > > come
> > > > > > with a
> > > > > > > > set of tests and many of them are critical for Gluon.
> > > > > > > > MKLDNN:
> > > > > > > > https://github.com/apache/incubator-mxnet/pull/10979
> > > > > > > > https://github.com/apache/incubator-mxnet/pull/10731
> > > > > > > > https://github.com/apache/incubator-mxnet/pull/10706
> > > > > > > > https://github.com/apache/incubator-mxnet/pull/10651
> > > > > > > > https://github.com/apache/incubator-mxnet/pull/10624
> > > > > > > > https://github.com/apache/incubator-mxnet/pull/10619
> > > > > > > > https://github.com/apache/incubator-mxnet/pull/10616
> > > > > > > >
> > > > > > > > Others:
> > > > > > > > https://github.com/apache/incubator-mxnet/pull/10918
> > > > > > > >
> > > > > > > > @Ashok @Tao @Patric @Alex, do you have other important
> > MKLDNN
> > > > bug
> > > > > > fixes
> > > > > > > > that should be merged?
> > > > > > > >
> > > > > > > > Best,
> > > > > > > > Da
> > > > > > > >
> > > > > > > > On 6/6/18, 5:23 PM, "Anirudh" > > > > > > > > anirudh2...@gmail.com>> wrote:
> > > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > I wanted to bring up some MKLDNN fixes that went
> > into
> > > > master
> > > > > > but not
> > > > > > > > into
> > > > > > > > 1.2.
> > > > > > > > Should these changes be going to the patch release
> > ? We
> > > had
> > > > > > kept some
> > > > > > > > changes from going into 1.2 branch since we were
> > waiting
> > > > for
> > > > > > the test
> > > > > > > > suite
> > > > > > > > for MKLDNN.
> > > > > > > > Is this test suite planned for the next major or
> > minor
> > > > > > release? Also,
> > > > > > > > are
> > > > > > > > there any critical MKLDNN bug fixes which are in
> > master
> > > and
> > > > > > well
> > > > > > > > tested and
> > > > > > > > can go into the patch release ?
> > > > > > > >
> > > > > > > > Anirudh
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, Jun 6, 2018 at 1:48 PM, Anirudh <
> > > > > anirudh2...@gmail.com
> > > > > > > > > > > > > > anirudh2...@gmail.com>> wrote:
> > > > > > > >
> > > > > > > > > Hi all,
> > > > > > > > >
> > > > > > > > > As you may be aware, 1.2 has an undocumented
> > backwards
> > > > > > incompatible
> > > > > > > > change
> > > > > > > > > relating to saving and loading params. Please
> > see:
> > > > > > > > https://github.com/
> > > > > > > > > apache/incubator-mxnet/issues/11091.
> > > > > > > > >
> > > > > > > > > More details about the fix will be tracked here:
> > > > > > > > https://issues.apache.
> > > > > > > > > org/jira/browse/MXNET-518
> > > > > > > > >
> > > > > > > > > The above fix will go as part of the 1.2.1 patch
> > > release
> > > > > > which will
> > > > > > > > be
> > > > > > > > > coming out soon.
> > > > > > > > >
> > > > > > > > > In addition to this, we will also be including:
> > > > > > > https://github.com/
> > > > > > > > > apache/incubator-mxnet/pull/11142
> > > > > > > > >
> > > > > > > > > I request the community to point out other bug
> > fixes
> > > that
> > > > > are
> > > > > > > > critical and
> > > > > > > > > should go as part of 1.2.1 patch release.
> > > > > > > > >
> > > > > > > > > Anirudh
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> >
> >
--
Yizhi Liu
DMLC member
Amazon Web Services
Vancouver, Canada
xisting committer and we will help you go through the invitation
> > > process."
> > >
> > > Yes you're absolutely right. Contributors wouldn't ask for this,
> > > instead, they will be nominated. In some cases like this [1] we're
> > > better than Weex :)
> > >
> > > [1] https://cwiki.apache.org/confluence/display/MXNET/
> > Becoming+a+Committer
> > >
> >
--
Yizhi Liu
DMLC member
Amazon Web Services
Vancouver, Canada
t;> > > carinme...@gmail.com>
>>>> > > > > > >> wrote:
>>>> > > > > > >>>
>>>> > > > > > >>>> 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 <
>>>> > chenhy12...@gmail.com
>>>> > > >
>>>> > > > > > 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 <
>>>> carinme...@gmail.com
>>>> > >:
>>>> > > > > > >>>>>
>>>> > > > > > >>>>>> 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
>>>> > > > > > >>>>>
>>>> > > > > > >>>>
>>>> > > > > > >>>
>>>> > > > > > >>
>>>> > > > > > >
>>>> > > > > > >
>>>> > > > > > >
>>>> > > > > > > --
>>>> > > > > > > Sandeep Krishnamurthy
>>>> > > > > >
>>>> > > > >
>>>> > > >
>>>> > >
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> Chen Hanyang 陈涵洋
>>>> Software School Fudan University
>>>> +86-138-1881-7745
>>>>
>>>
>>>
>>
--
Yizhi Liu
DMLC member
Amazon Web Services
Vancouver, Canada
t+Scala+API+Usability+Improvement>
> and leave any thoughts you may have. This wiki includes examples, targets
> and scenarios we have so far.
>
> Thanks,
> Qing
--
Yizhi Liu
DMLC member
Amazon Web Services
Vancouver, Canada
e important aspect of user experience. I think we should take a
>> step back and look at this from the perspective of a user, not from that of
>> a developer who works closely with MXNet.
>>
>> Regards,
>> Rahul
>>
>> On Mon, Mar 12, 2018 at 3:12 PM
mespace
>> changes) possible OR major version increase
>> 2. Vote succeeded: Refactoring of user-facing APIs possible and only users
>> of the changed APIs are affected while major version does not increase for
>> other APIs.
>> 3. Remove SemVer: We could introduce brea
gt; > > > A +1 vote is in *favor of* using a different versioning for all
>> > > > > > non-C-API's, with each API (Scala, R, Julia, C++, etc.) having
>> its
>> > > own
>> > > > > > version.
>> > > > > >
>> > > > > > A -1 vote is *against* using a different versioning for all
>> > > > non-C-API's,
>> > > > > > with all API's (Scala, R, Julia, C++, etc.) sharing the mxnet
>> > > version.
>> > > > > >
>> > > > > > This vote will conclude on Monday, March 19, 2018.
>> > > > > >
>> > > > > > Thanks,
>> > > > > > -Chris
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
--
Yizhi Liu
DMLC member
Amazon Web Services
Vancouver, Canada
uot;By doing major version change to Scala API, we remind users 'hey, be
> > > careful, we have something incompatible!' But then what?"
> > > They either choose to update their package and then fix potential
> > breaking
> > > API changes (the likely case
choose to update their package and then fix potential
> breaking
> > API changes (the likely case), or they stick with the current version.
> >
> > "Users get more confused with the version mapping. And it introduces
> > overhead to maintain."
> > I'
> 1.2
> > >> >> 2.1 -> 1.3
> > >> >> 3.0 -> 2.0
> > >>
> > >> > R-Package -> MXNet-Version
> > >> >> 1.0 -> 1.0
> > >> >> 2.0 -> 1.1
> > >> >> 2.1 -> 1.2
> &g
conventions we decide to
> use.
>
> -Kellen
>
> From: Carin Meier
> Sent: Saturday, March 10, 2018 1:41 PM
> To: dev@mxnet.incubator.apache.org
> Cc: d...@mxnet.apache.org
> Subject: Re: Publishing Scala Package/namespace change
>
> +1 as well. I'm actively deve
publish to Maven in the
> upcoming release. I understand that this probably breaks the Semver
> semantics that is agreed upon, However I would like to point out that the
> Scala package has never been published to maven as 1.0 under org.apache.
>
> Open to suggestions.
>
> Thanks, Naveen
--
Yizhi Liu
DMLC member
Amazon Web Services
Vancouver, Canada
Yes it is. Thanks!
2018-03-08 16:04 GMT-08:00 Chris Olivier :
> Done. Assume you meant your apache.org onew (there there two)
>
> On Thu, Mar 8, 2018 at 3:47 PM, YiZhi Liu wrote:
>
>> Hi Chris,
>>
>> could you help to add me to the permission group (committer)?
>
ot; link.
>> >
>> > If you don't have permissions, please email me directly (or even better,
>> > ping on slack) and I will add you to a permission group (let me know if
>> > you're a committer or contributor).
>> >
>>
--
Yizhi Liu
DMLC member
Amazon Web Services
Vancouver, Canada
incubation status is not necessarily a reflection
of the completeness or stability of the code, it does indicate
that the project has yet to be fully endorsed by the ASF.
--
Yizhi Liu
DMLC member
Amazon Web Services
Vancouver, Canada
lease process on general@ and the release
announcement will follow in the next few days.
--
Yizhi Liu
DMLC member
Amazon Web Services
Vancouver, Canada
, Feb 10, 2018 at 10:49 AM, YiZhi Liu wrote:
>
>> Let's make the voting end at 11:10 p.m., Tuesday, February. 13th.
>>
>> Thanks for reminding.
>>
>> Best,
>> Yizhi
>>
>> 2018-02-10 9:54 GMT-08:00 Marco de Abreu :
>> > Please extend
>
> -Marco
>
> On Sat, Feb 10, 2018 at 6:09 PM, Tianqi Chen
> wrote:
>
>> +1
>>
>> tianqi
>> On Fri, Feb 9, 2018 at 11:11 PM YiZhi Liu wrote:
>>
>> > Hi everyone,
>> >
>> > As we have updated the LICENSE file which caused t
accordingly:
+1 = approve
+0 = no opinion
-1 = disapprove (provide reason)
Best,
Yizhi
--
Yizhi Liu
DMLC member
Amazon Web Services
Vancouver, Canada
her release candidate with a updated
> LICENSE file will be proposed soon.
>
> Unfortunately, I will be traveling in China in the next three weeks. I'll
> let Yizhi lead the remaining efforts for 1.1.0 release.
>
> Thanks,
> Haibin
--
Yizhi Liu
DMLC member
Amazon Web Services
Vancouver, Canada
> > > > > >
> > > > > > > > > > > Given that most people on dev@ are in favor of a minor
> > > > release
> > > > > > > > (1.1.0)
> > > > > > > > > > > instead of a patch release due to API changes, I'd like
> > to
> > > > > > propose
> > > > > > > a
> > > > > > > > > vote
> > > > > > > > > > > to release Apache MXNet (incubating) 1.1.0. Voting will
> > > start
> > > > > now
> > > > > > > > > > (Sunday,
> > > > > > > > > > > January 28th) and end at 1pm Wednesday, January 31th
> PST.
> > > > > > > > > > >
> > > > > > > > > > > Link to release notes:
> > > > > > > > > > > https://cwiki.apache.org/confluence/display/MXNET/
> > > > > > > > > > > Apache+MXNet+%28incubating%29+1.1.0+Release+Notes
> > > > > > > > > > >
> > > > > > > > > > > Link to release candidate 1.1.0.rc0:
> > > > > > > > > > > https://github.com/apache/
> incubator-mxnet/releases/tag/
> > > > > 1.1.0.rc0
> > > > > > > > > > >
> > > > > > > > > > > View this page and scroll down to “Build from Source”
> > with
> > > > > source
> > > > > > > > code
> > > > > > > > > > > obtained from the 1.1.0.rc0 tag:
> > > > > > > > > > > https://mxnet.incubator.apache.org/install/index.html
> > > > > > > > > > >
> > > > > > > > > > > (Note: The README.md points to the 1.1.0 tag and does
> not
> > > > work
> > > > > at
> > > > > > > the
> > > > > > > > > > > moment.)
> > > > > > > > > > >
> > > > > > > > > > > Please remember to TEST first before voting
> accordingly:
> > > > > > > > > > > +1 = approve
> > > > > > > > > > > +0 = no opinion
> > > > > > > > > > > -1 = disapprove (provide reason)
> > > > > > > > > > >
> > > > > > > > > > > Best,
> > > > > > > > > > > Haibin
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Sandeep Krishnamurthy
> > > > > >
> > > > >
> > > >
> > >
> >
>
>
>
> --
> Sandeep Krishnamurthy
>
> --
> Yizhi Liu
> DMLC member
> Amazon Web Services
> Vancouver, Canada
>
>
>
> Nan
>
> On Wed, Jan 17, 2018 at 6:01 PM, Naveen Swamy wrote:
>
> > Hi Yizhi,
> > Here is the Apache guideline
> > http://www.apache.org/dev/publishing-maven-artifacts.html.
> >
> > -Naveen
> >
> >
> >
> > On Wed, Jan 17,
Since we now have changed Scala package prefix to org.apache, does someone
have guidance for posting it to Apache's Maven Repository?
FYI, ml.dmlc.mxnet was posted to oss.sonatype.org.
--
Yizhi Liu
DMLC member
Amazon Web Services
Vancouver, Canada
[
https://issues.apache.org/jira/browse/MXNET-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16327556#comment-16327556
]
Yizhi Liu commented on MXNET-4:
---
I think it's easier to have Random support MKL s
> > > > *Old way:*
> > > > >
> > > > > scala> import ml.dmlc.mxnet._
> > > > >import ml.dmlc.mxnet._scala> val arr = NDArray.ones(2, 3)
> > > > >arr: ml.dmlc.mxnet.NDArray = ml.dmlc.mxnet.NDArray@f5e74790
> > > > >
> > > > > *New way:*
> > > > >
> > > > > scala> import org.apache.mxnet._
> > > > >import org.apache.mxnet._
> > > > > scala> val arr = NDArray.ones(2, 3)
> > > > >arr: org.apache.mxnet.NDArray = org.apache.mxnet.NDArray@
> f5e74790
> > > > >
> > > > >
> > > > > Please let me know if anyone has any thoughts or issues with
> this
> > > change.
> > > > >
> > > > > Thanks,
> > > > > Roshani
> > > > >
> > > >
> > >
> >
>
>
>
>
--
Yizhi Liu
DMLC member
Amazon Web Services
Vancouver, Canada
; docs/
>
> ExamplesNot sure, since we have a lot of contributors here. We probably
> need to remove low quality examples and assign one maintainer for each of
> the rest.
>
> example/
>
> ToolsNot sure as well, since we have a bunch of things there. Probably need
> to the same thing as examples
>
> tools/
> plugin/
>
> AppendixLines of codes added into each folder on the last two months:
> Lines of codes added into example/
> Lines of codes added into src/
>
--
Yizhi Liu
DMLC member
Amazon Web Services
Vancouver, Canada
es related to the key functionality
> >>
> >> 3. https://github.com/dmlc/ps-lite/pull/121 contains everything (Please
> >> review this one)
> >>
> >>
> >> I am not sure who is the current owner of ps-lite, please help to share
> >> you
o it. But
>> > that's not what we want is it?
>> >
>> > No we are not saying don't add anything in master, we are just saying
>> > please don't add bad code to the master. And yes I have seen bad code has
>> > been merged to the master when protected branch was not enabled.
>> >
>> > Protected master hardly adds any stability. The faulty tests that breaks
>> > master at random got merged into master because they happened to succeed
>> > once.
>> >
>> > That's not true, it filter out one of the important aspect that at least
>> > when code was merged it completed the whole cycle of build and test. Sure
>> > flaky test we can track down.
>> >
>> > Thanks,
>> > Junyuan Xie
>> >
>>
--
Yizhi Liu
DMLC member
Requesting an invitation to Slack.
Thanks,
Yizhi
--
Yizhi Liu
DMLC member
-L1104
>
> So:
> * What is NDArrayFuncReturn ?
> * If I'm getting NDArrayFuncReturn (a private class) returned, am I
> calling some internal API I should not be using ?
> * What is correct way o do NDArrayFuncReturn -> NDArray ?
>
> Thanks,
> --TongKe
--
Yizhi Liu
DMLC member
Technical Manager
Qihoo 360 Inc, Shanghai, China
d from github / source via
> https://mxnet.incubator.apache.org/get_started/build_from_source.html
>
> or
>
> 2. there's some other repo to use?
>
>
> Thanks,
> --TongKe
--
Yizhi Liu
DMLC member
Technical Manager
Qihoo 360 Inc, Shanghai, China
I can't find NDArray auto diff anywhere
>
> 3. however, NDArray tracks dependencies -- which, in theory, should
> be enough for doing autodiff
>
> Does NDArray have autodiff somewhere?
>
> Thanks,
> --TongKe
--
Yizhi Liu
DMLC member
Technical Manager
Qihoo 360 Inc, Shanghai, China
You can retrieve the functions/operators by reflection. Or, when
compiling the scala package, it prints all operators out.
2017-10-19 8:15 GMT+00:00 YiZhi Liu :
> The javadoc cannot be added in this way. I'm afraid we have to write
> another 'javadoc generator' for these oper
You can retrieve the functions/operators by reflection. Or, when
compiling the scala package, it prints all operators out.
2017-10-19 8:15 GMT+00:00 YiZhi Liu :
> The javadoc cannot be added in this way. I'm afraid we have to write
> another 'javadoc generator' for these oper
.11-0.11.0-SNAPSHOT-javadoc.jar
>
> That jar looks mostly empty. Is that expected, or am I doing something wrong?
>
>
> 3. Currently, the best way I know for retrieving all the functions is
> to fire up a repl and run reflection. Is there a better method?
>
>
> Thanks,
> --
pi/scala/symbol.html
>>> >
>>> > I see Symbol.Variable, Symbol.Convolution
>>> >
>>> > When I look at Symbol.scala, I see Symbol.Variable at:
>>> > https://github.com/apache/incubator-mxnet/blob/master/
>>> scala-package/core/src/main/scala/ml/dmlc/mxnet/Symbol.scala#L982
>>> >
>>> > However, I can't find where Convolution, SoftMax, FullyConnected, ...
>>> > are defined.
>>> >
>>> > Where are these Symbols defined?
>>> >
>>> > (I have also tried: grep "Convolution" . -R | grep scala | grep def --
>>> > but found nothing).
>>> >
>>> > Thanks,
>>> > --TongKe
>>>
>>
>>
>>
>> --
>> Rahul Huilgol
--
Yizhi Liu
DMLC member
Technical Manager
Qihoo 360 Inc, Shanghai, China
ala package and was looking for a
> maven distro for v0.11. When do you think you'll have one up?
>
> On Tue, Sep 26, 2017 at 8:58 AM, YiZhi Liu wrote:
>
>> I'm currently working on maven deploy for scala package.
>>
>> 2017-09-26 16:00 GMT+08:00 Zihao Zh
ivity to the mailing lists and growing
>>>> the community, can everyone who is working on MXNet please share what
>>>> you're working on?
>>>>
>>>> I'm working on
>>>> -Redesigning the website
>>>> <https://mxnet.incubator.apache.org/versions/master/index.html>.
>>>> -Setting up a forum for user support.
>>>>
>>>> Seb Kiureghian
>>>>
>>>
>>
>>
>>
>> --
>> Sandeep Krishnamurthy
>
--
Yizhi Liu
DMLC member
Technical Manager
Qihoo 360 Inc, Shanghai, China
nts/Suggestion?
>
> Regards,
> Sandeep
>
>
> On Wed, Aug 16, 2017 at 10:56 AM, YiZhi Liu wrote:
>
>> What Nan and I worried about is the re-implementation of something
>> like https://github.com/apache/incubator-mxnet/blob/master/
>> scala-package/core/src/main/s
wouldn't need a lot of additions to be pleasurable to use from scala.
>
> Jörn
>
> On Wed, Aug 16, 2017 at 6:45 PM, Nan Zhu wrote:
>> I don't think there will be problems under "11", did the user see concrete
>> errors?
>>
>> Best,
>>
>&
Hi Nan,
Users have 2.11, but with a different minor version, will it cause conflicts?
2017-08-17 0:19 GMT+08:00 Nan Zhu :
> Hi, Yizhi,
>
> You mean users have 2.10 env while we assemble 2.11 in it?
>
> Best,
>
> Nan
>
> On Wed, Aug 16, 2017 at 9:08 AM, YiZhi Liu wrot
is just like we provide C++ & C APIs of MxNet in two separated
>> packages.
>>
>> About dependency problem, when you say "As far as I see this has the great
>> disadvantage that the Java API would force Scala as a dependency onto the
>> java users.", wou
7;t require that the public part of
> the Scala API is changed.
>
> What do you think?
>
> Jörn
>
> [1] https://cwiki.apache.org/confluence/display/SPARK/Java+API+Internals
>
> On Wed, Aug 16, 2017 at 3:39 PM, YiZhi Liu wrote:
>> Hi Joern,
>>
>> I suggest
ed approaches and I
> am also interested to work on MXNet.
>
> Jörn
--
Yizhi Liu
DMLC member
Technical Manager
Qihoo 360 Inc, Shanghai, China
enable 2 Factor Auth and make sure all three boxes on the
>> page show check marks.
>>
>> Please respond here with your Apache user id once complete.
>>
>> @pono or @henri will have to make sure that committers and PMC members are
>> added to the `mxnet` group h
gt; > -Joe
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > *From: *Henri Yandell
>> > > > *Date: *Thursday, January 26, 2017 at 2:47 PM
>> > > > *To: *"dev@mxnet.incubator.apache.org" <
>> dev@mxnet.incubator.apache.org>
>> > > > *Cc: *"Spisak, Joseph"
>> > > > *Subject: *New Logo?
>> > > >
>> > > >
>> > > >
>> > > > Joe - from a private conversation I believe you wanted to
>> propose/offer a
>> > > > new logo for the project?
>> > > >
>> > > > Aka *nudge* to bring the topic up here as a first item of business :)
>> > > >
>> > > > Hen
>> > > >
>> > >
>>
> --
> Ziheng Jiang
> Fudan University | Computer Science
--
Yizhi Liu
DMLC member
Technical Manager
Qihoo 360 Inc, Shanghai, China
72 matches
Mail list logo
