From: Leif M. <lei...@gm...> - 2012-08-20 20:48:31
|
Hello Everyone, Unfortunately, GSoC is already over and I think it's time for a little resumé: Before I go into problems I've faced and problems I've solved, I want to thank my mentor Vadim Zeitlin, who always gave good advice, responded quickly and overall was a good guide to get through this. I also must admit, that I haven't had the time I would have hoped for during the first half of the GSoC since my university assignments kept me busier than ever. Some problems I've faced: The last commit message of the C backend's original author was: "Many major improvements. Almost all testsuite compiles now.", which sounded quite good back then. I tried 'check-c-test-suite' and filtered the output, which revealed that 'only' about 18% of the tests failed. As I found out later, the generated proxy file wasn't even compiled unless a runtime test was present, which was the case for only ~4/426 tests. Compiling all the generated files raised the failing tests rate to 96%. So, sadly, I've based my proposition on completely wrong data. I started off by trying to nail down exactly which things (C++ features) were broken. To do so, I've implemented some runtime tests for test interfaces that were already there. Soon enough I noticed, that most of the test cases that were around mixed many C++ features and made it hard to determine exactly which [mix of] features were broken. I began to add test interfaces that would only test single features of the C++ language. If they tested multiple features, I made sure the test's name would indicated it. Things I've fixed: - Actually expose what's wrong (fix Makefiles) - Add a number of testcases and runtime tests for specific C++ features - Refactor code (and typemaps) massively - Add namespace support - Add some degree of type safeness and improve C API (proto)types - Improve template support - Improve natural 'char*' mapping for std::string - Improve docs Sadly, I didn't manage to reach my initially set goal of improving the C backend to a level, where it matches trunk standards. But as I explained above, this goal was set based on completly wrong assumptions. Anyway, for the near future I plan to do the following things: - Remove 'cppouttype' typemap - Repair context of enum values - Improve docs about C backend - Repair std::vector for work for all types (This will also fix a C API qualifier issue I think) Unrelated to my particular project, I keep wondering just why SWIG uses DOH instead of C++ classes, methods and functions. It made debugging extremely annoying for apparently no benefit. The backend code often contains code like "Replaceall" and other string manipulation code in place, which just doesn't look clean. I assume it's for historical reasons? Besides that, I want to thank you all for giving me the chance to hack on SWIG. I've learend a lot about its inner working and was able to improve my C++ knowledge a lot. I also want to thank all the other developers who were always very helpful and responded with advice quickly. Thanks again for the help and guidance, Best regards, Leif |
From: Vadim Z. <vz...@ze...> - 2012-08-20 21:23:20
|
On Mon, 20 Aug 2012 22:48:21 +0200 Leif Middelschulte <lei...@gm...> wrote: LM> Things I've fixed: LM> - Actually expose what's wrong (fix Makefiles) LM> - Add a number of testcases and runtime tests for specific C++ features LM> - Refactor code (and typemaps) massively LM> - Add namespace support LM> - Add some degree of type safeness and improve C API (proto)types LM> - Improve template support LM> - Improve natural 'char*' mapping for std::string LM> - Improve docs LM> LM> Sadly, I didn't manage to reach my initially set goal of improving the LM> C backend to a level, where it matches trunk standards. But as I LM> explained above, this goal was set based on completly wrong LM> assumptions. Hi, Thanks for this summary. I agree that the there turned out to be more problems with the existing code than we thought. You did improve it noticeably but it's still a pity that more couldn't been done, I'd really like to see C module in the trunk but a non-negligible amount of efforts will still be needed to make this happen. I'll try to do some of the work myself as I feel it would be a pity to leave it in its current almost-working-but-not-quite-good-enough state but I don't know when will this happen so if you're interested in continuing to work on it, it would be definitely very welcome. LM> Unrelated to my particular project, I keep wondering just why SWIG uses LM> DOH instead of C++ classes, methods and functions. I think it's mostly for historical reasons (I believe first versions of SWIG were written in C). And there are plans to change this. Unfortunately it's not that simple... Thanks for your work on this Leif, I realize it must not have been always simple for you and perhaps I should have helped you more. It would be great to see you working on SWIG in the future and maybe you'll have motivation to do it if you use it in any other projects. All the best, VZ |
From: Leif M. <lei...@gm...> - 2012-08-20 21:45:24
|
Am Montag, 20. August 2012 um 23:23 schrieb Vadim Zeitlin: > On Mon, 20 Aug 2012 22:48:21 +0200 Leif Middelschulte <lei...@gm... (mailto:lei...@gm...)> wrote: > > LM> Things I've fixed: > LM> - Actually expose what's wrong (fix Makefiles) > LM> - Add a number of testcases and runtime tests for specific C++ features > LM> - Refactor code (and typemaps) massively > LM> - Add namespace support > LM> - Add some degree of type safeness and improve C API (proto)types > LM> - Improve template support > LM> - Improve natural 'char*' mapping for std::string > LM> - Improve docs > LM> > LM> Sadly, I didn't manage to reach my initially set goal of improving the > LM> C backend to a level, where it matches trunk standards. But as I > LM> explained above, this goal was set based on completly wrong > LM> assumptions. > > Hi, > > Thanks for this summary. I agree that the there turned out to be more > problems with the existing code than we thought. You did improve it > noticeably but it's still a pity that more couldn't been done, I'd really > like to see C module in the trunk but a non-negligible amount of efforts > will still be needed to make this happen. I'll try to do some of the work > myself as I feel it would be a pity to leave it in its current > almost-working-but-not-quite-good-enough state but I don't know when will > this happen so if you're interested in continuing to work on it, it would > be definitely very welcome. > > I feel the same way. I'll probably bug you with problems to get this done soon ;-) > LM> Unrelated to my particular project, I keep wondering just why SWIG uses > LM> DOH instead of C++ classes, methods and functions. > > I think it's mostly for historical reasons (I believe first versions of > SWIG were written in C). And there are plans to change this. Unfortunately > it's not that simple... > > I'm looking forward to this day! > > Thanks for your work on this Leif, I realize it must not have been always > simple for you and perhaps I should have helped you more. > > You did a great job :) > It would be great to see you working on SWIG in the future and maybe you'll have motivation to do it if you use it in any other projects. > I love the idea behind SWIG and I'm sure I'll use it in the feature. I guess I won't maintain the C backend once it is in trunk though, because - as you might recall - I initially became interested in SWIG to leave C 'behind' :D But, who knows, maybe I'll need C++ libs in some C project in the future. > > All the best, Thanks again, Leif > VZ > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > _______________________________________________ > Swig-devel mailing list > Swi...@li... (mailto:Swi...@li...) > https://lists.sourceforge.net/lists/listinfo/swig-devel > |