You can subscribe to this list here.
2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(64) |
Dec
(161) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
(376) |
Feb
(195) |
Mar
(127) |
Apr
(30) |
May
(79) |
Jun
(83) |
Jul
(42) |
Aug
(39) |
Sep
(82) |
Oct
(102) |
Nov
(229) |
Dec
(76) |
2007 |
Jan
(62) |
Feb
(29) |
Mar
(83) |
Apr
(92) |
May
(84) |
Jun
(58) |
Jul
(36) |
Aug
(63) |
Sep
(131) |
Oct
(160) |
Nov
(46) |
Dec
(67) |
2008 |
Jan
(72) |
Feb
(82) |
Mar
(124) |
Apr
(144) |
May
(73) |
Jun
(38) |
Jul
(101) |
Aug
(26) |
Sep
(96) |
Oct
(35) |
Nov
(53) |
Dec
(92) |
2009 |
Jan
(92) |
Feb
(48) |
Mar
(90) |
Apr
(50) |
May
(104) |
Jun
(110) |
Jul
(136) |
Aug
(99) |
Sep
(80) |
Oct
(38) |
Nov
(106) |
Dec
(48) |
2010 |
Jan
(33) |
Feb
(70) |
Mar
(41) |
Apr
(54) |
May
(97) |
Jun
(76) |
Jul
(61) |
Aug
(27) |
Sep
(64) |
Oct
(74) |
Nov
(35) |
Dec
(55) |
2011 |
Jan
(66) |
Feb
(113) |
Mar
(101) |
Apr
(71) |
May
(93) |
Jun
(36) |
Jul
(30) |
Aug
(55) |
Sep
(30) |
Oct
(51) |
Nov
(59) |
Dec
(43) |
2012 |
Jan
(59) |
Feb
(32) |
Mar
(232) |
Apr
(174) |
May
(142) |
Jun
(38) |
Jul
(127) |
Aug
(99) |
Sep
(32) |
Oct
(8) |
Nov
(28) |
Dec
(144) |
2013 |
Jan
(105) |
Feb
(25) |
Mar
(70) |
Apr
(69) |
May
(40) |
Jun
(33) |
Jul
(20) |
Aug
(31) |
Sep
(82) |
Oct
(42) |
Nov
(78) |
Dec
(72) |
2014 |
Jan
(62) |
Feb
(68) |
Mar
(39) |
Apr
(54) |
May
(90) |
Jun
(87) |
Jul
(42) |
Aug
(76) |
Sep
(44) |
Oct
(49) |
Nov
(5) |
Dec
(28) |
2015 |
Jan
(33) |
Feb
(13) |
Mar
(12) |
Apr
(17) |
May
(15) |
Jun
(22) |
Jul
(16) |
Aug
(27) |
Sep
(8) |
Oct
(9) |
Nov
(14) |
Dec
(9) |
2016 |
Jan
(22) |
Feb
(15) |
Mar
(6) |
Apr
(6) |
May
(22) |
Jun
(83) |
Jul
(5) |
Aug
(9) |
Sep
(13) |
Oct
|
Nov
(31) |
Dec
(18) |
2017 |
Jan
(9) |
Feb
(15) |
Mar
(11) |
Apr
(11) |
May
(9) |
Jun
(10) |
Jul
(2) |
Aug
(1) |
Sep
(5) |
Oct
(4) |
Nov
(3) |
Dec
(9) |
2018 |
Jan
(3) |
Feb
(6) |
Mar
(1) |
Apr
(3) |
May
(8) |
Jun
(2) |
Jul
(3) |
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
|
2019 |
Jan
(3) |
Feb
(19) |
Mar
(11) |
Apr
(9) |
May
(7) |
Jun
(14) |
Jul
(1) |
Aug
(7) |
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
(3) |
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
(7) |
Jul
|
Aug
(3) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
2021 |
Jan
(8) |
Feb
(1) |
Mar
(11) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(2) |
Sep
(4) |
Oct
(9) |
Nov
(14) |
Dec
|
2022 |
Jan
(1) |
Feb
(5) |
Mar
(2) |
Apr
|
May
|
Jun
(3) |
Jul
(2) |
Aug
|
Sep
(7) |
Oct
(9) |
Nov
(5) |
Dec
(1) |
2023 |
Jan
(2) |
Feb
|
Mar
|
Apr
(2) |
May
(6) |
Jun
(1) |
Jul
|
Aug
(4) |
Sep
(4) |
Oct
|
Nov
(2) |
Dec
(5) |
2024 |
Jan
(11) |
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(9) |
Oct
(18) |
Nov
|
Dec
|
From: Jitka P. <jpl...@re...> - 2024-10-17 13:40:28
|
>> >> >> kicad - >> https://copr.fedorainfracloud.org/coprs/jplesnik/swig-rebuild/build/8117024/ > Works >> >> SWIG 4.3.0 now uses Python's structmember.h header file as part >> of a change to use heap types, see >> https://github.com/swig/swig/pull/2350. Python's header file >> defines T_NONE and this conflicts with a symbol with the same >> name defined by kicad. Attached patch removes this conflict in >> the generated wrappers. I'll also make a change in SWIG to only >> include this header file the earlier versions of SWIG where it is >> necessary to help mitigate this problem going forwards. > Kicad is failing with one more conflict symbol T_STRING. I added it to your patch and it works now. > >> pygsl - >> https://copr.fedorainfracloud.org/coprs/jplesnik/swig-rebuild/build/8117024/ >> >> >> Usual SWIG_AppendOutput problem, patch attached. > The build still failed. > https://copr.fedorainfracloud.org/coprs/jplesnik/swig-rebuild/build/8134468/ > > Thank you for all the patches. It helped me a lot. > > > I was wondering if there might be something wrong in the build. Is > there a working swig-4.2.1 build to compare with? For example, these > errors: > These errors were here also for swig 4.2.1 https://copr.fedorainfracloud.org/coprs/jplesnik/swig-test/build/8150034/ > _configtest.c:4:33: error: ‘gsl_multifit_fdfsolver’ has no member > named ‘J’ > 4 | ((gsl_multifit_fdfsolver *) 0)->J; > > appear before the two invocations of swig (one with -python and the > other with -xml). Probably nothing to do with SWIG and the problems to > look at are the test results at the end. There I can see potential > changes, eg: > > pygsl-2.4.0/src/gslwrap/interpolation.i: gsl_error_flag_drop > eval_deriv_e(double IN, double * OUTPUT){ > > and test failure: > > self = <interpolation_test.interpolation_linear > testMethod=test_eval_deriv_e> > > def test_eval_deriv_e(self): > v = self.interp.eval_deriv_e(10) > > > assert(v==2) > E assert [None, 2.0] == 2 > > As eval_deriv_e is not a void return, an extra return parameter is now > output due to the changed OUTPUT parameter when that value is NULL. > Previously the return value was swallowed return if it was NULL > (Python None), so this is a change in behaviour. I think the tests > should be adapted to the corrected version that SWIG now provides. > However, if the pygsl developers really want the original behaviour. > If so, it can be obtained by calling SWIG_Python_AppendOutput and > passing 1 for new (3rd) parameter. Attached patch does that and might > just make all the Python tests pass, but again, not really the correct > solution in my view. > > This patch will only work with swig-4.3, but try it out. If this is > the approach chosen and swig-4.2 support is needed, then a macro > similar to SWIG_AppendOutput could be used instead, something like: > > #define GSL_SWIG_AppendOutput(result, obj) > SWIG_Python_AppendOutput(result, obj, 1) > instead of the SWIG version: > #define SWIG_AppendOutput(result, obj) > SWIG_Python_AppendOutput(result, obj, $isvoid) > I would prefer fix which works for old and new version of swig. The patch you provided does not work. https://copr.fedorainfracloud.org/coprs/jplesnik/swig-rebuild/build/8150595/ Jitka -- Jitka Plesnikova Senior Software Engineer Red Hat |
From: Matěj C. <mc...@ce...> - 2024-10-14 20:42:23
|
On Tue Oct 8, 2024 at 12:33 AM CEST, William S Fulton wrote: > I have made a beta version of SWIG 4.3.0 available for testing before > making the official release. I aim to turn this into the official release > on 26 Oct if there are no major issues reported, so please test it before > then and send feedback via the Github issue tracker > <https://github.com/swig/swig/issues> or reply to this email including the > mailing lists. openSUSE has the Staging project for swig 4.3.0 at https://build.opensuse.org/project/show/openSUSE:Factory:Staging:H, logs (which are I am afraid otherwise not accessible) are at https://mcepl.fedorapeople.org/tmp/swig_logs/. Bugs are filed at https://bugzilla.suse.com/buglist.cgi?quicksearch=swig%204.3.0 I am personally working on M2Crypto (being its upstream), but I haven’t cracked it yet. Best, Matěj -- http://matej.ceplovi.cz/blog/, @mc...@fl...cial GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 If trains stop at train stations, what happens at work stations? |
From: William S F. <ws...@fu...> - 2024-10-14 20:30:37
|
On Mon, 14 Oct 2024 at 14:47, Jitka Plesnikova <jpl...@re...> wrote: > > > > On 10/11/24 10:27, William S Fulton wrote: > > > > On Thu, 10 Oct 2024 at 15:59, Jitka Plesnikova <jpl...@re...> > wrote: > >> >> On 10/8/24 22:41, William S Fulton wrote: >> Thank you for the patches, I will check them. >> BTW, there are 3 more packages which are failing with swig 4.3.0-beta1. >> >> hamlib - >> https://copr.fedorainfracloud.org/coprs/jplesnik/swig-rebuild/build/8116820/ >> > > I'm not sure what the problem here is: > > LD_LIBRARY_PATH=../src/.libs perl ../bindings/perltest.pl > > Can't call method "set_conf" without a package or object reference at ../bindings/perltest.pl line 13. > > Someone more familiar with this project will have to help out here. > > kicad - > https://copr.fedorainfracloud.org/coprs/jplesnik/swig-rebuild/build/8117024/ > > Works > > > SWIG 4.3.0 now uses Python's structmember.h header file as part of a > change to use heap types, see https://github.com/swig/swig/pull/2350. > Python's header file defines T_NONE and this conflicts with a symbol with > the same name defined by kicad. Attached patch removes this conflict in the > generated wrappers. I'll also make a change in SWIG to only include this > header file the earlier versions of SWIG where it is necessary to help > mitigate this problem going forwards. > > >> pygsl - >> https://copr.fedorainfracloud.org/coprs/jplesnik/swig-rebuild/build/8117024/ >> > > Usual SWIG_AppendOutput problem, patch attached. > > The build still failed. > > https://copr.fedorainfracloud.org/coprs/jplesnik/swig-rebuild/build/8134468/ > > Thank you for all the patches. It helped me a lot. > I was wondering if there might be something wrong in the build. Is there a working swig-4.2.1 build to compare with? For example, these errors: _configtest.c:4:33: error: ‘gsl_multifit_fdfsolver’ has no member named ‘J’ 4 | ((gsl_multifit_fdfsolver *) 0)->J; appear before the two invocations of swig (one with -python and the other with -xml). Probably nothing to do with SWIG and the problems to look at are the test results at the end. There I can see potential changes, eg: pygsl-2.4.0/src/gslwrap/interpolation.i: gsl_error_flag_drop eval_deriv_e(double IN, double * OUTPUT){ and test failure: self = <interpolation_test.interpolation_linear testMethod=test_eval_deriv_e> def test_eval_deriv_e(self): v = self.interp.eval_deriv_e(10) > assert(v==2) E assert [None, 2.0] == 2 As eval_deriv_e is not a void return, an extra return parameter is now output due to the changed OUTPUT parameter when that value is NULL. Previously the return value was swallowed return if it was NULL (Python None), so this is a change in behaviour. I think the tests should be adapted to the corrected version that SWIG now provides. However, if the pygsl developers really want the original behaviour. If so, it can be obtained by calling SWIG_Python_AppendOutput and passing 1 for new (3rd) parameter. Attached patch does that and might just make all the Python tests pass, but again, not really the correct solution in my view. This patch will only work with swig-4.3, but try it out. If this is the approach chosen and swig-4.2 support is needed, then a macro similar to SWIG_AppendOutput could be used instead, something like: #define GSL_SWIG_AppendOutput(result, obj) SWIG_Python_AppendOutput(result, obj, 1) instead of the SWIG version: #define SWIG_AppendOutput(result, obj) SWIG_Python_AppendOutput(result, obj, $isvoid) William |
From: Jitka P. <jpl...@re...> - 2024-10-14 13:47:44
|
On 10/11/24 10:27, William S Fulton wrote: > > > On Thu, 10 Oct 2024 at 15:59, Jitka Plesnikova <jpl...@re...> > wrote: > > > On 10/8/24 22:41, William S Fulton wrote: > Thank you for the patches, I will check them. > BTW, there are 3 more packages which are failing with swig > 4.3.0-beta1. > > hamlib - > https://copr.fedorainfracloud.org/coprs/jplesnik/swig-rebuild/build/8116820/ > > > I'm not sure what the problem here is: > LD_LIBRARY_PATH=../src/.libs perl ../bindings/perltest.pl <http://perltest.pl> > Can't call method "set_conf" without a package or object reference at ../bindings/perltest.pl <http://perltest.pl> line 13. > Someone more familiar with this project will have to help out here. > > kicad - > https://copr.fedorainfracloud.org/coprs/jplesnik/swig-rebuild/build/8117024/ Works > > SWIG 4.3.0 now uses Python's structmember.h header file as part of a > change to use heap types, see https://github.com/swig/swig/pull/2350. > Python's header file defines T_NONE and this conflicts with a symbol > with the same name defined by kicad. Attached patch removes this > conflict in the generated wrappers. I'll also make a change in SWIG to > only include this header file the earlier versions of SWIG where it is > necessary to help mitigate this problem going forwards. > > pygsl - > https://copr.fedorainfracloud.org/coprs/jplesnik/swig-rebuild/build/8117024/ > > > Usual SWIG_AppendOutput problem, patch attached. The build still failed. https://copr.fedorainfracloud.org/coprs/jplesnik/swig-rebuild/build/8134468/ Thank you for all the patches. It helped me a lot. SWIG in Copr contains the latest changes from git. Jitka -- Jitka Plesnikova Senior Software Engineer Red Hat |
From: William S F. <ws...@fu...> - 2024-10-11 17:39:38
|
> Thank you for the patches, I will check them. > I saw the failures for libftdi in https://copr.fedorainfracloud.org/coprs/jplesnik/swig-rebuild/build/8126509/ with the patch I sent. I've attached a fixed patch taking account that the preprocessor was not used for these typemaps, if you could apply this one instead please, it should then work. William |
From: William S F. <ws...@fu...> - 2024-10-11 08:28:40
|
On Thu, 10 Oct 2024 at 15:59, Jitka Plesnikova <jpl...@re...> wrote: > > On 10/8/24 22:41, William S Fulton wrote: > Thank you for the patches, I will check them. > BTW, there are 3 more packages which are failing with swig 4.3.0-beta1. > > hamlib - > https://copr.fedorainfracloud.org/coprs/jplesnik/swig-rebuild/build/8116820/ > I'm not sure what the problem here is: LD_LIBRARY_PATH=../src/.libs perl ../bindings/perltest.pl Can't call method "set_conf" without a package or object reference at ../bindings/perltest.pl line 13. Someone more familiar with this project will have to help out here. kicad - https://copr.fedorainfracloud.org/coprs/jplesnik/swig-rebuild/build/8117024/ SWIG 4.3.0 now uses Python's structmember.h header file as part of a change to use heap types, see https://github.com/swig/swig/pull/2350. Python's header file defines T_NONE and this conflicts with a symbol with the same name defined by kicad. Attached patch removes this conflict in the generated wrappers. I'll also make a change in SWIG to only include this header file the earlier versions of SWIG where it is necessary to help mitigate this problem going forwards. > pygsl - > https://copr.fedorainfracloud.org/coprs/jplesnik/swig-rebuild/build/8117024/ > Usual SWIG_AppendOutput problem, patch attached. William |
From: Jitka P. <jpl...@re...> - 2024-10-10 14:59:42
|
On 10/8/24 22:41, William S Fulton wrote: > >> SWIG_Python_AppendOutput() now takes three parameters (as do the >> equivalent helper functions for other target languages). >> >> User typemaps probably shouldn't be calling these >> language-specific >> helpers directly - just replace uses with SWIG_AppendOutput() >> which >> still takes two parameters (which will work with old and new SWIG >> versions). >> >> >> Yes, that's the fix I was going suggest too, except if they are >> using this function outside of typemaps, then they would need to >> keep calling SWIG_Python_AppendOutput, but set the final argument >> to either 0 or 1. Set to 1 for full backwards compatibility, but >> the correct approach is to set it to 0 or 1 in the same way that >> the new $isvoid special variables expands to 1 if wrapping a >> function returning void or 0 if wrapping a function not returning >> void. >> >> Jitka, I can put together patches for these quite quickly, but >> with caveat I can't test it easily. The patches should work with >> older versions of SWIG as well as latest. I've attached one for >> gnucash. If I do this, is the patch format okay, or do you prefer >> something slightly different? >> > The patches would be fine. I'll test them in my rebuild and then > report it to upstream and Fedora maintainer. > > > Thanks Jitka. I've attached patches for the all the remaining failing > projects in your list above. The only one I'm not entirely sure about > is plplot, but let me know if you see any problems and I'll track your > rebuilds too for these. Also just noticed that I got the gnucash patch > in reverse, sorry, but I see you figured that out! > > William > Thank you for the patches, I will check them. BTW, there are 3 more packages which are failing with swig 4.3.0-beta1. hamlib - https://copr.fedorainfracloud.org/coprs/jplesnik/swig-rebuild/build/8116820/ kicad - https://copr.fedorainfracloud.org/coprs/jplesnik/swig-rebuild/build/8117024/ pygsl - https://copr.fedorainfracloud.org/coprs/jplesnik/swig-rebuild/build/8117024/ Could you please look on them? Regards, Jitka -- Jitka Plesnikova Senior Software Engineer Red Hat |
From: William S F. <ws...@fu...> - 2024-10-08 21:13:22
|
That's pretty cool, thanks for letting us know. Wiliam On Tue, 8 Oct 2024 at 15:36, John Wyatt <jw...@re...> wrote: > Hello everyone, > > I submitted a simple SWIG Python implementation for 6.12-rc1 for the Linux > kernel's cpupower utility that was developed with 4.2.1. SWIG is now used > in the Linux kernel for a user-space utility. > > I ran the test script on my locally compiled 4.3.0-beta1. No issues as far > as I can tell at this point with Fedora 40 and Python 3.12.6. > > The current version of this simple test script (test_raw_pylibcpupower.py > <https://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux.git/tree/tools/power/cpupower/bindings/python/test_raw_pylibcpupower.py?h=cpupower>) > I used is at: > > https://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux.git/tree/tools/power/cpupower/bindings/python?h=cpupower > > Thank you for your work on SWIG. > > P.S. > We had to use the .swg file extension because the kernel uses .i for > something else and it is gitignored. > > On Mon, Oct 7, 2024 at 6:35 PM William S Fulton <ws...@fu...> > wrote: > >> I have made a beta version of SWIG 4.3.0 available for testing before >> making the official release. I aim to turn this into the official release >> on 26 Oct if there are no major issues reported, so please test it before >> then and send feedback via the Github issue tracker >> <https://github.com/swig/swig/issues> or reply to this email including >> the mailing lists. >> >> Download it from here: >> >> Source tarball: >> http://prdownloads.sourceforge.net/swig/swig-4.3.0-beta1.tar.gz >> Windows prebuilt executable: >> http://prdownloads.sourceforge.net/swig/swigwin-4.3.0-beta1.zip >> >> Summary of changes: >> >> - Add experimental support for C as a target language. >> - MzScheme/Racket is deprecated and planned for removal in SWIG-4.4. >> - The distributed Windows binary is now a 64-bit executable. >> - Add some missing use of move semantics for performance improvements. >> - Enhanced handling of namespaces when using the nspace feature. >> - STL wrapper enhancements for std::unique_ptr, std::string_view, >> std::filesystem. >> - Various enum and enum class wrapping improvements. >> - Other C++ handling improvements around templates, friends, C++11 >> trailing return types and C++17 fold expressions. >> - Many parser improvements for both C and C++, especially expressions. >> - Improvements to handling of string and character literals. >> - Minor preprocessor fixes. >> - Python: Stricter stable ABI conformance, add support for python-3.13. >> - C#: Add support for converting Doxygen comments into XML C# comments. >> - Various other target language specific enhancements and updates for >> Java, Javascript, Lua, MzScheme, Ocaml, Octave, Perl, Python, R, Ruby. >> >> More detailed information is in the CHANGES.current file in the release. >> >> William >> _______________________________________________ >> Swig-user mailing list >> Swi...@li... >> https://lists.sourceforge.net/lists/listinfo/swig-user >> > |
From: William S F. <ws...@fu...> - 2024-10-08 20:48:39
|
I've just pushed the tag now: v4.3.0-beta1 William On Tue, 8 Oct 2024 at 16:42, Lowekamp, Bradley (NIH/NIAID) [C] < blo...@ma...> wrote: > Hello, > > > > Is there an associated tag on Github? I have build infrastructure that can > easily use a SWIG version from a GH tag or hash. > > > > Thanks, > > Bradley > > > > *From: *William S Fulton <ws...@fu...> > *Date: *Monday, October 7, 2024 at 6:37 PM > *To: *swig-user <swi...@li...>, swig-devel < > swi...@li...> > *Subject: *[EXTERNAL] [Swig-user] swig-4.3.0 beta1 release available for > testing > > I have made a beta version of SWIG 4.3.0 available for testing before > making the official release. I aim to turn this into the official release > on 26 Oct if there are no major issues reported, so please test it before > then and send feedback via the Github issue tracker > <https://github.com/swig/swig/issues> or reply to this email including > the mailing lists. > > > > Download it from here: > > > > Source tarball: > http://prdownloads.sourceforge.net/swig/swig-4.3.0-beta1.tar.gz > > Windows prebuilt executable: > http://prdownloads.sourceforge.net/swig/swigwin-4.3.0-beta1.zip > > > > Summary of changes: > > > > - Add experimental support for C as a target language. > - MzScheme/Racket is deprecated and planned for removal in SWIG-4.4. > - The distributed Windows binary is now a 64-bit executable. > - Add some missing use of move semantics for performance improvements. > - Enhanced handling of namespaces when using the nspace feature. > - STL wrapper enhancements for std::unique_ptr, std::string_view, > std::filesystem. > - Various enum and enum class wrapping improvements. > - Other C++ handling improvements around templates, friends, C++11 > trailing return types and C++17 fold expressions. > - Many parser improvements for both C and C++, especially expressions. > - Improvements to handling of string and character literals. > - Minor preprocessor fixes. > - Python: Stricter stable ABI conformance, add support for python-3.13. > - C#: Add support for converting Doxygen comments into XML C# comments. > - Various other target language specific enhancements and updates for > Java, Javascript, Lua, MzScheme, Ocaml, Octave, Perl, Python, R, Ruby. > > > > More detailed information is in the CHANGES.current file in the release. > > > > William > > CAUTION: This email originated from outside of the organization. Do not > click links or open attachments unless you recognize the sender and are > confident the content is safe. > > > |
From: William S F. <ws...@fu...> - 2024-10-08 20:42:22
|
On Tue, 8 Oct 2024 at 07:03, Jitka Plesnikova <jpl...@re...> wrote: > > > > On 10/7/24 20:38, William S Fulton wrote: > > > > On Mon, 7 Oct 2024 at 19:11, Olly Betts <ol...@su...> wrote: > >> On 2024-10-07, Jitka Plesnikova <jpl...@re...> wrote: >> > last week,I ran scratch rebuild of swig dependencies which we had in >> Fedora. >> > >> > Some packages were failing with similar error, e.g. babeltrace2: >> > >> > bt2/native_bt.c: In function ?_wrap_clock_class_get_offset?: >> > bt2/native_bt.c:4251:17: error: too few arguments to function >> > ?SWIG_Python_AppendOutput? >> > 4251 | resultobj = SWIG_Python_AppendOutput(resultobj, >> > SWIG_From_long_SS_long((*arg2))); >> > | ^~~~~~~~~~~~~~~~~~~~~~~~ >> > >> > The complete log could be found on >> > >> https://copr.fedorainfracloud.org/coprs/jplesnik/swig-rebuild/build/8112850/ >> > >> > The other packages which failed with such errors are: >> > gnucash >> > ldns >> > libftdi >> > libselinux >> > libsemanage >> > plplot >> > python-cmake-build-extension >> > uboot-tools >> > >> > Today, I rebuilt these packages with swig from the latest commit >> > (2c3e1ec74) and the builds >> > are still failing. >> > >> > Do you know, what could be wrong? >> >> SWIG_Python_AppendOutput() now takes three parameters (as do the >> equivalent helper functions for other target languages). >> >> User typemaps probably shouldn't be calling these language-specific >> helpers directly - just replace uses with SWIG_AppendOutput() which >> still takes two parameters (which will work with old and new SWIG >> versions). > > > Yes, that's the fix I was going suggest too, except if they are using this > function outside of typemaps, then they would need to keep calling > SWIG_Python_AppendOutput, but set the final argument to either 0 or 1. Set > to 1 for full backwards compatibility, but the correct approach is to set > it to 0 or 1 in the same way that the new $isvoid special variables expands > to 1 if wrapping a function returning void or 0 if wrapping a function not > returning void. > > Jitka, I can put together patches for these quite quickly, but with caveat > I can't test it easily. The patches should work with older versions of SWIG > as well as latest. I've attached one for gnucash. If I do this, is the > patch format okay, or do you prefer something slightly different? > > The patches would be fine. I'll test them in my rebuild and then report it > to upstream and Fedora maintainer. > Thanks Jitka. I've attached patches for the all the remaining failing projects in your list above. The only one I'm not entirely sure about is plplot, but let me know if you see any problems and I'll track your rebuilds too for these. Also just noticed that I got the gnucash patch in reverse, sorry, but I see you figured that out! William |
From: Roderick G. <Rod...@au...> - 2024-10-08 16:20:59
|
I'm working to pull together a patch that fixes https://github.com/swig/swig/issues/945 and https://sourceforge.net/p/swig/bugs/1314/ for csharp. I independently discovered this same error while wrapping a large library and posted to github discussions here: https://github.com/swig/swig/discussions/3006. Before I get too much further into this, I want to make sure you are open to accepting a patch for this. I think it is necessarily a breaking change since it requires a new ctor argument on the proxy classes to provide a reference to the memory owner. I pushed some unit tests to https://github.com/roderickgreen/swig/tree/csharp-gc-keepalive. I can strip out the instrumentation I added if you are interested in seeing the WIP patch. It follows the pattern from the patch in the sourceforge bug tracker that Greg Knight provided, and I'm working on handling the rest of the code paths to get all the tests passing. Thanks, Rod ________________________________ The information contained in this e-mail and any attachments from Auria.space may contain confidential and/or proprietary information, and is intended only for the named recipient to whom it was originally addressed. If you are not the intended recipient, any disclosure, distribution, or copying of this e-mail or its attachments is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by return e-mail and permanently delete the e-mail and any attachments. |
From: Jitka P. <jpl...@re...> - 2024-10-08 06:02:56
|
On 10/7/24 20:38, William S Fulton wrote: > > > On Mon, 7 Oct 2024 at 19:11, Olly Betts <ol...@su...> wrote: > > On 2024-10-07, Jitka Plesnikova <jpl...@re...> wrote: > > last week,I ran scratch rebuild of swig dependencies which we > had in Fedora. > > > > Some packages were failing with similar error, e.g. babeltrace2: > > > > bt2/native_bt.c: In function ?_wrap_clock_class_get_offset?: > > bt2/native_bt.c:4251:17: error: too few arguments to function > > ?SWIG_Python_AppendOutput? > > 4251 | resultobj = SWIG_Python_AppendOutput(resultobj, > > SWIG_From_long_SS_long((*arg2))); > > | ^~~~~~~~~~~~~~~~~~~~~~~~ > > > > The complete log could be found on > > > https://copr.fedorainfracloud.org/coprs/jplesnik/swig-rebuild/build/8112850/ > > > > The other packages which failed with such errors are: > > gnucash > > ldns > > libftdi > > libselinux > > libsemanage > > plplot > > python-cmake-build-extension > > uboot-tools > > > > Today, I rebuilt these packages with swig from the latest commit > > (2c3e1ec74) and the builds > > are still failing. > > > > Do you know, what could be wrong? > > SWIG_Python_AppendOutput() now takes three parameters (as do the > equivalent helper functions for other target languages). > > User typemaps probably shouldn't be calling these language-specific > helpers directly - just replace uses with SWIG_AppendOutput() which > still takes two parameters (which will work with old and new SWIG > versions). > > > Yes, that's the fix I was going suggest too, except if they are using > this function outside of typemaps, then they would need to keep > calling SWIG_Python_AppendOutput, but set the final argument to either > 0 or 1. Set to 1 for full backwards compatibility, but the correct > approach is to set it to 0 or 1 in the same way that the new $isvoid > special variables expands to 1 if wrapping a function returning void > or 0 if wrapping a function not returning void. > > Jitka, I can put together patches for these quite quickly, but with > caveat I can't test it easily. The patches should work with older > versions of SWIG as well as latest. I've attached one for gnucash. If > I do this, is the patch format okay, or do you prefer something > slightly different? > The patches would be fine. I'll test them in my rebuild and then report it to upstream and Fedora maintainer. Jitka > William > > P.S. I'm planning on pushkng out the 4.3.0 release candidate in a few > hours time. > > > _______________________________________________ > Swig-devel mailing list > Swi...@li... > https://lists.sourceforge.net/lists/listinfo/swig-devel -- Jitka Plesnikova Senior Software Engineer Red Hat |
From: William S F. <ws...@fu...> - 2024-10-07 22:34:25
|
I have made a beta version of SWIG 4.3.0 available for testing before making the official release. I aim to turn this into the official release on 26 Oct if there are no major issues reported, so please test it before then and send feedback via the Github issue tracker <https://github.com/swig/swig/issues> or reply to this email including the mailing lists. Download it from here: Source tarball: http://prdownloads.sourceforge.net/swig/swig-4.3.0-beta1.tar.gz Windows prebuilt executable: http://prdownloads.sourceforge.net/swig/swigwin-4.3.0-beta1.zip Summary of changes: - Add experimental support for C as a target language. - MzScheme/Racket is deprecated and planned for removal in SWIG-4.4. - The distributed Windows binary is now a 64-bit executable. - Add some missing use of move semantics for performance improvements. - Enhanced handling of namespaces when using the nspace feature. - STL wrapper enhancements for std::unique_ptr, std::string_view, std::filesystem. - Various enum and enum class wrapping improvements. - Other C++ handling improvements around templates, friends, C++11 trailing return types and C++17 fold expressions. - Many parser improvements for both C and C++, especially expressions. - Improvements to handling of string and character literals. - Minor preprocessor fixes. - Python: Stricter stable ABI conformance, add support for python-3.13. - C#: Add support for converting Doxygen comments into XML C# comments. - Various other target language specific enhancements and updates for Java, Javascript, Lua, MzScheme, Ocaml, Octave, Perl, Python, R, Ruby. More detailed information is in the CHANGES.current file in the release. William |
From: William S F. <ws...@fu...> - 2024-10-07 18:40:03
|
On Mon, 7 Oct 2024 at 19:38, William S Fulton <ws...@fu...> wrote: > > > On Mon, 7 Oct 2024 at 19:11, Olly Betts <ol...@su...> wrote: > >> On 2024-10-07, Jitka Plesnikova <jpl...@re...> wrote: >> > last week,I ran scratch rebuild of swig dependencies which we had in >> Fedora. >> > >> > Some packages were failing with similar error, e.g. babeltrace2: >> > >> > bt2/native_bt.c: In function ?_wrap_clock_class_get_offset?: >> > bt2/native_bt.c:4251:17: error: too few arguments to function >> > ?SWIG_Python_AppendOutput? >> > 4251 | resultobj = SWIG_Python_AppendOutput(resultobj, >> > SWIG_From_long_SS_long((*arg2))); >> > | ^~~~~~~~~~~~~~~~~~~~~~~~ >> > >> > The complete log could be found on >> > >> https://copr.fedorainfracloud.org/coprs/jplesnik/swig-rebuild/build/8112850/ >> > >> > The other packages which failed with such errors are: >> > gnucash >> > ldns >> > libftdi >> > libselinux >> > libsemanage >> > plplot >> > python-cmake-build-extension >> > uboot-tools >> > >> > Today, I rebuilt these packages with swig from the latest commit >> > (2c3e1ec74) and the builds >> > are still failing. >> > >> > Do you know, what could be wrong? >> >> SWIG_Python_AppendOutput() now takes three parameters (as do the >> equivalent helper functions for other target languages). >> >> User typemaps probably shouldn't be calling these language-specific >> helpers directly - just replace uses with SWIG_AppendOutput() which >> still takes two parameters (which will work with old and new SWIG >> versions). > > > Yes, that's the fix I was going suggest too, except if they are using this > function outside of typemaps, then they would need to keep calling > SWIG_Python_AppendOutput, but set the final argument to either 0 or 1. Set > to 1 for full backwards compatibility, but the correct approach is to set > it to 0 or 1 in the same way that the new $isvoid special variables expands > to 1 if wrapping a function returning void or 0 if wrapping a function not > returning void. > > Jitka, I can put together patches for these quite quickly, but with caveat > I can't test it easily. The patches should work with older versions of SWIG > as well as latest. I've attached one for gnucash. If I do this, is the > patch format okay, or do you prefer something slightly different? > > William > > P.S. I'm planning on pushkng out the 4.3.0 release candidate in a few > hours time. > Missing patch attached. |
From: William S F. <ws...@fu...> - 2024-10-07 18:38:47
|
On Mon, 7 Oct 2024 at 19:11, Olly Betts <ol...@su...> wrote: > On 2024-10-07, Jitka Plesnikova <jpl...@re...> wrote: > > last week,I ran scratch rebuild of swig dependencies which we had in > Fedora. > > > > Some packages were failing with similar error, e.g. babeltrace2: > > > > bt2/native_bt.c: In function ?_wrap_clock_class_get_offset?: > > bt2/native_bt.c:4251:17: error: too few arguments to function > > ?SWIG_Python_AppendOutput? > > 4251 | resultobj = SWIG_Python_AppendOutput(resultobj, > > SWIG_From_long_SS_long((*arg2))); > > | ^~~~~~~~~~~~~~~~~~~~~~~~ > > > > The complete log could be found on > > > https://copr.fedorainfracloud.org/coprs/jplesnik/swig-rebuild/build/8112850/ > > > > The other packages which failed with such errors are: > > gnucash > > ldns > > libftdi > > libselinux > > libsemanage > > plplot > > python-cmake-build-extension > > uboot-tools > > > > Today, I rebuilt these packages with swig from the latest commit > > (2c3e1ec74) and the builds > > are still failing. > > > > Do you know, what could be wrong? > > SWIG_Python_AppendOutput() now takes three parameters (as do the > equivalent helper functions for other target languages). > > User typemaps probably shouldn't be calling these language-specific > helpers directly - just replace uses with SWIG_AppendOutput() which > still takes two parameters (which will work with old and new SWIG > versions). Yes, that's the fix I was going suggest too, except if they are using this function outside of typemaps, then they would need to keep calling SWIG_Python_AppendOutput, but set the final argument to either 0 or 1. Set to 1 for full backwards compatibility, but the correct approach is to set it to 0 or 1 in the same way that the new $isvoid special variables expands to 1 if wrapping a function returning void or 0 if wrapping a function not returning void. Jitka, I can put together patches for these quite quickly, but with caveat I can't test it easily. The patches should work with older versions of SWIG as well as latest. I've attached one for gnucash. If I do this, is the patch format okay, or do you prefer something slightly different? William P.S. I'm planning on pushkng out the 4.3.0 release candidate in a few hours time. |
From: Olly B. <ol...@su...> - 2024-10-07 18:11:40
|
On 2024-10-07, Jitka Plesnikova <jpl...@re...> wrote: > last week,I ran scratch rebuild of swig dependencies which we had in Fedora. > > Some packages were failing with similar error, e.g. babeltrace2: > > bt2/native_bt.c: In function ?_wrap_clock_class_get_offset?: > bt2/native_bt.c:4251:17: error: too few arguments to function > ?SWIG_Python_AppendOutput? > 4251 | resultobj = SWIG_Python_AppendOutput(resultobj, > SWIG_From_long_SS_long((*arg2))); > | ^~~~~~~~~~~~~~~~~~~~~~~~ > > The complete log could be found on > https://copr.fedorainfracloud.org/coprs/jplesnik/swig-rebuild/build/8112850/ > > The other packages which failed with such errors are: > gnucash > ldns > libftdi > libselinux > libsemanage > plplot > python-cmake-build-extension > uboot-tools > > Today, I rebuilt these packages with swig from the latest commit > (2c3e1ec74) and the builds > are still failing. > > Do you know, what could be wrong? SWIG_Python_AppendOutput() now takes three parameters (as do the equivalent helper functions for other target languages). User typemaps probably shouldn't be calling these language-specific helpers directly - just replace uses with SWIG_AppendOutput() which still takes two parameters (which will work with old and new SWIG versions). Cheers, Olly |
From: Jitka P. <jpl...@re...> - 2024-10-07 11:27:23
|
Hi, last week,I ran scratch rebuild of swig dependencies which we had in Fedora. Some packages were failing with similar error, e.g. babeltrace2: bt2/native_bt.c: In function ?_wrap_clock_class_get_offset?: bt2/native_bt.c:4251:17: error: too few arguments to function ?SWIG_Python_AppendOutput? 4251 | resultobj = SWIG_Python_AppendOutput(resultobj, SWIG_From_long_SS_long((*arg2))); | ^~~~~~~~~~~~~~~~~~~~~~~~ The complete log could be found on https://copr.fedorainfracloud.org/coprs/jplesnik/swig-rebuild/build/8112850/ The other packages which failed with such errors are: gnucash ldns libftdi libselinux libsemanage plplot python-cmake-build-extension uboot-tools Today, I rebuilt these packages with swig from the latest commit (2c3e1ec74) and the builds are still failing. Do you know, what could be wrong? BTW, you can see difference between build with swig 4.2.1 https://copr.fedorainfracloud.org/coprs/jplesnik/swig-test/monitor/ swig 4.3.0 https://copr.fedorainfracloud.org/coprs/jplesnik/swig-rebuild/monitor/ Jitka On 8/23/24 20:24, William S Fulton wrote: > https://github.com/swig/swig/pull/2925 brought up the question of when > we can release the fixes for python-3.13 which will be released on 1 > Oct. We could either > > 1. Release a swig-4.2.2 with just the python-3.13 support. > 2. Release swig-4.3.0 pretty much as it is, possibly with a follow-up > swig-4.3.1 patch release soon afterwards. > > The swig-4.2.2 patch release might be a bit risky in introducing > regressions, but with just a couple of patches might be okay, but > still require time and effort. My preference is for swig-4.3.0 as it > is generally better to release fewer changes more often and we have > about 8 months development now waiting to be released. In the past > we've taken too long to push out all the good work that's been > committed. I don't have any grander plan for swig-4.3.0, so as far as > I'm concerned it's feature complete. Perhaps we can polish this > version off for pushing out in say the 2nd or 3rd week of September. > > There are a few issues tagged in the swig-4.3 milestone, > https://github.com/swig/swig/milestone/8. Apart from one or two > regressions, I don't think there is anything there that can't be > bumped into swig-4.4. > > Any other thoughts? > > William > -- Jitka Plesnikova Senior Software Engineer Red Hat |
From: Jitka P. <jpl...@re...> - 2024-10-01 07:15:14
|
> Jitka, will you be able to kick off a Fedora run with the release > candidate when I push it out? Yes, I will do it. I tried to rebuild swig from the commit 0ecd145 and two Python tests failed on architecture i686 with following error: checking python testcase cpp_parameters (with run test) Traceback (most recent call last): File "/builddir/build/BUILD/swig-4.3.0-build/swig-4.3.0/Examples/test-suite/python/./cpp_parameters_runme.py", line 293, in <module> x = Single(a=1) TypeError: Single.__init__() got an unexpected keyword argument 'a' make[1]: *** [Makefile:140: cpp_parameters.cpptest] Error 1 checking python testcase cpp_static (with run test) checking python testcase cpp_typedef checking python testcase curiously_recurring_template_pattern checking python testcase default_args (with run test) checking python testcase default_arg_expressions checking python testcase default_arg_values (with run test) Traceback (most recent call last): File "/builddir/build/BUILD/swig-4.3.0-build/swig-4.3.0/Examples/test-suite/python/./default_arg_values_runme.py", line 19, in <module> raise RuntimeError RuntimeError make[1]: *** [Makefile:140: default_arg_values.cpptest] Error 1 You can check the swig build on link https://koji.fedoraproject.org/koji/taskinfo?taskID=124222053 Jitka -- Jitka Plesnikova Senior Software Engineer Red Hat |
From: William S F. <ws...@fu...> - 2024-09-29 16:50:50
|
On Sun, 29 Sept 2024 at 11:32, William S Fulton <ws...@fu...> wrote: > > Update, I'll try push out a release candidate in the next 48 hours unless > there is any 'must have' issue I've missed, let me know. > Olly, could you please check and expand the recently updated RELEASENOTES file with your various parser enhancements. William |
From: William S F. <ws...@fu...> - 2024-09-29 10:33:14
|
Update, I'll try push out a release candidate in the next 48 hours unless there is any 'must have' issue I've missed, let me know. > > I saw a lot of issues being added to the 4.3 milestone, but didn't > > understand the motivation for a lot of these. > > When I set (or change or remove) a milestone I aim to provide a > rationale in the ticket, unless it is entirely obvious from the > discussion (e.g. if you said something like "We really need to fix this > for 4.3.0" then it seems obvious to set the milestone). > > Checking the tickets which are and were on the 4.3 milestone, I don't > see *any* where it seems unclear why I set the milestone, so it's really > hard to respond usefully to a general complaint that you didn't > understand the motivation, especially for "a lot of these". > > If there are specific examples, please identify them and I can more > usefully comment. > Okay, sorry, that's an exaggeration. There are just a few that I don't have time for and seem low priority but will try and comment on them today. > > I havn't done any manual testing for a few years now since we moved to > > Github Actions and also used Appveyor for Windows. The Fedora testing > that > > Jitka does is the most fantastic thing too as it does a ton of stuff we > > can't do. > > Even Jitka's testing is mostly automated. Jitka, will you be able to kick off a Fedora run with the release candidate when I push it out? William |
From: William S F. <ws...@fu...> - 2024-09-26 12:40:25
|
Hi Dariusz Great! You just need a Github account, fork the swig repository, create a branch, commit your changes, then raise a pull request against the main swig repository. In other words, just follow the standard Github workflow to raise a pull request. All the tests will run within Github CI using Github Actions, so look out for those results to make sure the tests all pass. You'll also need to add in a test for your new code. See the docs on the SWIG test-suite at https://swig.org/Doc4.2/Extending.html#Extending_test_suite. William On Thu, 26 Sept 2024 at 13:34, Dariusz Ozygała <dar...@gm...> wrote: > Oh, that's nice. Actually we're also using our implementation for > std::function, but it's written by my collegue, so I'm oriented about that. > > When are you about to share this implementation for optional? > > czw., 26 wrz 2024, 14:25 użytkownik Christophe CALMEJANE < > chr...@l-...> napisał: > >> Hi, >> >> >> >> This is very interesting. On my side, I’m about to provide std::optional >> for C# and Python. Maybe it would be worth doing it together so it will >> cause less conflicts (and/or overhead). >> >> >> >> PS: I’m also going to provide std::function, std::chrono and std::tuple >> for C# and Python soon >> >> >> >> *Christophe CALMEJANE* >> >> Head of Technology, Middleware & Tools >> >> 13 Rue Levacher Cintrat >> <https://www.google.com/maps/search/13+Rue+Levacher+Cintrat?entry=gmail&source=g>, >> Parc Fontaine de Jouvence - 91460 Marcoussis - France >> Office : +33 1 70 84 08 98 >> >> >> l-acoustics.com >> >> <https://cloud.letsignit.com/collect/bc/64a7be18452a27db4360347b?p=UsTT3QRdxkzMmk8xWrTuV-uvIKAerqcZMr6658o8-taqTH6nWN6ZOM_Zy_q5b3x-VHo3zXRxrOe-IptTyhxCN2Rh9feXLiyWXdTMD1_8sy0mRKcAbIcY9EZYZKbviCE5yGd3tnlp7kBBVIKkAYwW0ZOXmUKQMhhzKNAXYq6Sn1hDmZx-ixmR73WCMx5w1u8RVm5w0rE8ATXQDni8p7dPMA==> >> >> <https://cloud.letsignit.com/collect/bc/64a7be18452a27db4360347b?p=UsTT3QRdxkzMmk8xWrTuV-uvIKAerqcZMr6658o8-taqTH6nWN6ZOM_Zy_q5b3x-VHo3zXRxrOe-IptTyhxCN2Rh9feXLiyWXdTMD1_8sy0mRKcAbIcY9EZYZKbviCE5krCQI7iOjKL9rcShM_dPkWyzshVh0h15MJjhKYhaTywwGK6nFl6NKEoi308fdsESJIkCnGW1O7C8EfmpIebWAw==> >> >> <https://cloud.letsignit.com/collect/bc/64a7be18452a27db4360347b?p=UsTT3QRdxkzMmk8xWrTuV-uvIKAerqcZMr6658o8-taqTH6nWN6ZOM_Zy_q5b3x-VHo3zXRxrOe-IptTyhxCN2Rh9feXLiyWXdTMD1_8sy02FJau7ravxn65ADDCFsrjQ5aqYW9g6SQ8F69CCS6-v-AA2tKPDXmcvjvjLIIjvyRUB-zpwjSP9Z_VrOKzUBybGPQcvBwwSRq6M2KrCjraYA==> >> >> <https://cloud.letsignit.com/collect/bc/64a7be18452a27db4360347b?p=UsTT3QRdxkzMmk8xWrTuV-uvIKAerqcZMr6658o8-taqTH6nWN6ZOM_Zy_q5b3x-VHo3zXRxrOe-IptTyhxCN2Rh9feXLiyWXdTMD1_8sy0LNijUNdUicuCOSnTBvePS5vNpnlj3JUYx_sJFFyu5S5UR6XJ8H3l0CTIGsj9k87ckiQKcZbU7sLwR-akh5tYD> >> >> <https://cloud.letsignit.com/collect/bc/64a7be18452a27db4360347b?p=UsTT3QRdxkzMmk8xWrTuV-uvIKAerqcZMr6658o8-taqTH6nWN6ZOM_Zy_q5b3x-VHo3zXRxrOe-IptTyhxCN2Rh9feXLiyWXdTMD1_8sy1zNTgIGfoGfk7_Je1fJuaspseiI_F2ZmkaC7rRCL-e5JfRL2IALGl1PNB_0OLvMpLd5yO3RhpUxyDQFGmUJi1n> >> >> <https://cloud.letsignit.com/collect/bc/64a7be18452a27db4360347b?p=UsTT3QRdxkzMmk8xWrTuV-uvIKAerqcZMr6658o8-taqTH6nWN6ZOM_Zy_q5b3x-VHo3zXRxrOe-IptTyhxCN2Rh9feXLiyWXdTMD1_8sy0mRKcAbIcY9EZYZKbviCE5DR33ee51F4MQQyP1gffWzUpshOs9woJxNJnwLb0kZ8apcYWiavBGdoeWRi_uLzUKoLwq2I4l-o5F5CYWgZTEpqGOrtK807e8kujj_tFgKN4=> >> >> >> >> >> >> >> >> *De : *Dariusz Ozygała <dar...@gm...> >> *Date : *jeudi, 26 septembre 2024 à 14:21 >> *À : *swi...@li... <swi...@li...> >> *Objet : *[Swig-devel] Contribute to swig repository. >> >> Vous n’obtenez pas souvent d’e-mail à partir de dar...@gm.... >> Pourquoi c’est important <https://aka.ms/LearnAboutSenderIdentification> >> >> Hello, >> I'd like to contribute to SWIG repository. >> I created an implementation for std::optional for wrapping it to Java, >> we're using it for quite a while in our project, I'd like to share it with >> others and post PR in your repository. >> What do I need to do to get access to post a PR ? >> Regards, >> Dariusz >> > _______________________________________________ > Swig-devel mailing list > Swi...@li... > https://lists.sourceforge.net/lists/listinfo/swig-devel > |
From: Dariusz O. <dar...@gm...> - 2024-09-26 12:20:53
|
Hello, I'd like to contribute to SWIG repository. I created an implementation for std::optional for wrapping it to Java, we're using it for quite a while in our project, I'd like to share it with others and post PR in your repository. What do I need to do to get access to post a PR ? Regards, Dariusz |