From: Ian L. T. <ia...@go...> - 2010-05-11 05:48:10
|
I have just added a preliminary patch for Go support to the patch tracker. https://sourceforge.net/tracker/?func=detail&aid=2999747&group_id=1645&atid=301645 Go is a new programming language: http://golang.org/ . This patch is preliminary in that there are still some 45 failing tests. However, I hope it is in reasonably good shape overall. I'm posting it now in the hopes of getting some preliminary comments as I complete the work. Thanks. Ian |
From: William S F. <ws...@fu...> - 2010-05-11 18:21:10
|
Ian Lance Taylor wrote: > I have just added a preliminary patch for Go support to the patch > tracker. > > https://sourceforge.net/tracker/?func=detail&aid=2999747&group_id=1645&atid=301645 > > Go is a new programming language: http://golang.org/ . This patch is > preliminary in that there are still some 45 failing tests. However, I > hope it is in reasonably good shape overall. I'm posting it now in > the hopes of getting some preliminary comments as I complete the work. > Great. I had a very quick scan and it looks okay. Very impressed that you have heaps of runtime tests and with about 90% passing it seems in a fairly good shape. I'm only accepting new languages onto trunk when the test-suite passes, but you seem pretty close. If you think it will help, I'll get you svn access and you can create a branch in our svn repo to complete development. William |
From: Ian L. T. <ia...@go...> - 2010-05-11 22:02:09
|
William S Fulton <ws...@fu...> writes: > Ian Lance Taylor wrote: >> I have just added a preliminary patch for Go support to the patch >> tracker. >> >> https://sourceforge.net/tracker/?func=detail&aid=2999747&group_id=1645&atid=301645 >> >> Go is a new programming language: http://golang.org/ . This patch is >> preliminary in that there are still some 45 failing tests. However, I >> hope it is in reasonably good shape overall. I'm posting it now in >> the hopes of getting some preliminary comments as I complete the work. >> > Great. I had a very quick scan and it looks okay. Very impressed that > you have heaps of runtime tests and with about 90% passing it seems in > a fairly good shape. I'm only accepting new languages onto trunk when > the test-suite passes, but you seem pretty close. If you think it will > help, I'll get you svn access and you can create a branch in our svn > repo to complete development. Thanks for taking a look at it. I'm OK with finishing it up in my own repository. Ian |
From: Ian L. T. <ia...@go...> - 2010-05-20 20:06:31
|
William S Fulton <ws...@fu...> writes: > Ian Lance Taylor wrote: >> I have just added a preliminary patch for Go support to the patch >> tracker. >> >> https://sourceforge.net/tracker/?func=detail&aid=2999747&group_id=1645&atid=301645 >> >> Go is a new programming language: http://golang.org/ . This patch is >> preliminary in that there are still some 45 failing tests. However, I >> hope it is in reasonably good shape overall. I'm posting it now in >> the hopes of getting some preliminary comments as I complete the work. >> > Great. I had a very quick scan and it looks okay. Very impressed that > you have heaps of runtime tests and with about 90% passing it seems in > a fairly good shape. I'm only accepting new languages onto trunk when > the test-suite passes, but you seem pretty close. If you think it will > help, I'll get you svn access and you can create a branch in our svn > repo to complete development. I've added a complete Go language patch to the patch tracker at https://sourceforge.net/tracker/?func=detail&aid=3004886&group_id=1645&atid=301645 Go has two compilers. All the tests pass with the 8g compiler. There are few tests which fail with the gccgo compiler, because gccgo does not yet fully support the panic and recover builtin functions. They should pass as soon as gccgo is upgraded. I think the patch is mostly OK. The support for gccgo will need to be adjusted a bit at some point as gccgo is going to change its representation of some of the types which appear in go.swg and friends. The patch I uploaded makes SWIG_overload_rank in overload.cxx a non-static function, so that go.cxx can call it. That in turn caused trouble in allegrocl.cxx and r.cxx, which have their own copies of SWIG_overload_rank. I added #defines to those files to work around the problem. I don't know what the preferred solution is here. What is the next step for getting this into the SWIG sources? Thanks. Ian |
From: William S F. <ws...@fu...> - 2010-05-24 06:07:20
|
Ian Lance Taylor wrote: > William S Fulton <ws...@fu...> writes: > >> Ian Lance Taylor wrote: >>> I have just added a preliminary patch for Go support to the patch >>> tracker. >>> >>> https://sourceforge.net/tracker/?func=detail&aid=2999747&group_id=1645&atid=301645 >>> >>> Go is a new programming language: http://golang.org/ . This patch is >>> preliminary in that there are still some 45 failing tests. However, I >>> hope it is in reasonably good shape overall. I'm posting it now in >>> the hopes of getting some preliminary comments as I complete the work. >>> >> Great. I had a very quick scan and it looks okay. Very impressed that >> you have heaps of runtime tests and with about 90% passing it seems in >> a fairly good shape. I'm only accepting new languages onto trunk when >> the test-suite passes, but you seem pretty close. If you think it will >> help, I'll get you svn access and you can create a branch in our svn >> repo to complete development. > > > I've added a complete Go language patch to the patch tracker at > > https://sourceforge.net/tracker/?func=detail&aid=3004886&group_id=1645&atid=301645 > > Go has two compilers. All the tests pass with the 8g compiler. There > are few tests which fail with the gccgo compiler, because gccgo does > not yet fully support the panic and recover builtin functions. They > should pass as soon as gccgo is upgraded. > > I think the patch is mostly OK. The support for gccgo will need to be > adjusted a bit at some point as gccgo is going to change its > representation of some of the types which appear in go.swg and > friends. > > The patch I uploaded makes SWIG_overload_rank in overload.cxx a > non-static function, so that go.cxx can call it. That in turn caused > trouble in allegrocl.cxx and r.cxx, which have their own copies of > SWIG_overload_rank. I added #defines to those files to work around > the problem. I don't know what the preferred solution is here. > > What is the next step for getting this into the SWIG sources? Hi Ian I'm not sure this will make swig-2.0.0 which has been a long time in the making and which I would like to get out this week. 2.0.1 will follow shortly afterwards and I'll make sure the Go module gets added for this. So can you hold off checking in until 2.0.0 is released. I'll need your SourceForge id to get you commit access, which I'll grant on condition you maintain this language module in the near future. I'd like to check how well it works... what is the easiest way to get one of the go compilers working, like 8g on Linux? I couldn't find any prebuilt binaries or ppa repositories for Ubuntu Lucid, is it a case of build your own? I couldn't help making a very quick scan of the patch though and have the following minor comments to what is one of the best quality new language patches I have seen. Can you remove the html file chapter renumbering from the patch - it isn't related to the new work and should be checked in separately, besides it looks like there are some weird duplicates. The links in Go.html should be Go_xxx not go_xxx. License headers for the files in the Lib directory should be removed, I think your original cut of SWIG predated the license clean up from a couple of months ago revisions 11873-11876. What is XXX in the "go" typemaps meant to indicate, it doesn't seem very conventional. You are missing SWIGTYPE *const& typemaps (recently cleaned up and important for the STL containers). The convention is to put keyword handling (GOKW) in a separate file, probably gokw.swg. I can see some reserved (illegal user) symbols being defined (_GoString_, _GoSlice_ etc). William |
From: Ian L. T. <ia...@go...> - 2010-05-24 13:56:51
|
William S Fulton <ws...@fu...> writes: > I'm not sure this will make swig-2.0.0 which has been a long time in > the making and which I would like to get out this week. 2.0.1 will > follow shortly afterwards and I'll make sure the Go module gets added > for this. So can you hold off checking in until 2.0.0 is > released. I'll need your SourceForge id to get you commit access, > which I'll grant on condition you maintain this language module in the > near future. No problem. My sourceforge ID is "ianlancetaylor". > I'd like to check how well it works... what is the easiest way to get > one of the go compilers working, like 8g on Linux? I couldn't find any > prebuilt binaries or ppa repositories for Ubuntu Lucid, is it a case > of build your own? There are some unofficial packages listed at http://go-lang.cat-v.org/ The language is still changing, so there aren't any official packages. Building your own just takes a few minutes; there are full instructions at http://golang.org/doc/install.html . > Can you remove the html file chapter renumbering from the patch - it > isn't related to the new work and should be checked in separately, > besides it looks like there are some weird duplicates. Sure. > The links in Go.html should be Go_xxx not go_xxx. OK. > License headers for the files in the Lib directory should be removed, > I think your original cut of SWIG predated the license clean up from a > couple of months ago revisions 11873-11876. Ah, OK. > What is XXX in the "go" typemaps meant to indicate, it doesn't seem > very conventional. It's meant to indicate a case where the typemaps are unable to convert the type from C/C++ syntax to Go syntax. Those are the cases which the code in go.cxx has to handle. For example, the syntax for pointer to pointer to int in C/C++ is of course "int**" and in Go is "**int". The typemap code does not seem able to make that transformation. The function goTypeWithInfo handles the transformations which aren't handled in the typemap code. > You are missing SWIGTYPE *const& typemaps (recently cleaned up and > important for the STL containers). > > The convention is to put keyword handling (GOKW) in a separate file, > probably gokw.swg. > > I can see some reserved (illegal user) symbols being defined > (_GoString_, _GoSlice_ etc). I'll fix all of those up. I'll send out another patch later this week. Ian |
From: William S F. <ws...@fu...> - 2010-05-25 19:12:49
|
Ian Lance Taylor wrote: > William S Fulton <ws...@fu...> writes: > > > I'm not sure this will make swig-2.0.0 which has been a long time in > > the making and which I would like to get out this week. 2.0.1 will > > follow shortly afterwards and I'll make sure the Go module gets added > > for this. So can you hold off checking in until 2.0.0 is > > released. I'll need your SourceForge id to get you commit access, > > which I'll grant on condition you maintain this language module in the > > near future. > > No problem. My sourceforge ID is "ianlancetaylor". > Access given. > > I'd like to check how well it works... what is the easiest way to get > > one of the go compilers working, like 8g on Linux? I couldn't find any > > prebuilt binaries or ppa repositories for Ubuntu Lucid, is it a case > > of build your own? > > There are some unofficial packages listed at http://go-lang.cat-v.org/ > The language is still changing, so there aren't any official > packages. Building your own just takes a few minutes; there are full > instructions at http://golang.org/doc/install.html . > Thanks, will try it out soon, probably after 2.0.0 release. > > > What is XXX in the "go" typemaps meant to indicate, it doesn't seem > > very conventional. > > It's meant to indicate a case where the typemaps are unable to convert > the type from C/C++ syntax to Go syntax. Those are the cases which > the code in go.cxx has to handle. For example, the syntax for pointer > to pointer to int in C/C++ is of course "int**" and in Go is "**int". > The typemap code does not seem able to make that transformation. > The function goTypeWithInfo handles the transformations which aren't > handled in the typemap code. > I need to look at the generated code, but probably a special variable will be more suitable as these indicate a substitution by SWIG of some sort, whereas XXX is not very conventional. William |
From: Ian L. T. <ia...@go...> - 2010-05-25 20:07:57
|
William S Fulton <ws...@fu...> writes: >> > What is XXX in the "go" typemaps meant to indicate, it doesn't seem >> > very conventional. >> >> It's meant to indicate a case where the typemaps are unable to convert >> the type from C/C++ syntax to Go syntax. Those are the cases which >> the code in go.cxx has to handle. For example, the syntax for pointer >> to pointer to int in C/C++ is of course "int**" and in Go is "**int". >> The typemap code does not seem able to make that transformation. >> The function goTypeWithInfo handles the transformations which aren't >> handled in the typemap code. >> > I need to look at the generated code, but probably a special variable > will be more suitable as these indicate a substitution by SWIG of some > sort, whereas XXX is not very conventional. Is there any existing example I could look at? To be clear, the XXX never appears in the generated code. The code in go.cxx looks for XXX and replaces it with something else generated at runtime. Ian |
From: William S F. <ws...@fu...> - 2010-05-28 21:20:46
|
Ian Lance Taylor wrote: > William S Fulton <ws...@fu...> writes: > >>>> What is XXX in the "go" typemaps meant to indicate, it doesn't seem >>>> very conventional. >>> It's meant to indicate a case where the typemaps are unable to convert >>> the type from C/C++ syntax to Go syntax. Those are the cases which >>> the code in go.cxx has to handle. For example, the syntax for pointer >>> to pointer to int in C/C++ is of course "int**" and in Go is "**int". >>> The typemap code does not seem able to make that transformation. The primitive types are normally hard coded in the typemap, but if you need a more generic handling of this, like "**MyStruct" for "MyStruct**", then you need a special variable to do the transformation. >>> The function goTypeWithInfo handles the transformations which aren't >>> handled in the typemap code. >>> >> I need to look at the generated code, but probably a special variable >> will be more suitable as these indicate a substitution by SWIG of some >> sort, whereas XXX is not very conventional. > > Is there any existing example I could look at? > > To be clear, the XXX never appears in the generated code. The code in > go.cxx looks for XXX and replaces it with something else generated at > runtime. > $javaclassname in the Java module and $csclassname in C# are special variables particular to a language module. There of course all the standard special variables like $1, $1_type, $1_ltype etc etc, see Typemaps.html#Typemaps_special_variables. William |
From: Ian L. T. <ia...@go...> - 2010-06-02 19:35:42
|
William S Fulton <ws...@fu...> writes: > I couldn't help making a very quick scan of the patch though and have > the following minor comments to what is one of the best quality new > language patches I have seen. > > Can you remove the html file chapter renumbering from the patch - it > isn't related to the new work and should be checked in separately, > besides it looks like there are some weird duplicates. > > The links in Go.html should be Go_xxx not go_xxx. > > License headers for the files in the Lib directory should be removed, > I think your original cut of SWIG predated the license clean up from a > couple of months ago revisions 11873-11876. > > What is XXX in the "go" typemaps meant to indicate, it doesn't seem > very conventional. > > You are missing SWIGTYPE *const& typemaps (recently cleaned up and > important for the STL containers). > > The convention is to put keyword handling (GOKW) in a separate file, > probably gokw.swg. > > I can see some reserved (illegal user) symbols being defined > (_GoString_, _GoSlice_ etc). OK, I think I've addressed all these issues. I've uploaded a new version of the patch to https://sourceforge.net/tracker/?func=detail&aid=3004886&group_id=1645&atid=301645# Ian |
From: William S F. <ws...@fu...> - 2010-06-08 19:21:02
|
Ian Lance Taylor wrote: > William S Fulton <ws...@fu...> writes: > > > I couldn't help making a very quick scan of the patch though and have > > the following minor comments to what is one of the best quality new > > language patches I have seen. > > > > Can you remove the html file chapter renumbering from the patch - it > > isn't related to the new work and should be checked in separately, > > besides it looks like there are some weird duplicates. > > > > The links in Go.html should be Go_xxx not go_xxx. > > > > License headers for the files in the Lib directory should be removed, > > I think your original cut of SWIG predated the license clean up from a > > couple of months ago revisions 11873-11876. > > > > What is XXX in the "go" typemaps meant to indicate, it doesn't seem > > very conventional. > > > > You are missing SWIGTYPE *const& typemaps (recently cleaned up and > > important for the STL containers). > > > > The convention is to put keyword handling (GOKW) in a separate file, > > probably gokw.swg. > > > > I can see some reserved (illegal user) symbols being defined > > (_GoString_, _GoSlice_ etc). > > OK, I think I've addressed all these issues. I've uploaded a new > version of the patch to > > https://sourceforge.net/tracker/?func=detail&aid=3004886&group_id=1645&atid=301645# > I got this patch to compile and run and the test-suite is 100% so as far as I'm concerned it is in a great shape to check in to trunk. Please go ahead and commit it. I've a few minor improvements which I can do or will ask you to do once it is checked in. William |
From: Ian L. T. <ia...@go...> - 2010-06-10 01:14:22
|
William S Fulton <ws...@fu...> writes: > I got this patch to compile and run and the test-suite is 100% so as > far as I'm concerned it is in a great shape to check in to > trunk. Please go ahead and commit it. I've a few minor improvements > which I can do or will ask you to do once it is checked in. Thanks. I've retested and committed the patch. Let me know if there is anything wrong, and what other changes you would like. How should I handle Go-specific changes going forward? Ian |
From: William S F. <ws...@fu...> - 2010-06-11 07:19:36
|
Ian Lance Taylor wrote: > William S Fulton <ws...@fu...> writes: > > > I got this patch to compile and run and the test-suite is 100% so as > > far as I'm concerned it is in a great shape to check in to > > trunk. Please go ahead and commit it. I've a few minor improvements > > which I can do or will ask you to do once it is checked in. > > Thanks. I've retested and committed the patch. Let me know if there > is anything wrong, and what other changes you would like. > Here are a couple of simple ones, I'll send some more in the next few days: - I can see a number of symbols starting with double underscore - these are illegal in C and C++. Some symbols start __goswig, these really ought have go and swig switched around so swig is first. - Can you not have one single #ifdef __cplusplus extern "C" #endif rather than having this occur multiple times... the other language modules seem to manage with a minimal number. We get problems sometimes of the wrapper file containg too many lines and reducing each wrapper method by 4 lines would help this problem. - Is stdout swallowed when running the test-suite? eg li_std_vector_ptr should display the vector - 'gotype' would be a more suitable name for the 'go' typemap. - I'm not sure what the -rename option does that can't be done with %rename? I'd prefer to see this removed to keep consistency amongst the language modules. - Why the 'This file should be compiled with gcc' message in the wrapper file? This is technically wrong - it should be g++ or really any c++ compiler as per the file extension; we don't normally put this kind of stuff in the generated code and is probably best left out and documented instead. You'll probably have noticed that I've committed some other simple fixes and will probably keep doing so until I've finished going over the patch. > How should I handle Go-specific changes going forward? Just commit them, you're basically the official SWIG Go maintainer now ;) William |
From: Ian L. T. <ia...@go...> - 2010-06-15 20:18:29
|
William S Fulton <ws...@fu...> writes: > - I can see a number of symbols starting with double underscore - > these are illegal in C and C++. Some symbols start __goswig, these > really ought have go and swig switched around so swig is first. > - Can you not have one single > #ifdef __cplusplus > extern "C" > #endif > rather than having this occur multiple times... the other language > modules seem to manage with a minimal number. We get problems > sometimes of the wrapper file containg too many lines and reducing > each wrapper method by 4 lines would help this problem. > - Is stdout swallowed when running the test-suite? eg > li_std_vector_ptr should display the vector > - 'gotype' would be a more suitable name for the 'go' typemap. > - Why the 'This file should be compiled with gcc' message in the > wrapper file? This is technically wrong - it should be g++ or really > any c++ compiler as per the file extension; we don't normally put this > kind of stuff in the generated code and is probably best left out and > documented instead. I've made all the above changes. > - I'm not sure what the -rename option does that can't be done with > %rename? I'd prefer to see this removed to keep consistency amongst > the language modules. I actually introduced that option mainly for the testsuite, specifically these lines in Examples/test-suite/go/Makefile.in: # Custom tests - tests with additional commandline options constant_pointers.cpptest: SWIGOPT += -rename foo=foofn director_enum.cpptest: SWIGOPT += -rename Hello=Helloe director_finalizer.cpptest: SWIGOPT += -rename deleteFoo=deleteFooFn enum_thorough.cpptest: SWIGOPT += -rename One=Onee -rename Two=Twoe mixed_types.cpptest: SWIGOPT += -rename Hello=Helloe overload_simple.cpptest: SWIGOPT += -rename foo=foofn smart_pointer_extend.cpptest: SWIGOPT += -rename CPtrFoo=CPtrFoos smart_pointer_member.cpptest: SWIGOPT += -rename Foo=Foos special_variable_macros.cpptest: SWIGOPT += -rename Name=Names template_partial_specialization.cpptest: SWIGOPT += -rename b=bfn template_partial_specialization_typedef.cpptest: SWIGOPT += -rename b=bfn template_specialization_enum.cpptest: SWIGOPT += -rename Hello=Helloe preproc.ctest: SWIGOPT += -rename a5=a5c -rename a6=a6c mod.multicpptest: SWIGOPT += -rename GetC=GetCFn Because Go packages only export capitalized names, name conflicts are much more common in Go than in other languages, so an explicit -rename option didn't seem completely out of place to me. I can add #ifdef SWIGGO %rename directives to the above tests, and drop the -rename option, if you would prefer. Let me know. Ian |
From: William S F. <ws...@fu...> - 2010-06-15 21:35:40
|
Ian Lance Taylor wrote: > William S Fulton <ws...@fu...> writes: > > > - I can see a number of symbols starting with double underscore - > > these are illegal in C and C++. Some symbols start __goswig, these > > really ought have go and swig switched around so swig is first. > > - Can you not have one single > > #ifdef __cplusplus > > extern "C" > > #endif > > rather than having this occur multiple times... the other language > > modules seem to manage with a minimal number. We get problems > > sometimes of the wrapper file containg too many lines and reducing > > each wrapper method by 4 lines would help this problem. > > - Is stdout swallowed when running the test-suite? eg > > li_std_vector_ptr should display the vector > > - 'gotype' would be a more suitable name for the 'go' typemap. > > - Why the 'This file should be compiled with gcc' message in the > > wrapper file? This is technically wrong - it should be g++ or really > > any c++ compiler as per the file extension; we don't normally put this > > kind of stuff in the generated code and is probably best left out and > > documented instead. > > I've made all the above changes. > Great thanks. > > > - I'm not sure what the -rename option does that can't be done with > > %rename? I'd prefer to see this removed to keep consistency amongst > > the language modules. > > I actually introduced that option mainly for the testsuite, > specifically these lines in Examples/test-suite/go/Makefile.in: > > # Custom tests - tests with additional commandline options > constant_pointers.cpptest: SWIGOPT += -rename foo=foofn > director_enum.cpptest: SWIGOPT += -rename Hello=Helloe > director_finalizer.cpptest: SWIGOPT += -rename deleteFoo=deleteFooFn > enum_thorough.cpptest: SWIGOPT += -rename One=Onee -rename Two=Twoe > mixed_types.cpptest: SWIGOPT += -rename Hello=Helloe > overload_simple.cpptest: SWIGOPT += -rename foo=foofn > smart_pointer_extend.cpptest: SWIGOPT += -rename CPtrFoo=CPtrFoos > smart_pointer_member.cpptest: SWIGOPT += -rename Foo=Foos > special_variable_macros.cpptest: SWIGOPT += -rename Name=Names > template_partial_specialization.cpptest: SWIGOPT += -rename b=bfn > template_partial_specialization_typedef.cpptest: SWIGOPT += -rename b=bfn > template_specialization_enum.cpptest: SWIGOPT += -rename Hello=Helloe > preproc.ctest: SWIGOPT += -rename a5=a5c -rename a6=a6c > mod.multicpptest: SWIGOPT += -rename GetC=GetCFn > > Because Go packages only export capitalized names, name conflicts are > much more common in Go than in other languages, so an explicit -rename > option didn't seem completely out of place to me. > > I can add #ifdef SWIGGO %rename directives to the above tests, and > drop the -rename option, if you would prefer. Let me know. > I'd rather -rename was dropped and make suitable changes in the test-suite. Not sure if you are aware or even if it will be useful, but Ruby has a similar problem with capitalization and renames symbols. You'll see lots of %warnfilter(SWIGWARN_RUBY_WRONG_NAME) as it warns whenever it changes the capitalization. Wherever you have the -rename for the test-suite, consider automatically ignoring the clashing symbol. That will be more user friendly for real life code. You can then use %rename or %warnfilter for Go in the test-suite as you see fit to keep the test-suite warning free. William |
From: Ian L. T. <ia...@go...> - 2010-06-16 22:08:30
Attachments:
foo.patch
|
William S Fulton <ws...@fu...> writes: > I'd rather -rename was dropped and make suitable changes in the > test-suite. Not sure if you are aware or even if it will be useful, > but Ruby has a similar problem with capitalization and renames > symbols. You'll see lots of %warnfilter(SWIGWARN_RUBY_WRONG_NAME) as > it warns whenever it changes the capitalization. Wherever you have the > -rename for the test-suite, consider automatically ignoring the > clashing symbol. That will be more user friendly for real life > code. You can then use %rename or %warnfilter for Go in the test-suite > as you see fit to keep the test-suite warning free. I made this work. It seems to me that the natural way to do it is to use the existing Language::addSymbol table via Language::lookupSymbol. In order to do that, I need this patch. Is this OK? Ian |
From: William S F. <ws...@fu...> - 2010-06-17 00:46:06
|
Ian Lance Taylor wrote: > William S Fulton <ws...@fu...> writes: > >> I'd rather -rename was dropped and make suitable changes in the >> test-suite. Not sure if you are aware or even if it will be useful, >> but Ruby has a similar problem with capitalization and renames >> symbols. You'll see lots of %warnfilter(SWIGWARN_RUBY_WRONG_NAME) as >> it warns whenever it changes the capitalization. Wherever you have the >> -rename for the test-suite, consider automatically ignoring the >> clashing symbol. That will be more user friendly for real life >> code. You can then use %rename or %warnfilter for Go in the test-suite >> as you see fit to keep the test-suite warning free. > > I made this work. It seems to me that the natural way to do it is to > use the existing Language::addSymbol table via Language::lookupSymbol. > In order to do that, I need this patch. Is this OK? Yup that's fine. Sorry, I meant to mention the target language symbol table, but you found it. You probably also found -debug-lsymbols which would be useful for what you are doing. While you are working in that area, you might want to implement the fairly new nspace feature which isn't implemented except for java/c# and is tested in the nspace*.i testcases. Documented in SWIGPlus.html. William |
From: Ian L. T. <ia...@go...> - 2010-06-17 21:20:13
|
William S Fulton <ws...@fu...> writes: > I'd rather -rename was dropped and make suitable changes in the > test-suite. Not sure if you are aware or even if it will be useful, > but Ruby has a similar problem with capitalization and renames > symbols. You'll see lots of %warnfilter(SWIGWARN_RUBY_WRONG_NAME) as > it warns whenever it changes the capitalization. Wherever you have the > -rename for the test-suite, consider automatically ignoring the > clashing symbol. That will be more user friendly for real life > code. You can then use %rename or %warnfilter for Go in the test-suite > as you see fit to keep the test-suite warning free. This is committed now. Ian |
From: William S F. <ws...@fu...> - 2010-06-17 23:58:16
|
Ian Lance Taylor wrote: > William S Fulton <ws...@fu...> writes: > >> I'd rather -rename was dropped and make suitable changes in the >> test-suite. Not sure if you are aware or even if it will be useful, >> but Ruby has a similar problem with capitalization and renames >> symbols. You'll see lots of %warnfilter(SWIGWARN_RUBY_WRONG_NAME) as >> it warns whenever it changes the capitalization. Wherever you have the >> -rename for the test-suite, consider automatically ignoring the >> clashing symbol. That will be more user friendly for real life >> code. You can then use %rename or %warnfilter for Go in the test-suite >> as you see fit to keep the test-suite warning free. > > This is committed now. > Cool. My final comment on your go patch is about the Makefiles. We require GNU make, so consider using GNU make's ifeq(...) else ... endif in the Makefiles instead of `if false; then ... fi` being displayed when running the make target, eg for GOSWIGARG and GOCOMPILEARG. The makefile output is somewhat clearer as to what is going on with this alternative approach as the if statements do not appear. It could work like the PY3 check in Examples/Makefile.in. William |