Release 0.6.1

[roryyorke]

Last release was over a year ago. Since then:

• CI fixes
• minor code clean-up
• a fix that's affected at least two different users.

Any objections to making a new release?

[murrayrm]

When I was building python-control 0.10.2, I noticed a problem in the slycot build: the Windows runner was failing due to not being able to find nmake. I bypassed the issue by installing slycot from conda-forge, but wanted to point out so that whoever does the release knows it may be an issue.

Details (not much more than above) in python-control gh-1164.

[bnavigator]

I has been on my TODO list for ages to move from legacy scikit-build to either scikit-build-core or meson. That should overlap with rework of how to find the build tools and library headers. I'll see if I can get to it in the next couple days

[roryyorke]

the Windows runner was failing due to not being able to find nmake.

Something similar happened on fairly trivial PR I just submitted; I think the relevant problem is some issue with flang --- see end; after this CMake (I assume) goes on to try other MSVC versions and can't find nmake for them, so the final error messages are all about nmake.

move from legacy scikit-build to either scikit-build-core or meson.

That would be great.

I have access to a Windows 11 machine; I'll see how far I get with setting up a build environment. My past attempts at building Slycot on Windows have generally gone quite badly, however.

  -- Check for working Fortran compiler: C:/Users/runneradmin/miniconda3/envs/build-env/conda-bld/slycot_1754230669354/_build_env/Library/bin/flang.exe - broken
  CMake Error at C:/Users/runneradmin/miniconda3/envs/build-env/conda-bld/slycot_1754230669354/_build_env/Library/share/cmake-4.0/Modules/CMakeTestFortranCompiler.cmake:59 (message):
    The Fortran compiler

      "C:/Users/runneradmin/miniconda3/envs/build-env/conda-bld/slycot_1754230669354/_build_env/Library/bin/flang.exe"

    is not able to compile a simple test program.

    It fails with the following output:

      Change Dir: 'C:/Users/runneradmin/miniconda3/envs/build-env/conda-bld/slycot_1754230669354/work/_cmake_test_compile/build/CMakeFiles/CMakeScratch/TryCompile-yslkbw'

      Run Build Command(s): C:/Users/runneradmin/miniconda3/envs/build-env/conda-bld/slycot_1754230669354/_build_env/Library/bin/cmake.exe -E env VERBOSE=1 nmake -f Makefile /nologo cmTC_c3a8d\fast
        "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.44.35207\bin\HostX86\x64\nmake.exe"  -f CMakeFiles\cmTC_c3a8d.dir\build.make /nologo -L                  CMakeFiles\cmTC_c3a8d.dir\build
      Building Fortran object CMakeFiles/cmTC_c3a8d.dir/testFortranCompiler.f.obj
        C:\Users\runneradmin\miniconda3\envs\build-env\conda-bld\slycot_1754230669354\_build_env\Library\bin\flang.exe     -o CMakeFiles\cmTC_c3a8d.dir\testFortranCompiler.f.obj -c C:\Users\runneradmin\miniconda3\envs\build-env\conda-bld\slycot_1754230669354\work\_cmake_test_compile\build\CMakeFiles\CMakeScratch\TryCompile-yslkbw\testFortranCompiler.f
      Linking Fortran executable cmTC_c3a8d.exe
        C:\Users\runneradmin\miniconda3\envs\build-env\conda-bld\slycot_1754230669354\_build_env\Library\bin\cmake.exe -E vs_link_exe --msvc-ver=1900 --intdir=CMakeFiles\cmTC_c3a8d.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100261~1.0\x86\rc.exe --mt="" --manifests -- C:\PROGRA~1\MICROS~2\2022\ENTERP~1\VC\Tools\MSVC\1444~1.352\bin\Hostx86\x64\link.exe /nologo @CMakeFiles\cmTC_c3a8d.dir\objects1.rsp @C:\Users\RUNNER~1\AppData\Local\Temp\nm2550.tmp
      Visual Studio Incremental Link with embedded manifests
      Create CMakeFiles\cmTC_c3a8d.dir/manifest.rc
      Create empty: CMakeFiles\cmTC_c3a8d.dir/embed.manifest
      RC Pass 1:
      C:\PROGRA~2\WI3CF2~1\10\bin\100261~1.0\x86\rc.exe /fo CMakeFiles\cmTC_c3a8d.dir/manifest.res CMakeFiles\cmTC_c3a8d.dir/manifest.rc
      LINK Pass 1:
      C:\PROGRA~1\MICROS~2\2022\ENTERP~1\VC\Tools\MSVC\1444~1.352\bin\Hostx86\x64\link.exe /nologo @CMakeFiles\cmTC_c3a8d.dir\objects1.rsp /out:cmTC_c3a8d.exe /implib:cmTC_c3a8d.lib /pdb:C:\Users\runneradmin\miniconda3\envs\build-env\conda-bld\slycot_1754230669354\work\_cmake_test_compile\build\CMakeFiles\CMakeScratch\TryCompile-yslkbw\cmTC_c3a8d.pdb /version:0.0 /machine:x64 /debug /INCREMENTAL /subsystem:console /MANIFEST /MANIFESTFILE:CMakeFiles\cmTC_c3a8d.dir/intermediate.manifest CMakeFiles\cmTC_c3a8d.dir/manifest.res
      LINK Pass 1: command "C:\PROGRA~1\MICROS~2\2022\ENTERP~1\VC\Tools\MSVC\1444~1.352\bin\Hostx86\x64\link.exe /nologo @CMakeFiles\cmTC_c3a8d.dir\objects1.rsp /out:cmTC_c3a8d.exe /implib:cmTC_c3a8d.lib /pdb:C:\Users\runneradmin\miniconda3\envs\build-env\conda-bld\slycot_1754230669354\work\_cmake_test_compile\build\CMakeFiles\CMakeScratch\TryCompile-yslkbw\cmTC_c3a8d.pdb /version:0.0 /machine:x64 /debug /INCREMENTAL /subsystem:console /MANIFEST /MANIFESTFILE:CMakeFiles\cmTC_c3a8d.dir/intermediate.manifest CMakeFiles\cmTC_c3a8d.dir/manifest.res" failed (exit code 1104) with the following output:
      LINK : fatal error LNK1104: cannot open file 'flangmain.lib'
      NMAKE : fatal error U1077: 'C:\Users\runneradmin\miniconda3\envs\build-env\conda-bld\slycot_1754230669354\_build_env\Library\bin\cmake.exe -E vs_link_exe --msvc-ver=1900 --intdir=CMakeFiles\cmTC_c3a8d.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100261~1.0\x86\rc.exe --mt="" --manifests -- C:\PROGRA~1\MICROS~2\2022\ENTERP~1\VC\Tools\MSVC\1444~1.352\bin\Hostx86\x64\link.exe /nologo @CMakeFiles\cmTC_c3a8d.dir\objects1.rsp @C:\Users\RUNNER~1\AppData\Local\Temp\nm2550.tmp' : return code '0xffffffff'
      Stop.
      NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.44.35207\bin\HostX86\x64\nmake.exe"  -f CMakeFiles\cmTC_c3a8d.dir\build.make /nologo -L                  CMakeFiles\cmTC_c3a8d.dir\build' : return code '0x2'
      Stop.

