implicit declaration of function ‘_PyLong_Frexp’; did you mean ‘_PyLong_New’? [-Wimplicit-function-declaration] #49
Comments
|
Ah I need to add 3.13 support some time. Let me see if I can get to it this weekend |
|
Compilation is fixed in the 3.13 branch (master...py3.13) but the tests are not passing (yet). |
|
Tests are passing locally as of 7541c2b |
|
There's an odd test failure with Somehow calling a function lazy compiles the function in 3.13 under certain conditions?! The test asserts that between these three lines: guppy3/guppy/heapy/test/test_View.py Lines 68 to 70 in 2e9baa0 only a list is allocated. Yet sometimes it shows 1 list object and 1 bytes object, where the bytes is the bytecode of the news function. This is extremely odd...
|
|
I know way too little about the inner workings of python, but the 3.13 change log (https://docs.python.org/3/whatsnew/changelog.html#changelog) mentions Once specifically with fixing a bug in 3.12 related to frame loading and performance tracing linking to python/cpython#107674. No idea if this is helpful at all. EDIT: @zhuyifei1999, could it be that due to the You could enforce compilation via |
|
No worries I just figured it out with gdb. C Backtrace: So it's this line What's odd is that this interaction should have at least existed since 3.12: python/cpython@b399115#diff-6f869eb8beb7cbe4bc6817584b99ad567f88962fa67f7beca25d009dc401234dR1480 I then tested with 3.12 and it repros if I only run test_View. Edit: Now it repros consistently even when I run all tests in 3.12 🙃 . Not sure I wanna figure out what's going on in coveragepy to see why it started reproing... inconsistently even (didn't repro in https://github.com/zhuyifei1999/guppy3/actions/runs/12582853256) In any case I'll just prime it, as you said.
Yes indeed. |
|
Ok the latest master should be good if you want to test around. I need to make sure the code doesn't die horribly when JIT is enabled (the tests will still probably fail like crazy but I need to make sure at least it doesn't crash Python :) ) before I release a new version. |
|
As for free-threaded support... I don't think it'd happen. The code already has to work with a lot of CPython's implementation details, and having to lock / unlock everything correctly sounds practically impossible without spending time dedicated to maintaining this and keeping up with every change in Python implementation detail. Besides... I'll have to lock and unlock every object in the process. The overhead sounds astronomical and almost definitely worse then just having a GIL. Edit: I could reconsider this if cpython starts exposing |
|
Do I need to do anything differently when installing? $ git clone [email protected]:zhuyifei1999/guppy3.git
$ cd guppy3/
$ python3 -m venv .venv
$ source .venv/bin/activate
(.venv) $ pip install .
Processing /tmp/guppy3
Installing build dependencies ... done
Getting requirements to build wheel ... done
Preparing metadata (pyproject.toml) ... done
Building wheels for collected packages: guppy3
Building wheel for guppy3 (pyproject.toml) ... done
Created wheel for guppy3: filename=guppy3-3.1.4.post1-cp313-cp313-linux_x86_64.whl size=704547 sha256=b8b38adac29747cb59b3b5c4b232d00486ec0e8fa6ba13b2bf8e9acbcb7a964f
Stored in directory: /tmp/pip-ephem-wheel-cache-x62_ac2g/wheels/8a/15/40/a1336784ef66a531bba40d24881c19cd17a46929745cbf9089
Successfully built guppy3
Installing collected packages: guppy3
Successfully installed guppy3-3.1.4.post1
(.venv) $ python3Python 3.13.1 (main, Dec 4 2024, 18:05:56) [GCC 14.2.1 20240910] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import guppy3
Traceback (most recent call last):
File "<python-input-0>", line 1, in <module>
import guppy3
ModuleNotFoundError: No module named 'guppy3'
>>> import guppy
Traceback (most recent call last):
File "<python-input-1>", line 1, in <module>
import guppy
File "/tmp/guppy3/guppy/__init__.py", line 18, in <module>
from guppy import sets as sets
File "/tmp/guppy3/guppy/sets/__init__.py", line 1, in <module>
from guppy.sets.setsc import BitSet # base bitset type
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ModuleNotFoundError: No module named 'guppy.sets.setsc' |
|
That's not supposed to happen. And I can repro that. Weird. Hold on. |
|
Oh I see why. It's importing from the guppy dir in the current working directory instead of what you installed in You can either: or: Or: |
|
OMG I forgot the |
|
I can confirm that version a0ef779 seems to work fine now for python 3.13 in the way it did for 3.12 for us. Thanks! |
Surprisingly JIT passes all tests without having to modify the code. But it's fun to see things one isn't normally supposed to: |
|
Alright I released 3.1.5 with the latest changes. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi,
new python 3.13 environment and the installation fails with:
Anything more I can/should provide?
Thanks!
The text was updated successfully, but these errors were encountered: