On Mon, Nov 05, 2018 at 09:04:23PM +0000, Olly Betts wrote:> Dave Courtois wrote: > > Hi there just a little word to tell you that Xapian 1.4.6 work in > > Golang 1.9. There is some issue with the MSet ESet, the namespace part > > of the name is drop by swig. There is also some error with define > > macro in .i files, but with minor change all work perfectly.I had a look and I think that at least the macro changes are only needed because the golang branch hasn't been updated for ages. SWIG has a "%nspace" feature to support wrapping namespaces, but it isn't implemented for Go yet. However, Xapian's C++ API doesn't make much use of namespaces beyond the top-level Xapian namespace, and I'd expect in Go that the Go package name would fulfil the same purpose as the C++ namespace name - i.e. C++ Xapian::MSet -> Go xapian.MSet and so on. I've merged the current RELEASE/1.4 branch into the golang branch and pushed it (really it'd be better to work against git master as that's where this would need to be merged first, but it's probably easier for you to test in your setup working from RELEASE/1.4 branch). Cheers, Olly
Hi Olly, I setup the environment for the golang branch and build it without problem. Cgo complain about the generated cc file and dosent regonize it as swig generated file... curious. There no more problem with the MSet and ESet and all class seem to be generated in Go correctly. I will try tomorrow to manually invoke swig over your .i file and see if the code is generated properly. The file generate-go-execption seem to be for python, is it part of the go binding? I see there is xapian_gc.cc I hope that will work, it's be welcome to not have to manage memory allocation manually. I will try to make it work tomorrow, it's late here. It's a good starting point. I know Xapian can work well in go, so it's only a matter of time before I made your version pass the test. have a good night. Dave Le dim. 11 nov. 2018 à 18:10, Olly Betts <olly at survex.com> a écrit :> On Mon, Nov 05, 2018 at 09:04:23PM +0000, Olly Betts wrote: > > Dave Courtois wrote: > > > Hi there just a little word to tell you that Xapian 1.4.6 work in > > > Golang 1.9. There is some issue with the MSet ESet, the namespace part > > > of the name is drop by swig. There is also some error with define > > > macro in .i files, but with minor change all work perfectly. > > I had a look and I think that at least the macro changes are only needed > because the golang branch hasn't been updated for ages. > > SWIG has a "%nspace" feature to support wrapping namespaces, but it > isn't implemented for Go yet. However, Xapian's C++ API doesn't make > much use of namespaces beyond the top-level Xapian namespace, and I'd > expect in Go that the Go package name would fulfil the same purpose > as the C++ namespace name - i.e. C++ Xapian::MSet -> Go xapian.MSet > and so on. > > I've merged the current RELEASE/1.4 branch into the golang branch and > pushed it (really it'd be better to work against git master as that's > where this would need to be merged first, but it's probably easier for > you to test in your setup working from RELEASE/1.4 branch). > > Cheers, > Olly >
On Sun, Nov 11, 2018 at 09:51:09PM -0500, Dave Courtois wrote:> I setup the environment for the golang branch and build it without > problem. Cgo complain about the generated cc file and dosent regonize it as > swig generated file... curious.If you want to use Cgo then you probably want to add -cgo to the command line options passed to swig (see go/Makefile.am).> There no more problem with the MSet and ESet and all class seem to be > generated in Go correctly. I will try tomorrow to manually invoke swig > over your .i file and see if the code is generated properly. The file > generate-go-execption seem to be for python, is it part of the go > binding?That is indeed just copied from the python bindings, and is not currently used. There were quite a few leftovers from copying the Python bindings as a starting point and I removed most of them, but this one I left as a placeholder as something it probably needed to give useful mapping of C++ exceptions into Go. It looks like SWIG's default wrapping of C++ exceptions appears to be to call _cgo_panic(), which presumably aborts the program. That's not very friendly. I gather than Go doesn't support thrown exceptions, and the equivalent to a C++ exception is an error type which is returned as a second return value. So generate-go-exceptions would ideally generate code to support that. Cheers, Olly