[roryyorke]

After spending several hours each weekend since posting this issue on trying to get Windows + conda builds to work, I was midway between infuriated and amused to read a recent opinion that we, the Slycot maintainers, are "lazy" to be relying on conda builds of the package.

Anyway, I have, at last, made progress.

I first tried converting to scikit-build-core (see https://github.com/roryyorke/Slycot/tree/rory/proto-scikit-core-build). This was relatively straightforward, and is an improvement --- but didn't sort out the Github Windows build.

Then, after many false starts, I got somewhere with our Windows build by taking a look at how https://github.com/conda-forge/slycot-feedstock gets it right --- there's a recentish PR there that has successful Windows builds. Copying from this I got the proof-of-concept https://github.com/roryyorke/Slycot/tree/rory/github-action-windows; a successful Windows build is at https://github.com/roryyorke/Slycot/actions/runs/17515691037 .

The important bits seem to have been

• remove older Github workflow config for setting up Conda
• get the right magic numbers in conda_build_config.yaml for MSVC and Fortran compilers,
• choosing the right value for the FC environment variable

My proposal for 0.6.1 is to do the minimum changes to our Github config so we can pass a sane test matrix (3.10 to 3.14? that's the range I see at the slycot-feedstock PR), and look at scikit-build-core for the next release. I'm going to focus on getting Windows builds passing on this test matrix on my proof-of-concept branch; if that seems to work, I can make the necessary changes to a new, master-based branch and hopefully get everything building and passing.

[bnavigator]

Sounds good to me. I spent some time with meson instead of scikit-build-core/cmake, but didn't get far.

[moorepants]

are "lazy" to be relying on conda builds of the package.

You have to just ignore that nonsense.

[roryyorke]

gh-250 fixes conda builds, there seems to be a problems with coveralls on OSX. I ended up only building for 3.13, the latest release Python; each build results in 9 test cases (per Python version across all platforms; see set-conda-test-matrix.py).

Proposed release notes below.

Fixes

Fixed a segmentation fault in ab09nd (gh-243).

Build

Conda build files updated from conda-forge/slycot-feedstock.

Testing

Fixes to Github Workflow CI.

Pull requests and issues associated with the release

PRs merged:

• Update macos gfortran version #237 CI: update gfortran version
• ab09nd iwork expression fix #243 fix Segmentation fault at garbage collection after running ab09nd with return value of nr=0 #242
• Fix some CI errors #244 CI: fixes
• Fix or silence ruff check warnings; add ruff check to Github Actions #246 CI: add ruff
• CI: skip docstrings_test.py and add defaults channel #247 CI: skip docstrings, add conda defaults channel
• Update license specification to latest packaging standards #249 license metadata update
• gh-TBD CI: fix conda build

Issues fixed:

• Segmentation fault at garbage collection after running ab09nd with return value of nr=0 #242: ab09nd segmentation fault

Issues closed ("wont-fix"):

• Installation problem in Ubuntu 22.04 #239: user install problem
• Slycot Numpy 2.0 warning #241: user install problem
• Crash when using AB09ND with bfsqrt, issue is incorrect dimension for iwork #245: duplicate of Segmentation fault at garbage collection after running ab09nd with return value of nr=0 #242

[ilayn]

FYI, I finally had a bit of time this weekend and started translating SLICOT to C. ilayn/SLICUTLET#1 is the main place to watch progress. It already has meson build scaffolding and provides bindings to Python and gets tested via pytest (already caught my own bugs). I also included some Fortran symbol mangling silliness to provide some convenience to link with MKL or other BLAS/LAPACK providers. ILP64 support is not so trivial so I left it for later.

I am not really planning at this stage the entire SLICOT to be translated as some of the routines are exceedingly niche but would be nice anyways. If there is interest I can prioritize the parts that python-control uses to package control a bit more uniformly on all C11 capable platforms.

All help feedback dis/encouragement is appreciated. Especially if you want to stretch some C programming muscles on a rainy weather it's more than welcome.

[roryyorke]

FYI, I finally had a bit of time this weekend and started translating SLICOT to C.

Interesting. Two questions:

1. Is it not practical to implement these in Python?
2. How much numerical analysis and "numerical linear algebra" (I assume there's a field like that) do you need to get into the nitty-gritty detail?

[roryyorke]

draft release at https://github.com/python-control/Slycot/releases/tag/untagged-3376af6f6e4c014bc6e6 - release notes have minor updates compared to what I put above.

[ilayn]

Interesting. Two questions:

1. It is very practical in Python actually but there is always these folks complaining about performance. Plus I think it would be better to leave it in a state non-Python projects can also use. It is really not that hard really. Just very tedious. Because these are established parts of the control theory (the identification and controller synthesis notwithstanding, they are quite outdated).
2. Numerical linear algebra is not needed too much. Also the translations are quite mechanical. What I have been doing is translating them into C then creating an extension module for Python and asking LLM to write pytest compatible unit tests. That formula turns out to be quite productive as opposed to asking LLM to translate it which turned out to be not very fruitful.

A call for action is here ilayn/harold#102 😄 It is really a hobby project (in a straightjacket) really. We are almost done with the entire SciPy library F77 translations, and it has been running in production for the last 5 versions. So it gave me enough courage to attack SLICOT too.

If I can cover python-control parts, maybe it might ease your pain of releasing wheels. Obviously, feel free to decline, no hard feelings.

[roryyorke]

I've published here, and pushed source sdist to PyPI.

For conda-forge: According to https://conda-forge.org/docs/maintainer/updating_pkgs/#pushing-to-regro-cf-autotick-bot-branch there should be an automatic process that will submit a PR for update. I'll leave this issue open until there's at least a PR, automatic or otherwise, on the feedstock repo.

[moorepants]

Yes, a PR will open on the feedstock automatically.

[moorepants]

There is also a new PR there to build with flang 21.

[roryyorke]

All done! We may also get Python 3.14 + flang 21 builds on conda-forge, see feedstock repo for that.