Discussion for API and implementation of the go wrapper #1

Activity

1. pavanky commented on Sep 26, 2015

   

   pavanky

   on Sep 26, 2015

   MemberAuthor

   More actions

   @rabarar We already have a functional C API for all functions in ArrayFire. You can perhaps look at https://github.com/arrayfire/arrayfire-python and https://github.com/arrayfire/arrayfire-rust wrappers to see how the C functions are being called from the respective languages.

   I foresee something similar happening in go as well.
2. rabarar commented on Sep 26, 2015

   

   rabarar

   on Sep 26, 2015

   Contributor

   More actions

   Perfect - I'll start there.

   On Sep 25, 2015, at 11:03 PM, Pavan Yalamanchili notifications@github.com wrote:

   @rabarar We already have a functional C API for all functions in ArrayFire. You can perhaps look at https://github.com/arrayfire/arrayfire-python and https://github.com/arrayfire/arrayfire-rust wrappers to see how the C functions are being called from the respective languages.

   I foresee something similar happening in go as well.

   —
   Reply to this email directly or view it on GitHub.
3. rabarar commented on Sep 27, 2015

   

   rabarar

   on Sep 27, 2015

   Contributor

   More actions

   Okay, correct me if I'm wrong, but it appears that I can build mappings between the calls in the ./src/api/unified directory and I should have a full coverage of the api? Correct?

   Take a look at the repo src/arrayfire/*.go and you'll see the beginning of a mapping. If you think this is the way to go, I'll continue to build out the mapping and we should have something to play with. I'm going to pause here unit you give me feedback.
4. pavanky commented on Sep 27, 2015

   

   pavanky

   on Sep 27, 2015

   MemberAuthor

   More actions

   @rabarar The easier way to do this is to look at the bottom half functions in every header file in arrayfire/include/af/ after the section extern "C" {
5. pavanky commented on Sep 27, 2015

   

   pavanky

   on Sep 27, 2015

   MemberAuthor

   More actions

   The structure you have so far looks good, but the one thing I am concerned about is users doing something like this (if the API allows it)

   x := randu(2, 3)
   y := randu(2, 3)
   x = add(x, y) // This will leak memory