Thanks Chris for your excellent explanation! Personally I like the way we
separate the world that Scala and Java shares so Java developers don't have to
think of how to use "Scala" in order to write Java code. I think usability for
Java users and Scala users is the most important tasks we need t
My $0.02 since I’m working with a lot of java and scala lately, including
the interaction between the two:
Please keep in mind the more complex dependency issues that will be
introduced by requiring Java users to now have to pull in a large scala
dependency base. In addition, a lot is Scala is com
Welcome, Jason, I think MXNet will achieve the great success as same as BigDL.
Looking forward to working with you :)
> -Original Message-
> From: Hen [mailto:bay...@apache.org]
> Sent: Friday, September 28, 2018 8:23 AM
> To: dev@mxnet.incubator.apache.org
> Cc: Jim Jagielski ; Michael
I mean that you don't have to be a code owner to review a PR. If code is
touched you are familiar with or code is similar to some of you've
submitted before than you could be a good reviewer. The bot could pick some
amount of reviewers based on this.
Best
Anton
чт, 27 сент. 2018 г. в 17:28, Qing
I vote for "2.) Leave the existing macro in place and add another
which generates a Java friendly version"
@Qing @Andrew, could you give some examples, so that people can better
understand how it provides "best possible experience" to Java users.
I have no strong preference between having JavaSha
That's not really the conversation I'm wanting to have. I want a discussion
about the macros with respect to NDArray so that we can get agreement on
our path forward with respect to implementing the NDArray wrapper.
The design that was put forth and agreed to was for a a Java wrapper around
the Sc
Great work Harsh! I like your webhook design. This would allow us to do a great
more for the label bot and speed up the response time.
-Marco: I think Anton means the "Assignees" field in issues and PRs
Thanks,
Qing
On 9/27/18, 5:06 PM, "Marco de Abreu"
wrote:
You mean like a replacement
I'd like to welcome four additional mentors (cc'd) for MXNet :)
* Jason Dai;
* Jim Jagielski;
* Bob Paulin; and
* Michael Wall.
Suneel Marthi has also stepped back from mentoring.
Thank you to each of our new mentors for joining in, and many thanks to
Suneel for the time he's given over the
I would like to loop this back a layer. Current, there is a discussion in the
MXNet Scala community on the ways to implement the Java APIs. Currently there
are two thoughts:
1. Make Scala Java Friendly (Create Java compatible methods in the Scala Class.
such as NDArray with Java compatible cons
You mean like a replacement for the codeowners feature?
Anton Chernov schrieb am Fr., 28. Sep. 2018, 01:39:
> As a feature request: Could we include detection and proposal of reviewers
> to the bot as well?
>
> Anton
>
> чт, 27 сент. 2018 г. в 15:27, Harsh Patel :
>
> > Hey,
> > I'm Harsh Patel,
As a feature request: Could we include detection and proposal of reviewers
to the bot as well?
Anton
чт, 27 сент. 2018 г. в 15:27, Harsh Patel :
> Hey,
> I'm Harsh Patel, and I am looking to contribute to MXNet. I wanted to get
> some feedback to improvements that could be made with the current
Hey,
I'm Harsh Patel, and I am looking to contribute to MXNet. I wanted to get
some feedback to improvements that could be made with the current structure
that we have for automatically labelling issues and pull requests. I have
linked my proposed design structure on the bottom of this wiki page (
Hi,
Currently, we're working to implement a new Java API and would like some
feedback from the community on an implementation detail. In short, the new
Java API will use the existing Scala API (in a manner similar to how the
current Clojure API works). This basically means that we're making Java
f
Thanks everyone for the input. I'll try to summarize the feedback from the
responses:
Using Squash-Merge is the project standard for very good reasons. However,
in the case of this PR to bring in the Julia language from its sibling
repo, we want to preserve all the individual commits of the many
c
+1 for rebase and merge. As a workaround for the aforementioned issue,
maybe we can create a tag for the commit before the merge, so that in case
people want to browse the recent main-repo commits by skipping this big
chunk of rebased commits, there is a pointer to take his or her hand on.
Best,
C
+1 to rebase and merge to preserve and track the contributions.
Thanks,
-Jason
On Thu, Sep 27, 2018 at 12:27 PM Aaron Markham
wrote:
> +1 to rebase and merge to retain the efforts of all of the contributors. If
> there's some git maintenance that can trim it down from 700+ commits then
> maybe
On Thu, Sep 27, 2018 at 08:32:53AM -0400, Steffen Rochel wrote:
> Congratulation to all contributors to the project, well deserved!
> https://www.infoworld.com/article/3308398/machine-learning/the-best-open-source-software-for-machine-learning.html#slide9
>
>
> Let's consider the recognition as m
Congratulation to all contributors to the project, well deserved!
https://www.infoworld.com/article/3308398/machine-learning/the-best-open-source-software-for-machine-learning.html#slide9
Let's consider the recognition as motivation to increase our effort.
Thanks and congratulation!
Steffen
+1 for rebase and merge
Aaron Markham schrieb am Do., 27. Sep. 2018,
06:27:
> +1 to rebase and merge to retain the efforts of all of the contributors. If
> there's some git maintenance that can trim it down from 700+ commits then
> maybe that's a compromise.
>
> On Wed, Sep 26, 2018, 21:23 Navee
19 matches
Mail list logo
