+1
On Thu, Sep 12, 2019 at 1:18 PM Zach Kimberg
wrote:
> We had a discussion a while back about trying to improve the way we handle
> issues by assigning them to users who are working on them. However, the
> discussion ended because issues could only be assigned to those with write
> access (com
> https://github.com/apache/incubator-mxnet/pull/15303
>
> thanks,
> -tao
>
> -Original Message-
> From: Marco de Abreu
> Sent: Wednesday, September 11, 2019 9:38 PM
> To: dev@mxnet.incubator.apache.org
> Subject: Re: [DISCUSS] Remove amalgamation
>
> Is A
-tao
-Original Message-
From: Marco de Abreu
Sent: Wednesday, September 11, 2019 9:38 PM
To: dev@mxnet.incubator.apache.org
Subject: Re: [DISCUSS] Remove amalgamation
Is Amalgamation only used on Android though? Are there any other use cases?
-Marco
Pedro Larroy schrieb am Mi., 11. Sep. 2019,
Is Amalgamation only used on Android though? Are there any other use cases?
-Marco
Pedro Larroy schrieb am Mi., 11. Sep. 2019,
11:57:
> Hi Anirudh
>
> Appreciate your feedback and sorry if my email came across that way to you,
> I think you might miss some context. I don't think calling somethi
Heres some foundation for “hacky” in computer science:
Calling a piece of code hacky isn’t the same as saying it’s bad, the code just
doesn’t have infrastructure around it. You can probably already piece together
why they call hackers hackers, and hackathons hackathons — hacks just need to
run
Hi Pedro,
I don't see anything "destructive" with Chris asking for justification for
you calling something "hacky". The only email in this thread where I see ad
hominems and disrespectful comments is your email.
On Sat, Sep 7, 2019, 10:18 PM Pedro Larroy
wrote:
> Apache mentors should have a lo
Well deserved Junru, welcome!
-Zhi
> On Sep 8, 2019, at 7:04 PM, Yuan Tang wrote:
>
> Welcome Junru!
>
> On Sun, Sep 8, 2019 at 9:21 PM Lin Yuan wrote:
>
>> Congratulations!
>>
>> On Sat, Sep 7, 2019 at 8:14 PM Sheng Zha wrote:
>>
>>> Hi all,
>>>
>>> Please join me in welcoming Junru Sha
Welcome Junru!
On Sun, Sep 8, 2019 at 9:21 PM Lin Yuan wrote:
> Congratulations!
>
> On Sat, Sep 7, 2019 at 8:14 PM Sheng Zha wrote:
>
> > Hi all,
> >
> > Please join me in welcoming Junru Shao as a new committer of Apache MXNet
> > (incubating)!
> >
> > Junru made a number of contributions to
Congratulations!
On Sat, Sep 7, 2019 at 8:14 PM Sheng Zha wrote:
> Hi all,
>
> Please join me in welcoming Junru Shao as a new committer of Apache MXNet
> (incubating)!
>
> Junru made a number of contributions to this project such as cond and
> while_loop control-flow
> operators, enabling dynam
Congratulations Junru!
On Sun, 8 Sep 2019 at 18:01, Qin, Zhennan wrote:
> Congratulations, Junru!
>
> Zhennan
>
>
> On Sun, 2019-09-08 at 03:14 +, Sheng Zha wrote:
>
> Hi all,
>
>
> Please join me in welcoming Junru Shao as a new committer of Apache MXNet
> (incubating)!
>
>
> Junru made a n
Congratulations, Junru!
Zhennan
On Sun, 2019-09-08 at 03:14 +, Sheng Zha wrote:
Hi all,
Please join me in welcoming Junru Shao as a new committer of Apache MXNet
(incubating)!
Junru made a number of contributions to this project such as cond and
while_loop control-flow
operators, ena
Congratulations!!
On Sun, Sep 8, 2019, 14:51 Marco de Abreu wrote:
> Congratulations!
>
> -Marco
>
> MiraiWK WKCN schrieb am So., 8. Sep. 2019, 06:10:
>
> > Congrats, Junru!
> >
> > 发件人: Sheng Zha
> > 发送时间: 2019年9月8日 11:14
> > 收件人: d...@mxnet.apache.org
> > 主题
Congratulations!
-Marco
MiraiWK WKCN schrieb am So., 8. Sep. 2019, 06:10:
> Congrats, Junru!
>
> 发件人: Sheng Zha
> 发送时间: 2019年9月8日 11:14
> 收件人: d...@mxnet.apache.org
> 主题: [Announcement] New Committer - Junru Shao
>
> Hi all,
>
> Please join me in welcoming Jun
Alright, let's get back to the actual topic.
ARMv7 and ARMv8 are covered by our separate pipelines, so that's good. But
I still would like to identify the blind spots that we would be creating.
Are there other use cases where people like to use Amalgamation? I remember
the Javascript version and A
Apache mentors should have a look at these reincident harassment and
destructive behaviors which demotivate contributions and take action. It
takes only one bad apple to ruin a community.
The mobile solution that is known to work as of know is cross compiling
with "ci/build.py -p build.android_arm
I went down the path for this and was disuaded by the errors I had and the
open issues about the same errors. It's one thing to leave something around
that works, but another to leave something around that wastes a lot of time
and causes abandonment.
The project needs a mobile solution. What's the
+1.
I have heard this before elsewhere if you don't understand the code, give
it a name like "hacky", "does not follow the pattern", "unmaintainable",
etc., may all that be true but it does not help making cliched and
disrespectful comments about someone else's contributions.
the code is not going
I can recall that we had quite a few issues where people tried to use
amalgamation. Have we identified these use cases so far and documented the
alternative.
I think the compilation only takes a few seconds and I think we also have
some nightly tests for it. So far it seemed very low maintenance,
Hi Pedro,
While I was not involved with amalgamation or its development in any way,
can you please refrain from referring to the work of others as a "hacky
solution"? This is derogatory slang and the statement was not supported
with any justification for such name-calling. Someone spent a good d
No, the vote was cancelled.
Pedro Larroy schrieb am Sa., 7. Sep. 2019,
00:05:
> Did this vote pass? Can we remove Python2 support from master?
>
> On Tue, Aug 27, 2019 at 2:51 PM Pedro Larroy >
> wrote:
>
> > +1
> >
> > On Tue, Aug 27, 2019 at 3:49 AM Leonard Lausen
> wrote:
> >
> >> Due to Re
Did this vote pass? Can we remove Python2 support from master?
On Tue, Aug 27, 2019 at 2:51 PM Pedro Larroy
wrote:
> +1
>
> On Tue, Aug 27, 2019 at 3:49 AM Leonard Lausen wrote:
>
>> Due to References: header the prior email was still sorted in the
>> discussion thread. Cancelling this and rese
The new website looks great Aaron. Nice work to everyone involved !
On Thu, Aug 29, 2019 at 5:26 PM Aaron Markham
wrote:
> Hi everyone,
>
> I'm very excited to share a preview and the pull requests for a new
> website and new documentation pipelines.
>
> The following link is using Apache's new
Update:
Artifacts of 1.5.1.rc0 have been uploaded to github and Apache dist. Before
voting, we still need some time to build packages for Scala, Clojure and R.
Thank you for your patience.
-tao
On Thu, Sep 5, 2019 at 10:15 PM Tao Lv wrote:
>
> Following the release process [1], I just created
Following the release process [1], I just created the tag for 1.5.1.rc0
[2]. Artifacts uploading and validation are still WIP. Will keep you
posted. Hopefully we can start the veto soon for a new release. :)
Let me know if you any question or suggestion for the release.
Thanks,
-tao
[1] https://
@ptrendx @yzhliu
I will create a PR for `np.random.gamma` implemented using the method I
proposed before the end of the week, as I need to proceed to implement more
distribution samplers, in which the gamma sampler serves as a necessity.
Refactoring `nd.random` may be left for further discussio
Thanks for the feedback.
We're starting to see merge conflicts as our base is wandering off
from master. The PRs are pretty massive, and there's a lot of moving
parts. I'd really appreciate reviews, so we can move forward.
The first PR only ADDs content and gives us the new site. Having the
new con
Code freezing!
If you happen to be around github, please help to review the PR [1] for
bumping version strings on the release branch. Thanks.
I will continue working on the rest steps for the release.
Thanks,
-tao
[1] https://github.com/apache/incubator-mxnet/pull/16072
On Mon, Sep 2, 2019 at
I don’t think we’d want to re-invent the wheel as there are many solutions
exist already. Another solution besides mlflow is Kubeflow Pipelines:
https://github.com/kubeflow/pipelines
On Mon, Sep 2, 2019 at 10:12 PM Naveen Swamy wrote:
> Look at https://mlflow.org/
>
> > On Sep 2, 2
Look at https://mlflow.org/
> On Sep 2, 2019, at 7:02 PM, Chaitanya Bapat wrote:
>
> Hello MXNet community,
>
> Reproducibility of ML experiments carried out by data scientists, analysts
> and experts is the talk of the town.
>
> While listening to TWiML's latest podcast - Managing Deep Learni
I drafted the release notes for 1.5.1 patch release:
https://cwiki.apache.org/confluence/display/MXNET/1.5.1+Release+Notes
Any comments or suggestions are highly appreciated!
-tao
On Mon, Sep 2, 2019 at 2:00 PM kellen sunderland <
kellen.sunderl...@gmail.com> wrote:
> Thanks for organizing the
Thanks for organizing the release Tao.
On Sun, Sep 1, 2019, 5:53 PM Tao Lv wrote:
> Hi Community,
>
> Code freeze for 1.5.1 patch release will be 9/3 6pm PST (9/4 9am CST). If
> you have any additional fix in progress and would like to include it in
> this release, please assure they have been m
First things first,
Big shout out to you (Aaron) and the team for laying a strong foundation
for the new website! We all knew that our original website needed
improvements and it's criticality for user adoption and growth. But doing
it well and in a timely manner. Great job, keep it up.
Those 3 P
Hen writes:
> Are you saying that trademarks for MXNet has been registered by other
> companies?
Yes, though not for the purpose of machine learning frameworks.
So I suppose there is no concern?
These are the active / pending registrations:
- Minimax GmbH & Co. KG trademarked MXNet it in German
On Fri, Aug 30, 2019 at 3:01 AM Leonard Lausen wrote:
> Anton Chernov writes:
> > As a physicist I would like to point out that "Gluon" means: An
> elementary
> > particle that acts as the exchange particle for the strong force between
> > quarks [1].
> > As a general scientific term it can bare
n
> >> >> In the history, most of the releases were done by the Amazon side.
> >> >> Currently, we are moving on to rotate this responsibility with
> >> >> contributors/committers not from Amazon to start working on them.
> >> >>
> >> >
> >> > >
> >> > > Ok. I was just asking if we want this fix in 1.5.1 since it
> >> > > addresses
> >> > > crashes using multiprocessing. The problem with cherry picking is
> >> > > that
> >> > > the
> &
different firm/institution should have real
> work
> > >> on MXNet
> > >> I can tell from the issues/PRs/rfcs they submitted and indeed and
> indeed
> > >> we should encourage the committers who is less active to be involved
> > into
> > >> MXN
Anton Chernov writes:
> As a physicist I would like to point out that "Gluon" means: An elementary
> particle that acts as the exchange particle for the strong force between
> quarks [1].
> As a general scientific term it can barely be seen as a candidate for
> trademark registration.
This doesn'
t supposed to go in a release branch.
>> > >
>> > > On Tue, Aug 27, 2019 at 1:19 PM Lin Yuan > > > apefor...@gmail.com>>
>> > > wrote:
>> > >
>> > > https://github.com/apache/incubator-mxnet/pull/15762 contains
>> > &g
gt; > > in
> > > 1.5
> > > for
> > > some users, which I got notice today and is fixed in master.
> > >
> > > Might be useful to put in 1.5.1:
> > > https://github.com/apache/incubator-mxnet/pull/15762 ?
> > >
> > > Pedro
ses were done by the Amazon side.
> >> >> Currently, we are moving on to rotate this responsibility with
> >> >> contributors/committers not from Amazon to start working on them.
> >> >>
> >> >> 4. Committers from different firm/institution
contributors/committers not from Amazon to start working on them.
>> >>
>> >> 4. Committers from different firm/institution should have real work
>> >> on MXNet
>> >> I can tell from the issues/PRs/rfcs they submitted and indeed and indeed
>> >
et
> >> I can tell from the issues/PRs/rfcs they submitted and indeed and indeed
> >> we should encourage the committers who is less active to be involved
> into
> >> MXNet contribution.
> >>
> >> Thanks,
> >> Qing
> >>
> >> _
I think for now PDF would still be used by a good amount of users since R
users are used to read PDF manual for packages that don't have websites.
Nowadays Github pages + pkgdown combination is getting more and more
popular so we would see a trend soon towards web hosted docs for R
packages.
On T
pkgdown makes some nice looking R microsites. Good idea. Do you know
if many R users would still want the pdf or have things moved to use
websites for reference like this?
One of the nice things about the new pipelines for docs is that
they're not wrapped by Sphinx, so our R contributors will have
Thanks for the update, Aaron.
Regarding the R docs, one suggestion I have is to use pkgdown package (
https://pkgdown.r-lib.org/index.html) to automatically generated the
documentation pages (tutorials, API reference, etc.). I've seen huge
adoption of this package being used for documentations in
> >
> http://jenkins.mxnet-ci.amazon-ml.com/blue/organizations/jenkins/NightlyTestsForBinaries/activity/
> > 2. https://github.com/apache/incubator-mxnet/pull/15803
> > cannot
> > pass
> > the
> > CI;
> > 3. I hope julia folks can take a look at th
nd is fixed in master.
>> >
>> > Might be useful to put in 1.5.1:
>> > https://github.com/apache/incubator-mxnet/pull/15762 ?
>> >
>> > Pedro.
>> >
>> > On Tue, Aug 20, 2019 at 7:49 AM Tao Lv > > ta...@apache.org>>
>> &
gt; > bunch of fixes to v1.5.x branch. So far, the branch looks
> > healthy:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> http://jenkins.mxnet-ci.amazon-ml.com/blue/organizations/jenkins/NightlyTestsForBinaries/activity/
> >
ommitters from different firm/institution should have real work
>> on MXNet
>> I can tell from the issues/PRs/rfcs they submitted and indeed and indeed
>> we should encourage the committers who is less active to be involved into
>> MXNet contribution.
>>
>> Thanks,
> license issue of a cat image in julia examples.
> https://github.com/apache/incubator-mxnet/issues/15542
> 5. Still no progress for the sidebar issue:
> https://github.com/apache/incubator-mxnet/issues/15200
> 6. There is a GPU OOM issue in 1.5.0 release and already root
> caused
&
Reopened #14253.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/14253#event-2592397494
Hi @reminisce , I try to pass a numpy-compatible array into a legacy operator,
and it raises this error.
```python
>>> import mxnet.numpy as np
>>> import mxnet as mx
>>> import mxnet.numpy as np
>>> a = np.array([1,2])
>>> b = np.array([3,4])
>>> mx.nd.broadcast_add(a,b)
Traceback (most recent c
Closed #14253.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/14253#event-2592397357
Gathering this data would be useful to make a decision.
I myself have invested lots of time porting to other platforms such as PI,
JETSON, Arm or Android. If the community is interested in maintaining a
platform there should be action. For a long time I haven't seen much effort
there. Ideally I li
I have an open issue about gathering data per platform install so there can
be an informed discussion on prioritization or even cutting platforms.
Until then... I wouldn't cut one.
I would like to hear the pros and cons for dropping some native platform
support in favor of containers. But... For w
.1+Release+Plan+and+Status
.
Thanks,
-tao
On Mon, Aug 12, 2019 at 9:57 PM Zhao, Patric <
patric.z...@intel.com>
wrote:
Thanks for the explanation, Marco & Tao. Sounds great!
-Original Message-
From: Tao Lv
Sent: Monday, August 12, 2019 9:54 PM
To: dev@mxnet.incubator.apache.or
ml.com/blue/organizations/jenkins/NightlyTestsForBinaries/activity/
> > > > > > > > 2. https://github.com/apache/incubator-mxnet/pull/15803
> cannot
> > > > pass
> > > > > > the
> > > > > > > > CI;
; > > > > > 3. I hope julia folks can take a look at the back porting for
> > > > > > > https://github.com/apache/incubator-mxnet/pull/15609 and
> > > > > > > https://github.com/apache/incubator-mxnet/pull/15608 - do we
> > still
> > > > >
gt; them?
> > > > > > 4. License issue of cub and pybind is still not fixed. We also
> has
> > a
> > > > > > license issue of a cat image in julia examples.
> > > > > > https://github.com/apache/incubator-mxnet/issues/15542
> > > > > > 5. St
caused
> > by
> > > > > Lin:
> > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-mxnet/issues/15703#issuecomment-522780492
> > > > > .
> > > > > We need decide
> > > .
> > > > We need decide whether we want to get it fixed in the 1.5.1 patch
> > > release.
> > > >
> > > > Please find details in
> > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/MXNET/1.
+1
On Tue, Aug 27, 2019 at 3:49 AM Leonard Lausen wrote:
> Due to References: header the prior email was still sorted in the
> discussion thread. Cancelling this and resending without that header.
>
> Leonard Lausen writes:
>
> > Marco de Abreu writes:
> >> 1. Which Python version to support.
fixed in the 1.5.1 patch
> > release.
> > >
> > > Please find details in
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/MXNET/1.5.1+Release+Plan+and+Status
> > > .
> > >
> > > Thanks,
> > > -tao
>
> > On Mon, Aug 12, 2019 at 9:57 PM Zhao, Patric
> > wrote:
> >
> > > Thanks for the explanation, Marco & Tao. Sounds great!
> > >
> > > > -Original Message-
> > > > From: Tao Lv
> > > > Sent: Monday, August 12, 2019 9:54 PM
>
I sincerely apologize for the mistake that I sent this email to the dev@. This
discussion thread is not intended for dev@ and I withdraw the discussion from
here.
-sz
On 2019/08/27 18:07:09, Sheng Zha wrote:
> Dear PPMC members,
>
> I'd like to start a discussion on inviting Tao Lv as a PPMC
Good summary. At the start the discussion thread my ask is to announce the
intention of py2 deprecation in the next release, and then actually deprecate
py2 in the next major release. Thus, the appropriate timing for dropping py2
support in CI should be the start of the next major release. The p
ge the committers who is less active to be involved into
> MXNet contribution.
>
> Thanks,
> Qing
>
>
> From: Lieven Govaerts
> Sent: Saturday, August 10, 2019 5:59
> To: dev@mxnet.incubator.apache.org
> Cc: d...@mxnet.apache.org
> Subject: Re: [DISCUSS] Apache MXNe
Just for the sake of completeness, another factor is the python platform tag
manylinux2010 compliance [1]. Since it required GLIBC2.12 and GCC4.3,
unfortunately even the existing minimum version standard wouldn't allow us to
be compliant.
[1] https://www.python.org/dev/peps/pep-0571/
On 2019/0
: Re: [DISCUSS] Apache MXNet: Path to graduation
Hi Qing,
as a user and ASF member observing this project:
On Sat, 10 Aug 2019 at 01:44, Qing Lan wrote:
> Hi All,
>
> I would like to start a thread to discuss about the graduation for Apache
> MXNet. From my time working in the commun
We could think about moving to a newer version and updating the standard. I'm
using gcc 4.9 with my work builds, but more modern compilers everywhere else
(and is be willing to update the work compiler).
One of the cons is that it makes our code less portable. When we update the
minimum requir
Due to References: header the prior email was still sorted in the
discussion thread. Cancelling this and resending without that header.
Leonard Lausen writes:
> Marco de Abreu writes:
>> 1. Which Python version to support. 3.5 vs 3.6 is currently in the
>> discussion due to Ubuntu 16.04 being s
Pedro,
thanks for already starting these efforts, but it might be too early for
that. Right now, this is a discussion thread where we try to gather
different opinions in order to lay a good base for a future voting thread.
In there, we would define the detailed timeline, versions etc. Until the
vo
I have sent a PR that removes Python2 from CI. But was closed. I thought
everyone was +1 on this one. This would remove quite a bit of load on CI:
https://github.com/apache/incubator-mxnet/pull/15990
If it's not the right time to do this, what steps do we need to take?
Pedro.
On Mon, Aug 26, 2
> > -Original Message-
> > > From: Tao Lv
> > > Sent: Monday, August 12, 2019 9:54 PM
> > > To: dev@mxnet.incubator.apache.org
> > > Subject: Re: [Discussion] MXNet 1.5.1 release
> > >
> > > > Regarding the open issue, is there def
> > well as the lack of recognition for such a critical activity. I'm not
> > > sure
> > > > about the cause but I believe this is something that should be
> > rectified
> > > > for future contributions and help on the CI front if improvements are
>
Lieven Govaerts writes:
> Hi,
>
> On Thu, 22 Aug 2019 at 17:01, Leonard Lausen wrote:
>
>> Hi,
>>
>> Pedro stated "Seems 3.6 is a reasonable choice." and there have been a
>> few +1 after Chaitanya's reply to Pedro. I would like to check if these
>> only refer to Chaitanya's mail about a dedicate
Hi,
On Thu, 22 Aug 2019 at 17:01, Leonard Lausen wrote:
> Hi,
>
> Pedro stated "Seems 3.6 is a reasonable choice." and there have been a
> few +1 after Chaitanya's reply to Pedro. I would like to check if these
> only refer to Chaitanya's mail about a dedicated "improvement" effort or
> about dr
Thanks for forwarding this, Haibin! Are we going to be represented?
-Marco
Haibin Lin schrieb am Sa., 24. Aug. 2019, 22:46:
> -- Forwarded message -
> From: Sally Khudairi
> Date: Wed, Aug 21, 2019 at 9:23 AM
> Subject: ApacheCon Europe 2019: Join our Hackathon!
> To:
>
>
> De
+1
On Thu, Aug 22, 2019 at 11:22 PM Junru Shao wrote:
> +1 for 3.6+
>
> On Thu, Aug 22, 2019 at 8:54 AM Marco de Abreu
> wrote:
>
> > +1 for 3.6+
> >
> > Yuan Tang schrieb am Do., 22. Aug. 2019,
> 08:08:
> >
> > > +1 to target 3.6+
> > >
> > > On Thu, Aug 22, 2019 at 11:01 AM Leonard Lausen
>
Hi Marco,
Thank you for helping CI all the time. You did an incredible job on it.
Please let me explain why it’s urgent we need to update our CI to allow fast
developing.
In this summer, we managed to hire a large amount of interns to help, they did
great to contribute to MXNet. But CI is on
I like this idea. Some thoughts:
* Disable CI checks when a PR is first submitted. Trigger it only when the
PR is flagged for that stage of review.
* I have WIP PRs that waste CI resources because of the automatic trigger,
but then I need CI to run on them sometimes. Changing the title could be a
gt; > when the hash of the layer in docker doesn't match and decides to
> > rebuild
> > > > it. the r script seems not to have changed. I have observed this in
> the
> > > > past and I think is due to bugs in docker. Maybe Kellen is able to
> > give
> >
u should use -R which is already in master. (you can
> > always
> > > copy the script on top if you are in an older revision).
> > >
> > > Another thing that worked for me in the past was to completely nuke the
> > > docker cache, so it redonwloads from the CI re
rom the CI repo. After that it worked
> fine
> > in some cases.
> >
> > These two workarounds are not ideal, but should unblock you.
> >
> > Pedro.
> >
> > On Fri, Aug 16, 2019 at 11:39 AM Aaron Markham <
> aaron.s.mark...@gmail.com>
> > wro
gt;
>> Is -R already in there?
>>
>> Here's an example of it happening to me right now I am making
>> minor changes to the runtime_functions logic for handling the R docs
>> output. I pull the fix, then run the container, but I see the R deps
>> la
+1 for 3.6+
On Thu, Aug 22, 2019 at 8:54 AM Marco de Abreu
wrote:
> +1 for 3.6+
>
> Yuan Tang schrieb am Do., 22. Aug. 2019, 08:08:
>
> > +1 to target 3.6+
> >
> > On Thu, Aug 22, 2019 at 11:01 AM Leonard Lausen
> wrote:
> >
> > > Hi,
> > >
> > > Pedro stated "Seems 3.6 is a reasonable choice.
+1 for 3.6+
Yuan Tang schrieb am Do., 22. Aug. 2019, 08:08:
> +1 to target 3.6+
>
> On Thu, Aug 22, 2019 at 11:01 AM Leonard Lausen wrote:
>
> > Hi,
> >
> > Pedro stated "Seems 3.6 is a reasonable choice." and there have been a
> > few +1 after Chaitanya's reply to Pedro. I would like to check
+1 to target 3.6+
On Thu, Aug 22, 2019 at 11:01 AM Leonard Lausen wrote:
> Hi,
>
> Pedro stated "Seems 3.6 is a reasonable choice." and there have been a
> few +1 after Chaitanya's reply to Pedro. I would like to check if these
> only refer to Chaitanya's mail about a dedicated "improvement" eff
Hi,
Pedro stated "Seems 3.6 is a reasonable choice." and there have been a
few +1 after Chaitanya's reply to Pedro. I would like to check if these
only refer to Chaitanya's mail about a dedicated "improvement" effort or
about dropping 3.5.
Thus two questions:
1) Are there any concerns about drop
, Aug 12, 2019 at 9:57 PM Zhao, Patric wrote:
> Thanks for the explanation, Marco & Tao. Sounds great!
>
> > -Original Message-
> > From: Tao Lv
> > Sent: Monday, August 12, 2019 9:54 PM
> > To: dev@mxnet.incubator.apache.org
> > Subje
@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
The device-side api I mentioned is the `RandGenerator` class. (the one used in
`ndarray.random()`), it generates random number with `curand_uniform()`:
https://github.com/apache/incubator-mxnet/blob/master/include/mxnet/random_generator.h#L111
Host api can be seen here (the one I used
I will take the silence as a “no”. Well, that’s a shame, then.
On Thu, Aug 15, 2019 at 4:32 PM Chris Olivier
wrote:
> Tensorflow and pytorch seem to have XLA compatibility (pytorch probably is
> not as stable as tensorflow in this respect, I imagine), and maybe others
> that I don’t know about
Sent you an invite.
On Sat, 17 Aug, 2019, 8:37 PM Lee Seng Cheong,
wrote:
> Hi,
>
> I would like to join the slack channel.
>
> I have followed the instructions listed in
> https://mxnet.apache.org/versions/master/community/mxnet_channels.html
> and subscribed to the developer's mailing list
>
>
@yzhliu No. What MXNet currently does is a scheme where, yes, each thread gets
assigned statically some number of elements, but it has a while loop for each
of them. The scheme I proposed has a single while loop that processes all
elements assigned to a given thread. There is a big difference be
@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
Hi @ptrendx , thanks for your reply, according to my discussion with @yzhliu ,
device-side API is much slower than host-side API.
Also, could you please talk a little bit about the advantage of your approach
compared with mine? thx :)
--
You are receiving this because you are on a team that w
ns logic for handling the R docs
> output. I pull the fix, then run the container, but I see the R deps
> layer re-running. I didn't touch that. Why it that running again?
>
> From https://github.com/aaronmarkham/incubator-mxnet
>f71cc6d..deec6aa
Is -R already in there?
Here's an example of it happening to me right now I am making
minor changes to the runtime_functions logic for handling the R docs
output. I pull the fix, then run the container, but I see the R deps
layer re-running. I didn't touch that. Why it that run
901 - 1000 of 5595 matches
Mail list logo
