Closed honsys closed 8 years ago
Cool proof of concept for swig usage! After some research it appears cgo is preferable for GoLang <-> C integration, however C++ isn't supported by cgo so I could see this working for GoLang <-> C++.
See: https://groups.google.com/forum/#!topic/golang-nuts/1uvhH29cvXg https://github.com/golang/go/issues/1476
Also, Ruby FFI (implements the DL from the standard library) supports all (or most?) Ruby interpreters where swig only supports MRI since it's output is an MRI C extension. I'd expect the performance to be very similar since both are linked dynamically at runtime. See: http://stackoverflow.com/a/2387551
I think for this project cgo will suffice, and if we ever choose to create Ruby implementation, FFI + GoRods wrapper compiled/linked to a .so would be best because of the interpreter support. Swig seems like a great tool to rapidly create multiple language bindings, but in this instance the two languages we'd potentially want to use (Go, Ruby) have better tools available.
Hi John,
Thanks for taking a look. My understanding is that swig only supports a subset of c++, but nevertheless it might be of interest to (someday) try a go -- c++ module.
I cloned the go src from github and followed the instructions to build it on my ubuntu mint desktop, but it choked.
And since you already have made the investment in cgo (and ruby ffi), a swig alternative seems to be only of academic interest.
Cheers, --david
On Mon, Feb 22, 2016 at 11:33 AM, John Jacquay notifications@github.com wrote:
Cool proof of concept for swig usage! After some research it appears cgo is preferable for GoLang <-> C integration, however C++ isn't supported by cgo so I could see this working for GoLang <-> C++.
See: https://groups.google.com/forum/#!topic/golang-nuts/1uvhH29cvXg golang/go#1476 https://github.com/golang/go/issues/1476
Also, Ruby FFI https://github.com/ffi/ffi (implements the DL from the standard library) supports all (or most?) Ruby interpreters where swig only supports MRI since it's output is an MRI C extension. I'd expect the performance to be very similar since both are linked dynamically at runtime. See: http://stackoverflow.com/a/2387551
I think for this project cgo will suffice, and if we ever choose to create Ruby implementation, FFI + GoRods wrapper compiled/linked to a .so would be best because of the interpreter support. Swig seems like a great tool to rapidly create multiple language bindings, but in this instance the two languages we'd potentially want to use (Go, Ruby) have better tools available.
— Reply to this email directly or view it on GitHub https://github.com/jjacquay712/GoRods/pull/1#issuecomment-187255599.
apologies if my text lacks upper-case -- the shift key aggravates my carpal tunnel & tendinitis. davidb.hon@gmail.com cell: 352-275-7438
This is just a potential starting point -- evaluate use of swig to generate iRODS "bindings" for Go, Ruby, Python, and perhaps other runtimes. In theory the module extensions for each language can derive from the same src and offer nearly identical module namespace func. signatures.