1. 27 Apr, 2023 30 commits
    • Kirill Smelkov's avatar
      gpython: tests: Prepare expected repr properly · 161629e6
      Kirill Smelkov authored
      In several places we were preparing repr of a string as '%s' which works
      ok most of the time but leads to failure if string contains '\'
      characters e.g. if it represents a path and we are running on windows:
      
              def test_pymain():
                  from golang import b
      
                  ....
      
                  # -m <module>
                  _ = pyout(['-m', 'hello', 'abc', 'def'], cwd=testdata)
                  # realpath rewrites e.g. `local/lib -> lib` if local/lib is symlink
                  hellopy = realpath(join(testdata, 'hello.py'))
          >       assert _ == b"hello\nworld\n['%s', 'abc', 'def']\n" % b(hellopy)
          E       assert b"hello\nworld\n['Z:\\\\home\\\\kirr\\\\src\\\\tools\\\\go\\\\pygo-win\\\\pygolang\\\\gpython\\\\testdata\\\\hello.py', 'abc', 'def'
          ]\n" == b"hello\nworld\n['Z:\\home\\kirr\\src\\tools\\go\\pygo-win\\pygolang\\gpython\\testdata\\hello.py', 'abc', 'def']\n"
          E         At index 17 diff: b'\\' != b'h'
          E         Full diff:
          E           (
          E         -  b"hello\nworld\n['Z:\\home\\kirr\\src\\tools\\go\\pygo-win\\pygolang\\gpytho"
          E         ?                                                                  ------------
          E         +  b"hello\nworld\n['Z:\\\\home\\\\kirr\\\\src\\\\tools\\\\go\\\\pygo-win\\\\pygo"
          E         ?                        ++    ++        ++   ++         ++  ++            ++
          E         -  b"n\\testdata\\hello.py', 'abc', 'def']\n",
          E         +  b"lang\\\\gpython\\\\testdata\\\\hello.py', 'abc', 'def']\n",
          E         ?    ++ ++++++++++++++            ++
          E           )
      
          gpython\gpython_test.py:183: AssertionError
      
      -> Fix it by preparing repr via repr(...) properly.
      161629e6
    • Kirill Smelkov's avatar
      gpython: Fix gevent activation on Windows · f23a9ef5
      Kirill Smelkov authored
      On Windows if geventmp is present gpython startup fails:
      
          (1.wenv) Z:\home\kirr\src\tools\go\pygo-win\pygolang>gpython
          Traceback (most recent call last):
            File "C:\Program Files\Python310\lib\runpy.py", line 196, in _run_module_as_main
              return _run_code(code, main_globals, None,
            File "C:\Program Files\Python310\lib\runpy.py", line 86, in _run_code
              exec(code, run_globals)
            File "Z:\home\kirr\src\tools\go\pygo-win\1.wenv\Scripts\gpython.exe\__main__.py", line 7, in <module>
            File "Z:\home\kirr\src\tools\go\pygo-win\pygolang\gpython\__init__.py", line 450, in main
              pymain(argv, init)
            File "Z:\home\kirr\src\tools\go\pygo-win\pygolang\gpython\__init__.py", line 223, in pymain
              init()
            File "Z:\home\kirr\src\tools\go\pygo-win\pygolang\gpython\__init__.py", line 428, in init
              _ = monkey.patch_all(thread=patch_thread)      # XXX sys=True ?
            File "Z:\home\kirr\src\tools\go\pygo-win\1.wenv\lib\site-packages\gevent\monkey.py", line 1255, in patch_all
              _notify_patch(events.GeventWillPatchAllEvent(modules_to_patch, kwargs), _warnings)
            File "Z:\home\kirr\src\tools\go\pygo-win\1.wenv\lib\site-packages\gevent\monkey.py", line 190, in _notify_patch
              notify_and_call_entry_points(event)
            File "Z:\home\kirr\src\tools\go\pygo-win\1.wenv\lib\site-packages\gevent\events.py", line 105, in notify_and_call_entry_points
              subscriber(event)
            File "Z:\home\kirr\src\tools\go\pygo-win\1.wenv\lib\site-packages\geventmp\monkey.py", line 160, in _patch_mp
              _patch_module("_mp.3._mp_util", _patch_module=True, _package_prefix='geventmp.')
            File "Z:\home\kirr\src\tools\go\pygo-win\1.wenv\lib\site-packages\geventmp\monkey.py", line 121, in _patch_module
              gevent_module = import_module(_package_prefix + name)
            File "C:\Program Files\Python310\lib\importlib\__init__.py", line 126, in import_module
              return _bootstrap._gcd_import(name[level:], package, level)
            File "<frozen importlib._bootstrap>", line 1050, in _gcd_import
            File "<frozen importlib._bootstrap>", line 1027, in _find_and_load
            File "<frozen importlib._bootstrap>", line 1006, in _find_and_load_unlocked
            File "<frozen importlib._bootstrap>", line 688, in _load_unlocked
            File "<frozen importlib._bootstrap_external>", line 883, in exec_module
            File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
            File "Z:\home\kirr\src\tools\go\pygo-win\1.wenv\lib\site-packages\geventmp\_mp\3\_mp_util.py", line 16, in <module>
              from gevent.os import _watch_child
          ImportError: cannot import name '_watch_child' from 'gevent.os' (Z:\home\kirr\src\tools\go\pygo-win\1.wenv\lib\site-packages\gevent\os.py)
      
      That happens because geventmp does not support windows actually.
      
      -> Fix it by requiring geventmp to be present only on non-windows.
      
      Adjust related comment as https://github.com/karellen/geventmp/pull/2 has been merged long ago.
      f23a9ef5
    • Kirill Smelkov's avatar
      gpython: Fix startup on Windows when installed by pip · 377e44cb
      Kirill Smelkov authored
      On windows setuptools install gpython.exe and gpython-script.py while
      pip/distlib install gpython.exe with gpython-script sometimes embedded
      into gpython.exe itself with argv[0] pointing to 'gpython' without .exe
      suffix. This leads to gpython startup failure:
      
          (1.wenv) Z:\home\kirr\src\tools\go\pygo-win\pygolang>gpython
          Traceback (most recent call last):
            File "C:\Program Files\Python310\lib\runpy.py", line 196, in _run_module_as_main
              return _run_code(code, main_globals, None,
            File "C:\Program Files\Python310\lib\runpy.py", line 86, in _run_code
              exec(code, run_globals)
            File "Z:\home\kirr\src\tools\go\pygo-win\1.wenv\Scripts\gpython.exe\__main__.py", line 7, in <module>
            File "Z:\home\kirr\src\tools\go\pygo-win\pygolang\gpython\__init__.py", line 437, in main
              pymain(argv, init)
            File "Z:\home\kirr\src\tools\go\pygo-win\pygolang\gpython\__init__.py", line 79, in pymain
              if not _is_buildout_script(exe):
            File "Z:\home\kirr\src\tools\go\pygo-win\pygolang\gpython\__init__.py", line 442, in _is_buildout_script
              with open(path, 'rb') as f:
          FileNotFoundError: [Errno 2] No such file or directory: 'Z:\\home\\kirr\\src\\tools\\go\\pygo-win\\1.wenv\\Scripts\\gpython'
      
          (1.wenv) Z:\home\kirr\src\tools\go\pygo-win\pygolang>dir ../1.wenv/scripts/gpython*
      
          Directory of Z:\home\kirr\src\tools\go\pygo-win\1.wenv\scripts
      
          26.04.2023     14:17       108,404  gpython.exe
                 1 file                   108,404 bytes
                 0 directories     88,508,866,560 bytes free
      
      -> Adjust pymain to handle this case accordingly.
      377e44cb
    • Kirill Smelkov's avatar
      os/signal: tests: Adjust exit code expectation for Windows · 2f632a3e
      Kirill Smelkov authored
      On windows upon terminating signal reception exict code of the process
      is always 3 instead of -signo. And so test_signal_all was failing as
      
              def test_signal_all():
                  retcode, out, _ = _pyrun([dir_testprog + "/signal_test_all.py"], stdout=PIPE)
                  assert b"ok (notify)"        in out
                  assert b"ok (ignore)"        in out
                  assert b"terminating ..."    in out
          >       assert retcode == -syscall.SIGTERM.signo
          E       assert 3 == -15
          E        +  where 15 = os.Signal(15).signo
          E        +    where os.Signal(15) = syscall.SIGTERM
      2f632a3e
    • Kirill Smelkov's avatar
      os/signal: Adjust signal_test_all.py to support Windows · c1d5b67b
      Kirill Smelkov authored
      - There is no e.g. signal.SIGKILL on windows:
      
          golang/os/signal_test.py::test_signal_all Traceback (most recent call last):
            File "Z:\home\kirr\src\tools\go\pygo-win\pygolang\golang\os\testprog\signal_test_all.py", line 82, in <module>
              main()
            File "Z:\home\kirr\src\tools\go\pygo-win\pygolang\golang\os\testprog\signal_test_all.py", line 39, in main
              allsigv.remove(syscall.SIGKILL) # SIGKILL/SIGSTOP cannot be caught
          AttributeError: module 'golang.syscall' has no attribute 'SIGKILL'. Did you mean: 'SIGILL'?
      
        -> filter-out signals conditionally depending on their presence.
      
      - Need to also filter-out SIGILL/SIGABRT because upon reception MSVC
        runtime terminates process.
      c1d5b67b
    • Kirill Smelkov's avatar
      os/signal: tests: use raise instead of kill(self) · ca4af748
      Kirill Smelkov authored
      Because on Windows os.kill unconditionally terminates target process,
      even if own self, instead of sending it any kind of signal.
      ca4af748
    • Kirill Smelkov's avatar
      os/signal: tests: Use SIGTERM/SIGINT on Windows · 75d40910
      Kirill Smelkov authored
      We use SIGUSR1/SIGUSR2 mainly in this test, but those signals are not
      available on Windows:
      
              @func
              def test_signal():
                  # Notify/Stop with wrong chan dtype -> panic
                  _ = panics("pychan: channel type mismatch")
          >       with _:  signal.Notify(chan(2), syscall.SIGUSR1)
          E       AttributeError: module 'golang.syscall' has no attribute 'SIGUSR1'
      
      -> Use SIGTERM/SIGINT if SIGUSR1/SIGUSR2 are not available.
      
      Don't want to use SIGTERM/SIGINT unconditionally because those signals are
      better to leave for the job control so that e.g. nxdtest can properly kill
      spawned pygolang tests.
      75d40910
    • Kirill Smelkov's avatar
      *.py: Open files in binary mode and decode to UTF-8 explicitly if needed · a5349f5d
      Kirill Smelkov authored
      On Windows in text mode files are opened with encoding=locale.getdefaultlocale()
      which is CP125X instead of UTF-8 even if $PYTHONIOENCODING=UTF-8. This
      way e.g. test_strings_print fail as:
      
          E           Failed: not equal:
          E           Expected:
          E               print(qq(b)): "привет αβγ b"
          E               print(qq(u)): "привет αβγ u"
          E           Got:
          E               print(qq(b)): "привет αβγ b"
          E               print(qq(u)): "привет αβγ u"
      
      where "Expected" was read from golang/testprog/golang_test_str.txt and
      decoded wrongly.
      
      -> Fix it by always opening files for reading in binary mode and
      utf8-decoding manually, if needed, everywhere.
      a5349f5d
    • Kirill Smelkov's avatar
      golang: tests: Spawn subprocess python with $PYTHONIOENCODING set to encoding... · 8d723b34
      Kirill Smelkov authored
      golang: tests: Spawn subprocess python with $PYTHONIOENCODING set to encoding of stdin/stdout/stderr
      
      We need to do it because on Windows `python x.py | ...` runs with stdio
      encoding set to cp125X even if just `python x.py` runs with stdio
      encoding=UTF-8.
      
          (1.wenv) Z:\home\kirr\src\tools\go\pygo-win\pygolang\golang\testprog>python golang_test_str.py
          print(qq(b)): "привет b"
          print(qq(u)): "привет u"
      
          (1.wenv) Z:\home\kirr\src\tools\go\pygo-win\pygolang\golang\testprog>python golang_test_str.py |more
          print(qq(b)): "яЁштхЄ b"
          print(qq(u)): "яЁштхЄ u"
      
          (1.wenv) Z:\home\kirr\src\tools\go\pygo-win\pygolang\golang\testprog>python golang_test_str.py >aaa.txt
          (1.wenv) Z:\home\kirr\src\tools\go\pygo-win\pygolang\golang\testprog>type aaa.txt
          print(qq(b)): "яЁштхЄ b"
          print(qq(u)): "яЁштхЄ u"
      
      Which leads to the following test_strings_print failure:
      
          E           Failed: not equal:
          E           Expected:
          E               print(qq(b)): "привет b"
          E               print(qq(u)): "привет u"
          E           Got:
          E               print(qq(b)): "������ b"
          E               print(qq(u)): "������ u"
      
      We also change golang_test_str.py to print not only russian and english
      letters, but also greek ones. This is to make sure that stdout IO encoding would
      not go cp125X unnoticed because then printing will fail with UnicodeEncodeError.
      
      Note: in the above example both got and expected are wrong. Via
      $PYTHONIOENCODING we only fix "got" and we will fix "expected" in the followup
      patch. After current patch test_strings_print result is
      
          E           Failed: not equal:
          E           Expected:
          E               print(qq(b)): "привет αβγ b"
          E               print(qq(u)): "привет αβγ u"
          E           Got:
          E               print(qq(b)): "привет αβγ b"
          E               print(qq(u)): "привет αβγ u"
      8d723b34
    • Kirill Smelkov's avatar
      golang: tests: Adjust golang_test_defer_excchain.txt-pytest golden to support Windows · ee55e19d
      Kirill Smelkov authored
      Apparently on Windows pytest detects terminal width differently than on
      Linux/macOS and the test fails as
      
          E           Failed: not equal:
          E           Differences (unified diff with -expected +actual):
          E               @@ -1,5 +1,12 @@
          E               -...
          E               -_____________________________________ main _____________________________________
          E               -../__init__.py:...: in _
          E               +============================= test session starts =============================
          E               +platform win32 -- Python 3.10.11, pytest-7.3.1, pluggy-1.0.0
          E               +rootdir: PYGOLANG
          E               +collected 1 item
          E               +<BLANKLINE>
          E               +golang_test_defer_excchain.py F                                          [100%]
          E               +<BLANKLINE>
          E               +================================== FAILURES ===================================
          E               +____________________________________ main _____________________________________
          E               +../__init__.py:106: in _
          E                    return f(*argv, **kw)
          E                golang_test_defer_excchain.py:42: in main
          E               @@ -8,6 +15,6 @@
          E                <BLANKLINE>
          E                During handling of the above exception, another exception occurred:
          E               -../__init__.py:...: in __exit__
          E               -    ...
          E               +../__init__.py:183: in __exit__
          E               +    d()
          E                golang_test_defer_excchain.py:31: in d1
          E                    raise RuntimeError("d1: aaa")
          E               @@ -15,9 +22,9 @@
          E                <BLANKLINE>
          E                During handling of the above exception, another exception occurred:
          E               -../__init__.py:...: in __exit__
          E               -    ...
          E               +../__init__.py:183: in __exit__
          E               +    d()
          E                golang_test_defer_excchain.py:33: in d2
          E                    1/0
          E               -E   ZeroDivisionError: ...
          E               +E   ZeroDivisionError: division by zero
          E                <BLANKLINE>
          E                During handling of the above exception, another exception occurred:
          E               @@ -25,3 +32,5 @@
          E                    raise RuntimeError("d3: bbb")
          E                E   RuntimeError: d3: bbb
          E               -=========================== ...
          E               +=========================== short test summary info ===========================
          E               +FAILED golang_test_defer_excchain.py::main - RuntimeError: d3: bbb
          E               +============================== 1 failed in 1.45s ==============================
      
      -> Fix it by not requesting header to be of particular width.
      ee55e19d
    • Kirill Smelkov's avatar
      golang: tests: Normalize \r\n to \n in doctests on windows · 17c1d2fa
      Kirill Smelkov authored
      On windows print emits \r\n instead of just \n. Here is how e.g.
      test_defer_excchain_dump fails without normalization:
      
          E           Failed: not equal:
          E           Differences (unified diff with -expected +actual):
          E               @@ -1,42 +1,43 @@
          E               -Traceback (most recent call last):
          E               -  File "PYGOLANG/golang/__init__.py", line ..., in _
          E               -    return f(*argv, **kw)
          E               -  File "PYGOLANG/golang/testprog/golang_test_defer_excchain.py", line 42, in main
          E               -    raise RuntimeError("err")
          E               -RuntimeError: err
          E               -<BLANKLINE>
          E               -During handling of the above exception, another exception occurred:
          E               -<BLANKLINE>
          E               -Traceback (most recent call last):
          E               -  File "PYGOLANG/golang/__init__.py", line ..., in __exit__
          E               -    ...
          E               -  File "PYGOLANG/golang/testprog/golang_test_defer_excchain.py", line 31, in d1
          E               -    raise RuntimeError("d1: aaa")
          E               -RuntimeError: d1: aaa
          E               -<BLANKLINE>
          E               -During handling of the above exception, another exception occurred:
          E               -<BLANKLINE>
          E               -Traceback (most recent call last):
          E               -  File "PYGOLANG/golang/__init__.py", line ..., in __exit__
          E               -    ...
          E               -  File "PYGOLANG/golang/testprog/golang_test_defer_excchain.py", line 33, in d2
          E               -    1/0
          E               -ZeroDivisionError: ...
          E               -<BLANKLINE>
          E               -During handling of the above exception, another exception occurred:
          E               -<BLANKLINE>
          E               -Traceback (most recent call last):
          E               -  ... "PYGOLANG/golang/testprog/golang_test_defer_excchain.py", line 45, in <module>
          E               -    main()
          E               -  ...
          E               -  File "PYGOLANG/golang/__init__.py", line ..., in _
          E               -    with __goframe__:
          E               -  File "PYGOLANG/golang/__init__.py", line ..., in __exit__
          E               -    ...
          E               -  File "PYGOLANG/golang/__init__.py", line ..., in __exit__
          E               -    ...
          E               -  File "PYGOLANG/golang/__init__.py", line ..., in __exit__
          E               -    ...
          E               -  File "PYGOLANG/golang/testprog/golang_test_defer_excchain.py", line 35, in d3
          E               -    raise RuntimeError("d3: bbb")
          E               -RuntimeError: d3: bbb
          E               +Traceback (most recent call last):
          E               +  File "PYGOLANG/golang/__init__.py", line 106, in _
          E               +    return f(*argv, **kw)
          E               +  File "PYGOLANG/golang/testprog/golang_test_defer_excchain.py", line 42, in main
          E               +    raise RuntimeError("err")
          E               +RuntimeError: err
          E               +
          E               +During handling of the above exception, another exception occurred:
          E               +
          E               +Traceback (most recent call last):
          E               +  File "PYGOLANG/golang/__init__.py", line 183, in __exit__
          E               +    d()
          E               +  File "PYGOLANG/golang/testprog/golang_test_defer_excchain.py", line 31, in d1
          E               +    raise RuntimeError("d1: aaa")
          E               +RuntimeError: d1: aaa
          E               +
          E               +During handling of the above exception, another exception occurred:
          E               +
          E               +Traceback (most recent call last):
          E               +  File "PYGOLANG/golang/__init__.py", line 183, in __exit__
          E               +    d()
          E               +  File "PYGOLANG/golang/testprog/golang_test_defer_excchain.py", line 33, in d2
          E               +    1/0
          E               +ZeroDivisionError: division by zero
          E               +
          E               +During handling of the above exception, another exception occurred:
          E               +
          E               +Traceback (most recent call last):
          E               +  File "PYGOLANG/golang/testprog/golang_test_defer_excchain.py", line 45, in <module>
          E               +    main()
          E               +  File "Z:\home\kirr\src\tools\go\pygo-win\1.wenv\lib\site-packages/decorator.py", line 232, in fun
          E               +    return caller(func, *(extras + args), **kw)
          E               +  File "PYGOLANG/golang/__init__.py", line 105, in _
          E               +    with __goframe__:
          E               +  File "PYGOLANG/golang/__init__.py", line 182, in __exit__
          E               +    with __goframe__:
          E               +  File "PYGOLANG/golang/__init__.py", line 182, in __exit__
          E               +    with __goframe__:
          E               +  File "PYGOLANG/golang/__init__.py", line 183, in __exit__
          E               +    d()
          E               +  File "PYGOLANG/golang/testprog/golang_test_defer_excchain.py", line 35, in d3
          E               +    raise RuntimeError("d3: bbb")
          E               +RuntimeError: d3: bbb
      17c1d2fa
    • Kirill Smelkov's avatar
      golang: tests: Normalize paths to use / delimiter in doctests's got · 06935819
      Kirill Smelkov authored
      Else on Windows e.g. test_defer_excchain_traceback fails as
      
          E           Failed: not equal:
          E           Differences (unified diff with -expected +actual):
          E               @@ -1,8 +1,8 @@
          E                Traceback (most recent call last):
          E               -  File "PYGOLANG/golang/golang_test.py", line ..., in test_defer_excchain_traceback
          E               +  File "PYGOLANG\golang\golang_test.py", line 1524, in test_defer_excchain_traceback
          E                    alpha()
          E               -  File "PYGOLANG/golang/golang_test.py", line ..., in alpha
          E               +  File "PYGOLANG\golang\golang_test.py", line 1521, in alpha
          E                    beta()
          E               -  File "PYGOLANG/golang/golang_test.py", line ..., in beta
          E               +  File "PYGOLANG\golang\golang_test.py", line 1520, in beta
          E                    raise RuntimeError("gamma")
          E                RuntimeError: gamma
      06935819
    • Kirill Smelkov's avatar
      golang: Prepare path for libgolang.dll before importing _golang · a5ce8175
      Kirill Smelkov authored
      Else it fails to import on Windows:
      
          collecting ... 05c8:err:module:import_dll Library libgolang.dll (which is needed by L"Z:\\home\\kirr\\src\\tools\\go\\pygo-win\\pygolang\\golang\\_golang.cp310-win_amd64.pyd") not found
          collected 0 items / 1 error
      
          =========================================================== ERRORS ===========================================================
          ___________________________________________ ERROR collecting golang/golang_test.py ___________________________________
          ImportError while importing test module 'Z:\home\kirr\src\tools\go\pygo-win\pygolang\golang\golang_test.py'.
          Hint: make sure your test modules/packages have valid Python names.
          Traceback:
          C:\Program Files\Python310\lib\importlib\__init__.py:126: in import_module
              return _bootstrap._gcd_import(name[level:], package, level)
          golang\__init__.py:45: in <module>
              from golang._golang import _pysys_exc_clear as _sys_exc_clear
          E   ImportError: DLL load failed while importing _golang: Модуль не найден.
      
      We need to increase required setuptools_dso version because dylink_prepare_dso
      and generation of *_dsoinfo.py modules was done after setuptools_dso 2.
      a5ce8175
    • Kirill Smelkov's avatar
      .gitignore += *.lib *.exp · 0b97e0a8
      Kirill Smelkov authored
      On Windows this files are generated when linking alongside *.dll files
      if there are exported symbols.
      
      See also https://github.com/mdavidsaver/setuptools_dso/pull/25.
      0b97e0a8
    • Kirill Smelkov's avatar
      setup: We need to link libpyxruntime DSO to py runtime · fbed01b0
      Kirill Smelkov authored
      Libpyxruntime by definition contains python-specific code and we already
      compile it with include path having python includes in it. However on
      windows pyconfig.h contains
      
          #pragma comment(lib,"python3.lib")
      
      which instructs the linker to automatically link to that library. And
      without proper library path the link fails:
      
          Z:\home\kirr\src\tools\go\pygo-win\BuildTools\vc\tools\msvc\14.35.32215\bin\Hostx64\x64\link.exe /nologo /INCREMENTAL:NO /LTCG /DLL /MANIFEST:EMBED,ID=2 /MANIFESTUAC:NO /LIBPATH:build\lib.win-amd64-cpython-31
          0\golang\runtime /LIBPATH:z:\home\kirr\src\tools\go\pygo-win\BuildTools\vc\tools\msvc\14.35.32215\lib\x64 /LIBPATH:z:\home\kirr\src\tools\go\pygo-win\BuildTools\kits\10\lib\10.0.22000.0\ucrt\x64 /LIBPATH:z:\h
          ome\kirr\src\tools\go\pygo-win\BuildTools\kits\10\lib\10.0.22000.0\um\x64 libgolang.lib build\temp.win-amd64-cpython-310\Release\golang/runtime/libpyxruntime.obj /OUT:build\lib.win-amd64-cpython-310\golang\ru
          ntime\libpyxruntime.dll /IMPLIB:build\lib.win-amd64-cpython-310\golang\runtime\libpyxruntime.lib
          LINK : fatal error LNK1104: cannot open file 'python310.lib'
      
      -> Fix it by providing proper library path for python.dll .
      
      We need to do it ourselves only for libpyxruntime dso because for py
      extensions this is automatically done by distutils out of the box.
      fbed01b0
    • Kirill Smelkov's avatar
      libgolang/gevent: Adjust to support Windows · 437bbd56
      Kirill Smelkov authored
      On Windows rthere is no fcntl
      
          golang/runtime\_runtime_gevent.cpp(4811): error C3861: 'S_ISBLK': identifier not found
          golang/runtime\_runtime_gevent.cpp(4823): error C2039: 'Fcntl': is not a member of 'golang::internal::syscall'
          .\golang/runtime/internal/syscall.h(36): note: see declaration of 'golang::internal::syscall'
          golang/runtime\_runtime_gevent.cpp(4823): error C2065: 'F_GETFL': undeclared identifier
          golang/runtime\_runtime_gevent.cpp(4823): error C3861: 'Fcntl': identifier not found
          golang/runtime\_runtime_gevent.cpp(4870): error C2065: 'O_ACCMODE': undeclared identifier
          golang/runtime\_runtime_gevent.cpp(4889): error C2039: 'Fcntl': is not a member of 'golang::internal::syscall'
          .\golang/runtime/internal/syscall.h(36): note: see declaration of 'golang::internal::syscall'
          golang/runtime\_runtime_gevent.cpp(4889): error C2065: 'F_SETFL': undeclared identifier
          golang/runtime\_runtime_gevent.cpp(4889): error C2065: 'O_NONBLOCK': undeclared identifier
          golang/runtime\_runtime_gevent.cpp(4889): error C3861: 'Fcntl': identifier not found
      
      and even if there would be gevent does not provide cooperative version
      of FileObject for non-POSIX platforms.
      
      -> Always use FileObjectThread on windows even for pipes.
      437bbd56
    • Kirill Smelkov's avatar
      os/signal: Use windows-specific code to turn wakeup pipe into nonblocking mode · 45473979
      Kirill Smelkov authored
      There is no fcntl on windows. Named pipes can be set into nonblocking
      mode via SetNamedPipeHandleState(PIPE_NOWAIT).
      45473979
    • Kirill Smelkov's avatar
      os/signal: Internally emulate sigaction via signal · acc6c3f1
      Kirill Smelkov authored
      On MSVC there is no sigaction and we have to use signal. Fortunately
      our sigaction usage in os/signal can be practically emulated because we
      do not use all features of sigaction and because on MSVC there is
      SIG_GET signal extension to query current signal handler without
      resetting it.
      
      Because the emulation is limited we keep it in os/signal.cpp instead of
      adjusting syscall::Sigaction .
      acc6c3f1
    • Kirill Smelkov's avatar
      os/signal: Factor call to sys::Sigaction into sys_sigaction internal helper · b15fa818
      Kirill Smelkov authored
      On MSVC we will need to use signal(2), because there is no sigaction,
      and sigaction will be partly emulated through that. Move signal setting
      code into common place as a preparatory step.
      b15fa818
    • Kirill Smelkov's avatar
      internal/syscall: Initial adjust to support MSVC · d3bf3b7d
      Kirill Smelkov authored
      - there is no strerror_r, but strerror_s instead
      - fcntl is not supported
      - we need to explicitly tell open to open files in binary mode
      - pipes are created via _pipe and explicitly in binary mode
      - there is no sigaction.
      d3bf3b7d
    • Kirill Smelkov's avatar
      internal/syscall: Adjust Pipe to take flags · 63b5c1d9
      Kirill Smelkov authored
      This way e.g. O_CLOEXEC can be passed in at pipe creation time removing
      potential race in between pipe+fcntl vs exec in the middle. It will also
      help in windows porting in follow-up patches becuase there is no fcntl
      on Windows, but pipe with O_CLOEXEC semantic can be created directly
      with flags=_O_NOINHERIT.
      63b5c1d9
    • Kirill Smelkov's avatar
      internal/atomic: Adjust to support MSVC · 534033a5
      Kirill Smelkov authored
      There is no fork on windows and that we do not need to install atfork
      handler at all.
      
          golang/runtime/internal/atomic.cpp(23): fatal error C1083: Cannot open include file: 'pthread.h': No such file or directory
      534033a5
    • Kirill Smelkov's avatar
      fmt: Adjust to support MSVC · 5098decb
      Kirill Smelkov authored
      - there is no __attribute__ on that compiler
      - sadly va_start is rejected to work on reference:
      
          z:\home\kirr\src\tools\go\pygo-win\BuildTools\vc\tools\msvc\14.35.32215\include\vadefs.h(194): error C2338: static_assert failed: 'va_start argument must not have reference type and must not be parenthesized'
          golang/fmt.cpp(53): note: see reference to class template instantiation '__vcrt_assert_va_start_is_not_reference<const golang::string &>' being compiled
      
        -> change format from string& to be string in sprintf.
      
        Probably it should be ok in practice from performance point of view because
        string contains only pointer to data, not the data itself.
      5098decb
    • Kirill Smelkov's avatar
      os: Adjust to support MSVC · 22a597a0
      Kirill Smelkov authored
      - There is no S_IRUSR & friends  -> use _S_IREAD & co.
      - Tthere is no sys_siglist       -> kind-of define it ourselves for all documented signals.
      22a597a0
    • Kirill Smelkov's avatar
      libgolang: Use custom list_entry on MSVC · 715fa60b
      Kirill Smelkov authored
      list_entry, as provided by linux/list.h, uses statement expressions(*) which
      are not supported by MSVC:
      
          #define list_entry(ptr, type, member) ({              \
                  const typeof( ((type *)0)->member ) *__mptr = (ptr);   \
                  (type *)( (char *)__mptr - offsetof(type,member) );})
      
          golang/runtime/libgolang.cpp(439): error C2059: syntax error: '{'
          golang/runtime/libgolang.cpp(439): error C2143: syntax error: missing ';' before '{'
          golang/runtime/libgolang.cpp(439): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
          golang/runtime/libgolang.cpp(439): error C2440: 'initializing': cannot convert from 'list_head' to 'int'
          golang/runtime/libgolang.cpp(439): note: No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called
          golang/runtime/libgolang.cpp(439): error C2143: syntax error: missing ';' before '*'
          golang/runtime/libgolang.cpp(439): error C2065: '__mptr': undeclared identifier
          golang/runtime/libgolang.cpp(439): error C2059: syntax error: ')'
      
      -> work it around by defining list_entry with C++ lambda.
      
      (*) https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html
      715fa60b
    • Kirill Smelkov's avatar
      libgolang: random_shuffle -> shuffle · 1845b93d
      Kirill Smelkov authored
      There is no std::random_shuffle on `MSVC /std:c++20` because it was removed in C++17:
      
          golang/runtime/libgolang.cpp(946): error C2039: 'random_shuffle': is not a member of 'std'
          z:\home\kirr\src\tools\go\pygo-win\BuildTools\vc\tools\msvc\14.35.32215\include\random(34): note: see declaration of 'std'
          golang/runtime/libgolang.cpp(946): error C3861: 'random_shuffle': identifier not found
      
          https://en.cppreference.com/w/cpp/algorithm/random_shuffle
      1845b93d
    • Kirill Smelkov's avatar
      libgolang: Provide custom bzero, mode_t and unistd.h on MSVC · 35ed2492
      Kirill Smelkov authored
      We need unistd.h because e.g. `cimport posix.stat` forces inclusion of unistd.h
      even if we use part of posix.stat that is available everywhere.
      
      We use bzero in libgolang.cpp - provide it in similar way via compat
      strings.h because on windows there is only string.h (no "s" in the end).
      
      We also use mode_t in several places - provide it via typedef in
      libgolang.h directly, because fcntl.h is present on MSVC.
      35ed2492
    • Kirill Smelkov's avatar
      pyx.build: Adjust compile flags if we are on Windows/MSVC · 5f107215
      Kirill Smelkov authored
      MSVC does not accept -std=c++11 but instead accepts /std:c++11. We cannot
      use that however because with /std:c++11 compilation fails with
      
          .\golang/libgolang.h(280): error C7555: use of designated initializers requires at least '/std:c++20'
          .\golang/libgolang.h(294): error C7555: use of designated initializers requires at least '/std:c++20'
          .\golang/libgolang.h(308): error C7555: use of designated initializers requires at least '/std:c++20'
      
      for
      
          276 // _selsend creates `_chansend(ch, ptx)` case for _chanselect.
          277 static inline
          278 _selcase _selsend(_chan *ch, const void *ptx) {
          279     _selcase _ = {
          280         .ch     = ch,			<-- NOTE
          281         .op     = _CHANSEND,
          282         .flags  = (enum _selflags)0,
          283         .user   = 0xff,
          284     };
      
      and similar places.
      
      -> Use /std:c++20 instead as MSVC advices  (WOW designated initializers are C99
      and it took 21 years for C++ to catch up).
      
      We also need to adjust exception handling mode into "fully conformant" instead
      of "assume extern C cannot throw" setuptools default so that `panic` and other
      extern C libgolang functions generate exceptions that could be caught
      instead of crashing programs.
      
      For C vs C++ flags we also need to adjust our build_ext, because the way
      setuptools/distutils organize compilation for MSVC is different from
      UNIX compilers.
      5f107215
    • Kirill Smelkov's avatar
      setup: Reuse golang.pyx.build to build DSOs · b5bd136c
      Kirill Smelkov authored
      We already reuse golang.pyx.build in setup.py to build Extensions, but
      DSOs were built via setuptools_dso directly so far. To support Windows
      we will soon need to adjust compilation flags for both Extensions and
      DSOs. It makes sense to first concentrate build recipes in one place
      before doing that.
      
      -> Move/factor DSOs build flags into golang.pyx.build and reuse that
      from setup.
      b5bd136c
    • Kirill Smelkov's avatar
      *: Fix dll export annotation everywhere · 0ffef2d8
      Kirill Smelkov authored
      We already try to annotate functions exported from DSOs as such.
      However so far we were testing only on Linux and macOS where
      -fvisibility=hidden is not the default, and thus linker forgives us
      annotation mistakes. But on Windows the default is to have hidden
      visibility out of the box and so the linker becomes strict about this.
      
      -> Fix all issues caught there.
      
      For example here is how it breaks if ~_interface() is not annotated properly:
      
          building 'golang.runtime.libpyxruntime' DSO as build\lib.win-amd64-cpython-310\golang\runtime\libpyxruntime.dll
          ...
          Z:\home\kirr\src\tools\go\pygo-win\BuildTools\vc\tools\msvc\14.35.32215\bin\Hostx64\x64\link.exe /nologo /INCREMENTAL:NO /LTCG /DLL /MANIFEST:EMBED,ID=2 /MANIFESTUAC:NO "/LIBPATH:C:\Program Files\Python310\li
          bs" /LIBPATH:build\lib.win-amd64-cpython-310\golang\runtime /LIBPATH:z:\home\kirr\src\tools\go\pygo-win\BuildTools\vc\tools\msvc\14.35.32215\lib\x64 /LIBPATH:z:\home\kirr\src\tools\go\pygo-win\BuildTools\kits
          \10\lib\10.0.22000.0\ucrt\x64 /LIBPATH:z:\home\kirr\src\tools\go\pygo-win\BuildTools\kits\10\lib\10.0.22000.0\um\x64 libgolang.lib build\temp.win-amd64-cpython-310\Release\golang/runtime/libpyxruntime.obj /OU
          T:build\lib.win-amd64-cpython-310\golang\runtime\libpyxruntime.dll /IMPLIB:build\lib.win-amd64-cpython-310\golang\runtime\libpyxruntime.lib
             Creating library build\lib.win-amd64-cpython-310\golang\runtime\libpyxruntime.lib and object build\lib.win-amd64-cpython-310\golang\runtime\libpyxruntime.exp
      
          libpyxruntime.obj : error LNK2001: unresolved external symbol "protected: __cdecl golang::_interface::~_interface(void)" (??1_interface@golang@@IEAA@XZ)
          build\lib.win-amd64-cpython-310\golang\runtime\libpyxruntime.dll : fatal error LNK1120: 1 unresolved externals
          error: command 'Z:\\home\\kirr\\src\\tools\\go\\pygo-win\\BuildTools\\vc\\tools\\msvc\\14.35.32215\\bin\\Hostx64\\x64\\link.exe' failed with exit code 1120
      0ffef2d8
  2. 25 Apr, 2023 1 commit
    • Kirill Smelkov's avatar
      check-manifest · 3a83e8f6
      Kirill Smelkov authored
          (z-dev) kirr@deca:~/src/tools/go/pygolang$ check-manifest
          lists of files in version control and sdist do not match!
          missing from VCS:
            golang/pyx/runtime.cpp
            golang/runtime/libgolang_dsoinfo.py
            golang/runtime/libpyxruntime_dsoinfo.py
      
      - golang/pyx/runtime.cpp is generated from golang/pyx/runtime.pyx
      - *_dsoinfo.py files are generated by setuptools_dso during the build
      3a83e8f6
  3. 16 Apr, 2023 6 commits
    • Kirill Smelkov's avatar
      tox += CPython 3.10, 3.11 · 7fb630c1
      Kirill Smelkov authored
      Tests now pass with those versions.
      Remove py38-dbg from test matrix ad this version is now a bit outdated
      and having just py38 without dbg there seems enough.
      7fb630c1
    • Kirill Smelkov's avatar
      tox: Fix list of py in "debug => use -s" to match main list of py interpreters · 462d6beb
      Kirill Smelkov authored
      I forgot to add py38 and py39 here while adding them in 792cbd6c (tox:
      -py36,py37d  +py38d, py38) and 32167853 (tox += CPython3.9). The former
      commit also removed py37d from test matrix.
      462d6beb
    • Kirill Smelkov's avatar
      golang: tests: Fix traceback tests for Python ≥ 3.10 · 53cd02b3
      Kirill Smelkov authored
      Python changed traceback output a bit:
      
      - added '^^^^^^^' and '~~^~~'
      - changed lineno of frame corresponding to __exit__ to be at line of `with ...`
      
      -> Adjust to that by introducing a bit more generalized conditionals in
         assertDoc.
      
      Here is, for example, how test_defer_excchain_traceback was failing on py3.11:
      
      E           Failed: not equal:
      E           Differences (unified diff with -expected +actual):
      E               @@ -1,6 +1,7 @@
      E                Traceback (most recent call last):
      E               -  File "PYGOLANG/golang/__init__.py", line ..., in _
      E               +  File "PYGOLANG/golang/__init__.py", line 103, in _
      E                    return f(*argv, **kw)
      E               -  File "PYGOLANG/golang/golang_test.py", line ..., in caller
      E               +           ^^^^^^^^^^^^^^
      E               +  File "PYGOLANG/golang/golang_test.py", line 1550, in caller
      E                    raise RuntimeError("ccc")
      E                RuntimeError: ccc
      E               @@ -9,7 +10,7 @@
      E                <BLANKLINE>
      E                Traceback (most recent call last):
      E               -  File "PYGOLANG/golang/__init__.py", line ..., in __exit__
      E               +  File "PYGOLANG/golang/__init__.py", line 180, in __exit__
      E                    d()
      E               -  File "PYGOLANG/golang/golang_test.py", line ..., in q2
      E               +  File "PYGOLANG/golang/golang_test.py", line 1548, in q2
      E                    raise RuntimeError("bbb")
      E                RuntimeError: bbb
      E               @@ -18,14 +19,16 @@
      E                <BLANKLINE>
      E                Traceback (most recent call last):
      E               -  File "PYGOLANG/golang/golang_test.py", line ..., in test_defer_excchain_traceback
      E               +  File "PYGOLANG/golang/golang_test.py", line 1553, in test_defer_excchain_traceback
      E                    caller()
      E               -  ...
      E               -  File "PYGOLANG/golang/__init__.py", line ..., in _
      E               -    return f(*argv, **kw)
      E               -  File "PYGOLANG/golang/__init__.py", line ..., in __exit__
      E               +  File "/home/kirr/src/tools/go/py3.venv/lib/python3.11/site-packages/decorator.py", line 232, in fun
      E               +    return caller(func, *(extras + args), **kw)
      E               +           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      E               +  File "PYGOLANG/golang/__init__.py", line 102, in _
      E               +    with __goframe__:
      E               +  File "PYGOLANG/golang/__init__.py", line 179, in __exit__
      E               +    with __goframe__:
      E               +  File "PYGOLANG/golang/__init__.py", line 180, in __exit__
      E                    d()
      E               -  File "PYGOLANG/golang/__init__.py", line ..., in __exit__
      E               -    d()
      E               -  File "PYGOLANG/golang/golang_test.py", line ..., in q1
      E               +  File "PYGOLANG/golang/golang_test.py", line 1545, in q1
      E                    raise RuntimeError("aaa")
      E                RuntimeError: aaa
      53cd02b3
    • Kirill Smelkov's avatar
      golang: tests: Fix for IPython ≥ 8 · dfe75e9a
      Kirill Smelkov authored
      IPython8 changed format of output tracebacks (see
      https://github.com/ipython/ipython/commit/02660f35 and further). Adding
      test support for later versions would add maintenance cost on pygolang
      side, but testing this is actually not needed, since we activate
      IPython-related patch only on py2 and for py2 the latest ipython version
      is ipython5.
      
      -> So simply skip this test if we see we have IPython ≥ 8.
         Skip it only on py3 just in case.
      
      For the reference here is how diff in between running
      golang_test_defer_excchain.py on IPython7 and IPython8 looks:
      
          diff --git a/golang/testprog/7 b/golang/testprog/8
          index 5c31ed2..8fea57b 100644
          --- a/golang/testprog/7
          +++ b/golang/testprog/8
          @@ -1,101 +1,91 @@
          -[22;0t]0;IPython: golang/testprog---------------------------------------------------------------------------
          +---------------------------------------------------------------------------
           RuntimeError                              Traceback (most recent call last)
          -~/src/tools/go/pygolang-master/golang/__init__.py in _(f, *argv, **kw)
          -    102         with __goframe__:
          ---> 103             return f(*argv, **kw)
          -    104
          +File ~/src/tools/go/pygolang-master/golang/__init__.py:103, in _func.<locals>._(f, *argv, **kw)
          +    102 with __goframe__:
          +--> 103     return f(*argv, **kw)
      
          -~/src/tools/go/pygolang-master/golang/testprog/golang_test_defer_excchain.py in main()
          -     41     defer(d1)
          ----> 42     raise RuntimeError("err")
          -     43
          +File ~/src/tools/go/pygolang-master/golang/testprog/golang_test_defer_excchain.py:42, in main()
          +     41 defer(d1)
          +---> 42 raise RuntimeError("err")
      
           RuntimeError: err
      
           During handling of the above exception, another exception occurred:
      
           RuntimeError                              Traceback (most recent call last)
          -~/src/tools/go/pygolang-master/golang/__init__.py in __exit__(__goframe__, exc_type, exc_val, exc_tb)
          -    179             with __goframe__:
          ---> 180                 d()
          -    181
          +File ~/src/tools/go/pygolang-master/golang/__init__.py:180, in _GoFrame.__exit__(__goframe__, exc_type, exc_val, exc_tb)
          +    179     with __goframe__:
          +--> 180         d()
          +    182 return __goframe__.recovered
      
          -~/src/tools/go/pygolang-master/golang/testprog/golang_test_defer_excchain.py in d1()
          +File ~/src/tools/go/pygolang-master/golang/testprog/golang_test_defer_excchain.py:31, in d1()
                30 def d1():
           ---> 31     raise RuntimeError("d1: aaa")
          -     32 def d2():
      
           RuntimeError: d1: aaa
      
           During handling of the above exception, another exception occurred:
      
           ZeroDivisionError                         Traceback (most recent call last)
          -~/src/tools/go/pygolang-master/golang/__init__.py in __exit__(__goframe__, exc_type, exc_val, exc_tb)
          -    179             with __goframe__:
          ---> 180                 d()
          -    181
          +File ~/src/tools/go/pygolang-master/golang/__init__.py:180, in _GoFrame.__exit__(__goframe__, exc_type, exc_val, exc_tb)
          +    179     with __goframe__:
          +--> 180         d()
          +    182 return __goframe__.recovered
      
          -~/src/tools/go/pygolang-master/golang/testprog/golang_test_defer_excchain.py in d2()
          +File ~/src/tools/go/pygolang-master/golang/testprog/golang_test_defer_excchain.py:33, in d2()
                32 def d2():
           ---> 33     1/0
          -     34 def d3():
      
           ZeroDivisionError: division by zero
      
           During handling of the above exception, another exception occurred:
      
           RuntimeError                              Traceback (most recent call last)
          -/usr/lib/python3.11/runpy.py in run_module(mod_name, init_globals, run_name, alter_sys)
          +File <frozen runpy>:226, in run_module(mod_name, init_globals, run_name, alter_sys)
      
          -/usr/lib/python3.11/runpy.py in _run_module_code(code, init_globals, mod_name, mod_spec, pkg_name, script_name)
          +File <frozen runpy>:98, in _run_module_code(code, init_globals, mod_name, mod_spec, pkg_name, script_name)
      
          -/usr/lib/python3.11/runpy.py in _run_code(code, run_globals, init_globals, mod_name, mod_spec, pkg_name, script_name)
          +File <frozen runpy>:88, in _run_code(code, run_globals, init_globals, mod_name, mod_spec, pkg_name, script_name)
      
          -~/src/tools/go/pygolang-master/golang/testprog/golang_test_defer_excchain.py in <module>
          -     43
          +File ~/src/tools/go/pygolang-master/golang/testprog/golang_test_defer_excchain.py:45
          +     42     raise RuntimeError("err")
                44 if __name__ == "__main__":
           ---> 45     main()
      
          -~/src/tools/go/py3.venv/lib/python3.11/site-packages/decorator.py in fun(*args, **kw)
          -    230             if not kwsyntax:
          -    231                 args, kw = fix(args, kw, sig)
          ---> 232             return caller(func, *(extras + args), **kw)
          -    233     fun.__name__ = func.__name__
          -    234     fun.__doc__ = func.__doc__
          +File ~/src/tools/go/py3.venv/lib/python3.11/site-packages/decorator.py:232, in decorate.<locals>.fun(*args, **kw)
          +    230 if not kwsyntax:
          +    231     args, kw = fix(args, kw, sig)
          +--> 232 return caller(func, *(extras + args), **kw)
      
          -~/src/tools/go/pygolang-master/golang/__init__.py in _(f, *argv, **kw)
          -    100         # run f under separate frame, where defer will register calls.
          -    101         __goframe__ = _GoFrame()
          ---> 102         with __goframe__:
          -    103             return f(*argv, **kw)
          -    104
          +File ~/src/tools/go/pygolang-master/golang/__init__.py:102, in _func.<locals>._(f, *argv, **kw)
          +     99 def _(f, *argv, **kw):
          +    100     # run f under separate frame, where defer will register calls.
          +    101     __goframe__ = _GoFrame()
          +--> 102     with __goframe__:
          +    103         return f(*argv, **kw)
      
          -~/src/tools/go/pygolang-master/golang/__init__.py in __exit__(__goframe__, exc_type, exc_val, exc_tb)
          -    177
          -    178             # even if d panics - we have to call other defers
          ---> 179             with __goframe__:
          -    180                 d()
          -    181
          +File ~/src/tools/go/pygolang-master/golang/__init__.py:179, in _GoFrame.__exit__(__goframe__, exc_type, exc_val, exc_tb)
          +    176     d = __goframe__.deferv.pop()
          +    178     # even if d panics - we have to call other defers
          +--> 179     with __goframe__:
          +    180         d()
          +    182 return __goframe__.recovered
      
          -~/src/tools/go/pygolang-master/golang/__init__.py in __exit__(__goframe__, exc_type, exc_val, exc_tb)
          -    177
          -    178             # even if d panics - we have to call other defers
          ---> 179             with __goframe__:
          -    180                 d()
          -    181
          +File ~/src/tools/go/pygolang-master/golang/__init__.py:179, in _GoFrame.__exit__(__goframe__, exc_type, exc_val, exc_tb)
          +    176     d = __goframe__.deferv.pop()
          +    178     # even if d panics - we have to call other defers
          +--> 179     with __goframe__:
          +    180         d()
          +    182 return __goframe__.recovered
      
          -~/src/tools/go/pygolang-master/golang/__init__.py in __exit__(__goframe__, exc_type, exc_val, exc_tb)
          -    178             # even if d panics - we have to call other defers
          -    179             with __goframe__:
          ---> 180                 d()
          -    181
          -    182         return __goframe__.recovered
          +File ~/src/tools/go/pygolang-master/golang/__init__.py:180, in _GoFrame.__exit__(__goframe__, exc_type, exc_val, exc_tb)
          +    178     # even if d panics - we have to call other defers
          +    179     with __goframe__:
          +--> 180         d()
          +    182 return __goframe__.recovered
      
          -~/src/tools/go/pygolang-master/golang/testprog/golang_test_defer_excchain.py in d3()
          -     33     1/0
          +File ~/src/tools/go/pygolang-master/golang/testprog/golang_test_defer_excchain.py:35, in d3()
                34 def d3():
           ---> 35     raise RuntimeError("d3: bbb")
          -     36
          -     37 @func
      
           RuntimeError: d3: bbb
      dfe75e9a
    • Kirill Smelkov's avatar
      golang: tests: Fix fmtargspec on py3.11 · c1e41ac8
      Kirill Smelkov authored
      Starting from python3.11 inspect.formatargspec was removed:
      
          f = <function test_func.<locals>.zzz at 0x7fb6d265fec0>
      
              def fmtargspec(f): # -> str
                  with warnings.catch_warnings():
                      warnings.simplefilter('ignore', DeprecationWarning)
          >           return inspect.formatargspec(*inspect.getargspec(f))
          E           AttributeError: module 'inspect' has no attribute 'formatargspec'
      
          golang/golang_test.py:1823: AttributeError
      
      We were already handling formatargspec deprecation in 45f4df9e (golang:
      tests: Silence inspect deprecation warning), but now is the time to
      actually replace its usage.
      
      -> Fix it by using `str(inspect.signature(f))` instead of
         `inspect.formatargspec(*inspect.getargspec(f))`.
      c1e41ac8
    • Kirill Smelkov's avatar
      pyx.build: Fix tests with recent setuptools · 304464e0
      Kirill Smelkov authored
      With setuptools 65 running test_pyx_build_cmdclass is failing because besides
      cmdclass_custom.py it sees nearby golang_pyx_user/ and golang_dso_user/ with
      top-project setups and rejects it:
      
          ---- 8< ----
          golang/pyx/build_test.py::test_pyx_build_cmdclass error: Multiple top-level packages discovered in a flat-layout: ['golang_pyx_user', 'golang_dso_user'].
      
          To avoid accidental inclusion of unwanted files or directories,
          setuptools will not proceed with this build.
      
          If you are trying to create a single distribution with multiple packages
          on purpose, you should not rely on automatic discovery.
          Instead, consider the following options:
      
          1. set up custom discovery (`find` directive with `include` or `exclude`)
          2. use a `src-layout`
          3. explicitly set `py_modules` or `packages` with a list of names
      
          To find more information, look for "package discovery" on setuptools docs.
          FAILED
      
          ================================ FAILURES =================================
          _________________________ test_pyx_build_cmdclass _________________________
      
              def test_pyx_build_cmdclass():
          >       _ = pyout(["cmdclass_custom.py", "build_ext"], cwd=testprog)
      
          golang/pyx/build_test.py:60:
          _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
          golang/golang_test.py:1742: in pyout
              return pyrun(argv, stdin=stdin, stdout=stdout, stderr=stderr, **kw)
          _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
      
          argv = ['cmdclass_custom.py', 'build_ext'], stdin = None, stdout = b'', stderr = None
          kw = {'cwd': '/home/kirr/src/tools/go/pygolang-master/golang/pyx/testprog'}, retcode = 1
      
              def pyrun(argv, stdin=None, stdout=None, stderr=None, **kw):
                  retcode, stdout, stderr = _pyrun(argv, stdin=stdin, stdout=stdout, stderr=stderr, **kw)
                  if retcode:
          >           raise RuntimeError(' '.join(argv) + '\n' + (stderr and str(stderr) or '(failed)'))
          E           RuntimeError: cmdclass_custom.py build_ext
          E           (failed)
      
          golang/golang_test.py:1736: RuntimeError
          ---- 8< ----
      
      -> Work it around by defining py_modules explicitly as suggested in
      https://stackoverflow.com/a/72547402/9456786.
      304464e0
  4. 23 Jan, 2023 1 commit
    • Kirill Smelkov's avatar
      *: Replace usage of &vector[0] with vector.data() · 39dde7eb
      Kirill Smelkov authored
      We use &vector[0] in several places to get the pointer to vector data,
      but std::vector[i] states invariant that i must be < vector.size(). If
      the vector is not empty - then &vector[0] works ok. However if the
      vector is empty - then the invariant is broken.
      
      Normally it should not be a problem, since with empty vector we usually
      use (&vector[0], vector.size()) pair, and for empty vector its size is
      zero. In other words even if &vector[0] returns some not good pointer
      with zero size that data should never be accessed. But a build of
      libstdc++ could have asserts turned on and verify that i is actually <
      size. For example with default install on Fedora the following program
      with plain select()
      
          from golang import select
          select()
      
      crashes with assert triggered on the breakage of that invariant
      
          [Thread debugging using libthread_db enabled]
          Using host libthread_db library "/lib64/libthread_db.so.1".
          /usr/include/c++/10/bits/stl_vector.h:1042: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) [with _Tp = golang::_selcase; _Alloc = std::allocator<golang::_selcase>; std::vector<_Tp, _Alloc>::reference = golang::_selcase&; std::vector<_Tp, _Alloc>::size_type = long unsigned int]: Assertion '__builtin_expect(__n < this->size(), true)' failed.
      
          Program received signal SIGABRT, Aborted.
          0x00007ffff7e22a25 in raise () from /lib64/libc.so.6
          (gdb) bt
          #0  0x00007ffff7e22a25 in raise () from /lib64/libc.so.6
          #1  0x00007ffff7e0b895 in abort () from /lib64/libc.so.6
          #2  0x00007fffea638d6d in std::__replacement_assert (__condition=0x7fffea63ea88 "__builtin_expect(__n < this->size(), true)",
              __function=0x7fffea63eab8 "std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) [with _Tp = golang::_selcase; _Alloc = std::allocator<golang::_selcase>; std::vector<_Tp, "..., __line=1042, __file=0x7fffea63ebe8 "/usr/include/c++/10/bits/stl_vector.h")
              at /usr/include/c++/10/x86_64-redhat-linux/bits/c++config.h:2552
          #3  std::vector<golang::_selcase, std::allocator<golang::_selcase> >::operator[] (this=<synthetic pointer>, __n=0)
              at /usr/include/c++/10/bits/stl_vector.h:1042
          #4  std::vector<golang::_selcase, std::allocator<golang::_selcase> >::operator[] (__n=0, this=<synthetic pointer>)
              at /usr/include/c++/10/bits/stl_vector.h:1040
          #5  __pyx_pf_6golang_7_golang_6pyselect (__pyx_self=<optimized out>, __pyx_v_pycasev=<optimized out>) at golang/_golang.cpp:7930
          #6  __pyx_pw_6golang_7_golang_7pyselect (__pyx_self=<optimized out>, __pyx_args=<optimized out>, __pyx_kwds=<optimized out>) at golang/_golang.cpp:7284
          #7  0x00007ffff7bceeab in cfunction_call_varargs (func=<built-in function pyselect>, args=(), kwargs=0x0)
              at /usr/src/debug/python3-3.8.10-1.fc32.x86_64/Objects/call.c:743
          ...
      
      -> Fix it all via replacing &vector[0] with vector.data() everywhere.
      
      No need to add new test since select() is used by test_blockforever()
      and running that test on Fedora was crashing as well.
      
      /reviewed-by @jerome
      /reviewed-at nexedi/pygolang!22
      39dde7eb
  5. 05 Oct, 2022 2 commits
    • Kirill Smelkov's avatar
      py.bench: Automatically discover benchmarks in test files · ffb40903
      Kirill Smelkov authored
      Since the beginning (9bf03d9c "py.bench: New command to benchmark python
      code similarly to `go test -bench`") py.bench was automatically
      discovering benchmarks in bench_*.py files only. This was inherited from
      wendelin.core which keeps its benchmarks in those files.
      
      However in pygolang, following Go convention(*), we already have several
      benchmarks that reside together with tests in same *_test.py files. And
      currently just running py.bench does not discover them.
      
      -> Let's fix this and teach py.bench to automatically discover
      benchmarks in the test files by default as well.
      
      Pytest's default is to look for tests in test_*.py and *_test.py (+).
      Add those patterns and also keep bench_*.py for backward compatibility.
      
      Before this patch running py.bench inside pygolang repository does not
      run any benchmark at all. After the patch py.bench runs all the
      benchmarks by default:
      
          (z-dev) kirr@deca:~/src/tools/go/pygolang$ py.bench
          ========================= test session starts ==========================
          platform linux2 -- Python 2.7.18, pytest-4.6.11, py-1.10.0, pluggy-0.13.1
          rootdir: /home/kirr/src/tools/go/pygolang
          plugins: timeout-1.4.2, profiling-1.7.0, mock-2.0.0
          collected 18 items
      
          pymod: golang/golang_str_test.py
          Benchmarkstddecode              2000000 0.756 µs/op
          Benchmarkudecode                20000   74.359 µs/op
          Benchmarkstdencode              3000000 0.327 µs/op
          Benchmarkbencode                40000   32.613 µs/op
      
          pymod: golang/golang_test.py
          Benchmarkpyx_select_nogil       500000  2.051 µs/op
          Benchmarkpyx_go_nogil           90000   12.177 µs/op
          Benchmarkpyx_chan_nogil         600000  1.826 µs/op
          Benchmarkgo                     80000   13.267 µs/op
          Benchmarkchan                   500000  2.076 µs/op
          Benchmarkselect                 300000  3.835 µs/op
          Benchmarkdef                    30000000        0.035 µs/op
          Benchmarkfunc_def               40000   29.387 µs/op
          Benchmarkcall                   30000000        0.043 µs/op
          Benchmarkfunc_call              2000000 0.819 µs/op
          Benchmarktry_finally            20000000        0.096 µs/op
          Benchmarkdefer                  600000  1.755 µs/op
      
          pymod: golang/sync_test.py
          Benchmarkworkgroup_empty        40000   25.807 µs/op
          Benchmarkworkgroup_raise        40000   31.637 µs/op                     [100%]
      
          =========================== warnings summary ===========================
      
      (*) see https://pkg.go.dev/cmd/go#hdr-Test_packages
      (+) see https://docs.pytest.org/en/7.1.x/reference/reference.html#confval-python_files
      
      /reviewed-by @jerome
      /reviewed-on nexedi/pygolang!20
      ffb40903
    • Kirill Smelkov's avatar
      golang_str: Speedup utf-8 decoding a bit on py2 · 9cb7b210
      Kirill Smelkov authored
      We recently moved our custom UTF-8 encoding/decoding routines to Cython.
      Now we can start taking speedup advantage on C level to make our own
      UTF-8 decoder a bit less horribly slow on py2:
      
          name       old time/op  new time/op  delta
          stddecode   752ns ± 0%   743ns ± 0%   -1.19%  (p=0.000 n=9+10)
          udecode     216µs ± 0%    75µs ± 0%  -65.19%  (p=0.000 n=9+10)
          stdencode   328ns ± 2%   327ns ± 1%     ~     (p=0.252 n=10+9)
          bencode    34.1µs ± 1%  32.1µs ± 1%   -5.92%  (p=0.000 n=10+10)
      
      So it is ~ 3x speedup for u(), but still significantly slower compared
      to std unicode.decode('utf-8').
      
      Only low-hanging fruit here to make _utf_decode_rune a bit more prompt,
      since it sits in the most inner loop. In the future
      _utf8_decode_surrogateescape might be reworked as well to avoid
      constructing resulting unicode via py-level list of py-unicode character
      objects. And similarly for _utf8_encode_surrogateescape.
      
      On py3 the performance of std and u/b decode/encode is approximately the same.
      
      /trusted-by @jerome
      /reviewed-on !19
      9cb7b210