I made a test regular merge commit into a copy of master. It seemed to go
fine. Here is a listing of what it will look like for everyone.
https://github.com/apache/incubator-mxnet/commits/test-merge-julia-import
Although, I would be happy to push the merge button. I think the most
important
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
Pedro - Maybe a merge commit is a better answer in this case. I originally
ruled it out since it wasn't an option in the github web interface, but
since this looks like it is going to have to be done outside it because of
the subtrees anyway, it might be a better fit.
On Fri, Sep 28, 2018 at 5:07
Should we try to first being into a branch and then try merge that branch?
> On Sep 28, 2018, at 4:40 PM, Pedro Larroy
> wrote:
>
> 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
We are actually running into troubles with using the subtree and the
rebase. Since it looks like this is not going to be a simple, "click the
button" through the web page merge, I rather hand this task off to someone
with more context in making sure it gets in there correctly.
Chiyuan or any
Agreed with Pedro. Maybe the merge-commit option from the github interface
was disabled for a reason. But as Pedro said, maybe it is good to
temporarily enable it for this PR and merge using that.
- It should be technically easier than rebasing due to the
git-subtree-import issue we are
ok then, my vote is still -1, however, because it’s just adding needless
friction for developers imho.
On Fri, Sep 28, 2018 at 7:42 AM kellen sunderland <
kellen.sunderl...@gmail.com> wrote:
> "Range loops aren’t always the most performant way" Do you have an example
> where there's a perf
I updated
https://cwiki.apache.org/confluence/display/MXNET/Project+Proposals+for+next+MXNet+Release,
removed the completed items from 1.3 release and would like to kick off
discussion about the next release. Please suggest what you would like to
see included in the next release together with link
Hi there, I am Javier, I was posting before on slack and I was advised to
subscribe to that channel
just that :)
Ciao
J.
Hey Jim, welcome to the community.
To the best of my knowledge we have not yet discussed/run a Maturity
Model. My gut feel is that MXNet would come away a fairly bi-model
result. My view of the project is that it's getting the Apache Way right
in terms of Code, Releases, and Quality. I think
Hello MXNet devs,
I'd like to discuss uniformly adopting C++11 range loops in the MXNet
project. The benefits I see are:
* Improved C++ readability (examples below).
* Consistency with other languages. The range-loops are quite similar to
loops almost all other programming languages. Given
On 28/09/18 11:27, kellen sunderland wrote:
I'd love to see some more
sustained contribution from other open source communities to help us out in
this area
That's not exactly the model I have seen to work. What I have seen works
really well at other projects is pulling users in as
-1
Range loops aren’t always the most performant way. In addition, sometimes
you want the index. Or maybe you want to iterate backwards, or not start
from the first, etc. Maybe you want the iterator because you remove it from
the list at the bottom of the loop Seems like a rule for the sake
Sorry bad paste on the gist - here is the good one
https://gist.github.com/gigasquid/01cd48f563db4739910592dd9ac9db20
On Fri, Sep 28, 2018 at 10:24 AM Carin Meier wrote:
> +1 on option #2
>
> In the case of minimizing the the overhead for code maintenance, I wanted
> to suggest the option of
+1 on option #2
In the case of minimizing the the overhead for code maintenance, I wanted
to suggest the option of investigating generating code from the Java
Reflection for the Java APIs. I did a quick gist from Clojure of what the
generated classes look like from the current Scala Symbol.api
Hi MXNet devs,
I'm struggled with new Travis CI for a while, it always run time out for this
PR:
https://github.com/apache/incubator-mxnet/pull/12530
Most of the time, Jenkins CI can pass, while Travis can't be finished within 50
minutes. For this PR, it shouldn't affect much on the build time
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
Sorry I meant to say next 'Regarding the *minor* release'.
On Sat, Sep 29, 2018 at 5:27 AM kellen sunderland <
kellen.sunderl...@gmail.com> wrote:
> Thanks for transparently setting a rough timeline Steffen. I think this
> will go a long way in helping the community plan their work, even if the
Hi Kellen,
Thanks for your explanation. Do you have a time plan to solve the timeout
issue? Rebasing can't work for my case. Or shall we run it silently to disallow
it voting X for overall CI result? Because most developers are used to ignore
the PRs with 'X'.
Thanks,
Zhennan
-Original
Are we sure that this is due to lacking permissions and not because of some
technical limitation? If we are certain, we can ask out mentors to create a
ticket with Apache Infra to make that switch.
-Marco
Carin Meier schrieb am Sa., 29. Sep. 2018, 01:17:
> I made a test regular merge commit
Thanks for transparently setting a rough timeline Steffen. I think this
will go a long way in helping the community plan their work, even if the
details change somewhat on the road to the release.
Regarding the major release: I would propose we unify TensorRT with the
subgraph operator work.
Hey Zhennan, you're safe to ignore Travis failures for now. They're just
informational.
The reason you sometimes see quick builds and sometimes see slow builds is
that we're making use of ccache in between builds. If your PR is similar
to what's in master you should build very quickly, if not
"Range loops aren’t always the most performant way" Do you have an example
where there's a perf difference?
"In addition, sometimes you want the index. Or maybe you want to iterate
backwards, or not start from the first, etc. Maybe you want the iterator
because you remove it from the list at the
Jason, Jim, Bob and Michael - welcome to the project! Looking forward
working with you.
I like Jim's suggestion to make an assessment where we are based on the
maturity model and will do a first pass over the weekend.
Regards,
Steffen
On Thu, Sep 27, 2018 at 7:37 PM Zhao, Patric wrote:
>
+1 on option #2. Having clear Java interface for NDArray, from my perspective,
would be a better experience for Java users as it won't require them to deal
with Scala code in any capacity. Overhead of extra code for additional macros
is justified, in my mind, as it will be introduced with
Hi Aaron,
Thanks a lot for effort. This consolidation will make it more convenient
for developers to find development resource and help to attract more
contributors.
I have also created a story to make it easy for developers to navigate from
mxnet.io:
+1
Using range-based for-loop whenever possible improves code readability and
makes code less prone to human error.
I did some preliminary research on Google and did not find any complaint
about its performance drawback. Here is one piece from StackOverflow for
reference:
27 matches
Mail list logo
