It has been raised but there are practical complications about introducing
an additional layer of logic for skipping CI in some scenarios.
How many of these PRs do we have which will justify investing human effort
on optimizing an automated process?
How much effort shall it be dedicated to this
Hi MXNet community
AI on MCUs can enable cheaper, lower power, better privacy and lower
latency applications. There’s an estimate of more than 20 billion connected
devices to be deployed in 2020 and a part of them will do some amount of AI
/ ML tasks. Testing in embedded devices is very
Thanks a lot, I think is very beneficial that we invest in these kind of
tooling for code quality. As a developer I wonder, do we have actionable
items for looking at / fixing these issues or right now is done in an
informational / good will basis?
Is there a way to colorize this output?
Pedro.
Hi
I'm investigating this issue:
https://github.com/apache/incubator-mxnet/issues/12994
To me this code seems suspicious, as it doesn't do what is stated in the
comment.
https://github.com/apache/incubator-mxnet/blob/master/src/kvstore/gpu_topology.h#L577
I don't think the depth of the binary
+1 non-binding. Thanks for driving this, looking forward to see the
positive impact.
On Mon, Oct 29, 2018 at 11:47 PM Carin Meier wrote:
> This vote is to adopt the document
>
>
Hi
There are some tests that fail when some features are not compiled in, such
as Opencv.
In some cases we skip the test according to some precondition such as:
@unittest.skipIf(not graphviz_exists(),
I would propose that we have a Python module that exports a set of methods
to check what
This is the first hangout that I was able to attend, I liked the format and
found them valuable. Thanks for organizing and publishing the notes.
Looking forward to the next one.
Pedro
On Thu, Oct 25, 2018 at 6:44 AM Steffen Rochel
wrote:
> Carin - please see
>
>
Hi Srihari
Thanks for the document. We could add it to the relevant section in the
wiki so it's easier to keep track whenever you feel comfortable with it.
https://cwiki.apache.org/confluence/display/MXNET/Design+Proposals
The calls to synchronize and wait looks very similar. Shall we use
for nominees affiliated with Amazon AWS.
>
> Please comment on the proposal (see thread "[DISCUSS] - Revisions to
> Committer Criteria).
>
> Steffen
>
> On Tue, Oct 23, 2018 at 7:09 AM Pedro Larroy >
> wrote:
>
> > Hi
> >
> > Tianqi, there's a sayin
Hi
Tianqi, there's a saying that the road to hell is paved with good
intentions. I think most of us here are enthusiastic about increasing
diversity of contributions to this project and are working actively towards
this. Having any kind of positive or negative discrimination seems to me
like it
I did pip install mxnet-mkl==1.3.1b20181018 on an AMD Ryzen 1950X and unit
tests are passing.
Is this build using AVX512? in /proc/cpuinfo I see only "avx" flag.
There's no "avx2" like on recent intel cpus.
Pedro.
On Fri, Oct 19, 2018 at 5:12 PM Hagay Lupesko wrote:
> Awesome collaborative
t; > making the change I see more potential risk than obvious benefits. I
> > also
> > > feel that this change will make the difference between the runtime
> docker
> > > files and the CI docker files less clear to users, not more clear. In
> > > ge
Very nice!
Pedro
> On 17. Oct 2018, at 23:12, Alfredo Luque
> wrote:
>
> This is huge. Thanks for working on this. Is there a similar plan with eg;
> tensor-rt support being ported into the main cuda-9.x packages?
>
> On October 17, 2018 at 2:10:20 PM, Alex Zai (aza...@gmail.com) wrote:
>
Do nightly artifacts need to be signed? For releases what you wrote and what
Apache recommends makes total sense. Thus artifacts from cd can’t be signed
manually.
Pedro
> On 17. Oct 2018, at 22:29, Naveen Swamy wrote:
>
> I am collaborating with Zach Kimberg and Qing to work on automatic (
>
lightweight and suited to their task
> as possible.
>
> On Wed, Oct 17, 2018, 1:58 AM Hagay Lupesko wrote:
>
> > The PR provides a good explanation of this change and all code updates.
> > LGTM.
> >
> > On Tue, Oct 16, 2018 at 8:41 AM Pedro Larroy <
> pedr
To play around we use the java api branch? is there a link to some example
code?
Thanks.
On Fri, Oct 12, 2018 at 9:16 PM Davydenko, Denis <
dzianis.davydze...@gmail.com> wrote:
> Not so long ago there was a design shared for MXNet Java API: [1]
>
> In a couple of days we are going to have
XNET/Reproducing+test+results
But seems not many people read it, also it doesn't solve provisioning the
instance and installing the initial dependencies.
Pedro.
On Mon, Oct 15, 2018 at 8:58 PM Naveen Swamy wrote:
> Timur,
> Here is a meetup Scheduled for 23rd October in London, where Pe
Hi
I would like to rename the dockerfiles since they are used as a runtime
environment and not only as build as they were initially intended.
More info about the change in this PR:
https://github.com/apache/incubator-mxnet/pull/12423/files
Pedro.
our guidance if the assessment should be
> discussed further within PPMC, on private@ and next steps.
>
> Steffen
>
> On Fri, Sep 28, 2018 at 1:53 PM Pedro Larroy >
> wrote:
>
> > So Isabel, are you saying that if we publish a clearer TODO list or
> > contribution
So - Does the regular merge seem like a good
> option?
> > > > > > > >> > >> > > If so, what is the best way to make that happen?
> > > > > > > >> > >> > >
> > > > > > > >> > >>
+1
@Chris: do you have data on the performance difference? As far as I know
there's a "rewrite rule" like the one between lambdas and C++ functors, so
performance should be very well defined, but maybe there's something that
you are point out that we are missing.
Having a consistent and concise
ugh. The PR that introduced that test
> is https://github.com/apache/incubator-mxnet/pull/10921 - it was merged
> two
> days ago.
>
> Best regards,
> Marco
>
> On Tue, Oct 2, 2018 at 8:43 AM Pedro Larroy
> wrote:
>
> > Thanks for checking Lin. If it happens again we wil
I think there's two approaches that we can take to mitigate the build &
test time problem, in one hand use a paid travis CI plan, in other improve
the unit tests in suites and only run a core set of tests, as we should do
on devices, but on this case we reduce coverage.
Hi
I saw this failure on CI:
http://jenkins.mxnet-ci.amazon-ml.com/blue/organizations/jenkins/incubator-mxnet/detail/master/1697/pipeline
Have you seen other cases where we fail to select the best CUDNN algorithm?
In which circumstances this could happen, and do you think is a good idea
to have
So Isabel, are you saying that if we publish a clearer TODO list or
contributions needed material we might get more contribution there?
One thing that I like from other projects is to make a list of low-hanging
fruit issues or easy contributions that newcomers can pick to get familiar
with the
I'm not familiar with the specifics of this contribution, as a general
approach my understanding is that if the list of commits is big and you
want to preserve history, usually merging is better so you keep history and
causality, if you rebase all the commits on top of master you are changing
the
Hi Naveen
Great document. I spent some time understanding your proposal and I check
the linked talk on youtube from Boehm.
The topic is complex and the solution needs to be well thought, and seems
the document reflects that.
1- One thing that was not clear to me from the document is that, if
Hi Sheng
This is an open bug in Jenkins:
https://issues.jenkins-ci.org/browse/JENKINS-37984
Anybody that has some bandwidth can contribute a fix for Jenkins. A
mitigation could be to reduce the size of the main pipeline which can be
done in a PR.
A fix for this could take a while.
Pedro.
On
Hi
I think we should explicitly define march to be x86-64 (which is the
default in Linux) and documented here:
https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html
We can then also remove -msse2 which is enabled by default.
piotr@ip-172-31-30-23:0:~/qemu (master)+$ echo "" | gcc -v -E - 2>&1 |
Nice! Will this be broadcasted via Chime or other medium?
On Wed, Aug 1, 2018 at 5:55 PM Steffen Rochel
wrote:
> I just updated the agenda for the meetup in Seattle on August 16th 2018.
> https://www.meetup.com/Apache-MXNet-Seattle-meetup/events/253104242/
> We will have two tutorials:
> (1)
hanks for supporting Windows build in here.
>
> Thanks,
> Qing
>
> On 8/2/18, 10:08 AM, "Marco de Abreu"
>
> wrote:
>
> Hello Pedro,
>
> These are great efforts! It's great to see that we are improving
> our
> situati
Yes, we can do something fun for these errors, something maybe with a cat
an a DL theme, or some funny style transfer stuff.
Pedro
On Thu, Aug 2, 2018 at 11:54 PM Aaron Markham
wrote:
> Hi everyone,
> I would like to suggest that we adopt a custom landing page for missing
> pages, rather than
.
>
> -Marco
>
> Pedro Larroy schrieb am Do., 2. Aug. 2018,
> 18:42:
>
> > Agree with Marco, there's a lot of stuff unrelated to MXNet. And right
> now
> > we have good separation of concerns via the dockerized builds and
> > ci/build.py infrastructure.
>
Hi
I have taken some effort to cleanup the Windows build process and condense
it in a single python script, provided that the required dependencies are
installed (opencv, openblas and cuda/cudnn in gpu).
Now there's a single command necessary to get a build:
python ci\build_windows.py
The
How was it? I actually missed it while trying to get code in for the
release.
On Wed, Aug 1, 2018 at 5:47 PM Steffen Rochel
wrote:
> Hi - it looks there has been confusion about the hangout scheduled for
> today. I was on the 8am PDT call and chatted with Marco.
> I will be on the call today
en CI updates
> > are required), is it going to be inside 3rd party module, versions of
> > dependencies in tools should match with other resources in repo ex:
> > setup.py etc.
> >
> > Why not under mxnet repo a CI / tools / infra folder and all this tools
> go
> &
Hi Carl
This is great, I like a lot the design for the tool. I think it will
prevent addition of flaky tests once is implemented.
I don't have major concerns with the design, please keep us updated with
PRs about this tool.
Thanks!
Pedro.
On Tue, Jul 31, 2018 at 3:01 AM Carl Tsai wrote:
>
I like tools more.
On Wed, Aug 1, 2018 at 11:05 AM Marco de Abreu
wrote:
> Hi,
>
> definitely a good point, Isabel. During our office hour we thought about
> creating a repository under the Apache account with a name like
> incubator-mxnet-tools or incubator-mxnet-infrastructure. Does anybody
Hi Hagay
We are aware of this and we are working in this direction which as you
point out, is more desirable.
There's a huge amount of non-trivial work that has gone into building these
distribution packages from Sheng which needs to be adapted for our CI
system, and taken into consideration.
...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
TRUE;CN=dev@mxnet.incubator.apache.org;X-NUM-GUESTS=0:mailto:d...@mxnet.incu
bator.apache.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
;CN=Pedro Larroy;X-NUM-GUESTS=0
...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=de
v...@mxnet.incubator.apache.org;X-NUM-GUESTS=0:mailto:d...@mxnet.incubator.apac
he.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;CN=Pedro
Larroy;X-NUM-GUESTS=0:mailto:pedro.larroy.li
...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
TRUE;CN=dev@mxnet.incubator.apache.org;X-NUM-GUESTS=0:mailto:d...@mxnet.incu
bator.apache.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
;CN=Pedro Larroy;X-NUM-GUESTS=0
I would like to get these PR merged:
https://github.com/apache/incubator-mxnet/pull/11636
https://github.com/apache/incubator-mxnet/pull/11562
How much longer until the code freeze?
On Thu, Jul 26, 2018 at 1:44 AM Roshani Nagmote
wrote:
> Hi all,
>
> PRs waiting to be merged for 1.3 release:
...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
TRUE;CN=dev@mxnet.incubator.apache.org;X-NUM-GUESTS=0:mailto:d...@mxnet.incu
bator.apache.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
;CN=Pedro Larroy;X-NUM-GUESTS=0
...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
TRUE;CN=dev@mxnet.incubator.apache.org;X-NUM-GUESTS=0:mailto:d...@mxnet.incu
bator.apache.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
;CN=Pedro Larroy;X-NUM-GUESTS=0
...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=de
v...@mxnet.incubator.apache.org;X-NUM-GUESTS=0:mailto:d...@mxnet.incubator.apac
he.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;CN=Pedro
Larroy;X-NUM-GUESTS=0:mailto:pedro.larroy.li
...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
;CN=dev@mxnet.incubator.apache.org;X-NUM-GUESTS=0:mailto:dev@mxnet.incubato
r.apache.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
;CN=Pedro Larroy;X-NUM-GUESTS=0
...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
TRUE;CN=dev@mxnet.incubator.apache.org;X-NUM-GUESTS=0:mailto:d...@mxnet.incu
bator.apache.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
;CN=Pedro Larroy;X-NUM-GUESTS=0
Yes Naveen, I think you are saying exactly the same as I hinted. Sheng also
agreed with this.
Pedro.
On Thu, Jul 19, 2018 at 6:54 PM Naveen Swamy wrote:
> I do not think there needs to be a distinction made for
> support/office-hours by committer or contributors(in this case Amazon
> employed
Have you guys tried CLion, works like a charm for me. (Requires license).
On Wed, Jul 18, 2018 at 10:09 PM Naveen Swamy wrote:
> Thanks Sandeep for putting this together, it would make it easy for people
> who prefer to IDEs to get started with MXNet easily.
>
> On Wed, Jul 18, 2018 at 1:04 PM,
There's an MXNet comitter in our office hours (Marco de Abreu @marcoabreu),
others are contributors such as Anton (@lebeg) or others. I think we could
refocus the conversation to the point that the office hours might have some
emphasis in a particular area of MXNet.
On Thu, Jul 19, 2018 at 6:21
BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20180802T12Z
DTEND:20180802T13Z
DTSTAMP:20180719T164141Z
ORGANIZER;CN=Pedro Larroy:mailto:pedro.larroy.li...@gmail.com
...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
TRUE;CN=dev@mxnet.incubator.apache.org;X-NUM-GUESTS=0:mailto:d...@mxnet.incu
bator.apache.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
;CN=Pedro Larroy;X-NUM-GUESTS=0
-1 It's a lot of traffic, whomever wants to subscribe can do it in
github. I'm afraid it will decrease signal to noise ratio in the list.
On Thu, Jul 12, 2018 at 11:32 PM Lin Yuan wrote:
> +1
>
> On Thu, Jul 12, 2018 at 12:26 PM Anirudh Acharya
> wrote:
>
> > +1
> >
> > On Thu, Jul 12, 2018
This is a great discussion, thanks for raising the question Naveen.
>From my experience working in all kinds of software project of varying
sizes and flavours:
1. People should be aware of git rebase interactive and have more
hygiene in their PRs. If a PR is hygienic and is separated in a
Hi
I would like to know your opinion in regards to deprecating and removing
Python 2. Maybe for MXNet 2.0 ?
What's the reason to have support for Python2?
Pedro.
Agree with Sheng. Not always a website has trusted SSL cert, and you might
still want to download cat and elephant pictures from it. (I checked some
usages of this function).
On Wed, Jul 4, 2018 at 9:47 AM Marco de Abreu
wrote:
> Thanks for raising this issue Sheng.
>
> My proposal would be to
Hi
Could we cleanup some of the branches on the main repo? the devel-arm and
devel-android are not needed.
Maybe there's something I'm not aware, but what is the policy with the
other branches? should in the main repo only be release branches so we
don't confuse users?
Pedro.
Marco
>
> Marco de Abreu schrieb am So., 1. Juli
> 2018,
> 11:57:
>
> > I'm on it.
> >
> > Pedro Larroy schrieb am So., 1. Juli
> 2018,
> > 09:03:
> >
> >> Hi
> >>
> >> Master is not building due to RAT license check on the clojure package.
> Is
> >> anyone having a look at this?
> >>
> >> Pedro.
> >>
> >
>
other info is provided. Link
> > to your info from the contribute page that's under community.
> >
> > Ping me if you need help.
> >
> > Sent from VMware Boxer
> >
> > On Jun 25, 2018 19:17, Pedro Larroy
> wrote:
> > Hi
> >
>
gt; Thanks everyone for your feedback and efforts with the Clojure
> package
> > PR.
> > > >
> > > > I'm delighted to join the MXNet community and work with you all and
> am
> > > > excited to invite the Clojure community to grow with it :)
> > >
Hi
Master is not building due to RAT license check on the clojure package. Is
anyone having a look at this?
Pedro.
Yes, great work Carin! I even saw your book on Clojure autographed.
Pedro.
On Wed, Jun 27, 2018 at 7:24 PM Naveen Swamy wrote:
> Hi All,
>
> Carin (https://github.com/gigasquid) has done a worked on a Clojure MXNet
> package for the Clojure community, Thank you Carin.
>
> I would like to merge
Am I doing something wrong? When my PRs get merged, JIRA issues don't get
closed:
https://issues.apache.org/jira/browse/MXNET-460
@YiZhi Liu: as per PR instructions, a JIRA ticket is not required for minor
patches, only for things that you would include in release notes.
Pedro.
On Thu, Jun 28,
Hi
I want to add a section on how to develop MXNet itself to attract
contributors. Would this be acceptable for the website?
Is there any recommended workflow for this? Any tools?
is it going into docs and `make html` or something else?
Thanks.
Pedro
Nice design document. From where does it come the default value
of MXNET_KVSTORE_GPUARRAY_BOUND of 10M?
Do you generate a tree for each GPU?
Pedro.
On Mon, Jun 18, 2018 at 2:30 PM Carl Yang wrote:
> Hi,
>
> Currently, we have two methods for single-machine communication:
> parameter server
github.com/apache/incubator-mxnet/issues/11091> . Now
> pulling
> > > > this
> > > > change for the cmake fix would be also mean we need to pull 8 more
> > > commits
> > > > from dmlc-core and its considerable risk to introduce for the p
:
> Thank you Pedro. But this would still crash the nosetests process and thus
> prevent the summary from being created, right?
>
> On Thu, Jun 21, 2018 at 11:14 PM Pedro Larroy <
> pedro.larroy.li...@gmail.com>
> wrote:
>
> > A crash in the library is not an
fix the main
> > issue, we should move ahead here.
> > I missed reviewing all the known issue of 1.2.0 and add it to 1.2.1
> release
> > notes. I will do that now.
> >
> > Anirudh
> >
> >
> >
> > On Thu, Jun 21, 2018 at 10:42 AM, Pedro Larroy <
A crash in the library is not an error in the test, is a different
situation.
I suggest adding these flags to get stack traces and addressing the crash
as a separate bug.
https://github.com/larroy/mxnet/commit/46389e5851a60d06c37755e5772e6cbcd71b0080
Check the return code when executing the
t without it.
> I opened an issue here some time back:
> https://github.com/apache/incubator-mxnet/issues/10856
>
> Anirudh
>
> On Thu, Jun 21, 2018 at 12:16 PM, Pedro Larroy <
> pedro.larroy.li...@gmail.com
> > wrote:
>
> > Got it. Sorry to bring this up, and t
Agree with Anirudh, they are different things. Maybe change the "C++" label
to "backend" would be more informative?
On Thu, Jun 21, 2018 at 12:11 PM Anirudh wrote:
> Hi Hagay,
>
> I think we should keep these two labels seperate since they mean different
> things.
> The C++ label refers to the
n the interest of our
> customers who are eagerly waiting for the patch release to fix the main
> issue, we should move ahead here.
> I missed reviewing all the known issue of 1.2.0 and add it to 1.2.1 release
> notes. I will do that now.
>
> Anirudh
>
>
>
> On Thu, Jun
I think I have fixed this before, I will check if the patch didn't make it
to the branch.
On Thu, Jun 21, 2018 at 10:24 AM Pedro Larroy
wrote:
> -1 I can't compile:
>
> 3rdparty/dmlc-core/libdmlc.a(io.cc.o): In function
> `std::thread::thread::Init(std::function (dmlc::io::In
Welcome Jim. Great to have you in the project.
On Mon, Jun 18, 2018 at 10:51 PM Steffen Rochel
wrote:
> Welcome Jim, appreciating your support.
> Steffen
>
> On Mon, Jun 18, 2018 at 3:14 PM Naveen Swamy wrote:
>
> > Hi All,
> >
> > I am excited to announce that we have an additional mentor
I agree with Tianqi, Eric and others. We shouldn't dilute the community
with another forum. Disqus is already working and has healthy
participation, you can get an email digest if you so desire. Subscribing to
a mailing list to get a question answered is quite a heavyweight investment
for many
Hi Sebastian.
Thank you for your comment. That's why I said "I would propose", because I
don't know if it's possible as my experience with Apache is limited to the
MXNet project.
How do you interpret this part?: "Since the appointed Project Management
Committees have the power to create their
Great points and feedback.
I think everyone here wants the best for the project. We should definitely
not shoot down pioneering contributions and be more inclusive with people
that are actively contributing to the community with not just code. This
should include code, documentation, website
Hi
We have this url alive, and google is indexing:
http://mxnet.incubator.apache.org/test/versions/
Is this url right, or is it pointing some users to the wrong documentation?
Pedro
ure to merge from apache/master and not larroy/master
> if you have conflicts? Not sure why you got these conflicts otherwise.
>
> All the best,
>
> Thomas
>
> 2018-06-12 23:39 GMT-07:00 Pedro Larroy :
>
> > Thanks a lot for creating these branches and proposing the idea,
Thanks, we are in sync and will find a solution next week.
On Wed, Jun 13, 2018 at 4:54 PM Marco de Abreu
wrote:
> I think Sheng manages the publishing to PyPi and we should be fine with
> just adding it as another flavour.
>
> -Marco
>
> On Wed, Jun 13, 2018 at 6:36 AM Pedro
> >
> > >> > > If a test fails in nightly, the commit would not be reverted since
> > >> it's
> > >> > > hard to pin a failure to a specific PR. We will have reporting for
> > >> > failures
> > >> > > on nightly (the
Thanks a lot for creating these branches and proposing the idea, for the
reasons you listed.
We tried during this week to work with these branches with @lebeg for
Android and Arm support, for the reasons listed below these branches are
not useful for us, so you can delete them.
1. We don't
* I personally don't like the idea that comittership status is decided in a
closed mail list. This is not the transparency level that I would expect in
an open source project. I'm happy to receive feedback from others that
might be opposed to my application for committer to know what things could
Hi Team
The time to validate a PR is growing, due to our number of supported
platforms and increased time spent in testing and running models. We are
at approximately 3h for a full successful run.
This is compounded with the failure rate of builds due to flaky tests of
more than 50% which is a
> > > > >
> > > > > What I can say for now that this failure is not deterministic (on
> > > RPi's)
> > > > > and the library import to python passes in 1 of 4 times. The
> creation
> > > of
> > > > > NDArray's in this case fails though in
way to interop on the JVM between languages.
> There is no pure Java API at the moment that I am aware of.
>
> On Wed, Jun 6, 2018 at 5:54 AM, Pedro Larroy >
> wrote:
>
> > Hi
> >
> > These Java classes that the document refers to, where are they located?
> Do
Hi Aaron
This is great! what about including social feed like MXNet twitter or
medium on the home page as well?
I also miss a quick install instruction like other frameworks have in a
high visibility place, so there's less friction to try the framework. I
think current install instructions are
Nice! I have seen these called "low hanging fruits" we could link them in
the instructions to contribute.
On Wed, May 30, 2018 at 3:36 AM, sandeep krishnamurthy <
sandeep.krishn...@gmail.com> wrote:
> Awesome!
>
> On Tue, May 29, 2018, 6:03 PM Aaron Markham
> wrote:
>
> > Just wanted to bring
Hi
These Java classes that the document refers to, where are they located? Do
we have a Java API atm? The origin of my question is that for android I
think we need a Java API.
Pedro.
On Tue, Jun 5, 2018 at 5:40 PM, Carin Meier wrote:
> Thanks everyone. I'll work on getting together a PR with
t to python passes in 1 of 4 times. The creation of
> NDArray's in this case fails though in all cases with similar message that
> the stack is corrupted.
>
> Will update on findings.
>
> -- Anton
>
>
> 2018-06-05 16:19 GMT+02:00 Pedro Larroy :
>
> > Could y
Could you compile with debug symbols or get a core file? From this output
is not clear why the crash is happening.
On Sun, May 27, 2018 at 10:04 AM, Naveen Swamy wrote:
> Hi,
> I am working to publish MXNet-Scala package to maven and encountering an
> issue when trying to build with
Hi team.
Flaky test failures are impacting PR validation and hindering contributions
to MXNet.
We should prioritize dealing with these failing tests.
See recent failures on master:
http://jenkins.mxnet-ci.amazon-ml.com/job/incubator-mxnet/job/master/
The biggest offenders right now:
It would be great if we could improve the documentation of building with
MKL? Whenever I have done this it took quite some effort to get it right,
also add the different MKL related libraries.
there's also duplicated scripts:
./3rdparty/mkldnn/scripts/prepare_mkl.bat
/5/thread:137: undefined reference to `pthread_create'
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
Can we update dmlc-core on the release branch? this was recently fixed:
https://github.com/dmlc/dmlc-core/commit/b744643f386660ddc39467a04e3a98853a7419b9
On
t; >
> > > > I agree with Anirudh that the focus of the discussion should be
> limited
> > > to
> > > > the release branch, not the master branch. Anything that breaks on
> > master
> > > > but works on release branch should not block th
ng all of the flaky tests which would delay
> the release by considerable amount of time.
> Or is it something else ?
>
> Anirudh
>
>
> On Fri, May 4, 2018 at 4:49 AM, Pedro Larroy <pedro.larroy.li...@gmail.com
> >
> wrote:
>
> > Could you remove the fixe
e the tests and the CI. I have seen the PR builds are
> >> non-deterministic and you have to retry over and over (wasting resources
> >> and time) and hope you get lucky.
> >>
> >> Look at the dashboard for master build
> >> http://jenkins.mxnet-ci.amaz
gt;
> > Look at the dashboard for master build
> > http://jenkins.mxnet-ci.amazon-ml.com/job/incubator-mxnet/job/master/
> >
> > -Naveen
> >
> > On Thu, May 3, 2018 at 5:11 AM, Pedro Larroy <
> pedro.larroy.li...@gmail.com
> > >
> > wrote:
>
: Command '['docker', 'build', '-f',
> 'docker/Dockerfile.build.ubuntu_cpu', '--build-arg', 'USER_ID=1000',
> '-t', 'mxnet/build.ubuntu_cpu', 'docker']' returned non-zero exit status 2
>
>
> On 5/3/18, 8:01 AM, "Pedro Larroy" <pedro.larroy.li...@gmail.com> wrote:
>
>
201 - 300 of 390 matches
Mail list logo
