Downloads fine for me @ssc, I am on a horribly slow wifi connection on a
Trans-Atlantic flight - it worked for me.
On Sat, Oct 21, 2017 at 1:37 AM, Meghna Baijal
wrote:
> I verified again, on an ubuntu instance this time. Worked without the ‘g’
>
> sha512sum --check ./apache-mxnet-src-0.12.0.rc
I verified again, on an ubuntu instance this time. Worked without the ‘g’
sha512sum --check ./apache-mxnet-src-0.12.0.rc0-incubating.tar.gz.sha512
On Fri, Oct 20, 2017 at 10:16 PM, Sebastian wrote:
> Hmm, still doesn't work. Looks like the download of
> https://dist.apache.org/repos/dist/dev/i
Hmm, still doesn't work. Looks like the download of
https://dist.apache.org/repos/dist/dev/incubator/mxnet/0.12.0.rc0
/apache-mxnet-src-0.12.0.rc0-incubating.tar.gz.sha512 has some problems
on my machine, I can't view the file contents, maybe a problem with the
content-type?
On 21.10.2017 07:
Hi Sebastian,
Can you try the following:
gsha512sum --check ./apache-mxnet-src-0.12.0.rc0-incubating.tar.gz.sha512
This worked for me.
Thanks,
Meghna Baijal
On Oct 20, 2017 9:53 PM, "Sebastian" wrote:
Verifying the sha512 sig didn't work for me, what am I doing wrong here?
sha512sum -c apache
Verifying the sha512 sig didn't work for me, what am I doing wrong here?
sha512sum -c apache-mxnet-src-0.12.0.rc0-incubating.tar.gz.sha512
sha512sum: apache-mxnet-src-0.12.0.rc0-incubating.tar.gz.sha512: no
properly formatted SHA512 checksum lines found
On 21.10.2017 02:36, Suneel Marthi wrote
Hello All,
Jenkins CI seems to be stable. If your build was terminated by someone over
the last couple of days, you can trigger it now by pushing an empty commit
to the same branch or manually in Jenkins if you have access.
Thanks,
Meghna Baijal
On Thu, Oct 19, 2017 at 12:04 PM, Chris Olivier
wr
Ok, just looking for anything that can cut a task out if possible. I do
support not using Apache Jenkins server anyMore — it’s really not been
working out for various reasons. But having a person full time is
something that Steffen would have to address, I imagine.
On Fri, Oct 20, 2017 at 6:03 PM
I didn't see the clear advantage of CodePipline over pure jenkins, because
we don't need to deploy here.
On Fri, Oct 20, 2017 at 5:34 PM, Chris Olivier
wrote:
> CodePipeline, then. You can point it to Jenkins instances.
>
>
> On Fri, Oct 20, 2017 at 4:49 PM Mu Li wrote:
>
> > AWS CodeBuild is
+1
On Fri, Oct 20, 2017, 5:01 PM Meghna Baijal
wrote:
> This is the vote to release Apache MXNet (incubating) version 0.12.0.
>
> Voting will start now (Friday, October 20, 2017 11:55PM UTC) and
>
> close Tuesday, October 24, 2017 11:55PM UTC.
>
>
> Link to release notes:
>
>
> https://cwiki.ap
+1 binding
1. Checked Sigs and hashes
2. has -incubating in artifact name
On Fri, Oct 20, 2017 at 8:34 PM, Chris Olivier
wrote:
> +1
>
>
> On Fri, Oct 20, 2017 at 5:01 PM Meghna Baijal
> wrote:
>
> > This is the vote to release Apache MXNet (incubating) version 0.12.0.
> >
> > Voting will sta
+1
On Fri, Oct 20, 2017 at 5:01 PM Meghna Baijal
wrote:
> This is the vote to release Apache MXNet (incubating) version 0.12.0.
>
> Voting will start now (Friday, October 20, 2017 11:55PM UTC) and
>
> close Tuesday, October 24, 2017 11:55PM UTC.
>
>
> Link to release notes:
>
>
> https://cwiki.
CodePipeline, then. You can point it to Jenkins instances.
On Fri, Oct 20, 2017 at 4:49 PM Mu Li wrote:
> AWS CodeBuild is not an option. It doesn't support GPU instances, mac os x,
> and windows. Not even mention the edge devices.
>
> On Fri, Oct 20, 2017 at 4:07 PM, Chris Olivier
> wrote:
>
This is the vote to release Apache MXNet (incubating) version 0.12.0.
Voting will start now (Friday, October 20, 2017 11:55PM UTC) and
close Tuesday, October 24, 2017 11:55PM UTC.
Link to release notes:
https://cwiki.apache.org/confluence/display/MXNET/MXNet+0.12.0+Release+Notes
Link to rele
AWS CodeBuild is not an option. It doesn't support GPU instances, mac os x,
and windows. Not even mention the edge devices.
On Fri, Oct 20, 2017 at 4:07 PM, Chris Olivier
wrote:
> Why don;t we look into fully managed AWS CodeBuild? It maintains
> everything. It's also compatible with Jenkins.
>
Sorry, posting to the correct thread: https://imgur.com/a/aADkA
On Fri, Oct 20, 2017 at 4:06 PM, Chris Olivier
wrote:
> Can you resend the link? One below doesn't work for me.
>
> On Fri, Oct 20, 2017 at 1:02 PM, sandeep krishnamurthy <
> sandeep.krishn...@gmail.com> wrote:
>
> > Looks nice. Rab
I believe that Mu already started that discussion about using old mxnet.io
Jenkins server. I expect deciding whether to replace would hinge in large
part upon what it would be replaced with.
On Fri, Oct 20, 2017 at 4:30 PM, sandeep krishnamurthy <
sandeep.krishn...@gmail.com> wrote:
> Chris: If
Chris: If the community decides to go with separate setup, then there will
be a tech design discussion and CodeCommit / Jenkins / Travis such
proposals will be covered and discussed.
Thanks,
Sandeep
On Fri, Oct 20, 2017 at 4:22 PM, Seb Kiureghian wrote:
> But the feather can definitely be added
But the feather can definitely be added once MXNet graduates.
On Fri, Oct 20, 2017 at 4:21 PM, Seb Kiureghian wrote:
> The feather can only be used by Top Level Projects.
>
> On Fri, Oct 20, 2017 at 4:19 PM, Chris Olivier
> wrote:
>
>> When the word Apache is in the Hadoop logo (not always), it
The feather can only be used by Top Level Projects.
On Fri, Oct 20, 2017 at 4:19 PM, Chris Olivier
wrote:
> When the word Apache is in the Hadoop logo (not always), it includes the
> feather and color scheme.
>
> On Fri, Oct 20, 2017 at 4:18 PM, Chris Olivier
> wrote:
>
>> Thanks.
>>
>> Is ther
When the word Apache is in the Hadoop logo (not always), it includes the
feather and color scheme.
On Fri, Oct 20, 2017 at 4:18 PM, Chris Olivier
wrote:
> Thanks.
>
> Is there any way to work the feather into it?
>
> i.e. https://goo.gl/images/BU4dnG
>
> On Fri, Oct 20, 2017 at 4:11 PM, Seb Kiu
Thanks.
Is there any way to work the feather into it?
i.e. https://goo.gl/images/BU4dnG
On Fri, Oct 20, 2017 at 4:11 PM, Seb Kiureghian wrote:
> https://imgur.com/a/aADkA
>
> On Fri, Oct 20, 2017 at 4:07 PM, Chris Olivier
> wrote:
>
> > Why don;t we look into fully managed AWS CodeBuild? It
https://imgur.com/a/aADkA
On Fri, Oct 20, 2017 at 4:07 PM, Chris Olivier
wrote:
> Why don;t we look into fully managed AWS CodeBuild? It maintains
> everything. It's also compatible with Jenkins.
>
> On Fri, Oct 20, 2017 at 1:51 PM, Tianqi Chen
> wrote:
>
> > +1
> >
> > Tianqi
> > On Fri, Oct
Why don;t we look into fully managed AWS CodeBuild? It maintains
everything. It's also compatible with Jenkins.
On Fri, Oct 20, 2017 at 1:51 PM, Tianqi Chen
wrote:
> +1
>
> Tianqi
> On Fri, Oct 20, 2017 at 1:39 PM Mu Li wrote:
>
> > +1
> >
> >
> > It seems that the Apache CI is quite overloade
Can you resend the link? One below doesn't work for me.
On Fri, Oct 20, 2017 at 1:02 PM, sandeep krishnamurthy <
sandeep.krishn...@gmail.com> wrote:
> Looks nice. Rabbit :-)
> +1
>
>
> On Fri, Oct 20, 2017 at 11:02 AM, Seb Kiureghian
> wrote:
>
> > Can we start a vote on the logo?
> >
> > __
I can create the same logo in white so it will fit with the /master website.
Longer term, I think the site could use another redesign. The blue
background makes it difficult to read text on the homepage.
On Fri, Oct 20, 2017 at 2:03 PM, Mu Li wrote:
> Clearly better than the previous logos we
Clearly better than the previous logos we had. One concern is that the logo
color is inconsistent with the current doc theme:
https://mxnet.incubator.apache.org/versions/master/index.html. We need to
change either the logo or the doc theme.
On Fri, Oct 20, 2017 at 1:02 PM, sandeep krishnamurthy <
+1
Tianqi
On Fri, Oct 20, 2017 at 1:39 PM Mu Li wrote:
> +1
>
>
> It seems that the Apache CI is quite overloaded these days, and MXNet's CI
> pipeline is too complex to run there. In addition, we may need to add more
> devices, e.g. macpro and rasbperry pi, into the server, and more tasks such
+1
It seems that the Apache CI is quite overloaded these days, and MXNet's CI
pipeline is too complex to run there. In addition, we may need to add more
devices, e.g. macpro and rasbperry pi, into the server, and more tasks such
as pip build. It means a lot of requests to the Infra team.
We can
Looks nice. Rabbit :-)
+1
On Fri, Oct 20, 2017 at 11:02 AM, Seb Kiureghian wrote:
> Can we start a vote on the logo?
>
>
> From: Lupesko, Hagay
> Sent: Monday, October 2, 2017 12:08:49 AM
> To: dev@mxnet.incubator.apache.org; Madan Jampani; sebou...@gmail.com
>
Hello all,
I am hereby opening up a discussion thread on how we can stabilize Apache
MXNet CI build system.
Problems:
Recently, we have seen following issues with Apache MXNet CI build systems:
1. Apache Jenkins master is overloaded and we see issues like - unable
to trigger bui
Can we start a vote on the logo?
From: Lupesko, Hagay
Sent: Monday, October 2, 2017 12:08:49 AM
To: dev@mxnet.incubator.apache.org; Madan Jampani; sebou...@gmail.com
Subject: Re: New Apache MXNet logo idea
Like it!
It’s cute, fun and playful. For me it also assoc
Please subscribe me to Mxnet slack channel. Thx
Currently, it hasn't. We'll add soon.
2017-10-20 17:43 GMT+08:00 TongKe Xue :
> Hi!
>
> [I'm referring to the Scala API]
>
> 1. mxnet symbol has auto diff:
> https://mxnet.incubator.apache.org/tutorials/r/symbol.html
>
> 2. from Googling around, I can't find NDArray auto diff anywhere
>
>
As with every change, there need to be steps. The python API of gluon is a
first step toward moving API to the set of the new operator. I think
exchange and compilation are next step it is relatively easy to do so
without start implementing these ops (we canonicalize to core ops and
convert them ba
The core ops do not mean implementation. They are merely a spec that we
want to agree on what attributes we need.
- The current list of the proposal spec is here:
http://nnvm.tvmlang.org/top.html (I think eventually MXNet's document
should have one such page)
- They are is modeled after numpy and
Thansk for that explanation!
What is meant by the "core ops"? Are these the gluon python ops? I know
what the "legacy ops" are -- things like BatchNormProp/BatchNormOp. WHat
are the "new ones"?
I apologize for not knowing this, but what are some of the "pain points"
with the legacy ops? Not in
The major concern is engineering overhead. The exchange formats are not
serialization format like json. So we need to do the conversion back and
force, and there are quite a lot of caveat there. The existing ones like
onnx is also evolving very fast and there is no backward compatibility so
far.
I
First of all, I agree that supporting the format as an important step of
adding influence. We are going to do it in either options. The overhead of
engineering is not that much difference. I also do not argue for specific
types of APIs(gluon vs symbolic) we should use.
MXNet Sym API contains two
I am not implementing it, but I prefer C++ for this reason. But then
again, I am biased towards C++ in general :)
Are there reasons to not do it in C++? Maybe there are...
On Fri, Oct 20, 2017 at 8:08 AM, Tianqi Chen
wrote:
> I do not have a preference in terms of specifically having to do thi
I do not have a preference in terms of specifically having to do this in
particular language, and merely mean python would be an easier path. Most
other languages users can still get onnx model to mxnet's format(with a
script) and load it from there.
Tianqi
On Fri, Oct 20, 2017 at 8:06 AM, Chris
How would this impact use by other languages such as Scala, Perl, C++, etc?
On Fri, Oct 20, 2017 at 8:01 AM, Tianqi Chen
wrote:
> Given the instability nature of the current status of onnx, and the ease of
> development, python would be favorable as the initial choice
>
> On Fri, Oct 20, 2017 at
Given the instability nature of the current status of onnx, and the ease of
development, python would be favorable as the initial choice
On Fri, Oct 20, 2017 at 8:00 AM, Chris Olivier
wrote:
> Also, what language is the expectation here? Is the ONNX serialization to
> be developed in the C++ la
Also, what language is the expectation here? Is the ONNX serialization to
be developed in the C++ layer or python? Seems like what I saw before was
python.
On Fri, Oct 20, 2017 at 1:05 AM, Lupesko, Hagay wrote:
> Tianqi,
>
> “I would want the code to be in the repo as long as we reach the
> co
Hi!
[I'm referring to the Scala API]
1. mxnet symbol has auto diff:
https://mxnet.incubator.apache.org/tutorials/r/symbol.html
2. from Googling around, I can't find NDArray auto diff anywhere
3. however, NDArray tracks dependencies -- which, in theory, should
be enough for doing autodif
Tianqi,
“I would want the code to be in the repo as long as we reach the consensus.”
+1
“The reason why I am seeing this decision so seriously is that it will affect
how we can influence the design of the exchange format we act on”
IMO, the most important first thing to do in order to influence
45 matches
Mail list logo
