HI Jesse - added you to slack. Please use discuss.mxnet.io to raise your
questions and get support from the community.
Steffen
On Tue, May 1, 2018 at 6:48 PM jesse brizzi wrote:
> Hey everyone,
>
> I'm looking to get slack access and hopefully offer my help with
> contributions/development.
>
>
No, the implementation still comes from MXNet backend.
I don't think there would be any overhead unlike C++ with virtual
functions, Interface or trait is just telling you what the signature looks
like. users program against interfaces and can choose a different
implementation if they like. For exam
Hey Naveen,
I'm not familiar with Scala, so please correct me if I'm wrong with my
assumptions. This basically sounds like we'd have an interface for the
Scala API and a separate implementation, right?
In general, I really like these decoupled approaches (you already
highlighted the advantages)!
Hey everyone,
I'm looking to get slack access and hopefully offer my help with
contributions/development.
I work for a startup that uses Mxnet for some of our internal R&D and deep
learning based services, specifically the scala and python interfaces, and
have run into a few bugs/issues that we c
Hi Aaron,
I think it'd be a good idea to create pip packages for the release
candidates. Sheng, would it be possible to incorporate this into your build
pipeline? In my opinion, we shouldn't advertise the RCs not too much on our
website, so I'd say we could skip #2. #3 in combination with #1 sounds
I see, seems like this slipped through in my review. Sorry for that!
Would anybody object to putting things like these in our S3 bucket?
On Wed, May 2, 2018 at 3:36 AM, shiwen hu wrote:
> this util is use in decompression mkldnn depend. pr is
> https://github.com/apache/incubator-mxnet/pull/106
this util is use in decompression mkldnn depend. pr is
https://github.com/apache/incubator-mxnet/pull/10629 .
marcoabreu Ask me not to put it in a private repositories.
If it doesn't feel right, we can discuss another plan.
Now I've changed it to pre-release
2018-05-02 6:37 GMT+08:00 Hen :
> Winc
Hi Marco,
Putting 1.2.0 was meant to allow a preview and for testing, but I see how
this can cause confusion.
Change the names and/or hiding the RC is possible with some refactoring of
the site build scripts. I'd be happy to take a look at this.
I think another solution could be:
1. create pip in
Wincing at a binary of 7z being there. Seems like something to delete.
On Tue, May 1, 2018 at 3:32 PM Marco de Abreu
wrote:
> Hello,
>
> I have just had a look at
> https://github.com/apache/incubator-mxnet/releases
> and it seems like the releases section is being used for other purposes
> than
Hello,
I have just had a look at https://github.com/apache/incubator-mxnet/releases
and it seems like the releases section is being used for other purposes
than MXNet releases (e.g.
https://github.com/apache/incubator-mxnet/releases/tag/utils). This causes
MXNet 1.1.0 to not be shown as "Latest re
Hello,
we have been approached by a few users about the release status of MXNet
1.2. One thing that seems to be confusing in particular is the fact that we
already show version 1.2.0 on our website. Would it be possible to
blacklist (and remove) pre-release versions from website until they have
be
I think this project is going to significantly improve the usability of
MXNet-Scala APIs.
I had a offline discussion with Qing about this. I agree with Yizhi that
keeping in the same namespace will make it easy for existing and new users
to quickly lookup the APIs. Along with that I have one recom
12 matches
Mail list logo