swig-devel — SWIG Developer List

Re: [Swig-devel] Proposal: add SWIG_fail to java

[Mika R. <mik...@ou...>]

Friendly ping.

I still think this would be an improvement to writing java wrappers. Happy
to rework according to feedback.

    Mika

On Fri, 3 Jan 2025 at 15:50, Mika Raento <mik...@ou...> wrote:

> Friendly ping!
>
> I'd appreciate guidance on how to make progress with this change. I do
> think it makes writing correct java wrappers much easier. I'm willing to
> spend time to improve it where necessary.
>
>     Mika
>
> On Mon, Dec 2, 2024 at 7:30 PM Mika Raento <mik...@ou...>
> wrote:
>
>> Dear swig-devel,
>>
>> I'd like to propose adding the SWIG_fail feature to the java target
>> language's code generation. Currently it is quite easy to leak memory in
>> java bindings, as typival early exit code will skip freearg typemaps. (The
>> specific motivation for my case was the memory leak in
>> realm-kotlin's SWIG wrapper, see
>> https://github.com/realm/realm-kotlin/pull/1854. That wrapper can be
>> fixed in other ways but it would be nice to use SWIG_fail there).
>>
>> I've drafted a PR with the code, documentation and test changes:
>> https://github.com/swig/swig/pull/3079 for discussion on the specifics.
>>
>> I guess the main downside is that this will undoubtedly cause some
>> breakage somewhere as it changes the behavior of SWIG_exception for Java,
>> introduces the 'fail:' label that users may have used themselves and adds a
>> new enclosing block for the 'meat' of the generated code so that the goto
>> doesn't skip stack variable initialization.
>>
>> Any guidance on how to make the change less likely to cause breakage
>> would be appreciated.
>>
>> Best,
>>     Mika Raento
>>
>
>
> --
>
> Mika Raento
>
>
>

-- 

Mika Raento

[Swig-devel] Scilab SWIG and unused variables

[William S F. <ws...@fu...>]

Hi Vincent

I made numerous commits to make the SWIG generated code warning free for
gcc's -Wunused-variable with a few exceptions. You can see these leading up
to
https://github.com/swig/swig/commits/1f8684eb540d5d7c63fe7d5c3853990dd2316999/.
Scilab is one of the exceptions that I was unable to sort. Could you please
take a look? I think some of the char array typemaps are incomplete and the
cause of the majority of the warnings. You can check by simply running the
test-suite as follows:

make check-scilab-test-suite CXXFLAGS="-Wunused-variable -std=c++20"
CFLAGS="-Wunused-variable"

Regards
William

[Swig-devel] Announce - swig-4.3.1

[William S F. <ws...@fu...>]

*** ANNOUNCE: SWIG 4.3.1 (15 Apr 2025) ***

https://www.swig.org

We're pleased to announce SWIG-4.3.1, the latest SWIG release.

What is SWIG?
=============

SWIG is a software development tool that reads C/C++ header files and
generates the wrapper code needed to make C and C++ code accessible
from other programming languages including Perl, Python, Tcl, Ruby,
PHP, C#, Go, Java, Javascript, Lua, Scheme (Guile, MzScheme), D,
Ocaml, Octave, R, Scilab.  SWIG can also export its parse tree in
the form of XML.  Major applications of SWIG include generation of
scripting language extension modules, rapid prototyping, testing,
and user interface development for large C/C++ systems.

Release Notes
=============
Detailed release notes are available with the release and are also
published on the SWIG web site at https://swig.org/release.html.

Availability
============
The release is available for download on Sourceforge at

     https://prdownloads.sourceforge.net/swig/swig-4.3.1.tar.gz

A Windows version is also available at

     https://prdownloads.sourceforge.net/swig/swigwin-4.3.1.zip

Please report problems with this release to the swig-devel mailing list,
details at https://www.swig.org/mail.html.

--- The SWIG Developers

Re: [Swig-devel] swig-4.3.1 patch release

[William S F. <ws...@fu...>]

I have not been feeling well, so will get to this later this week.

William

On Thu, 10 Apr 2025 at 08:49, William S Fulton <ws...@fu...>
wrote:

