Re: Following semantic versioning

Great!! Yes, please share! On Fri, Mar 9, 2018 at 7:29 PM Can Balioglu wrote: > We found a rather "hacky" way to dynamically inject our operators and data > iterators during runtime. I can share the details if you are interested. We > also plan to send out a design

Re: Following semantic versioning

We found a rather "hacky" way to dynamically inject our operators and data iterators during runtime. I can share the details if you are interested. We also plan to send out a design proposal for a proper extensibility framework similar to TensorFlow's plugin API. -Can On Wed, Mar 7, 2018, at

Re: Following semantic versioning

One potential problem is with libstdc++. Specifically with vectors. Our operator interface uses vectors, which breaks when core lib and extension are compiled with different compiler version On 2018/03/06 22:45:16, Chris Olivier wrote: > The static init of your module

Re: Following semantic versioning

I also don't see any reason it wouldn't work. I wonder if we could do this and then offer a convenient pip package with operators in separated .SOs, each linked against various libs. For example all versions of blas libs, all versions of cuda. We could then detected the user's environment at

Re: Following semantic versioning

The static init of your module should register your operator just as it does for the operators in mxnet (NNVM_REGISTER_OP). While I haven't done it personally, I see no reason why it wouldn't work like any other operator at that point. On Tue, Mar 6, 2018 at 1:28 PM, Barber, Christopher <

Re: Following semantic versioning

There are two separate issues: how to compile against the MXNet source and how to dynamically load external dynamic libraries. While it would be nice to have all necessary headers in the same place, it doesn't really matter that much if people building extensions have to have access to the

Re: Following semantic versioning

This was discussed in the past and so far, it seems possible for Unix builds, although it’s going to be messy since the compile would generally need access to all a large portion of the headers in the source tree, since the “things needed to create your own op” aren’t necessarily all contained in

Re: Following semantic versioning

Could we actually just define a mechanism so the libs could register their ops at runtime? No linking required? On Tue, Mar 6, 2018, 8:36 PM Pedro Larroy wrote: > This is a good point. What additional blockers would there be for linking > against a user provided

Re: Following semantic versioning

This is a good point. What additional blockers would there be for linking against a user provided library with custom operators? On Tue, Mar 6, 2018 at 5:16 PM, Barber, Christopher < christopher.bar...@analog.com> wrote: > To avoid this kind of problem, you really need to support features that

Re: Following semantic versioning

To avoid this kind of problem, you really need to support features that allow MXNet to be extended without having to resort to forking. There is currently no way to add C++ custom operators without forking, and no way to share such operators across projects. This creates a perverse incentive to

Re: Following semantic versioning

I think its important to understand someone's day_job's customer is also a user of MXNet. Right now MXNet project needs to put effort in helping users and bringing them on-board. I don't think its a good idea to ask the customer to come back after a new release is made or ask to use a fork. With