From: William S F. <ws...@fu...> - 2013-08-29 05:57:55
|
I've been thinking that it is time to pull together a bunch of nearly completed work that has been done in the past and release it as SWIG 3. I had in mind the following: - C++0x/C++11 support - Nested classes - Doxygen support Possibly also: - Javascript - Perl changes from Robert Stone Also: - Drop .NET 1.1 support (.NET 2.0 as minimum) for C# I don't think there are many backward compatibility problems with the above work, except maybe nested classes. However, I suggest a big version number increment because the documentation and nested classes have always been seen as main missing features, plus C++11 is a big additional feature. The main concern is that most of these are unfinished, so perhaps we can release 3.0.x as beta versions until it is stable/finished. We can in the meantime release 2.0.x versions until 3.1.0 is ready. Any objections/agreement? William |
From: Vadim Z. <vz...@ze...> - 2013-08-29 12:02:09
|
On Thu, 29 Aug 2013 06:57:39 +0100 William S Fulton <ws...@fu...> wrote: WSF> I've been thinking that it is time to pull together a bunch of nearly WSF> completed work that has been done in the past and release it as SWIG 3. WSF> WSF> I had in mind the following: WSF> - C++0x/C++11 support WSF> - Nested classes WSF> - Doxygen support Those would be great to have, especially the first two (which is not to say that the third one is not important, but just that the first two are even more so). FWIW, I'm using the nested classes fork right now as I've started wrapping the part of our library which uses nested classes extensively and I had absolutely no problems with it, i.e. it just worked out of the box, at least with C# and Python backends, so I'm all for including it in SWIG mainline -- and thanks a lot to Vladimir Kalinin for working on this! WSF> Possibly also: WSF> - Javascript WSF> - Perl changes from Robert Stone WSF> WSF> Also: WSF> - Drop .NET 1.1 support (.NET 2.0 as minimum) for C# This would simplify C# typemaps somewhat... WSF> I don't think there are many backward compatibility problems with the WSF> above work, except maybe nested classes. FWIW I haven't seen any incompatibilities. But, of course, I didn't test everything that SWIG supports. My library is big and complicated but not monstrous enough to serve as an extensive test case. WSF> However, I suggest a big version number increment because the WSF> documentation and nested classes have always been seen as main missing WSF> features, plus C++11 is a big additional feature. IMO nested classes alone justify the version number change. WSF> The main concern is that most of these are unfinished, so perhaps we can WSF> release 3.0.x as beta versions until it is stable/finished. We can in WSF> the meantime release 2.0.x versions until 3.1.0 is ready. WSF> WSF> Any objections/agreement? Mostly agreement, but I also think that 3.0 shouldn't be called beta as it won't be less stable than 2.0.10. Regards, VZ |
From: Karl W. <kar...@gm...> - 2013-08-29 12:21:27
|
Maybe you could release the new features as a 2.9.x series, then release 3.0 once they're considered stable/finished? Cheers, Karl On 29 August 2013 07:57, William S Fulton <ws...@fu...> wrote: > I've been thinking that it is time to pull together a bunch of nearly > completed work that has been done in the past and release it as SWIG 3. > > I had in mind the following: > - C++0x/C++11 support > - Nested classes > - Doxygen support > > Possibly also: > - Javascript > - Perl changes from Robert Stone > > Also: > - Drop .NET 1.1 support (.NET 2.0 as minimum) for C# > > I don't think there are many backward compatibility problems with the > above work, except maybe nested classes. However, I suggest a big > version number increment because the documentation and nested classes > have always been seen as main missing features, plus C++11 is a big > additional feature. > > The main concern is that most of these are unfinished, so perhaps we can > release 3.0.x as beta versions until it is stable/finished. We can in > the meantime release 2.0.x versions until 3.1.0 is ready. > > Any objections/agreement? > > William > > > ------------------------------------------------------------------------------ > Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! > Discover the easy way to master current and previous Microsoft technologies > and advance your career. Get an incredible 1,500+ hours of step-by-step > tutorial videos with LearnDevNow. Subscribe today and save! > http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk > _______________________________________________ > Swig-devel mailing list > Swi...@li... > https://lists.sourceforge.net/lists/listinfo/swig-devel > |
From: Robert S. <ta...@tr...> - 2013-08-29 18:38:38
|
On Thu, Aug 29, 2013 at 06:57:39AM +0100, William S Fulton wrote: > I've been thinking that it is time to pull together a bunch of nearly > completed work that has been done in the past and release it as SWIG 3. > > I had in mind the following: > - C++0x/C++11 support > - Nested classes > - Doxygen support > > Possibly also: > - Javascript > - Perl changes from Robert Stone > > Also: > - Drop .NET 1.1 support (.NET 2.0 as minimum) for C# > > I don't think there are many backward compatibility problems with the > above work, except maybe nested classes. However, I suggest a big > version number increment because the documentation and nested classes > have always been seen as main missing features, plus C++11 is a big > additional feature. > > The main concern is that most of these are unfinished, so perhaps we can > release 3.0.x as beta versions until it is stable/finished. We can in > the meantime release 2.0.x versions until 3.1.0 is ready. > > Any objections/agreement? I have one known backward compatibility issue. C++ static member functions are currently surfaced to Perl as functions instead of methods. Specifically, this means: struct X { public: static void fun(); }; is run in Perl using "X::fun()" but the branch requires method dispatch using "X->fun()". Director support was not feasible without this, and the best Jason and I could come up to support the old call style were heuristics that had ugly ramifications for overloaded functions and error messaging. There were two instances of these in our tests, all other tests on master pass without modifications. If we can accept that issue, I would love to see this work hit the main release. -Robert |
From: William S F. <ws...@fu...> - 2013-08-29 18:45:18
|
On 29/08/13 19:21, Robert Stone wrote: > On Thu, Aug 29, 2013 at 06:57:39AM +0100, William S Fulton wrote: >> I've been thinking that it is time to pull together a bunch of nearly >> completed work that has been done in the past and release it as SWIG 3. >> >> I had in mind the following: >> - C++0x/C++11 support >> - Nested classes >> - Doxygen support >> >> Possibly also: >> - Javascript >> - Perl changes from Robert Stone >> >> Also: >> - Drop .NET 1.1 support (.NET 2.0 as minimum) for C# >> >> I don't think there are many backward compatibility problems with the >> above work, except maybe nested classes. However, I suggest a big >> version number increment because the documentation and nested classes >> have always been seen as main missing features, plus C++11 is a big >> additional feature. >> >> The main concern is that most of these are unfinished, so perhaps we can >> release 3.0.x as beta versions until it is stable/finished. We can in >> the meantime release 2.0.x versions until 3.1.0 is ready. >> >> Any objections/agreement? > > I have one known backward compatibility issue. C++ static > member functions are currently surfaced to Perl as functions instead of > methods. Specifically, this means: > > struct X { > public: > static void fun(); > }; > > is run in Perl using "X::fun()" but the branch requires method dispatch > using "X->fun()". Director support was not feasible without this, and > the best Jason and I could come up to support the old call style were > heuristics that had ugly ramifications for overloaded functions and > error messaging. There were two instances of these in our tests, all > other tests on master pass without modifications. > You'll have to excuse my perl ignorance, but does this mean you need an instance of X in order to call the static function? Hopefully not. > If we can accept that issue, I would love to see this work hit > the main release. > Unless there are any objections from other perl fans, I'd would rather see the director support in the perl module even if it means a backwards compatibility breakage. It just needs documenting in the Perl.html file and the CHANGES.current. Can you put a director chapter in the Perl.html file too if you don't already have one? William |
From: Robert S. <ta...@tr...> - 2013-08-29 19:47:40
|
On Thu, Aug 29, 2013 at 07:45:04PM +0100, William S Fulton wrote: > On 29/08/13 19:21, Robert Stone wrote: > > > > I have one known backward compatibility issue. C++ static > >member functions are currently surfaced to Perl as functions instead of > >methods. Specifically, this means: > > > > struct X { > > public: > > static void fun(); > > }; > > > >is run in Perl using "X::fun()" but the branch requires method dispatch > >using "X->fun()". Director support was not feasible without this, and > >the best Jason and I could come up to support the old call style were > >heuristics that had ugly ramifications for overloaded functions and > >error messaging. There were two instances of these in our tests, all > >other tests on master pass without modifications. > > > You'll have to excuse my perl ignorance, but does this mean you need > an instance of X in order to call the static function? Hopefully > not. No instance is needed, this is using the "class method" syntax in Perl, just like how constructors are usually handled. > > If we can accept that issue, I would love to see this work hit > >the main release. > > > Unless there are any objections from other perl fans, I'd would > rather see the director support in the perl module even if it means > a backwards compatibility breakage. It just needs documenting in the > Perl.html file and the CHANGES.current. Can you put a director > chapter in the Perl.html file too if you don't already have one? I will update the Perl docs, I am nearly certain I have changes that haven't been shared yet. I'll get this in the next couple of days. -Robert |
From: William S F. <ws...@fu...> - 2013-08-31 07:35:12
|
On 29/08/13 12:24, Vadim Zeitlin wrote: > On Thu, 29 Aug 2013 06:57:39 +0100 William S Fulton <ws...@fu...> wrote: > > WSF> I've been thinking that it is time to pull together a bunch of nearly > WSF> completed work that has been done in the past and release it as SWIG 3. > WSF> > WSF> I had in mind the following: > WSF> - C++0x/C++11 support > WSF> - Nested classes > WSF> - Doxygen support > > Those would be great to have, especially the first two (which is not to > say that the third one is not important, but just that the first two are > even more so). FWIW, I'm using the nested classes fork right now as I've > started wrapping the part of our library which uses nested classes > extensively and I had absolutely no problems with it, i.e. it just worked > out of the box, at least with C# and Python backends, so I'm all for > including it in SWIG mainline -- and thanks a lot to Vladimir Kalinin for > working on this! > > WSF> Possibly also: > WSF> - Javascript > WSF> - Perl changes from Robert Stone > WSF> > WSF> Also: > WSF> - Drop .NET 1.1 support (.NET 2.0 as minimum) for C# > > This would simplify C# typemaps somewhat... > > WSF> I don't think there are many backward compatibility problems with the > WSF> above work, except maybe nested classes. > > FWIW I haven't seen any incompatibilities. But, of course, I didn't test > everything that SWIG supports. My library is big and complicated but not > monstrous enough to serve as an extensive test case. > > WSF> However, I suggest a big version number increment because the > WSF> documentation and nested classes have always been seen as main missing > WSF> features, plus C++11 is a big additional feature. > > IMO nested classes alone justify the version number change. > > WSF> The main concern is that most of these are unfinished, so perhaps we can > WSF> release 3.0.x as beta versions until it is stable/finished. We can in > WSF> the meantime release 2.0.x versions until 3.1.0 is ready. > WSF> > WSF> Any objections/agreement? > > Mostly agreement, but I also think that 3.0 shouldn't be called beta as it > won't be less stable than 2.0.10. > Okay, given this and Karl's comments, I'd rather just them out as 3.0.x. The old functionality will certainly be as stable so need for a beta tag. Perhaps some of the new features will be refined a bit over time but that is pretty much how it normally works and we can document this where necessary. So I propose releasing 2.0.11 fairly soon from master, say within 1-2 weeks. It could could well be the last 2.0.x version. Then start merging code onto master ready for 3.0.0. I would really appreciate some help on this. Would the following folk be able to prepare their branches ready for merge onto trunk (please confirm or object): C++11 - William Fulton Nested classes - Vladimir Kalinin Doxygen - ??? any volunteers ??? Javascript - Oliver Buchtala Perl improvements - Robert Stone .NET 2.0 - Brant Kyser Scilab - Simon Marchetto This will include ensuring the appropriate branch either has Travis builds turned on so I can see the build output is good before merging or otherwise github patches show the Travis tests as passing. In some cases not much needs to be done. I could also do with some help getting the c++11 work ready if anyone is interested in this area, but I'd mostly like some assistance with the doxygen branch, I just don't recall what the state of it is like. William |
From: Oliver B. <oli...@go...> - 2013-08-31 09:06:50
|
> C++11 - William Fulton > Nested classes - Vladimir Kalinin > Doxygen - ??? any volunteers ??? > Javascript - Oliver Buchtala Hi, I totally agree with your plans and start to make the Javascript branch ready for that. Cheers, Oliver |
From: Marko K. <mar...@is...> - 2013-09-04 07:38:33
|
William, doxygen branch is ready for a review. See my mail from 23. Feb (set to your address not mailing list). Marko Dne 31.8.2013 8:34, piše William S Fulton: > On 29/08/13 12:24, Vadim Zeitlin wrote: >> On Thu, 29 Aug 2013 06:57:39 +0100 William S Fulton <ws...@fu...> wrote: >> >> WSF> I've been thinking that it is time to pull together a bunch of nearly >> WSF> completed work that has been done in the past and release it as SWIG 3. >> WSF> >> WSF> I had in mind the following: >> WSF> - C++0x/C++11 support >> WSF> - Nested classes >> WSF> - Doxygen support >> >> Those would be great to have, especially the first two (which is not to >> say that the third one is not important, but just that the first two are >> even more so). FWIW, I'm using the nested classes fork right now as I've >> started wrapping the part of our library which uses nested classes >> extensively and I had absolutely no problems with it, i.e. it just worked >> out of the box, at least with C# and Python backends, so I'm all for >> including it in SWIG mainline -- and thanks a lot to Vladimir Kalinin for >> working on this! >> >> WSF> Possibly also: >> WSF> - Javascript >> WSF> - Perl changes from Robert Stone >> WSF> >> WSF> Also: >> WSF> - Drop .NET 1.1 support (.NET 2.0 as minimum) for C# >> >> This would simplify C# typemaps somewhat... >> >> WSF> I don't think there are many backward compatibility problems with the >> WSF> above work, except maybe nested classes. >> >> FWIW I haven't seen any incompatibilities. But, of course, I didn't test >> everything that SWIG supports. My library is big and complicated but not >> monstrous enough to serve as an extensive test case. >> >> WSF> However, I suggest a big version number increment because the >> WSF> documentation and nested classes have always been seen as main missing >> WSF> features, plus C++11 is a big additional feature. >> >> IMO nested classes alone justify the version number change. >> >> WSF> The main concern is that most of these are unfinished, so perhaps we can >> WSF> release 3.0.x as beta versions until it is stable/finished. We can in >> WSF> the meantime release 2.0.x versions until 3.1.0 is ready. >> WSF> >> WSF> Any objections/agreement? >> >> Mostly agreement, but I also think that 3.0 shouldn't be called beta as it >> won't be less stable than 2.0.10. >> > Okay, given this and Karl's comments, I'd rather just them out as 3.0.x. > The old functionality will certainly be as stable so need for a beta > tag. Perhaps some of the new features will be refined a bit over time > but that is pretty much how it normally works and we can document this > where necessary. > > So I propose releasing 2.0.11 fairly soon from master, say within 1-2 > weeks. It could could well be the last 2.0.x version. Then start merging > code onto master ready for 3.0.0. I would really appreciate some help on > this. Would the following folk be able to prepare their branches ready > for merge onto trunk (please confirm or object): > > C++11 - William Fulton > Nested classes - Vladimir Kalinin > Doxygen - ??? any volunteers ??? > Javascript - Oliver Buchtala > Perl improvements - Robert Stone > .NET 2.0 - Brant Kyser > Scilab - Simon Marchetto > > This will include ensuring the appropriate branch either has Travis > builds turned on so I can see the build output is good before merging or > otherwise github patches show the Travis tests as passing. In some cases > not much needs to be done. > > I could also do with some help getting the c++11 work ready if anyone is > interested in this area, but I'd mostly like some assistance with the > doxygen branch, I just don't recall what the state of it is like. > > William > > > > ------------------------------------------------------------------------------ > Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! > Discover the easy way to master current and previous Microsoft technologies > and advance your career. Get an incredible 1,500+ hours of step-by-step > tutorial videos with LearnDevNow. Subscribe today and save! > http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk > _______________________________________________ > Swig-devel mailing list > Swi...@li... > https://lists.sourceforge.net/lists/listinfo/swig-devel > > > -- > Marko Klopcic, +386 1 5680695, www.asystelectronic.si > Asyst electronic d.o.o. / iSYSTEM AG > Brodisce 18, SI-1236 Trzin, SLOVENIA |
From: Vladimir K. <vka...@op...> - 2013-09-09 13:23:14
|
Hi William, I've just returned from vacation and didn't see the post earlier. I'm not quite familiar with the merging process - do you mean I have to merge (fast-forward) changes from https://github.com/swig/swig 'master' branch to my 'master' branch at https://github.com/wkalinin/swig for it to be ready for merge to trunk? Best regards, Vladimir mailto:vka...@op... ----- Original Message ----- On 29/08/13 12:24, Vadim Zeitlin wrote: > On Thu, 29 Aug 2013 06:57:39 +0100 William S Fulton <ws...@fu...> wrote: > > WSF> I've been thinking that it is time to pull together a bunch of nearly > WSF> completed work that has been done in the past and release it as SWIG 3. > WSF> > WSF> I had in mind the following: > WSF> - C++0x/C++11 support > WSF> - Nested classes > WSF> - Doxygen support > > Those would be great to have, especially the first two (which is not to > say that the third one is not important, but just that the first two are > even more so). FWIW, I'm using the nested classes fork right now as I've > started wrapping the part of our library which uses nested classes > extensively and I had absolutely no problems with it, i.e. it just worked > out of the box, at least with C# and Python backends, so I'm all for > including it in SWIG mainline -- and thanks a lot to Vladimir Kalinin for > working on this! > > WSF> Possibly also: > WSF> - Javascript > WSF> - Perl changes from Robert Stone > WSF> > WSF> Also: > WSF> - Drop .NET 1.1 support (.NET 2.0 as minimum) for C# > > This would simplify C# typemaps somewhat... > > WSF> I don't think there are many backward compatibility problems with the > WSF> above work, except maybe nested classes. > > FWIW I haven't seen any incompatibilities. But, of course, I didn't test > everything that SWIG supports. My library is big and complicated but not > monstrous enough to serve as an extensive test case. > > WSF> However, I suggest a big version number increment because the > WSF> documentation and nested classes have always been seen as main missing > WSF> features, plus C++11 is a big additional feature. > > IMO nested classes alone justify the version number change. > > WSF> The main concern is that most of these are unfinished, so perhaps we can > WSF> release 3.0.x as beta versions until it is stable/finished. We can in > WSF> the meantime release 2.0.x versions until 3.1.0 is ready. > WSF> > WSF> Any objections/agreement? > > Mostly agreement, but I also think that 3.0 shouldn't be called beta as it > won't be less stable than 2.0.10. > Okay, given this and Karl's comments, I'd rather just them out as 3.0.x. The old functionality will certainly be as stable so need for a beta tag. Perhaps some of the new features will be refined a bit over time but that is pretty much how it normally works and we can document this where necessary. So I propose releasing 2.0.11 fairly soon from master, say within 1-2 weeks. It could could well be the last 2.0.x version. Then start merging code onto master ready for 3.0.0. I would really appreciate some help on this. Would the following folk be able to prepare their branches ready for merge onto trunk (please confirm or object): C++11 - William Fulton Nested classes - Vladimir Kalinin Doxygen - ??? any volunteers ??? Javascript - Oliver Buchtala Perl improvements - Robert Stone .NET 2.0 - Brant Kyser Scilab - Simon Marchetto This will include ensuring the appropriate branch either has Travis builds turned on so I can see the build output is good before merging or otherwise github patches show the Travis tests as passing. In some cases not much needs to be done. I could also do with some help getting the c++11 work ready if anyone is interested in this area, but I'd mostly like some assistance with the doxygen branch, I just don't recall what the state of it is like. William ------------------------------------------------------------------------------ Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk _______________________________________________ Swig-devel mailing list Swi...@li... https://lists.sourceforge.net/lists/listinfo/swig-devel |
From: Sylvestre L. <syl...@de...> - 2013-08-29 12:44:27
|
On 29/08/2013 07:57, William S Fulton wrote: > I've been thinking that it is time to pull together a bunch of nearly > completed work that has been done in the past and release it as SWIG 3. Good news. > > The main concern is that most of these are unfinished, so perhaps we can > release 3.0.x as beta versions until it is stable/finished. We can in > the meantime release 2.0.x versions until 3.1.0 is ready. I know I am biased but if Scilab support is ready and merged on time, maybe we could use this beta period to improve it, don't you think ? Sylvestre |
From: William S F. <ws...@fu...> - 2013-09-01 20:49:58
|
On 29/08/13 13:28, Sylvestre Ledru wrote: > On 29/08/2013 07:57, William S Fulton wrote: >> I've been thinking that it is time to pull together a bunch of nearly >> completed work that has been done in the past and release it as SWIG 3. > Good news. > >> >> The main concern is that most of these are unfinished, so perhaps we can >> release 3.0.x as beta versions until it is stable/finished. We can in >> the meantime release 2.0.x versions until 3.1.0 is ready. > I know I am biased but if Scilab support is ready and merged on time, > maybe we could use this beta period to improve it, don't you think ? > I've added Scilab to the list of intended features for SWIG 3. There should be plenty of time to improve it. Given the test-suite is passing, I think that this is a good sign that it is good enough for SWIG 3 as it is. As mentioned elsewhere, I'll review and let you know if there are any major problems. William |
From: Sylvestre L. <syl...@de...> - 2013-09-02 07:49:56
|
On 01/09/2013 22:49, William S Fulton wrote: > On 29/08/13 13:28, Sylvestre Ledru wrote: >> On 29/08/2013 07:57, William S Fulton wrote: >>> I've been thinking that it is time to pull together a bunch of nearly >>> completed work that has been done in the past and release it as SWIG 3. >> Good news. >> >>> >>> The main concern is that most of these are unfinished, so perhaps we can >>> release 3.0.x as beta versions until it is stable/finished. We can in >>> the meantime release 2.0.x versions until 3.1.0 is ready. >> I know I am biased but if Scilab support is ready and merged on time, >> maybe we could use this beta period to improve it, don't you think ? >> > I've added Scilab to the list of intended features for SWIG 3. There > should be plenty of time to improve it. Given the test-suite is passing, > I think that this is a good sign that it is good enough for SWIG 3 as it > is. As mentioned elsewhere, I'll review and let you know if there are > any major problems. Excellent news. Thanks! Sylvestre |
From: Vadim Z. <vz...@ze...> - 2013-09-01 21:52:08
|
On Sat, 31 Aug 2013 08:34:57 +0100 William S Fulton <ws...@fu...> wrote: WSF> So I propose releasing 2.0.11 fairly soon from master, say within 1-2 WSF> weeks. Just in case you hadn't seen it yet, could you please include https://github.com/swig/swig/pull/82 in it? AFAICS this shouldn't break anything and this is something that I'd really prefer to have in the official SWIG version instead of having it in my own branch only. WSF> Nested classes - Vladimir Kalinin I tried merging this one with master myself and there is just one conflict but unfortunately it's not a totally obvious one, at least not to me, in C# code. I hope Vladimir has time to look at it but if not I'll try to return to this myself soon (after 2.0.11 I guess). Regards, VZ |
From: William S F. <ws...@fu...> - 2013-09-02 05:56:09
|
On 01/09/13 22:51, Vadim Zeitlin wrote: > On Sat, 31 Aug 2013 08:34:57 +0100 William S Fulton <ws...@fu...> wrote: > > WSF> So I propose releasing 2.0.11 fairly soon from master, say within 1-2 > WSF> weeks. > > Just in case you hadn't seen it yet, could you please include > https://github.com/swig/swig/pull/82 in it? AFAICS this shouldn't break > anything and this is something that I'd really prefer to have in the > official SWIG version instead of having it in my own branch only. > I've seen it alright, it is in my TODO queue for swig-2.0.11. William |
From: Vadim Z. <vz...@ze...> - 2013-09-09 13:03:54
|
On Mon, 9 Sep 2013 16:49:21 +0400 Vladimir Kalinin <vka...@op...> wrote: VK> I'm not quite familiar with the merging process - VK> do you mean I have to merge (fast-forward) changes from VK> https://github.com/swig/swig 'master' branch to my 'master' branch at VK> https://github.com/wkalinin/swig for it to be ready for merge to trunk? Hello Vladimir, You can't fast forward your branch as it has diverged from master since then, so it needs to be either rebased on master or merged with it. Personally I think it would be nice to rebase it because the current history is a bit weird (e.g. it starts with 2 identical commits: 2f97ad9 and c0084fd somehow; and it also contains some strange self-merges like c1e2a87 and b6c69c8) but I don't know if SWIG has any rules about this. What is certain is that currently merging swig/master into wkalinin/swig doesn't work automatically, there are conflicts in Source/Modules/csharp.cxx Looking at them again now, they seem less serious than when I saw them the first time, it looks like we just should combine all changes to the directors, both the improved smart pointer support done in master and the nested classes support from your branch. But there could be some ordering issues that I'm not aware of here, so it would be still better if you could look at the merge yourself. TIA, VZ |
From: Vladimir K. <vka...@op...> - 2013-09-09 15:46:53
|
Hi Vadim, As far as I can understand, rebasing will require to repeat the merge work that I already done (I merged upstream/master 27.02.13 last time), so if there is no special requirement I would prefer just merge & pull request. (the first revision merges were quite non-trivial) Best regards, Vladimir mailto:vka...@op... ----- Original Message ----- On Mon, 9 Sep 2013 16:49:21 +0400 Vladimir Kalinin <vka...@op...> wrote: VK> I'm not quite familiar with the merging process - VK> do you mean I have to merge (fast-forward) changes from VK> https://github.com/swig/swig 'master' branch to my 'master' branch at VK> https://github.com/wkalinin/swig for it to be ready for merge to trunk? Hello Vladimir, You can't fast forward your branch as it has diverged from master since then, so it needs to be either rebased on master or merged with it. Personally I think it would be nice to rebase it because the current history is a bit weird (e.g. it starts with 2 identical commits: 2f97ad9 and c0084fd somehow; and it also contains some strange self-merges like c1e2a87 and b6c69c8) but I don't know if SWIG has any rules about this. What is certain is that currently merging swig/master into wkalinin/swig doesn't work automatically, there are conflicts in Source/Modules/csharp.cxx Looking at them again now, they seem less serious than when I saw them the first time, it looks like we just should combine all changes to the directors, both the improved smart pointer support done in master and the nested classes support from your branch. But there could be some ordering issues that I'm not aware of here, so it would be still better if you could look at the merge yourself. TIA, VZ |
From: William S F. <ws...@fu...> - 2013-09-09 18:24:06
|
On 09/09/13 14:03, Vadim Zeitlin wrote: > On Mon, 9 Sep 2013 16:49:21 +0400 Vladimir Kalinin <vka...@op...> wrote: > > VK> I'm not quite familiar with the merging process - > VK> do you mean I have to merge (fast-forward) changes from > VK> https://github.com/swig/swig 'master' branch to my 'master' branch at > VK> https://github.com/wkalinin/swig for it to be ready for merge to trunk? > > Hello Vladimir, > > You can't fast forward your branch as it has diverged from master since > then, so it needs to be either rebased on master or merged with it. > > Personally I think it would be nice to rebase it because the current > history is a bit weird (e.g. it starts with 2 identical commits: 2f97ad9 > and c0084fd somehow; and it also contains some strange self-merges like > c1e2a87 and b6c69c8) but I don't know if SWIG has any rules about this. > > What is certain is that currently merging swig/master into wkalinin/swig > doesn't work automatically, there are conflicts in Source/Modules/csharp.cxx > Looking at them again now, they seem less serious than when I saw them the > first time, it looks like we just should combine all changes to the > directors, both the improved smart pointer support done in master and the > nested classes support from your branch. But there could be some ordering > issues that I'm not aware of here, so it would be still better if you could > look at the merge yourself. I think this is going to be the first time we merge github branches in SWIG. I don't truly know what we should be doing. What I do know is that if I was to merge most branches, it completely confuses me with all the history of the development in the branch tangling the history of master. So in many ways I'd prefer not to see the history of the development of any of the branches, rather a single patch to apply to master with 'git am'. It seems that many projects work this way. A rebase should result in an easy to read branch history, so I'm all for a rebase too. I believe the correct etiquette is to create a new branch with the rebase as the current branch is already public. Anyway, if I merge or apply a patch, your branch needs to be in a clean working state to for merging to current master. Ultimately I would like a Github pull request. I will then either 'git merge' it or 'git am' it when the Travis tests all pass. Could you wait until 2.0.11 is released before doing this though? William |
From: Vladimir K. <vka...@op...> - 2013-09-09 19:09:01
|
> So in many ways I'd prefer not to see the history of the development of > any of the branches, rather a single patch to apply to master with 'git > am'. It seems that many projects work this way. A rebase should result > in an easy to read branch history, so I'm all for a rebase too. I > believe the correct etiquette is to create a new branch with the rebase > as the current branch is already public. I think you can also pull/merge with 'squash' option, to discard the branch history while merging. (As I said to Vadim above - doing a rebase now will require repeating a work already done) Of course, if it is not viable, I'll do the rebase - it would be good to see the changes finally in trunk, so that our clients would not have to use forked swig version. > Could you wait until 2.0.11 is released before doing this though? I'm really in no hurry ) (after all, I still didn't finish the changes you proposed on abstract classes feature implementation) Vladimir |
From: Vladimir K. <vka...@op...> - 2013-09-24 19:40:56
|
> I think this is going to be the first time we merge github branches in > SWIG. I don't truly know what we should be doing. What I do know is that > if I was to merge most branches, it completely confuses me with all the > history of the development in the branch tangling the history of master. > So in many ways I'd prefer not to see the history of the development of > any of the branches, rather a single patch to apply to master with 'git > am'. It seems that many projects work this way. A rebase should result > in an easy to read branch history, so I'm all for a rebase too. I > believe the correct etiquette is to create a new branch with the rebase > as the current branch is already public. > > Anyway, if I merge or apply a patch, your branch needs to be in a clean > working state to for merging to current master. Ultimately I would like > a Github pull request. I will then either 'git merge' it or 'git am' it > when the Travis tests all pass. Could you wait until 2.0.11 is released > before doing this though? > I merged the current swig master to my branch, so that now it can be easily merged upstream. Since you are going to ignore the branch history (--squash), doing rebase makes no sense (rebase would only be necessary to get a cleaner version of the branch history). I also posted a pull request on github. |
From: William S F. <ws...@fu...> - 2013-09-25 22:11:59
|
On 24/09/13 20:40, Vladimir Kalinin wrote: >> I think this is going to be the first time we merge github branches in >> SWIG. I don't truly know what we should be doing. What I do know is that >> if I was to merge most branches, it completely confuses me with all the >> history of the development in the branch tangling the history of master. >> So in many ways I'd prefer not to see the history of the development of >> any of the branches, rather a single patch to apply to master with 'git >> am'. It seems that many projects work this way. A rebase should result >> in an easy to read branch history, so I'm all for a rebase too. I >> believe the correct etiquette is to create a new branch with the rebase >> as the current branch is already public. >> >> Anyway, if I merge or apply a patch, your branch needs to be in a clean >> working state to for merging to current master. Ultimately I would like >> a Github pull request. I will then either 'git merge' it or 'git am' it >> when the Travis tests all pass. Could you wait until 2.0.11 is released >> before doing this though? >> > > I merged the current swig master to my branch, so that now it can be > easily merged upstream. Since you are going to ignore the branch > history (--squash), doing rebase makes no sense (rebase would only be > necessary to get a cleaner version of the branch history). > I also posted a pull request on github. > Thanks, I'll look at this next, finally, and I apologise for not getting around to it sooner. I see there are test-suite failures from the Travis build, are you looking at those? William |
From: Vladimir K. <vka...@op...> - 2013-10-10 09:43:01
|
> Thanks, I'll look at this next, finally, and I apologise for not getting > around to it sooner. I see there are test-suite failures from the Travis > build, are you looking at those? I found the corresponding travis log, and looks like there is a bug in feature:flatnested implementation (private nested classes are wrapped). (I'll look into it ASAP) I don't understand the reason of the 'go' runtime test fail though. (Will have to install 'go' and debug.) |
From: William S F. <ws...@fu...> - 2013-09-26 18:55:57
|
On 24/09/13 20:40, Vladimir Kalinin wrote: >> I think this is going to be the first time we merge github branches in >> SWIG. I don't truly know what we should be doing. What I do know is that >> if I was to merge most branches, it completely confuses me with all the >> history of the development in the branch tangling the history of master. >> So in many ways I'd prefer not to see the history of the development of >> any of the branches, rather a single patch to apply to master with 'git >> am'. It seems that many projects work this way. A rebase should result >> in an easy to read branch history, so I'm all for a rebase too. I >> believe the correct etiquette is to create a new branch with the rebase >> as the current branch is already public. >> >> Anyway, if I merge or apply a patch, your branch needs to be in a clean >> working state to for merging to current master. Ultimately I would like >> a Github pull request. I will then either 'git merge' it or 'git am' it >> when the Travis tests all pass. Could you wait until 2.0.11 is released >> before doing this though? >> > > I merged the current swig master to my branch, so that now it can be > easily merged upstream. Since you are going to ignore the branch > history (--squash), doing rebase makes no sense (rebase would only be > necessary to get a cleaner version of the branch history). > I also posted a pull request on github. Some first impressions of the patch: - Documentation needed. - As this is a major c++ feature, one fairly simple example in Examples/<lang>/nested is needed, maybe showing off two nested classes deep. - More runtime tests needed, the nested class runtime tests can be easily duplicated from Java to C#. - Nested class within the java/c# proxy class is not indented correctly. - cwrap.c:1178 directorname assignment is pointless. - In nested_class.i, the following effectively removes the test from SWIG parsing, was that the intention? -#ifdef SWIG +#if defined(__GNUC__) || defined(_MSC_VER) I'll take a deeper look next, but it basically looks like it does what it should which I think is quite exciting. Do you have any plans to extend this to other languages atm? One of the things I want to get to grips with next is what happens with the languages that havn't yet implemented support for nested classes... this behaviour needs documenting too. William |
From: Vladimir K. <vka...@op...> - 2013-10-10 11:07:52
|
> Some first impressions of the patch: > > - Documentation needed. This is what I was able to compose atm: <H2><a name="SWIGPlus_nested_classes"></a>6.27 Nested classes</H2> <p> If the target language supports the nested classes concept (like Java), the nested C++ classes are wrapped as nested target language proxy classes. (In case of Java - "static" nested classes.) Only public nested classes are wrapped. Otherwise there is little difference between nested and normal classes. </p> <p> If the target language doesn't support nested classes directly, or the support is not implemented in the language module (like for python currently), then the visible nested classes are moved to the same name space as the containing class (nesting hierarchy is "flattened"). The same behaviour may be turned on for C# and Java by the %feature ("flatnested"); </p> Would that be enough? Actually, the nested classes should require no special attention from the user, so the extensive documentation seems to be unnecessary Also, what to do with the old workarounds description - just delete it or mark as "Compatibility Note" for SWIG 2.0 and earlier? |
From: William S F. <ws...@fu...> - 2013-10-10 11:22:48
|
On Oct 10, 2013 12:07 PM, "Vladimir Kalinin" <vka...@op...> wrote: > > > Some first impressions of the patch: > > > > - Documentation needed. > > This is what I was able to compose atm: > > <H2><a name="SWIGPlus_nested_classes"></a>6.27 Nested classes</H2> > <p> > If the target language supports the nested classes concept (like Java), the nested C++ classes > are wrapped as nested target language proxy classes. (In case of Java - "static" nested classes.) > Only public nested classes are wrapped. Otherwise there is little difference between nested and > normal classes. > </p> > <p> > If the target language doesn't support nested classes directly, or the support is not implemented in the > language module (like for python currently), then the visible nested classes are moved to the same name > space as the containing class (nesting hierarchy is "flattened"). The same behaviour may be turned on for > C# and Java by the %feature ("flatnested"); > </p> > > Would that be enough? Actually, the nested classes should require no > special attention from the user, so the extensive documentation seems > to be unnecessary > Yes sounds good if it is that simple. Perhaps add on what happens with a super simple example if the nested class has the same name as one in the outer namespace. > Also, what to do with the old workarounds description - just delete > it or mark as "Compatibility Note" for SWIG 2.0 and earlier? > Yes. Can you just mention the workaround so that it can be found by users upgrading and just mention what needs doing to replace the feature and how the generated code will be different. William |