> I plan to make the 4.3.1 release this weekend. Below I've listed all the
> commits in master since 4.3.0 and marked with 'y' the commits I plan to
> cherry-pick onto the release branch. I've also prefixed with there is an
> associated issue number. I'm only adding regression fixes and really low
> risk non-essential changes. Please let me know if there are other candidate
> commits.
>
> #3067 y 61f0bbe97 Python external_runtime example fixup
> #3067 y 095429213 Add external runtime Python example using typemap
> #3067 y 56afa6e6d Fix Python limited API and external runtime
>         124d8a8c3 Test code for removed methods from std::list for
> compatibility with java.util.List
>         34b71a3bb Fix javac -Xlint warning [this-escape] - JDK 21 in
> director constructors
>         ef0d38bff Support JDK 21 and std::list
>         83be871ee Remove unused JAVA_TOOLS_JAR make variable
>         aaeef05f7 Fix javac -Xlint warning [this-escape] - JDK 21 in STL
> containers
>         390da4d67 Add Java 21 testing
>         37caf2e66 warning fix for cdata Java wrappers for visual c++
>         af6581727 Fix javac -Xlint warnings:
>         c2ad64d0a Java compiler lint warnings fixes in test code
>         a16e3cb8c Add Java compiler linting checks javac -Xlint
>         6b69a05b4 Remove typemaps for signed/usigned wchar_t
>         c3b29f87f Update manual section numbers
>         f3ea85af0 [MzScheme/Racket] Drop support
>         0db0a3994 Omit empty deprecated/experiemtnal lists
>         644c860de remove redundant casts to const char* after using
> GetStringUTFChars function
> #3149 y 3b39c8080 CHANGES.current: Document previous commit
> #3149 y 4bec60866 Update octheaders.hpp
>       y 62d492577 Pin cccl version to 1.4
>         86f061cec User specified CC/CXX detection fix
>         a5568a728 deprecated boost atomic_count.hpp
>         837cc1c06 int conversion warnings
>       y fedb45cf4 Upgrade to cccl-1.4
>         df836dee6 configure: Leave overridden CC/CXX values alone
>         f66ea491e Update AX_CXX_COMPILE_STDCXX to upstream serial 25
>         34d0b35cc Remove can fail for Windows GHA
>         4811cb2a2 GHA update for ubuntu-20.04 EOL (#3133)
>         0cc821269 Strip additional -std flags that autoconf now adds to CC
> and CXX
>         e0ecea47b [ci] Enable Go 1.24 testing
>         e7f50af67 [guile] Add CHANGES entry for ports.i fix
>         e11f216a7 [guile] Fix ports.i
>         2f8137b0f [ci] Mark failing windows.yml jobs as continue-on-error
>         e42b3ca60 Remove unused SKIP_PYTHON3
>         651449ee0 [Python] Remove left-over check for Python 1.x
>         6dbf867d2 Fix handling of corner cases by previous change
>         4a0372aac Improve parsing multi-line expr via skip_balanced()
>         1bff64d5e Don't test against Go 1.24 for now. It doesn't work with
> the default CFLAGS.
>         959dbd4dd Test against Go versions 1.20 and 1.24. Stop testing old
> Go versions.
>         26b0911a7 Add support for $n special variable expansion in the
> names of typemap local variables
>         fe3a7af85 Revert "[Go] Use unsafe.Slice and unsafe.String in Go
> fragments"
>         ff5c118aa [Go] Use unsafe.Slice and unsafe.String in Go fragments
>         e8787615a Regression fix when using -keyword, kwargs or
> compactdefaultargs option
> #2889 y 892be2b80 Fix crash when using directors in Python without limited
> API
>         c67582d0e Revert python to windows-2022.
>         dcca453b4 More %interface docs
>         e1b2d20f6 Destructor declaration correction in docs
>         8fd4df01b CHANGES.current: Add entry for Lua unsigned long long fix
>         e2c3e568f Add Lua test case for long long
>         390844a7d Fix "unsigned long long" being interpreted as "signed
> long long" in Lua
>         db6f488fe Correct docs for libraries requiring .NET 4
>         36ef36dcb Add <errno.h> fragment for errno usage
>         1e4559022 Add memory access violation message to C# docs
> #3070 y f362bb099 Explicitly include errno.h for ERANGE
> #3070 y dfe9d8ea2 [Java] Fix regression wrapping enum values
>         d9edb22d1 %apply and typedefs improvement
>         40b6cc684 Use exact type for temporary variable wrapping
> parameters with default args and compactdefaultargs
>         5c2e83dd1 Typedefs to references fix for the compactdefaultargs
> feature
>         936767da8 Few error message improvements and consistency tweaks
>         3cda507e5 Fix initializer lists used with -keyword or
> compactdefaultargs option
>         7af22e929 Fix pedantic warning in tests
>         7fb816dcb typo fix in docs
> #3058 y ada653aaf Suppress unhelpful GCC/clang warnings in new tests
> #3058 y 4e315cdd7 Fix precedence of casts
>         9187aaf22 [guile] Improve constant wrapping
>         acd508f4b Improve testsuite comment
>         1382a403f Use defined type in cpp11_brackets_expression testcase
>         c77498d5d [Perl] Destroy C++ local variables on exception
>         376911013 Java docs code style corrections
>         c9ce79be7 C# docs code style corrections
>         7635b4033 Improve C# Java docs for memory handling and member
> variable accessors
>         0b4496a73 Fix testsuite SWIG warnings; enable SWIG -Werror
>         ce6d2dd11 Drop support for raw type strings in interface files
>         f84f80c31 Bump version to 4.4.0
>
> William
>
> On Wed, 5 Feb 2025 at 18:33, William S Fulton <ws...@fu...>
> wrote:
>
>> There havn't been many commits to master since 4.3.0 for a swig-4.4
>> release, however there are some regressions which ought to be released
>> sooner rather than later so I was thinking of pushing out a 4.3.1 release
>> soon (like within a month). This is mostly in response to
>> https://github.com/swig/swig/issues/3118, but also all those tagged for
>> 4.3.1 milestone - https://github.com/swig/swig/milestone/12.
>>
>> Any objections? If anyone has any "must have" regression fixes (either to
>> be fixed or already fixed), could they please tag with with the 4.3.1
>> milestone. I'll create a release branch and then I'll cherry-pick the
>> changes onto it like I did for the release-4.1 branch.
>>
>> William
>>
>

Re: [Swig-devel] swig-4.3.1 patch release

[William S F. <ws...@fu...>]

I plan to make the 4.3.1 release this weekend. Below I've listed all the
commits in master since 4.3.0 and marked with 'y' the commits I plan to
cherry-pick onto the release branch. I've also prefixed with there is an
associated issue number. I'm only adding regression fixes and really low
risk non-essential changes. Please let me know if there are other candidate
commits.

#3067 y 61f0bbe97 Python external_runtime example fixup
#3067 y 095429213 Add external runtime Python example using typemap
#3067 y 56afa6e6d Fix Python limited API and external runtime
        124d8a8c3 Test code for removed methods from std::list for
compatibility with java.util.List
        34b71a3bb Fix javac -Xlint warning [this-escape] - JDK 21 in
director constructors
        ef0d38bff Support JDK 21 and std::list
        83be871ee Remove unused JAVA_TOOLS_JAR make variable
        aaeef05f7 Fix javac -Xlint warning [this-escape] - JDK 21 in STL
containers
        390da4d67 Add Java 21 testing
        37caf2e66 warning fix for cdata Java wrappers for visual c++
        af6581727 Fix javac -Xlint warnings:
        c2ad64d0a Java compiler lint warnings fixes in test code
        a16e3cb8c Add Java compiler linting checks javac -Xlint
        6b69a05b4 Remove typemaps for signed/usigned wchar_t
        c3b29f87f Update manual section numbers
        f3ea85af0 [MzScheme/Racket] Drop support
        0db0a3994 Omit empty deprecated/experiemtnal lists
        644c860de remove redundant casts to const char* after using
GetStringUTFChars function
#3149 y 3b39c8080 CHANGES.current: Document previous commit
#3149 y 4bec60866 Update octheaders.hpp
      y 62d492577 Pin cccl version to 1.4
        86f061cec User specified CC/CXX detection fix
        a5568a728 deprecated boost atomic_count.hpp
        837cc1c06 int conversion warnings
      y fedb45cf4 Upgrade to cccl-1.4
        df836dee6 configure: Leave overridden CC/CXX values alone
        f66ea491e Update AX_CXX_COMPILE_STDCXX to upstream serial 25
        34d0b35cc Remove can fail for Windows GHA
        4811cb2a2 GHA update for ubuntu-20.04 EOL (#3133)
        0cc821269 Strip additional -std flags that autoconf now adds to CC
and CXX
        e0ecea47b [ci] Enable Go 1.24 testing
        e7f50af67 [guile] Add CHANGES entry for ports.i fix
        e11f216a7 [guile] Fix ports.i
        2f8137b0f [ci] Mark failing windows.yml jobs as continue-on-error
        e42b3ca60 Remove unused SKIP_PYTHON3
        651449ee0 [Python] Remove left-over check for Python 1.x
        6dbf867d2 Fix handling of corner cases by previous change
        4a0372aac Improve parsing multi-line expr via skip_balanced()
        1bff64d5e Don't test against Go 1.24 for now. It doesn't work with
the default CFLAGS.
        959dbd4dd Test against Go versions 1.20 and 1.24. Stop testing old
Go versions.
        26b0911a7 Add support for $n special variable expansion in the
names of typemap local variables
        fe3a7af85 Revert "[Go] Use unsafe.Slice and unsafe.String in Go
fragments"
        ff5c118aa [Go] Use unsafe.Slice and unsafe.String in Go fragments
        e8787615a Regression fix when using -keyword, kwargs or
compactdefaultargs option
#2889 y 892be2b80 Fix crash when using directors in Python without limited
API
        c67582d0e Revert python to windows-2022.
        dcca453b4 More %interface docs
        e1b2d20f6 Destructor declaration correction in docs
        8fd4df01b CHANGES.current: Add entry for Lua unsigned long long fix
        e2c3e568f Add Lua test case for long long
        390844a7d Fix "unsigned long long" being interpreted as "signed
long long" in Lua
        db6f488fe Correct docs for libraries requiring .NET 4
        36ef36dcb Add <errno.h> fragment for errno usage
        1e4559022 Add memory access violation message to C# docs
#3070 y f362bb099 Explicitly include errno.h for ERANGE
#3070 y dfe9d8ea2 [Java] Fix regression wrapping enum values
        d9edb22d1 %apply and typedefs improvement
        40b6cc684 Use exact type for temporary variable wrapping parameters
with default args and compactdefaultargs
        5c2e83dd1 Typedefs to references fix for the compactdefaultargs
feature
        936767da8 Few error message improvements and consistency tweaks
        3cda507e5 Fix initializer lists used with -keyword or
compactdefaultargs option
        7af22e929 Fix pedantic warning in tests
        7fb816dcb typo fix in docs
#3058 y ada653aaf Suppress unhelpful GCC/clang warnings in new tests
#3058 y 4e315cdd7 Fix precedence of casts
        9187aaf22 [guile] Improve constant wrapping
        acd508f4b Improve testsuite comment
        1382a403f Use defined type in cpp11_brackets_expression testcase
        c77498d5d [Perl] Destroy C++ local variables on exception
        376911013 Java docs code style corrections
        c9ce79be7 C# docs code style corrections
        7635b4033 Improve C# Java docs for memory handling and member
variable accessors
        0b4496a73 Fix testsuite SWIG warnings; enable SWIG -Werror
        ce6d2dd11 Drop support for raw type strings in interface files
        f84f80c31 Bump version to 4.4.0

William

On Wed, 5 Feb 2025 at 18:33, William S Fulton <ws...@fu...>
wrote:

> There havn't been many commits to master since 4.3.0 for a swig-4.4
> release, however there are some regressions which ought to be released
> sooner rather than later so I was thinking of pushing out a 4.3.1 release
> soon (like within a month). This is mostly in response to
> https://github.com/swig/swig/issues/3118, but also all those tagged for
> 4.3.1 milestone - https://github.com/swig/swig/milestone/12.
>
> Any objections? If anyone has any "must have" regression fixes (either to
> be fixed or already fixed), could they please tag with with the 4.3.1
> milestone. I'll create a release branch and then I'll cherry-pick the
> changes onto it like I did for the release-4.1 branch.
>
> William
>

[Swig-devel] swig-4.3.1 patch release

[William S F. <ws...@fu...>]

There havn't been many commits to master since 4.3.0 for a swig-4.4
release, however there are some regressions which ought to be released
sooner rather than later so I was thinking of pushing out a 4.3.1 release
soon (like within a month). This is mostly in response to
https://github.com/swig/swig/issues/3118, but also all those tagged for
4.3.1 milestone - https://github.com/swig/swig/milestone/12.

Any objections? If anyone has any "must have" regression fixes (either to
be fixed or already fixed), could they please tag with with the 4.3.1
milestone. I'll create a release branch and then I'll cherry-pick the
changes onto it like I did for the release-4.1 branch.

William

Re: [Swig-devel] Proposal: add SWIG_fail to java

[Mika R. <mik...@ou...>]

Friendly ping!

I'd appreciate guidance on how to make progress with this change. I do
think it makes writing correct java wrappers much easier. I'm willing to
spend time to improve it where necessary.

    Mika

On Mon, Dec 2, 2024 at 7:30 PM Mika Raento <mik...@ou...> wrote:

> Dear swig-devel,
>
> I'd like to propose adding the SWIG_fail feature to the java target
> language's code generation. Currently it is quite easy to leak memory in
> java bindings, as typival early exit code will skip freearg typemaps. (The
> specific motivation for my case was the memory leak in
> realm-kotlin's SWIG wrapper, see
> https://github.com/realm/realm-kotlin/pull/1854. That wrapper can be
> fixed in other ways but it would be nice to use SWIG_fail there).
>
> I've drafted a PR with the code, documentation and test changes:
> https://github.com/swig/swig/pull/3079 for discussion on the specifics.
>
> I guess the main downside is that this will undoubtedly cause some
> breakage somewhere as it changes the behavior of SWIG_exception for Java,
> introduces the 'fail:' label that users may have used themselves and adds a
> new enclosing block for the 'meat' of the generated code so that the goto
> doesn't skip stack variable initialization.
>
> Any guidance on how to make the change less likely to cause breakage would
> be appreciated.
>
> Best,
>     Mika Raento
>


-- 

Mika Raento

Re: [Swig-devel] Toolchain upgrade for C#

[William S F. <ws...@fu...>]

On Mon, 25 Nov 2024 at 16:06, Vadim Zeitlin <vz...@ze...> wrote:

> On Mon, 25 Nov 2024 14:46:05 +0000 Christophe CALMEJANE via Swig-devel <
> swi...@li...> wrote:
>
> CC> Still my main question remains, has it been considered to migrate from
> the
> CC> deprecated mono compiler to Microsoft Dotnet one?
>
>  I think this would require a significant effort because, AFAIK, dotnet
> toolchain can't be used to compile individual C# source files, as the
> traditional compilers do, and what SWIG makefiles use, and requires
> creating a
> project for each and every test.
>
>  But please correct me if I'm wrong, I could have missed something.


I have started looking at this. It seems that dotnet does not support C++
.vcxproj files, so we can't even use dotnet for the examples under
Examples/csharp. I had some luck running these examples under Linux though
by suppressing the csc.exe / mono-csc.exe invocation and then using dotnet
commands to create a project to build the C# layer. These are the steps for
the Examples/csharp/class example:


rm example-vc.vcxproj example-cs.csproj example.sln
dotnet new console -n example -o .
rm Program.cs
make COMPILETOOL=true RUNTOOL=true # To invoke swig and compile the
generated c/c++ code, suppresses invoking C# compiler and running the
example
dotnet build -nowarn:CS8981
env LD_LIBRARY_PATH=. dotnet run

Building quietly required some extra options...
dotnet build --verbosity quiet -clp:NoSummary

I think this has potential to work once autoconf is modified to detect
dotnet and modify the build accordingly. I'll try go in this direction
next. It would indeed need to create a project for each test (via dotnet
new). It generates a tiny example.csproj file:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net8.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>

</Project>

and doesn't take long. It finds all the .cs files in the current directory
including subdirectories. The test-suite might work by soft linking the
appropriate runme.cs file to the Examples/test-suite/csharp directory from
the testcase subdirectory that contains the generated C# files as all the
files will then be in a self-contained directory tree. It is possible to
write dotnet templates for 'dotnet new' which might be worth exploring.

William

[Swig-devel] Proposal: add SWIG_fail to java

[Mika R. <mik...@ou...>]

Dear swig-devel,

I'd like to propose adding the SWIG_fail feature to the java target
language's code generation. Currently it is quite easy to leak memory in
java bindings, as typival early exit code will skip freearg typemaps. (The
specific motivation for my case was the memory leak in
realm-kotlin's SWIG wrapper, see
https://github.com/realm/realm-kotlin/pull/1854. That wrapper can be fixed
in other ways but it would be nice to use SWIG_fail there).

I've drafted a PR with the code, documentation and test changes:
https://github.com/swig/swig/pull/3079 for discussion on the specifics.

I guess the main downside is that this will undoubtedly cause some breakage
somewhere as it changes the behavior of SWIG_exception for Java, introduces
the 'fail:' label that users may have used themselves and adds a new
enclosing block for the 'meat' of the generated code so that the goto
doesn't skip stack variable initialization.

Any guidance on how to make the change less likely to cause breakage would
be appreciated.

Best,
    Mika Raento

Re: [Swig-devel] Post 4.3.0 release perspective

[William S F. <ws...@fu...>]

On Thu, 24 Oct 2024 at 22:36, Olly Betts <ol...@su...> wrote:

> On 2024-10-21, William S Fulton <ws...@fu...> wrote:
> > Looking at the https://swig.org/mail.html page on the web site, I was
> > considering updating it given the mailing lists seem to have gone out of
> > fashion a bit.
> >
> > 1. The GMane and Nabble mailing list search facility no longer works, so
> > I'll remove that. I don't know of any replacements, but the SourceForge
> > search doesn't seem so bad these days too, which is good.
>
> I can confirm the Gmane search is gone (as it happens I used to run it!)
> as has the web frontend - Gmane is now only an NNTP gateway and archive
> of mailing lists and that part still works (I'm posting this using it).
>
> > 2. I think we should suggest users also try stackoverflow for support as
> > that seems to be the modern way and currently more popular than the
> > swig-user mailing list.
>
> I really don't like stackoverflow, and don't like the idea that we
> might promote it as a place to get help.
>
> I especially dislike that it tends to dominate in general web search
> results, but usually isn't actually the best place to get a definitive
> answer to something.
>
> Its mechanism for promoting answers isn't terrible but it can only
> promote the best answer that someone on stackoverflow gave, and it can
> suffer from group-think where the promoted answer is what is generally
> believed but not what is actually correct.
>
> It also seems to have a lot of questions where there are no useful
> answers, but which still rank well in general web search results.
>
> Not related to usefulness, but stackoverflow also seems to be run by a
> company that does not treat its volunteer moderators well.
>
> > I was also half thinking of suggesting to use Github discussions for
> > general user help.
>
> I can't say that idea fills me with joy either.
>

Regarding the emailing list and general community support, I have updated
https://swig.org/mail.html taking into account these and subsequent
comments as well as what the SWIG community uses.

I did a quick analysis of where the community goes for support and came up
with the following analysis covering the last year Dec 2023 - Nov 2024. I
compared the 3 main areas that seem to be the places that uses actually go
to for support:

1. Stackoverflow tagged with [swig] -
https://stackoverflow.com/questions/tagged/swig
2. swig-user mailing list -
https://sourceforge.net/p/swig/mailman/swig-user/
3. Github discussions -
https://github.com/swig/swig/discussions?discussions_q=sort%3Adate_created

Total questions asked on Stackoverflow: 67
Total threads/questions asked on swig-user: 30
Total Github discussions threads: 23

The place that users go to for asking questions is ordered as above.

Success rate is rather hard to measure, but we have:

Total questions marked as answered on Stackoverflow for the 67 questions: 29

Total posts on swig-user for the 30 threads: 74
Total posts on swig-user for the 30 threads with a reply: 26

Total posts for the 23 threads on Github discussions: 70
Total of the 23 threads marked as answered on Github discussions:7

Success rate is possibly best on Stackoverflow and swig-user, but most
activity is on Github discussions. Caveat: I make a particular effort to
try and at least reply to most swig-user queries.

I'm not sure we can conclude anything definitive with respect to where the
best success rate is for help.

Feel free to pick holes in this and find other options for community
support, but given the mixed bag that users actually go to, I've mentioned
all three without recommending any one over the other. I'd rather give
links to what is actually useful rather than mandate any one place over
another for now. However, I have made it clear where to file bugs and
patches in the list of options at https://swig.org/mail.html. But if anyone
has further improvements, please raise merge requests for the web pages at
https://github.com/swig/www/.

William

Re: [Swig-devel] Toolchain upgrade for C#

[Christophe C. <chr...@l-...>]

Hi,

I did wrote some helper function to add C# target to a CMake project using the dotnet tool, not sure if it’s of any help or is the kind of thing you are asking for (see here: https://github.com/christophe-calmejane/cmakeUtils/blob/main/helpers/GenerateCSharpTarget.cmake ).

I looked at the nullable reference support you mentioned in swig 4.2, which is great to let the user decide if he wants to use C#8 features or not.
The only downside I’ve seen so far is that it’s causing quite a lot of warnings in the PINVOKE auto-generated file. Is there any way to not set ‘#nullable enable’ in this file (or overwrite it)? Or add additional flags to silence the warnings just for that file?

private static global::System.Exception pendingException = null;

  *   Cannot convert null literal to non-nullable reference type.
global::System.Exception e = null;

  *   Converting null literal or possible null value to non-nullable type.
And so on..

Thanks for the help.

Christophe





De : William S Fulton <ws...@fu...>
Date : mardi, 26 novembre 2024 à 20:51
À : Mario Emmenlauer <ma...@em...>
Cc : Christophe CALMEJANE <chr...@l-...>, swi...@li... <swi...@li...>
Objet : Re: [Swig-devel] Toolchain upgrade for C#


On Mon, 25 Nov 2024 at 15:46, Mario Emmenlauer via Swig-devel <swi...@li...<mailto:swi...@li...>> wrote:

Dear Christophe,

thanks a lot for your great interest!


On 25.11.24 15:46, Christophe CALMEJANE via Swig-devel wrote:
> Still my main question remains, has it been considered to migrate from the deprecated mono compiler to Microsoft Dotnet one?

Yes, we have weighted and considered the options, and after some careful
consideration, we agree that you can provide a PR, so we can understand and
discuss the changes directly on the diffset.

Please see https://github.com/apache/thrift/blob/master/CONTRIBUTING.md for
more info, and thanks a lot for your support!

I'm not sure what the Apache Thrift contributing link has to do with contributing to SWIG!

In answer to your question, SWIG aims to generate C# code that will work with the versions of .NET that I mentioned earlier in the chain. Users can use whatever C# compiler they like that supports these versions. With regards to the compiler versions supported in the SWIG test-suite and examples for testing, I would happily accept a patch that supports modern dotnet toolsuite that Microsoft provide. But as Vadim points out it isn't clear how the dotnet toolchain can easily fit in with our makefiles for building the unmanaged code, but I really would like someone to help in this space. If there was some sort of example that show how to use the toolchain for a project that uses PInvoke and C code, it might provide the info required.

William

Re: [Swig-devel] Toolchain upgrade for C#

[William S F. <ws...@fu...>]

On Mon, 25 Nov 2024 at 15:46, Mario Emmenlauer via Swig-devel <
swi...@li...> wrote:

>
> Dear Christophe,
>
> thanks a lot for your great interest!
>
>
> On 25.11.24 15:46, Christophe CALMEJANE via Swig-devel wrote:
> > Still my main question remains, has it been considered to migrate from
> the deprecated mono compiler to Microsoft Dotnet one?
>
> Yes, we have weighted and considered the options, and after some careful
> consideration, we agree that you can provide a PR, so we can understand and
> discuss the changes directly on the diffset.
>
> Please see https://github.com/apache/thrift/blob/master/CONTRIBUTING.md
> for
> more info, and thanks a lot for your support!


I'm not sure what the Apache Thrift contributing link has to do with
contributing to SWIG!

In answer to your question, SWIG aims to generate C# code that will work
with the versions of .NET that I mentioned earlier in the chain. Users can
use whatever C# compiler they like that supports these versions. With
regards to the compiler versions supported in the SWIG test-suite and
examples for testing, I would happily accept a patch that supports modern
dotnet toolsuite that Microsoft provide. But as Vadim points out it isn't
clear how the dotnet toolchain can easily fit in with our makefiles for
building the unmanaged code, but I really would like someone to help in
this space. If there was some sort of example that show how to use the
toolchain for a project that uses PInvoke and C code, it might provide the
info required.

William

Re: [Swig-devel] Toolchain upgrade for C#

[Vadim Z. <vz...@ze...>]

On Mon, 25 Nov 2024 14:46:05 +0000 Christophe CALMEJANE via Swig-devel <swi...@li...> wrote:

CC> Still my main question remains, has it been considered to migrate from the
CC> deprecated mono compiler to Microsoft Dotnet one?

 I think this would require a significant effort because, AFAIK, dotnet
toolchain can't be used to compile individual C# source files, as the
traditional compilers do, and what SWIG makefiles use, and requires creating a
project for each and every test.

 But please correct me if I'm wrong, I could have missed something.

 Regards,
VZ

Re: [Swig-devel] Toolchain upgrade for C#

[Mario E. <ma...@em...>]

Dear Christophe,

thanks a lot for your great interest!


On 25.11.24 15:46, Christophe CALMEJANE via Swig-devel wrote:
> Still my main question remains, has it been considered to migrate from the deprecated mono compiler to Microsoft Dotnet one?

Yes, we have weighted and considered the options, and after some careful
consideration, we agree that you can provide a PR, so we can understand and
discuss the changes directly on the diffset.

Please see https://github.com/apache/thrift/blob/master/CONTRIBUTING.md for
more info, and thanks a lot for your support!

All the best,

    Mario

Re: [Swig-devel] Toolchain upgrade for C#

[Christophe C. <chr...@l-...>]

Hi,

My issue was actually due to some syntax that is not supported by the mono compiler, that I managed to work around.

Still my main question remains, has it been considered to migrate from the deprecated mono compiler to Microsoft Dotnet one?
I’m developing on macOS and I cannot run the test-suite from it (may not be related to Mono at all actually): the makefiles are compiling .so files which cannot be used on macOS. But maybe by using Dotnet it will be automatic and cross-platform?
Not sure how much effort is required to migrate, I don’t fully understand all the current toolchain.

Christophe CALMEJANE
Head of Technology, Middleware & Tools

[https://storage.letsignit.com/5e205f9364ef1e0007df8dd1/157931868809400396551428155263482193943.png]
13 Rue Levacher Cintrat, Parc Fontaine de Jouvence - 91460 Marcoussis - France
Office  : +33 1 70 84 08 98

l-acoustics.com
[https://storage.letsignit.com/5e205f9364ef1e0007df8dd1/34828667325724549301384413623356639143.png]<https://cloud.letsignit.com/collect/bc/64a7be18452a27db4360347b?p=UsTT3QRdxkzMmk8xWrTuV-uvIKAerqcZMr6658o8-taqTH6nWN6ZOM_Zy_q5b3x-VHo3zXRxrOe-IptTyhxCN2Rh9feXLiyWXdTMD1_8sy0mRKcAbIcY9EZYZKbviCE5yGd3tnlp7kBBVIKkAYwW0ZOXmUKQMhhzKNAXYq6Sn1hDmZx-ixmR73WCMx5w1u8RVm5w0rE8ATXQDni8p7dPMA==>  [https://storage.letsignit.com/5e205f9364ef1e0007df8dd1/178170618866157368622765932246699512081.png] <https://cloud.letsignit.com/collect/bc/64a7be18452a27db4360347b?p=UsTT3QRdxkzMmk8xWrTuV-uvIKAerqcZMr6658o8-taqTH6nWN6ZOM_Zy_q5b3x-VHo3zXRxrOe-IptTyhxCN2Rh9feXLiyWXdTMD1_8sy0mRKcAbIcY9EZYZKbviCE5krCQI7iOjKL9rcShM_dPkWyzshVh0h15MJjhKYhaTywwGK6nFl6NKEoi308fdsESJIkCnGW1O7C8EfmpIebWAw==>   [https://storage.letsignit.com/5e205f9364ef1e0007df8dd1/284525336458572053570367734995237269837.png] <https://cloud.letsignit.com/collect/bc/64a7be18452a27db4360347b?p=UsTT3QRdxkzMmk8xWrTuV-uvIKAerqcZMr6658o8-taqTH6nWN6ZOM_Zy_q5b3x-VHo3zXRxrOe-IptTyhxCN2Rh9feXLiyWXdTMD1_8sy02FJau7ravxn65ADDCFsrjQ5aqYW9g6SQ8F69CCS6-v-AA2tKPDXmcvjvjLIIjvyRUB-zpwjSP9Z_VrOKzUBybGPQcvBwwSRq6M2KrCjraYA==>   [https://storage.letsignit.com/5e205f9364ef1e0007df8dd1/logo_5e205f9364ef1e0007df8dd1_40e4ebcc85fe2550fa013ff6c52aae88.png] <https://cloud.letsignit.com/collect/bc/64a7be18452a27db4360347b?p=UsTT3QRdxkzMmk8xWrTuV-uvIKAerqcZMr6658o8-taqTH6nWN6ZOM_Zy_q5b3x-VHo3zXRxrOe-IptTyhxCN2Rh9feXLiyWXdTMD1_8sy0LNijUNdUicuCOSnTBvePS5vNpnlj3JUYx_sJFFyu5S5UR6XJ8H3l0CTIGsj9k87ckiQKcZbU7sLwR-akh5tYD>   [https://storage.letsignit.com/5e205f9364ef1e0007df8dd1/logo_5e205f9364ef1e0007df8dd1_98bb140e27bdc29eec87f67fc7ed5d1c.png] <https://cloud.letsignit.com/collect/bc/64a7be18452a27db4360347b?p=UsTT3QRdxkzMmk8xWrTuV-uvIKAerqcZMr6658o8-taqTH6nWN6ZOM_Zy_q5b3x-VHo3zXRxrOe-IptTyhxCN2Rh9feXLiyWXdTMD1_8sy1zNTgIGfoGfk7_Je1fJuaspseiI_F2ZmkaC7rRCL-e5JfRL2IALGl1PNB_0OLvMpLd5yO3RhpUxyDQFGmUJi1n>   [https://storage.letsignit.com/5e205f9364ef1e0007df8dd1/65382111016339093392920242222991313588.png] <https://cloud.letsignit.com/collect/bc/64a7be18452a27db4360347b?p=UsTT3QRdxkzMmk8xWrTuV-uvIKAerqcZMr6658o8-taqTH6nWN6ZOM_Zy_q5b3x-VHo3zXRxrOe-IptTyhxCN2Rh9feXLiyWXdTMD1_8sy0mRKcAbIcY9EZYZKbviCE5DR33ee51F4MQQyP1gffWzUpshOs9woJxNJnwLb0kZ8apcYWiavBGdoeWRi_uLzUKoLwq2I4l-o5F5CYWgZTEpqGOrtK807e8kujj_tFgKN4=>



De : William S Fulton <ws...@fu...>
Date : vendredi, 22 novembre 2024 à 20:49
À : Vadim Zeitlin <vz...@ze...>
Cc : Christophe CALMEJANE via Swig-devel <swi...@li...>
Objet : Re: [Swig-devel] Toolchain upgrade for C#


On Fri, 22 Nov 2024 at 16:26, Vadim Zeitlin <vz...@ze...<mailto:vz...@ze...>> wrote:
On Fri, 22 Nov 2024 16:02:17 +0000 Christophe CALMEJANE via Swig-devel <swi...@li...<mailto:swi...@li...>> wrote:

CC> I’m asking because I’d like to propose a PR for std::optional that makes use of C# nullable reference types, and it seems to be quite a pain to support both C#<8 and C#>=8 for that.

 Hi,

 I don't know the answers to your other questions, but I'm curious about what exactly makes it difficult to support C# < 8? I have my own typemaps for optional-like class written (checks notes) 12 years ago, so long before C# 8, and yet they seem to work just fine.

Yes, I would try and support the oldest version of C# possible for maximum flexibility for users. Note from the C# chapter though:

SWIG 3 and later requires .NET 2.0 at a minimum.
There are some minor exceptions, where the minimum required is .NET 4.0.
This is when using the <tt>std::complex</tt> and <tt>std::list</tt> STL containers.

[Also for std::unordered_set].

SWIG also added support for nullable references in version 4.2.0. Perhaps you can look at the docs for that and support in the same sort of way???

William


William

Re: [Swig-devel] Toolchain upgrade for C#

[William S F. <ws...@fu...>]

On Fri, 22 Nov 2024 at 16:26, Vadim Zeitlin <vz...@ze...> wrote:

> On Fri, 22 Nov 2024 16:02:17 +0000 Christophe CALMEJANE via Swig-devel <
> swi...@li...> wrote:
>
> CC> I’m asking because I’d like to propose a PR for std::optional that
> makes use of C# nullable reference types, and it seems to be quite a pain
> to support both C#<8 and C#>=8 for that.
>
>  Hi,
>
>  I don't know the answers to your other questions, but I'm curious about
> what exactly makes it difficult to support C# < 8? I have my own typemaps
> for optional-like class written (checks notes) 12 years ago, so long before
> C# 8, and yet they seem to work just fine.
>
>
Yes, I would try and support the oldest version of C# possible for maximum
flexibility for users. Note from the C# chapter though:

SWIG 3 and later requires .NET 2.0 at a minimum.
There are some minor exceptions, where the minimum required is .NET 4.0.
This is when using the <tt>std::complex</tt> and <tt>std::list</tt> STL
containers.

[Also for std::unordered_set].

SWIG also added support for nullable references in version 4.2.0. Perhaps
you can look at the docs for that and support in the same sort of way???

William


William

Re: [Swig-devel] Toolchain upgrade for C#

[Vadim Z. <vz...@ze...>]

On Fri, 22 Nov 2024 16:02:17 +0000 Christophe CALMEJANE via Swig-devel <swi...@li...> wrote:

CC> I’m asking because I’d like to propose a PR for std::optional that makes use of C# nullable reference types, and it seems to be quite a pain to support both C#<8 and C#>=8 for that.

 Hi,

 I don't know the answers to your other questions, but I'm curious about what exactly makes it difficult to support C# < 8? I have my own typemaps for optional-like class written (checks notes) 12 years ago, so long before C# 8, and yet they seem to work just fine.

 Regards,
VZ

[Swig-devel] Toolchain upgrade for C#

[Christophe C. <chr...@l-...>]

Hi,

If I’m not mistaken, SWIG currently uses the Mono project for the C# test-suite. That project is not really maintained and is using an old version of C#.
Are there any plans on migrating to the Microsoft supported replacement of Mono, dotnet?

More generally, is it acceptable to drop support for old C# version? C#13 is out but Mono is still using C#7 which is 7y old.

I’m asking because I’d like to propose a PR for std::optional that makes use of C# nullable reference types, and it seems to be quite a pain to support both C#<8 and C#>=8 for that.

Any thoughts?
Thanks, regards

Christophe CALMEJANE
Head of Technology, Middleware & Tools

[https://storage.letsignit.com/5e205f9364ef1e0007df8dd1/157931868809400396551428155263482193943.png]
13 Rue Levacher Cintrat, Parc Fontaine de Jouvence - 91460 Marcoussis - France
Office  : +33 1 70 84 08 98

l-acoustics.com
[https://storage.letsignit.com/5e205f9364ef1e0007df8dd1/34828667325724549301384413623356639143.png]<https://cloud.letsignit.com/collect/bc/64a7be18452a27db4360347b?p=UsTT3QRdxkzMmk8xWrTuV-uvIKAerqcZMr6658o8-taqTH6nWN6ZOM_Zy_q5b3x-VHo3zXRxrOe-IptTyhxCN2Rh9feXLiyWXdTMD1_8sy0mRKcAbIcY9EZYZKbviCE5yGd3tnlp7kBBVIKkAYwW0ZOXmUKQMhhzKNAXYq6Sn1j2xyBLWvF02lAtBLfioAwT>  [https://storage.letsignit.com/5e205f9364ef1e0007df8dd1/178170618866157368622765932246699512081.png] <https://cloud.letsignit.com/collect/bc/64a7be18452a27db4360347b?p=UsTT3QRdxkzMmk8xWrTuV-uvIKAerqcZMr6658o8-taqTH6nWN6ZOM_Zy_q5b3x-VHo3zXRxrOe-IptTyhxCN2Rh9feXLiyWXdTMD1_8sy0mRKcAbIcY9EZYZKbviCE5krCQI7iOjKL9rcShM_dPkWyzshVh0h15MJjhKYhaTyzuqZ4ie7sno56jroIN9ZSo>   [https://storage.letsignit.com/5e205f9364ef1e0007df8dd1/284525336458572053570367734995237269837.png] <https://cloud.letsignit.com/collect/bc/64a7be18452a27db4360347b?p=UsTT3QRdxkzMmk8xWrTuV-uvIKAerqcZMr6658o8-taqTH6nWN6ZOM_Zy_q5b3x-VHo3zXRxrOe-IptTyhxCN2Rh9feXLiyWXdTMD1_8sy02FJau7ravxn65ADDCFsrjQ5aqYW9g6SQ8F69CCS6-v-AA2tKPDXmcvjvjLIIjvySoQPH0hdhFsDTu3osl-Z7y>   [https://storage.letsignit.com/5e205f9364ef1e0007df8dd1/logo_5e205f9364ef1e0007df8dd1_40e4ebcc85fe2550fa013ff6c52aae88.png] <https://cloud.letsignit.com/collect/bc/64a7be18452a27db4360347b?p=UsTT3QRdxkzMmk8xWrTuV-uvIKAerqcZMr6658o8-taqTH6nWN6ZOM_Zy_q5b3x-VHo3zXRxrOe-IptTyhxCN2Rh9feXLiyWXdTMD1_8sy0LNijUNdUicuCOSnTBvePS5vNpnlj3JUYx_sJFFyu5S6oHykNMLGn_xbBjY4CKnQo=>   [https://storage.letsignit.com/5e205f9364ef1e0007df8dd1/logo_5e205f9364ef1e0007df8dd1_98bb140e27bdc29eec87f67fc7ed5d1c.png] <https://cloud.letsignit.com/collect/bc/64a7be18452a27db4360347b?p=UsTT3QRdxkzMmk8xWrTuV-uvIKAerqcZMr6658o8-taqTH6nWN6ZOM_Zy_q5b3x-VHo3zXRxrOe-IptTyhxCN2Rh9feXLiyWXdTMD1_8sy1zNTgIGfoGfk7_Je1fJuaspseiI_F2ZmkaC7rRCL-e5GCRWQurIaztOnMVwTwecp8=>   [https://storage.letsignit.com/5e205f9364ef1e0007df8dd1/65382111016339093392920242222991313588.png] <https://cloud.letsignit.com/collect/bc/64a7be18452a27db4360347b?p=UsTT3QRdxkzMmk8xWrTuV-uvIKAerqcZMr6658o8-taqTH6nWN6ZOM_Zy_q5b3x-VHo3zXRxrOe-IptTyhxCN2Rh9feXLiyWXdTMD1_8sy0mRKcAbIcY9EZYZKbviCE5DR33ee51F4MQQyP1gffWzUpshOs9woJxNJnwLb0kZ8ZXn0fkAx706ZFMBZcEuYiI>


Si vous recevez ce mail pendant votre période de repos, vous n’êtes pas tenu d’y répondre immédiatement.
If you receive this email during your time off, you are not required to respond immediately.

[https://storage.letsignit.com/5e205f9364ef1e0007df8dd1/generated/effects_441587a357fa77555b7bb7a52c0011ae83171eda3212dc1d03dd56fa.png]

Re: [Swig-devel] Post 4.3.0 release perspective

[Matěj C. <mc...@ce...>]

On Sat Oct 26, 2024 at 10:16 PM CEST, Olly Betts wrote:
> I'd certainly love to not be relying on github.  The key thing
> that would need resolving is CI, which has made a huge difference to
> SWIG development - a migration that lost that is really not going to
> work.  SWIG runs a lot of jobs (well over 100) so it's quite resource
> intensive and really needs multiple concurrent runners - a single
> machine or VM running jobs would get too behind.

I can recommend GitLab CI. Certainly I don’t have that many
jobs with M2Crypto, but their system seems to me to be the most
flexible out there with a random Docker containers included.

They have limited amount of free runs, but for such distinguished
project as SWIG I am quite certain you can get free tier with
https://docs.gitlab.com/ee/subscriptions/community_programs.html#gitlab-for-open-source
I certainly got it with much less respectful project.

Best,

Matěj

-- 
http://matej.ceplovi.cz/blog/, @mc...@fl...cial
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
The truth is a beautiful and terrible thing, and should therefore
be treated with caution.
  -- Albus Dumbledore

Re: [Swig-devel] Post 4.3.0 release perspective

[Matěj C. <mc...@ce...>]

On Sat Oct 26, 2024 at 10:16 PM CEST, Olly Betts wrote:
> Migrating everything would put them all in one place, but some of these
> tickets are still open because they're never realistically going to be
> solved for various reasons.  If we dump them into the github tracker
> which already has 400+ open tickets they'll just sit there indefinitely
> instead.  For such intractable tickets it would be better to make a call
> and close as "wontfix" or "incomplete" or whatever is appropriate,
> possibly with a documentation update to note a known limitation.

Absolutely! As a former bug master, I am the last person who
would be against cleaning up the list of tickets to cover only
actionable and relevant tickets. Some spring (or perhaps autumn)
cleaning is certainly always a good idea. Issue tracker is just
TODO list, if there are things there, which shouldn’t be there,
they shouldn’t be there.

Matěj
-- 
http://matej.ceplovi.cz/blog/, @mc...@fl...cial
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
… one of the main causes of the fall of the Roman Empire was
that, lacking zero, they had no way to indicate successful
termination of their C programs.
  -- Robert Firth

Re: [Swig-devel] Post 4.3.0 release perspective

[Olly B. <ol...@su...>]

On 2024-10-25, Matěj Cepl <mc...@ce...> wrote:
> On Thu Oct 24, 2024 at 11:36 PM CEST, Olly Betts wrote:
>> It's cumbersome having tickets in two places, and the github ticket
>> system has some annoying limitations but the sourceforge one is
>> definitely worse.  Just migrating all 77 open tickets over doesn't seem
>> helpful, but migrating the more useful ones will make it easier to see
>> what's left and hopefully moves us closer to being able to fully retire
>> the old tracker.
>
> Zero experience myself, just one search through DuckDuckGo:
>
> [Two SF to github migration tools]

To reiterate, I do NOT think just migrating all 77 open tickets over is
helpful, so a migration tool is not a missing piece here.

Migrating everything would put them all in one place, but some of these
tickets are still open because they're never realistically going to be
solved for various reasons.  If we dump them into the github tracker
which already has 400+ open tickets they'll just sit there indefinitely
instead.  For such intractable tickets it would be better to make a call
and close as "wontfix" or "incomplete" or whatever is appropriate,
possibly with a documentation update to note a known limitation.

Also some are likely to have since been reported separately via github
so then we'd have duplicate tickets, which are hard to spot when you
have nearly 500 open tickets.

So I'm planning to go through and for those with reproducers try to
reproduce with the latest git master (I have a directory tree with a
subdirectory for each ticket which I've tested a reproducer from, so
it's quick and easy for me to do, at least for those since I started
adding a `runme` script with the commands to automate the test which is
most of them at this point).  If they're now fixed we can close,
otherwise check if we seem to have a github ticket and if so add any
useful extra details or testcases.  If there's no existing equivalent
ticket, open a replacement github ticket which has a reproducer.

That should leave a significantly smaller pile to review in more detail.

It's probably also worth a pass through the older (and/or least recently
updated) github tickets at some point too.  I try to retest ones which I
notice and look like they might have been solved by more recent changes
but I've likely missed some.  I think dealing with the SF tickets is
a higher priority though as they're older (even the newest open one
there is now a decade old - the oldest is from 2005).

> (and of course, given the enshitification well on its way at
> GitHub, I would prefer GitLab or something even wilder like
> SourceHut).

I'd certainly love to not be relying on github.  The key thing
that would need resolving is CI, which has made a huge difference to
SWIG development - a migration that lost that is really not going to
work.  SWIG runs a lot of jobs (well over 100) so it's quite resource
intensive and really needs multiple concurrent runners - a single
machine or VM running jobs would get too behind.

Cheers,
    Olly

Re: [Swig-devel] Post 4.3.0 release perspective

[Matěj C. <mc...@ce...>]

On Thu Oct 24, 2024 at 11:36 PM CEST, Olly Betts wrote:
>> 2. I think we should suggest users also try stackoverflow for support as
>> that seems to be the modern way and currently more popular than the
>> swig-user mailing list.

With the continuing enshitification of everything I believe more
and more strongly in the independent small web and ownership
of one’s data. Which lead me back to emails and I find the
experience rather pleasant to be honest. Everything in the one
INBOX and with quality anti-spam measures we have now it is
rather clean (actually, good ol’ bogofilter server-side with
well trained data seems to work just fine). Besides, I have here
archived emails from 1996, and nothing absolutely nothing can
beat it for me.

So, at least, please email list alive.

> I really don't like stackoverflow, and don't like the idea that we
> might promote it as a place to get help.

See above about enshitification … did they finally fix their
cookies handling or is it just my Firefox?

> It's cumbersome having tickets in two places, and the github ticket
> system has some annoying limitations but the sourceforge one is
> definitely worse.  Just migrating all 77 open tickets over doesn't seem
> helpful, but migrating the more useful ones will make it easier to see
> what's left and hopefully moves us closer to being able to fully retire
> the old tracker.

Zero experience myself, just one search through DuckDuckGo:

* https://github.com/ttencate/sf2github, and
* https://github.com/cmungall/gosf2github

(and of course, given the enshitification well on its way at
GitHub, I would prefer GitLab or something even wilder like
SourceHut).

Best,

Matěj

-- 
http://matej.ceplovi.cz/blog/, @mc...@fl...cial
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
One reason that life is complex is that it has a real part and an
imaginary part.
    -- Andrew König

Re: [Swig-devel] Post 4.3.0 release perspective

[Olly B. <ol...@su...>]

On 2024-10-21, William S Fulton <ws...@fu...> wrote:
> Looking at the https://swig.org/mail.html page on the web site, I was
> considering updating it given the mailing lists seem to have gone out of
> fashion a bit.
>
> 1. The GMane and Nabble mailing list search facility no longer works, so
> I'll remove that. I don't know of any replacements, but the SourceForge
> search doesn't seem so bad these days too, which is good.

I can confirm the Gmane search is gone (as it happens I used to run it!)
as has the web frontend - Gmane is now only an NNTP gateway and archive
of mailing lists and that part still works (I'm posting this using it).

> 2. I think we should suggest users also try stackoverflow for support as
> that seems to be the modern way and currently more popular than the
> swig-user mailing list.

I really don't like stackoverflow, and don't like the idea that we
might promote it as a place to get help.

I especially dislike that it tends to dominate in general web search
results, but usually isn't actually the best place to get a definitive
answer to something.

Its mechanism for promoting answers isn't terrible but it can only
promote the best answer that someone on stackoverflow gave, and it can
suffer from group-think where the promoted answer is what is generally
believed but not what is actually correct.

It also seems to have a lot of questions where there are no useful
answers, but which still rank well in general web search results.

Not related to usefulness, but stackoverflow also seems to be run by a
company that does not treat its volunteer moderators well.

> I was also half thinking of suggesting to use Github discussions for
> general user help.

I can't say that idea fills me with joy either.

> Post release is a good time to ponder how things are done. Any thoughts on
> any of the above or any other SWIG development topics for that matter?

Two things:

1) The sourceforge trackers

I'm thinking about doing another pass over the remaining sourceforge
tickets and opening a replacement github ticket for any which have a
decent reproducer and can still be reproduced (it's 2 years+ since I
last did a pass through).

It's cumbersome having tickets in two places, and the github ticket
system has some annoying limitations but the sourceforge one is
definitely worse.  Just migrating all 77 open tickets over doesn't seem
helpful, but migrating the more useful ones will make it easier to see
what's left and hopefully moves us closer to being able to fully retire
the old tracker.

2) Deprecation

You added a policy for deprecation of target languages in
447cd4dd14fc11664c6b2ecbade91cabe5f3dffd.  I think we should come up
with a clear general policy on handling deprecations - I've done a lot
of cleaning up of ancient deprecated features over the last few
releases, mostly of things deprecated for over a decade, some for over
two decades.  Doing this I found we unfortunately lack a simple way to
even identify such deprecated features, let alone know when they were
deprecated without digging about in old CHANGES entries or git history.
Such cleaning up would be easier to stay on top of if we had a policy
for when to remove (quite possibly the same as that for target
languages) and newly added deprecations were recorded in a central list
(which is probably useful for users) or at least marked with a grep-able
comment.

Maybe the policy should be flexible as some deprecations are more
disruptive for users and perhaps deserve a longer period before
removal whereas some are an easy update which also works with all
recent SWIG versions.  The key thing I'd like to have is a simple way to
find which deprecated features are due for removal so we don't end up
with them hanging around for decades.

Related, you asked for comments on the target language deprecation
policy and I noted that "removal from SWIG in a subsequent release
(usually one SWIG release)" would suggest that since we deprecated
mzscheme in 4.3.0 we could remove it in 4.3.1, which I don't think is
what we want (or what you intended).  You didn't respond so I wonder if
you missed this comment.

Cheers,
    Olly

Re: [Swig-devel] csharp gc keepalive patch

[William S F. <ws...@fu...>]

I've commented https://github.com/swig/swig/discussions/3006, so probably
best to continue there.

William

On Tue, 8 Oct 2024 at 17:21, Roderick Green via Swig-devel <
swi...@li...> wrote:

> 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.
> _______________________________________________
> Swig-devel mailing list
> Swi...@li...
> https://lists.sourceforge.net/lists/listinfo/swig-devel
>

[Swig-devel] Post 4.3.0 release perspective

[William S F. <ws...@fu...>]

Firstly, a big thanks to the numerous people who have contributed recently
to the 4.3.0 release. Also a special mention for Olly who has really upped
the momentum on dealing with patches and Github issues.

Please consider master open for future 4.4 development. If 4.3.x patch
releases are needed, we can create a release-4.3 branch and cherry-pick
changes from master onto it later. I'm going to try and make more regular
big release every, every 6-9 months. With that in mind, I've set a
tentative date for May next year for 4.4.

Looking at the https://swig.org/mail.html page on the web site, I was
considering updating it given the mailing lists seem to have gone out of
fashion a bit.

1. The GMane and Nabble mailing list search facility no longer works, so
I'll remove that. I don't know of any replacements, but the SourceForge
search doesn't seem so bad these days too, which is good.
2. I think we should suggest users also try stackoverflow for support as
that seems to be the modern way and currently more popular than the
swig-user mailing list. I was also half thinking of suggesting to use
Github discussions for general user help.

Post release is a good time to ponder how things are done. Any thoughts on
any of the above or any other SWIG development topics for that matter?

William