Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

trying to fix cygwin CI, cf #216 #218

Draft
wants to merge 6 commits into
base: main
Choose a base branch
from
Draft

trying to fix cygwin CI, cf #216 #218

wants to merge 6 commits into from

Conversation

dimpase
Copy link
Member

@dimpase dimpase commented Jan 14, 2025

trying to fix cygwin CI, cf #216

tornaria and others added 4 commits January 13, 2025 20:37
@tornaria
test the custom signal handler with cypari2
9be8773 
This test triggers the following bug on cysignals 1.12.0 - 1.12.2:

```
Python 3.13.1 (main, Dec 14 2024, 12:44:03) [GCC 13.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import cypari2
>>> from cysignals.alarm import alarm
>>> try:
...     alarm(0.5)
...     while True: pass
... except:
...     pass
...
>>> cypari2.Pari()
Traceback (most recent call last):
  File "<python-input-3>", line 1, in <module>
    cypari2.Pari()
    ~~~~~~~~~~~~^^
  File "cypari2/pari_instance.pyx", line 471, in cypari2.pari_instance.Pari.__cinit__
  File "cypari2/closure.pyx", line 138, in cypari2.closure._pari_init_closure
cysignals.signals.AlarmInterrupt
```
@tornaria
fix custom signal handling, which was broken after sagemath#166
6731d2c 
There was a typo in sagemath#181: when the pari sigint handling was converted
to a general mechanism, the line

```
    PARI_SIGINT_pending = 0;
```

got translated into

```
    custom_signal_unblock();
```
instead of the correct
```
    custom_set_pending_signal(0);
```

This error didn't take effect until sagemath#166 removed the pari sigint
handling.

This causes some doctest failures in sagemath:
```
src/sage/coding/linear_code.py
src/sage/geometry/integral_points.pxi
src/sage/rings/integer.pyx
src/sage/rings/polynomial/polynomial_element.pyx
```
related to mishandling of AlarmInterrupt.

See: https://github.com/sagemath/cysignals/pull/181/files#r1904885037
@tornaria
skip new test on windows (needs cysignals.alarm)
36844ad
@dimpase
tring to fix cygwin
ecd15bb
@dimpase dimpase mentioned this pull request Jan 14, 2025
Merged
@dimpase dimpase requested a review from tobiasdiez January 14, 2025 18:10
@dimpase
Copy link
Member Author

dimpase commented Jan 14, 2025

Cygwin build still fails - it now can find mesonpy, but still fails pretty fast, and the log shows that meson mixes toolsets quite badly.

@dimpase dimpase marked this pull request as draft January 14, 2025 18:12
@dimpase
Copy link
Member Author

dimpase commented Jan 15, 2025

ninja (invoked from meson?) picks up wrong Python headers - instead of Cygwin's Python, it takes native ones, oops:

Found ninja.EXE-1.12.0 at C:\tools\cygwin\bin\ninja.EXE
  + meson compile
  [1/3] Compiling Cython source 'D:/a/cysignals/cysignals/src/cysignals/signals.pyx'
  [2/3] Compiling C object src/cysignals/signals.cp39-win_amd64.pyd.p/meson-generated_src_cysignals_signals.pyx.c.obj
  FAILED: src/cysignals/signals.cp39-win_amd64.pyd.p/meson-generated_src_cysignals_signals.pyx.c.obj
  "gcc" "-Isrc\cysignals\signals.cp39-win_amd64.pyd.p" "-Isrc\cysignals" "-I..\src\cysignals" "-Isrc" "-I..\src" "-IC:\hostedtoolcache\windows\Python\3.9.13\x64\Include" "-fvisibility=hidden" "-fdiagnostics-color=always" "-DNDEBUG" "-D_FILE_OFFSET_BITS=64" "-Wall" "-Winvalid-pch" "-Wextra" "-Wpedantic" "-O3" "-DCYTHON_CLINE_IN_TRACEBACK=0" "-U_FORTIFY_SOURCE" "-DMS_WIN64=" -MD -MQ src/cysignals/signals.cp39-win_amd64.pyd.p/meson-generated_src_cysignals_signals.pyx.c.obj -MF "src\cysignals\signals.cp39-win_amd64.pyd.p\meson-generated_src_cysignals_signals.pyx.c.obj.d" -o src/cysignals/signals.cp39-win_amd64.pyd.p/meson-generated_src_cysignals_signals.pyx.c.obj "-c" src/cysignals/signals.cp39-win_amd64.pyd.p/src/cysignals/signals.pyx.c
  In file included from C:\hostedtoolcache\windows\Python\3.9.13\x64\Include/Python.h:50,
                   from src/cysignals/signals.cp39-win_amd64.pyd.p/src/cysignals/signals.pyx.c:16:
  C:\hostedtoolcache\windows\Python\3.9.13\x64\Include/pyport.h:741:2: error: #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)."
...

@tobiasdiez
Copy link
Contributor

I've no idea why this is failing now - there were no changes to this workflow and also no updates to the cygwin action...very strange.

@dimpase
Copy link
Member Author

dimpase commented Jan 15, 2025

maybe a change to the host environment?

@dimpase
Copy link
Member Author

dimpase commented Jan 15, 2025

there is also an error related to chocolatey shown in the log, some kind of version mismatch.

@dimpase
Copy link
Member Author

dimpase commented Jan 15, 2025

I've opened egor-tensin/setup-cygwin#14

@dimpase
Copy link
Member Author

dimpase commented Jan 15, 2025

I eliminated the chocolatey warning in the action update, but it hasn't changed anything. I'm giving up. Let's disable the cygwin CI, maybe?

@tornaria
Copy link
Contributor

I eliminated the chocolatey warning in the action update, but it hasn't changed anything. I'm giving up. Let's disable the cygwin CI, maybe?

It's running python 3.9 which we shouldn't waste time supporting anyway.

In fact, I am needing some python 3.11 and maybe 3.12 to fix the sig_occurred() mishap (https://docs.python.org/3/c-api/exceptions.html#c.PyErr_GetHandledException and https://docs.python.org/3/c-api/exceptions.html#c.PyErr_GetRaisedException), but I'll try to workaround it for earlier python. For PyErr_GetRaisedException() one can use PyErr_Fetch(), but I'm not sure there's an alternative to PyErr_GetHandlerException() before python 3.11.

I assume dropping python 3.9 is ok, but I'm not sure about python 3.10.

@tornaria
Copy link
Contributor

I assume dropping python 3.9 is ok, but I'm not sure about python 3.10.

https://scientific-python.org/specs/spec-0000/#2024---quarter-4 seems to suggest it might be ok to drop python 3.10 if necessary.

@dimpase
Copy link
Member Author

dimpase commented Jan 16, 2025

I assume dropping python 3.9 is ok, but I'm not sure about python 3.10.

cygwin is stuck on 3.9, so this seems like dead wood.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@tobiasdiez tobiasdiez Awaiting requested review from tobiasdiez

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@dimpase @tobiasdiez @tornaria