{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":139483800,"defaultBranch":"master","name":"pygolang","ownerLogin":"navytux","currentUserCanPush":false,"isFork":false,"isEmpty":false,"createdAt":"2018-07-02T19:11:49.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/1794248?v=4","public":true,"private":false,"isOrgOwned":false},"refInfo":{"name":"","listCacheKey":"v0:1696885322.0","currentOid":""},"activityList":{"items":[{"before":"abf3dcec0309f0072093ec769158a16f668247cc","after":"93e9c25a6f527a5aa26cab92f3c0cdc57271b68d","ref":"refs/heads/y/bstr+x/gpystr","pushedAt":"2024-05-20T09:58:10.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"navytux","name":"Kirill Smelkov","path":"/navytux","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1794248?s=80&v=4"},"commit":{"message":"X golang_str: Add ustr.decode for symmetry with bstr.decode and because gpy2 breaks without it\n\nWithout working unicode.decode gpy2 fails when running ERP5 as follows:\n\n    $ /srv/slapgrid/slappart49/t/ekg/i/5/bin/runTestSuite --help\n    No handlers could be found for logger \"SecurityInfo\"\n    Traceback (most recent call last):\n      File \"/srv/slapgrid/slappart49/t/ekg/soft/b5048b47894a7612651c7fe81c2c8636/bin/.runTestSuite.pyexe\", line 296, in <module>\n        main()\n      File \"/srv/slapgrid/slappart49/t/ekg/soft/b5048b47894a7612651c7fe81c2c8636/parts/pygolang/gpython/__init__.py\", line 484, in main\n        pymain(argv, init)\n      File \"/srv/slapgrid/slappart49/t/ekg/soft/b5048b47894a7612651c7fe81c2c8636/parts/pygolang/gpython/__init__.py\", line 292, in pymain\n        run(mmain)\n      File \"/srv/slapgrid/slappart49/t/ekg/soft/b5048b47894a7612651c7fe81c2c8636/parts/pygolang/gpython/__init__.py\", line 192, in run\n        _execfile(filepath, mmain.__dict__)\n      File \"/srv/slapgrid/slappart49/t/ekg/soft/b5048b47894a7612651c7fe81c2c8636/parts/pygolang/gpython/__init__.py\", line 339, in _execfile\n        six.exec_(code, globals, locals)\n      File \"/srv/slapgrid/slappart49/t/ekg/soft/b5048b47894a7612651c7fe81c2c8636/eggs/six-1.16.0-py2.7.egg/six.py\", line 735, in exec_\n        exec(\"\"\"exec _code_ in _globs_, _locs_\"\"\")\n      File \"<string>\", line 1, in <module>\n      File \"/srv/slapgrid/slappart49/t/ekg/soft/b5048b47894a7612651c7fe81c2c8636/bin/runTestSuite\", line 10, in <module>\n        from Products.ERP5Type.tests.runTestSuite import main; sys.exit(main())\n      File \"/srv/slapgrid/slappart49/t/ekg/soft/b5048b47894a7612651c7fe81c2c8636/parts/erp5/product/ERP5Type/__init__.py\", line 96, in <module>\n        from . import ZopePatch\n      File \"/srv/slapgrid/slappart49/t/ekg/soft/b5048b47894a7612651c7fe81c2c8636/parts/erp5/product/ERP5Type/ZopePatch.py\", line 75, in <module>\n        from Products.ERP5Type.patches import ZopePageTemplateUtils\n      File \"/srv/slapgrid/slappart49/t/ekg/soft/b5048b47894a7612651c7fe81c2c8636/parts/erp5/product/ERP5Type/patches/ZopePageTemplateUtils.py\", line 58, in <module>\n        convertToUnicode(u'', 'text/xml', ())\n      File \"/srv/slapgrid/slappart49/t/ekg/soft/b5048b47894a7612651c7fe81c2c8636/eggs/Zope-4.8.9+slapospatched002-py2.7.egg/Products/PageTemplates/utils.py\", line 73, in convertToUnicode\n        return source.decode(encoding), encoding\n    AttributeError: unreadable attribute\n\nand in general if we treat both bstr ans ustr being two different\nrepresentations of the same entity, if we have bstr.decode, having\nustr.decode is also needed for symmetry with both operations converting\nbytes representation of the string into unicode.\n\nNow there is full symmetry in between bstr/ustr and encode/decode. Quoting updated encode/decode text:\n\n    Encode encodes unicode representation of the string into bytes, leaving string domain.\n    Decode decodes bytes   representation of the string into ustr, staying inside string domain.\n\n    Both bstr and ustr are accepted by encode and decode treating them as two\n    different representations of the same entity.\n\n    On encoding, for bstr, the string representation is first converted to\n    unicode and encoded to bytes from there. For ustr unicode representation\n    of the string is directly encoded.\n\n    On decoding, for ustr, the string representation is first converted to\n    bytes and decoded to unicode from there. For bstr bytes representation of\n    the string is directly decoded.","shortMessageHtmlLink":"X golang_str: Add ustr.decode for symmetry with bstr.decode and becau…"}},{"before":"a69d44dda5c83b8bd8664f36c9e7b775fed6af3a","after":"abf3dcec0309f0072093ec769158a16f668247cc","ref":"refs/heads/y/bstr+x/gpystr","pushedAt":"2024-05-10T09:33:51.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"navytux","name":"Kirill Smelkov","path":"/navytux","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1794248?s=80&v=4"},"commit":{"message":"X golang_str: Fix bstr/ustr __add__ and friends to return NotImplemented wrt unsupported types\n\nIn bbbb58f0 (golang_str: bstr/ustr support for + and *) I've added\nsupport for binary string operations, but similarly to __eq__ did not\nhandle correctly the case for arbitrary arguments that potentially\ndefine __radd__ and similar.\n\nAs the result it breaks when running e.g. bstr + pyparsing.Regex\n\n      File \".../pyparsing-2.4.7-py2.7.egg/pyparsing.py\", line 6591, in pyparsing_common\n        _full_ipv6_address = (_ipv6_part + (':' + _ipv6_part) * 7).setName(\"full IPv6 address\")\n      File \"golang/_golang_str.pyx\", line 469, in golang._golang._pybstr.__add__\n        return pyb(zbytes.__add__(a, _pyb_coerce(b)))\n      File \"golang/_golang_str.pyx\", line 243, in golang._golang._pyb_coerce\n        raise TypeError(\"b: coerce: invalid type %s\" % type(x))\n    TypeError: b: coerce: invalid type <class 'pyparsing.Regex'>\n\nbecause pyparsing.Regex is a type, that does not inherit from str, but defines\nits own __radd__ to handle str + Regex as Regex.\n\n-> Fix it by returning NotImplemented from under __add__ and other operations\nwhere it is needed so that bstr and ustr behave in the same way as builtin str\nwrt third types, but care to handle bstr/ustr promise that\n\n    only explicit conversion through `b` and `u` accept objects with buffer interface. Automatic coercion does not.","shortMessageHtmlLink":"X golang_str: Fix bstr/ustr __add__ and friends to return NotImplemen…"}},{"before":"28c353f89fc1030568d9c8935178f95f2a35f54b","after":"a69d44dda5c83b8bd8664f36c9e7b775fed6af3a","ref":"refs/heads/y/bstr+x/gpystr","pushedAt":"2024-05-08T20:39:00.000Z","pushType":"push","commitsCount":5,"pusher":{"login":"navytux","name":"Kirill Smelkov","path":"/navytux","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1794248?s=80&v=4"},"commit":{"message":"fixup! X golang_str: More fixes for bstr to be accepted as name of an attribute\n\nContrary to py3.11, py3.9 also explicitly checks for unicode inside\nbuiltin getattr. -> Patch that explicitly as well.","shortMessageHtmlLink":"fixup! X golang_str: More fixes for bstr to be accepted as name of an…"}},{"before":"e035c704d6fc44abf2c2c6853bfb5609205725a9","after":"28c353f89fc1030568d9c8935178f95f2a35f54b","ref":"refs/heads/y/bstr+x/gpystr","pushedAt":"2024-05-06T12:59:55.000Z","pushType":"push","commitsCount":24,"pusher":{"login":"navytux","name":"Kirill Smelkov","path":"/navytux","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1794248?s=80&v=4"},"commit":{"message":"Merge branch 'master' into y/bstr+x/gpystr\n\n* master: (21 commits)\n  time: Redo timers properly\n  time: Rearrange code a bit\n  libgolang: Adjust and require runtimes to provide semaphores with timeout\n  time: test: Add test for stop on func-based Timer\n  time: test: Explicitly release Timer/Ticker resources\n  golang: pychan: Fix memory leak in .from_chan_* pychan <- chan[X] wrappers\n  tox: *-asan: Activate LeakSanitizer on recent CPython 3\n  tox: Explicitly use -fno-omit-frame-pointer for ASAN/TSAN builds\n  tox -= CPython 3.5, 3.6, 3.7\n  tox: Tell it that our trun is ok to run\n  gpython: Fix thinko when rejecting unknown -X option\n  gpython: Fix `gpython -X gpython.runtime=threads` to spawn subinterpreters with threads runtime by default\n  gpython: tests: Factorize test_Xruntime\n  golang_str: fix UCS2 builds\n  setup: py.bench needs py on py3\n  tox += CPython 3.12\n  gpython: Fix -V when underlying python is not exactly release\n  golang: tests: Fix for Pytest ≥ 7.4\n  *: Replace imp with importlib on py3\n  pyx.build: Fix build after Cython 3 release\n  ...","shortMessageHtmlLink":"Merge branch 'master' into y/bstr+x/gpystr"}},{"before":"2ec5e96bbc1d5748e0fa47bcb7b74c58858c195a","after":"044deb35782b9841369296480248dc917b3a6d51","ref":"refs/heads/master","pushedAt":"2024-04-19T19:24:17.000Z","pushType":"push","commitsCount":5,"pusher":{"login":"navytux","name":"Kirill Smelkov","path":"/navytux","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1794248?s=80&v=4"},"commit":{"message":"time: Redo timers properly\n\nBackground: in 2019 in 9c260fde (time: New package that mirrors Go's\ntime) and b073f6df (time: Move/Port timers to C++/Pyx nogil) I've added\nbasic timers - with proper API but with very dumb implementation that\nwas spawning one thread per each timer. There were just a few timers in\nthe users and this was working, surprisingly, relatively ok...\n\n... until 2023 where I was working on XLTE that needs to organize 100Hz\npolling of Amarisoft eNodeB service to retrieve information about flows\non Data Radio Bearers:\n\n    https://lab.nexedi.com/kirr/xlte/-/commit/2a016d48\n    https://lab.nexedi.com/kirr/xlte/-/blob/8e606c64/amari/drb.py\n\nThere each request comes with its own deadline - to catch \"no reply\",\nand the deadlines are implemented via timers. So there are 100 threads\ncreated every second which adds visible overhead, consumes a lot of\nvirtual address space and RSS for threads stacks, and should be all unnecessary.\n\nWe was tolerating even that for some time, but recently Joanne approached me\nwith reports that xamari program, that does the polling, is leaking memory.\n\nWith that, and because it was hard to find what is actually leaking,\nI've started to remove uncertainties and there are a lot of uncertainty\nin what is going on when lots of threads are being created over and over.\n\nIn the end the leak turned out to be likely a different thing (see\nhttps://lab.nexedi.com/nexedi/pygolang/-/merge_requests/24, still\ndiscovered while working on hereby patch), but all of the above was\nenough motivation to finally start redoing the timers properly.\n\n--------\n\nSo when it comes to do the timers properly more or less, there is\nusually queue of armed timers, and a loop that picks entries from that\nqueue to fire them. I was initially trying to do the simple thing and\nuse std::priority_queue for that, because priority_queue is internally\nheap, and heaps can provide O(log(n)) insertion and removal of arbitrary\nelement, plus O(1) \"pick top element to process\". Exactly what would\nsuit. However I quickly found that even in 2024, std::priority_queue\ndoes not provide removal operation at all, and there is no such thing as\ne.g. std::sift_heap, that would help to implement that manually. Which\nis surprising, because e.g. libevent implements all that just ok via\nsifting up/down upon removal in logarithmic complexity:\n\nhttps://github.com/libevent/libevent/blob/80e25c02/minheap-internal.h#L96-L115\n\nthe lack of efficient removal operation turned out to be a blocker to\nuse std::priority_queue because most of the timers, that are armed for\ntimeouts, are never expired and upon successful completion of covered\noperation, the timer is stopped. In other words the timer is removed\nfrom the timer queue and the removal is one of the most often\noperations.\n\nSo, if std::priority_queue cannot work, we would need to either bring in\nanother implementation of a heap, or, if we are to bring something,\nbring and use something else that is more suitable for implementing\ntimers.\n\nThat reminded me that in 2005 for my Navy project, I already implemented\ncustom timer wheel to handle timeouts after reading https://lwn.net/Articles/152436/ .\nContrary to heaps, such timer wheels provide O(1) insertion and removal\nof timers and work generally faster. But this time I did not want to\ndelve into implementing all that myself again and tried to look around\nof what is available out there.\n\nThere was an update to kernel timer-wheel implementation described at\nhttps://lwn.net/Articles/646950/ and from that a project called\nTimeout.c was also found that provides implementation for such a wheel\nfor user space: https://25thandclement.com/~william/projects/timeout.c.html .\n\nHowever when we are to pick third-party code, we should be ready to\nunderstand it and fix bugs there on our own. So the audit of timeout.c\ndid not went very smoothly - there are many platform-depended places,\nand the issue tracker shows signs that sometimes not everything is ok\nwith the implementation. With that I've looked around a bit more and\nfound more compact and more portable Ratas library with good structure\nand description and whose audit came more well:\n\n    https://www.snellman.net/blog/archive/2016-07-27-ratas-hierarchical-timer-wheel\n    https://github.com/jsnell/ratas\n\nHere, after going through the code, I feel to be capable to understand\nissues and fix bugs myself if that would become needed.\n\nAnd the benchmark comparison of Timeout.c and Ratas shows that they\nshould be of the same order regarding performance:\n\nhttps://lab.nexedi.com/kirr/misc/-/blob/4f51fd6/bench/time-wheel/ratas-vs-timeout.pdf\nhttps://lab.nexedi.com/kirr/ratas/-/commit/382321d2\nhttps://lab.nexedi.com/kirr/timeout/-/commit/d6f15744\n\nwhich makes Ratas the winner for me.\n\nHaving timer-wheel implementation, the rest is just technique to glue it\nall together. One implementation aspect deserves to be mentioned though:\n\nThe timer loop uses Semaphore.acquire, recently modernized to also\naccept timeout, to organize sleep in between pauses with also being able\nto be simultaneously woken up if new timer is armed with earlier\nexpiration time.\n\nOther than that the changes are mostly straightforward. Please see the\npatch itself for details.\n\nRegarding how the new implementation is more efficient for what we had\nbefore, there are added benchmarks to measure arming timers that do not\nfire, and, for symmetry, arming timers that do fire. We are most\ninterested in the first benchmark, because it shows how cheap or\nexpensive it is to use timers to implement timeouts, but the second one\nis also useful to have to see the overhead of the whole timers machinery.\n\nOn my machine under py3.11 they go as after this patch:\n\n    name              time/op\n    timer_arm_cancel   805ns ± 0%\n    timer_arm_fire    9.63µs ± 0%\n\nand before the patch the benchmarks simply do not run till the end\nbecause they run out of memory due to huge number of threads being\ncreated.\n\nStill with the following test program we can measure the effect new\ntimers implementation has:\n\n    ---- 8< ----\n    from golang import time\n\n    def main():\n        δt_rate = 1*time.millisecond\n\n        tprev = time.now()\n        tnext = tprev + δt_rate\n        while 1:\n            timer = time.Timer(5*time.second)\n            _ = timer.stop()\n            assert _ is True\n\n            t = time.now()\n            δtsleep = tnext - t\n            #print('sleep %.3f ms' % (δtsleep/time.millisecond))\n            time.sleep(δtsleep)\n            tprev = tnext\n            tnext += δt_rate\n\n    main()\n    ---- 8< ----\n\nThis program creates/arms and cancels a timer 1000 times per second.\n\nBefore hereby patch this program consumes ~ 30% of CPU, while after\nhereby patch this program consumes ~ 7-8% of CPU.\n\nFor the reference just a sleep part of that program, with all code\nrelated to timers removed consumes ~5% of CPU, while the consumption of\nplain sleep(1ms) in C and directly using system calls\n\n    ---- 8< ----\n    #include <unistd.h>\n\n    int main() {\n        while (1) {\n            usleep(1000);\n        }\n        return 0;\n    }\n    ---- 8< ----\n\nis ~ 3-4% of CPU on my machine.\n\n/cc @jerome\n/cc ORS team (@jhuge, @lu.xu, @tomo, @xavier_thompson, @Daetalus)\n/proposed-for-review-on https://lab.nexedi.com/nexedi/pygolang/-/merge_requests/26","shortMessageHtmlLink":"time: Redo timers properly"}},{"before":"c3deb6a3396e3c351b717c5d93adeb08ffbb4922","after":"2ec5e96bbc1d5748e0fa47bcb7b74c58858c195a","ref":"refs/heads/master","pushedAt":"2024-04-19T19:13:15.000Z","pushType":"push","commitsCount":5,"pusher":{"login":"navytux","name":"Kirill Smelkov","path":"/navytux","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1794248?s=80&v=4"},"commit":{"message":"golang: pychan: Fix memory leak in .from_chan_* pychan <- chan[X] wrappers\n\nThe code of pychan_from_raw, that pychan.from_chan_X calls, was creating\npychan object and then setting pychan._ch to the specified raw channel.\nBut it missed that pychan.__new__ was creating full Python object, with\neverything initialized - in particular with pychan._ch initialized to\nanother channel created by pychan.__cinit__ constructor, and so pointer\nto that another channel was removed without decrefing it first. That\ncaused the leak of that second channel observable as the following\nLeakSanitizer report when run on e.g. added test:\n\n    Direct leak of 72 byte(s) in 1 object(s) allocated from:\n        #0 0x7f70902f3bd7 in malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69\n        #1 0x7f708bfab612 in zalloc golang/runtime/libgolang.cpp:1307\n        #2 0x7f708bfa56c0 in _makechan golang/runtime/libgolang.cpp:469\n        #3 0x7f708be78da2 in __pyx_f_6golang_7_golang__makechan_pyexc golang/_golang.cpp:8844\n        #4 0x7f708be703ad in __pyx_pf_6golang_7_golang_6pychan___cinit__ golang/_golang.cpp:4870\n        #5 0x7f708be7019d in __pyx_pw_6golang_7_golang_6pychan_1__cinit__ golang/_golang.cpp:4833\n        #6 0x7f708beaa0f8 in __pyx_tp_new_6golang_7_golang_pychan golang/_golang.cpp:29896\n        #7 0x7f708be743af in __pyx_f_6golang_7_golang_pychan_from_raw golang/_golang.cpp:7240\n        #8 0x7f708be73e76 in __pyx_f_6golang_7_golang_6pychan_from_chan_int golang/_golang.cpp:6927\n        #9 0x7f7088a990a5 in __pyx_pf_6golang_12_golang_test_62test_pychan_from_raw_noleak golang/_golang_test.cpp:7479\n        #10 0x7f7088a98ef2 in __pyx_pw_6golang_12_golang_test_63test_pychan_from_raw_noleak golang/_golang_test.cpp:7445\n\n-> Fix it by adjusting raw chan -> py chan conversion routine to first\ncreate uninitialized py object - with no underlying channel created at all.\n\nAdjust pynil to use pychan_from_raw instead of duplicating its code, so\nthat we keep the logic and the fix only in one place.\n\nThe context where this problem was originally discovered is xamari from\nXLTE where on every request new timer is created to handle request\ntimeout, and that timer, being Python-level object, wraps underlying\nC-level timer with creating pychan wrapper of that:\n\nhttps://lab.nexedi.com/kirr/xlte/-/blob/8e606c64/amari/__init__.py#L182-193\nhttps://lab.nexedi.com/nexedi/pygolang/-/blob/6dd420da/golang/_time.pyx#L96\nhttps://lab.nexedi.com/nexedi/pygolang/-/blob/6dd420da/golang/_time.pyx#L104\n\nAs the result on every request memory was leaked on and on.\n\nBesides new test going ok even under LeakSanitizer, the following test\nprogram confirms the fix:\n\n```py\nfrom golang import context\n\ndef main():\n    bg = context.background()\n    key = object()\n    while 1:\n        ctx = context.with_value(bg, key, 1)\n\nmain()\n```\n\nBefore the patch it leaks ~ 1GB of RAM every second on my computer due\nto similar raw chan -> py chan wrapping in py context.with_value\n\nhttps://lab.nexedi.com/nexedi/pygolang/-/blob/6dd420da/golang/_context.pyx#L169-180\nhttps://lab.nexedi.com/nexedi/pygolang/-/blob/6dd420da/golang/_context.pyx#L38-43\n\nAfter the fix that program stays at constant RSS usage forever.\n\n/cc ORS team (@jhuge, @lu.xu, @tomo, @xavier_thompson, @Daetalus)\n/reviewed-by @jerome\n/reviewed-on https://lab.nexedi.com/nexedi/pygolang/-/merge_requests/24","shortMessageHtmlLink":"golang: pychan: Fix memory leak in .from_chan_* pychan &lt;- chan[X] wra…"}},{"before":"6dd420daa85715b6f620fbfe344be32b6620e29a","after":"c3deb6a3396e3c351b717c5d93adeb08ffbb4922","ref":"refs/heads/master","pushedAt":"2024-04-17T19:38:42.000Z","pushType":"push","commitsCount":5,"pusher":{"login":"navytux","name":"Kirill Smelkov","path":"/navytux","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1794248?s=80&v=4"},"commit":{"message":"gpython: Fix thinko when rejecting unknown -X option\n\nBefore:\n\n    (z-dev) kirr@deca:~/src/tools/go/pygolang$ gpython -X gpython.zzz\n    Traceback (most recent call last):\n      File \"/home/kirr/src/wendelin/venv/z-dev/bin/gpython\", line 3, in <module>\n        from gpython import main; main()\n      File \"/home/kirr/src/tools/go/pygolang/gpython/__init__.py\", line 397, in main\n        raise RuntimeError('gpython: unknown -X option %s' % opt)\n    RuntimeError: gpython: unknown -X option -X                                        <-- NOTE\n\nAfter:\n\n    (z-dev) kirr@deca:~/src/tools/go/pygolang$ gpython -X gpython.zzz\n    Traceback (most recent call last):\n      File \"/home/kirr/src/wendelin/venv/z-dev/bin/gpython\", line 3, in <module>\n        from gpython import main; main()\n      File \"/home/kirr/src/tools/go/pygolang/gpython/__init__.py\", line 397, in main\n        raise RuntimeError('gpython: unknown -X option %s' % arg)\n    RuntimeError: gpython: unknown -X option gpython.zzz                               <-- NOTE\n\n/proposed-for-review-on https://lab.nexedi.com/nexedi/pygolang/-/merge_requests/25","shortMessageHtmlLink":"gpython: Fix thinko when rejecting unknown -X option"}},{"before":"6446a0be11c3e8e0df16bbabf11ecab72cae24ba","after":"6dd420daa85715b6f620fbfe344be32b6620e29a","ref":"refs/heads/master","pushedAt":"2024-02-17T20:13:36.000Z","pushType":"push","commitsCount":4,"pusher":{"login":"navytux","name":"Kirill Smelkov","path":"/navytux","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1794248?s=80&v=4"},"commit":{"message":"tox += CPython 3.12\n\nTests now pass with that version.\n\n/reviewed-by @jerome\n/reviewed-on https://lab.nexedi.com/nexedi/pygolang/-/merge_requests/23","shortMessageHtmlLink":"tox += CPython 3.12"}},{"before":"17dbfbac88a1adba8da0c733e24b2a8317139468","after":"e035c704d6fc44abf2c2c6853bfb5609205725a9","ref":"refs/heads/y/bstr+x/gpystr","pushedAt":"2024-01-31T04:33:38.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"navytux","name":"Kirill Smelkov","path":"/navytux","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1794248?s=80&v=4"},"commit":{"message":"X Bring y/bstr+x/gpystr to be at least usable\n\nAsked by Kazuhiko: https://lab.nexedi.com/nexedi/pygolang/-/merge_requests/21#note_198526","shortMessageHtmlLink":"X Bring y/bstr+x/gpystr to be at least usable"}},{"before":null,"after":"17dbfbac88a1adba8da0c733e24b2a8317139468","ref":"refs/heads/y/bstr+x/gpystr","pushedAt":"2023-10-09T21:02:02.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"navytux","name":"Kirill Smelkov","path":"/navytux","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1794248?s=80&v=4"},"commit":{"message":"X My draft state of x/gpystr work;  py2/py3 pickle problem should be essentially solved","shortMessageHtmlLink":"X My draft state of x/gpystr work; py2/py3 pickle problem should be e…"}},{"before":"31fc69512bbc92f3bf700f2a1dc29dde88302413","after":"6446a0be11c3e8e0df16bbabf11ecab72cae24ba","ref":"refs/heads/master","pushedAt":"2023-08-16T20:09:08.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"navytux","name":"Kirill Smelkov","path":"/navytux","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1794248?s=80&v=4"},"commit":{"message":"pyx.build: Fix build after Cython 3 release\n\nUnfortunately the best Cython release ever[1] breaks build for Pygolang[2], and\npeople on the net also report that there are other problems - both build\nfailures and popped up performance problems due to changed semantic[3,4,...].\n\nFix it all on Pygolang side by, for now, not delving into being Cython 3\nbeta-testers and relying on field-proven Cython 2.\n\n/reported-by @levin.zimmermann\n\n[1] https://groups.google.com/g/cython-users/c/o41CrcRkVvo\n[2] https://lab.nexedi.com/nexedi/wendelin.core/merge_requests/16#note_188623\n[3] https://news.ycombinator.com/item?id=36778617\n[4] https://github.com/cython/cython/issues/5540","shortMessageHtmlLink":"pyx.build: Fix build after Cython 3 release"}},{"before":"55d39d4dd62a5b0fc9aa134d13eeab8a0e4b5fa1","after":"31fc69512bbc92f3bf700f2a1dc29dde88302413","ref":"refs/heads/master","pushedAt":"2023-05-03T10:28:28.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"navytux","name":"Kirill Smelkov","path":"/navytux","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1794248?s=80&v=4"},"commit":{"message":"pyx.build: v↑ setuptools_dso (2.7 -> 2.8)\n\nThis fixes linking to editable pygolang install on Windows.\nSee https://github.com/mdavidsaver/setuptools_dso/commit/fca6f29e and\nhttps://github.com/mdavidsaver/setuptools_dso/pull/25 for details.\n\nWithout this fix e.g. test_pyx_build was also failing:\n\n    platform win32 -- Python 3.10.11, pytest-7.3.1, pluggy-1.0.0 -- Z:\\home\\kirr\\src\\tools\\go\\pygo-win\\1.wenv\\Scripts\\python.exe\n    cachedir: .pytest_cache\n    rootdir: Z:\\home\\kirr\\src\\tools\\go\\pygo-win\\pygolang\n    collecting 3 items\n    collected 3 items\n\n    golang/pyx/build_test.py::test_pyx_build running build_ext\n    skipping 'pyxuser\\test.cpp' Cython extension (up-to-date)\n    building 'pyxuser.test' extension\n    Z:\\home\\kirr\\src\\tools\\go\\pygo-win\\BuildTools\\vc\\tools\\msvc\\14.35.32215\\bin\\Hostx64\\x64\\cl.exe /c /nologo /O2 /W3 /GL /DNDEBUG /MD -IZ:\\home\\kir\n    r\\src\\tools\\go\\pygo-win\\pygolang -IZ:\\home\\kirr\\src\\tools\\go\\pygo-win\\pygolang\\golang\\_compat\\windows -IZ:\\home\\kirr\\src\\tools\\go\\pygo-win\\1.wen\n    v\\include\\site\\python3.10 -IZ:\\home\\kirr\\src\\tools\\go\\pygo-win\\1.wenv\\include \"-IC:\\Program Files\\Python310\\include\" \"-IC:\\Program Files\\Python3\n    10\\Include\" -Iz:\\home\\kirr\\src\\tools\\go\\pygo-win\\BuildTools\\vc\\tools\\msvc\\14.35.32215\\include -Iz:\\home\\kirr\\src\\tools\\go\\pygo-win\\BuildTools\\ki\n    ts\\10\\include\\10.0.22000.0\\shared -Iz:\\home\\kirr\\src\\tools\\go\\pygo-win\\BuildTools\\kits\\10\\include\\10.0.22000.0\\ucrt -Iz:\\home\\kirr\\src\\tools\\go\\\n    pygo-win\\BuildTools\\kits\\10\\include\\10.0.22000.0\\um -Iz:\\home\\kirr\\src\\tools\\go\\pygo-win\\BuildTools\\kits\\10\\include\\10.0.22000.0\\winrt /EHsc /Tp\n    pyxuser\\test.cpp /Fobuild\\temp.win-amd64-cpython-310\\Release\\pyxuser\\test.obj /std:c++20 /EHc- /EHsr\n    cl : Command line warning D9025 : overriding '/EHc' with '/EHc-'\n    test.cpp\n    ...\n    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:EM\n    BED,ID=2 /MANIFESTUAC:NO /LIBPATH:Z:\\home\\kirr\\src\\tools\\go\\pygo-win\\pygolang\\golang\\runtime \"/LIBPATH:C:\\Program Files\\Python310\\libs\" \"/LIBPAT\n    H:C:\\Program Files\\Python310\" /LIBPATH:z:\\home\\kirr\\src\\tools\\go\\pygo-win\\BuildTools\\vc\\tools\\msvc\\14.35.32215\\lib\\x64 /LIBPATH:z:\\home\\kirr\\src\n    \\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\\\n    um\\x64 libgolang.lib /EXPORT:PyInit_test build\\temp.win-amd64-cpython-310\\Release\\pyxuser\\test.obj /OUT:build\\lib.win-amd64-cpython-310\\pyxuser\\\n    test.cp310-win_amd64.pyd /IMPLIB:build\\temp.win-amd64-cpython-310\\Release\\pyxuser\\test.cp310-win_amd64.lib\n    LINK : fatal error LNK1181: cannot open input file 'libgolang.lib'\t\t<-- NOTE\n    error: command 'Z:\\\\home\\\\kirr\\\\src\\\\tools\\\\go\\\\pygo-win\\\\BuildTools\\\\vc\\\\tools\\\\msvc\\\\14.35.32215\\\\bin\\\\Hostx64\\\\x64\\\\link.exe' failed with exi\n    t code 1181\n    FAILED\n\n    ========================== FAILURES ===========================\n    _______________________ test_pyx_build ________________________\n\n        def test_pyx_build():\n            pyxuser = testprog + \"/golang_pyx_user\"\n    >       pyrun([\"setup.py\", \"build_ext\", \"-i\"], cwd=pyxuser)\n\n    golang\\pyx\\build_test.py:31:\n    _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _\n\n    argv = ['setup.py', 'build_ext', '-i'], stdin = None, stdout = None, stderr = None\n    kw = {'cwd': 'Z:\\\\home\\\\kirr\\\\src\\\\tools\\\\go\\\\pygo-win\\\\pygolang\\\\golang\\\\pyx/testprog/golang_pyx_user'}, retcode = 1\n\n        def pyrun(argv, stdin=None, stdout=None, stderr=None, **kw):\n\n            retcode, stdout, stderr = _pyrun(argv, stdin=stdin, stdout=stdout, stderr=stderr, **kw)\n            if retcode:\n    >           raise RuntimeError(' '.join(argv) + '\\n' + (stderr and str(stderr) or '(failed)'))\n    E           RuntimeError: setup.py build_ext -i\n    E           (failed)\n\n    golang\\golang_test.py:1771: RuntimeError","shortMessageHtmlLink":"pyx.build: v↑ setuptools_dso (2.7 -&gt; 2.8)"}},{"before":"39dde7ebeb04ee8ed4194d49088d20c1e20e7d0c","after":"55d39d4dd62a5b0fc9aa134d13eeab8a0e4b5fa1","ref":"refs/heads/master","pushedAt":"2023-04-27T18:19:40.000Z","pushType":"push","commitsCount":41,"pusher":{"login":"navytux","name":"Kirill Smelkov","path":"/navytux","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1794248?s=80&v=4"},"commit":{"message":"Windows support\n\nPygolang stopped to work on Windows in 2019 starting from 8fa3c15b (Start using\nCython and providing Cython/nogil API). Restore it now.","shortMessageHtmlLink":"Windows support"}}],"hasNextPage":false,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAETqTUSAA","startCursor":null,"endCursor":null}},"title":"Activity · navytux/pygolang"}