cfbolz changed the topic of #pypy to: #pypy PyPy, the flexible snake https://pypy.org | IRC logs: https://quodlibet.duckdns.org/irc/pypy/latest.log.html#irc-end and https://libera.irclog.whitequark.org/pypy | insert pithy quote here
Julian has quit [Quit: leaving]
fotis has joined #pypy
fotis has quit [Ping timeout: 252 seconds]
<mattip> something changed in the way _hpy_backend tests are skipped on linux32 and windows64
<mattip> and the skipping gives a KeyError
<mattip> that is on linux32
<mattip> whohoo, we have over 600 packages on conda for pypy-windows (and over 1000 for pypy-posix)
<LarstiQ> those `awaiting-parents` also look promising in that just waiting might be enough to get them done
<mattip> I tried adding a CI job but tox + azure pipelines is not working like I thought
lritter has joined #pypy
lritter has quit [Ping timeout: 265 seconds]
otisolsen70 has joined #pypy
otisolsen70_ has joined #pypy
otisolsen70_ has quit [Read error: Connection reset by peer]
otisolsen70 has quit [Ping timeout: 265 seconds]
<ctismer> mattip: I just saw that issue 2674 _does_ apply of course. Did not see the extension (tired from debugging).
<ctismer> mattip: How comes that this three-years-old issue was never handled? Client vanished?
<mattip> laziness?
<mattip> that issue has a pretty minimum reproducer. Let me see if I can turn it into a failing test
slav0nic has joined #pypy
stkrdknmibalz has quit [Quit: WeeChat 3.0.1]
<ctismer> mattip: Well, that was not criticising. But when inheritance is not working, why does no other extension complain as well? May be the usage of inheritance is very uncommon for extensions.
<mattip> So we have bases=(object, noddy) where noddy is a c-extension type with an added attribute,
<mattip> so its tp_basicsize is larger than object's tp_basicsize
<mattip> and I seem to recall some logic where the tp_allocate uses the largets tp_basicsize of all the base classes
<mattip> but I don't recall any rule about that changing which tp_new is called for the derived class
<mattip> shouldn't it still be the tp_new of the first base class?
otisolsen70 has joined #pypy
<ctismer> Ahaa, then it's different. I remember something about inheritance. That is quite some calculation obtaining the right MRO.
<ctismer> My case is even simpler.
<mattip> (I pushed a test to the issue-2674 branch)
<mattip> what is your case like? I didn't find time to try out your code
<ctismer> it is simply this "nothing":
<mattip> so no dual inheritance?
<ctismer> QObject is a builtin wrapped Qt type in PySide. No, simple inheritance.
<mattip> neither as an hg repo nor a git repo
<ctismer> Do you support Py_tp_call?
<ctismer> you paste this link into your shell. It appends to your cloned git repos. No?
<ctismer> what is the response in the shell?
* ctismer can also send you a .zip with the whole checkout
<LarstiQ> pressing the `Download` tab/link it pops up a list of `git fetch` commands, from there I can `git clone 'https://codereview.qt-project.org/c/pyside/pyside-setup/+/369623'; and then do the magic to get the right commit
<LarstiQ> not sure why these aren't just branches :shrug:
<ctismer> Aaah, sorry, I forgot what I'm doing ðŸĪŠ
<ctismer> exactly, open it in the browser and choose how you want to download - that gives you the link for the terminal
<mattip> strange, git clone ... from LarstiQ 's message does not work for me
<mattip> git version 2.25.1
<cfbolz> me neither
<ctismer> wot?
<mattip> when I look at the "CPython QtCore.QObject.__new__", I see it is "built-in method __new__ of Shiboken.ObjectType object"
<mattip> is it something different in PyPy?
<ctismer> ok, I will try to paste a direct link, what I download.
<ctismer> >>>> QtCore.QObject.__new__
<ctismer> <builtin_function_or_method object at 0x00007f90ef1467c8>
<ctismer> >>> QtCore.QObject.__new__
<ctismer> <built-in method __new__ of Shiboken.ObjectType object at 0x7faa0906e4e0>
<mattip> so somehow the tp_new is not getting assigned correctly, even though the mro is quite straightforward
<mattip> [<class 'PySide6.QtCore.QObject'>, <class 'Shiboken.Object'>, <class 'object'>]
<ctismer> here is what the link is in terminal:
<ctismer> git fetch "https://codereview.qt-project.org/pyside/pyside-setup" refs/changes/23/369623/6 && git checkout FETCH_HEAD
<mattip> right, but first you need a clone, so first
<mattip> git clone "https://codereview.qt-project.org/pyside/pyside-setup" && cd pyside-setup
<ctismer> yes. That was in the setup instruction link, probably scrolled away :)
<ctismer> the above class is correctly initialized. Just in the inheritance case, the Py_tp_new slot should be called that does a quite complex dance.
<mattip> on PyPy, what is Shiboken.ObjectType.__new__ ?
<mattip> it should be the same as QtCore.QObject.__new__
<mattip> and different from object.__new__
<ctismer> don't you mean Shiboken.Object.__new__ ?
<ronan> mattip: note that in 2674, the issue might just be that PyType_FromSpec() isn't called
<mattip> ronan: thanks. It does seem to be a different issue
<ctismer> but we _are_ using PyType_FromSpec
<ronan> BTW, I don't think we can support creating raw PyHeapTypeObjects
<mattip> ctismer: ok, ronan was specifically referring to issue 2674, not your case.
<ctismer> therefore I asked if you are supporting `Py_tp_new`
<ctismer> ah, sorry :)
<mattip> we support everything, excecpt we have bugs, so we are trying to figure out what the bug is
<ctismer> I see
<mattip> again: what is QtCore.QObject.__new__, is it Shiboken.ObjectType.__new__ or is it object.__new__ ?
<mattip> on PyPy
<mattip> ronan: why can't we support creating PyHeapTypeObjects? We pass the tests for PyHeapTypeObject in cpyext/test/test_typeobjects.py
<mattip> ronan: is there a test missing?
<mattip> ctismer: building PySide6 requires going through too many hoops. Now I need to sign up to be a qt developer in order to get the libraries.
<ronan> mattip: look at what PyType_FromSpec() is doing, we're not replicating any of it when peoplpe bypass it
<ronan> also, CPython docs are explicit that the only supported way of creating heap types is through PyType_FromSpec() and friends
<ctismer> mattip: it is
<ctismer> >>>> QtCore.QObject.__mro__
<ctismer> >>>> QtCore.QObject.__mro__[0].__new__
<ctismer> (<class 'PySide6.QtCore.QObject'>, <class 'Shiboken.Object'>, <class 'object'>)
<ctismer> <builtin_function_or_method object at 0x00007f8b587ec4f0>
<ctismer> >>>> QtCore.QObject.__mro__[1].__new__
<ctismer> >>>> QtCore.QObject.__mro__[2].__new__
<ctismer> <function object.__new__ at 0x000000010a61abd0>
<ctismer> <function object.__new__ at 0x000000010a61abd0>
<mattip> so the problem is that the Shiboken.Object.__new__ is object.__new__
<mattip> when it should be a different tp_new
<ctismer> but why does it work in Python?
<ctismer> you mean, initialization is going this path??? That is quite different from Python. But when this is so, then the fix is easy :-D
<mattip> it seems we have no tests at all of PyType_FromSpec nor any of PyType_FromSpecWithBases
<ctismer> right (this is not for me, but I discovered exactly that...)
<ctismer> mattip: and that is used in CPython.
<ctismer> here is what you saw in the __mro__:
<mattip> thanks. We need a test we can put into test_typeobjects.py, or as a stand-alone C file we can add
<mattip> to cpyext/test/ like cpyext/test/banana.c
<ctismer> not clear for me how the layout should be. Does Shiboken.Object.__new__ call Shiboken.__ObjectType.__new__ in some way?
Julian has joined #pypy
* ctismer thinks this is a dumb question. Simulate classes with Python and try it, right?
<mattip> haha, in digging around for PyType_FromSpec, I found issue https://bugs.python.org/issue26979 about tp_new
<mattip> and guess who commented on that issue almost exactly 3 years ago?
<ctismer> *huestel*
<antocuni> mattip: it's the same problem I complained about in an email which I sent to the C-API mailing list, which got ignored
<mattip> right, I was just writing that
<antocuni> CPython devs are so busy trying not to break anything that they don't have time to fix bugs :)
otisolsen70_ has joined #pypy
otisolsen70 has quit [Ping timeout: 265 seconds]
<vstinner> antocuni: (rolling eyes)
* ctismer 😇
<ctismer> mattip: sorry that I was so stubborn and did not see the obvious. Many thanks!!
<mattip> I converted the test to use PyType_FromSpec and use the Py_tp_new slot, which works
<mattip> multiple inheritence still does not, but PySide is not using multiple inheritance
otisolsen70_ has quit [Quit: Leaving]
<mattip> so somehow the creation of Shiboken.Object is different to what I am doing in the test
<mattip> here is the test
<LarstiQ> mattip, cfbolz: sorry, pasted the wrong thing. But seems you figured that out.
<mattip> maybe because Shiboken.Object uses {Py_tp_base, (&PyType_Type)} ?
Julian has quit [Ping timeout: 252 seconds]
<mattip> well adding a Py_tp_base breaks things, but for some obscure reason it is setting tp_doc inappropriately
<mattip> but it is still calling the tp_new from the spec
Julian has joined #pypy
* ctismer busy building, will try sth. soon
<ctismer> great that PyPy forces me to make the implementation better, really!
<mattip> hang on
<mattip> ctismer: the mro is showing Shiboken.Object, not Shiboken.ObjectType
<ctismer> yes. Dunno if that is wrong or right ATM.
<mattip> Shiboken.Object, from pyside-setup/sources/shiboken6/libshiboken/basewrapper.cpp line 229
<mattip> does not have a Py_tp_new
<ctismer> I am just supplying one, hoping for a crash
<mattip> how is Shiboken.ObjectType.__new__ getting assigned to PySide6.QtCore.QObject.__new__
<mattip> ?
* mattip off
<ctismer> just tested it, no change at all
<ctismer> I was not aware that this needs to be assigned. (confused ATM)
<ctismer> "how is Shiboken.ObjectType.__new__ getting assigned to PySide6.QtCore.QObject.__new__": That works through some registration of types, probably something that PyPy cannot see. I will send some log, again building...
* ctismer walking the dog
Julian has quit [Ping timeout: 265 seconds]
Julian has joined #pypy
dmalcolm_ has joined #pypy
dmalcolm has quit [Ping timeout: 252 seconds]
jacob22 has quit [Quit: Konversation terminated!]
Julian has quit [Ping timeout: 265 seconds]
Julian has joined #pypy
<ctismer> mattip: I am sending you the log files.
<ctismer> You see in line 169 that after this, the __new__- call comes, but not in PyPy.
<ronan> ctismer: looks like it's a metaclass problem
Julian has quit [Ping timeout: 252 seconds]
yuiza has joined #pypy
<ronan> ctismer: what's type(Obj) on pypy?
<ctismer> ronan: no, that's secondary. The real problem is that `SbkObjectTypeTpNew` gets not called, and we try to figure out where it's wrong.
<ronan> ctismer: that doesn't seem secondary, it's the first place where cpython and pypy diverge
<ctismer> no! Look at line 170. Python inserts a lot that PyPy skips. The metaobjects are secondary.
<ronan> ctismer: line 170 is cpython creating the class Obj, by calling the metaclass
Atque has joined #pypy
Julian has joined #pypy
<ctismer> ronan: "what's type(Obj) on pypy?" How should I know that? The thing is crashing when creating.
<ctismer> but it's an ordinary Python class that inherits from QtCore.QObject.
<ronan> ctismer: ahhh, sorry, I thought it was crashing when calling Obj()
<ronan> ctismer: yes, I thought it crashed on line 10
Julian has quit [Ping timeout: 265 seconds]
<ctismer> yes, it crashes on line 10. The instantiation is the problem.
Julian has joined #pypy
<ctismer> Ah, sorry!!! Then I can tell. Wait
yuiza_ has joined #pypy
<ctismer> ronan: hey :)
<ctismer> >>> type(Obj)
<ctismer> >>>> type(Obj)
<ctismer> <class 'type'>
<ctismer> <class 'Shiboken.ObjectType'>
<ronan> ctismer: well, the question becomes wny does it fail at computing the metaclass?
<ctismer> the inheritance gets simply ignored?
<ctismer> yes
Julian has quit [Ping timeout: 245 seconds]
<ronan> wait, what about type(QtCore.QObject)?
<ctismer> at least this does not look like an error on the PySide side
<ctismer> ok, wait...
<ctismer> >>>> type(QtCore.QObject)
<ctismer> <class 'Shiboken.ObjectType'>
<ctismer> <class 'type'>
<ctismer> >>> type(QtCore.QObject)
<ctismer> confused
<ctismer> >>>> Obj.__mro__
<ctismer> (<class '__main__.Obj'>, <class 'PySide6.QtCore.QObject'>, <class 'Shiboken.Object'>, <class 'object'>)
<ctismer> >>> Obj.__mro__
<ctismer> (<class '__main__.Obj'>, <class 'PySide6.QtCore.QObject'>, <class 'Shiboken.Object'>, <class 'object'>)
<ronan> ctismer: SbkObject_TypeF looks wrong, you're calling PyType_FromSpec() and then setting the type
<ctismer> PyPy seems to ignore the mro, as it is used in dictobject.c, how can that work?
<ronan> pypy ignores modifications done after PyType_Ready()
<ctismer> thanks, good point!
Julian has joined #pypy
<ctismer> ronan: I did not know how to set the meta type correctly before calling SbkType_FromSpec. Is that possible?
greedom has joined #pypy
<ctismer> I think I must use the direct API, because I cannot set the meta type with the Limited API.
Julian has quit [Ping timeout: 260 seconds]
<ctismer> which is possible to do, since the Limited API cannot be used at all, because that contradicts PyPy's structure. :-D
<ctismer> ronan: 1024 thanks for your reasoning, now I know what to implement tomorrow.
Julian has joined #pypy
yuiza has left #pypy [#pypy]
<ronan> ctismer: I think you can use Py_tp_base, or PyType_FromSpecWithBases
Julian has quit [Ping timeout: 265 seconds]
<ctismer> yes I read about that but did not understand - seems to need a helper class?
yuiza_ is now known as yizawa
greedom has quit [Remote host closed the connection]
greedom has joined #pypy
Julian has joined #pypy
<ronan> ctismer: yes, you're right, sorry. In fact, it's an open problem: https://bugs.python.org/issue15870
Julian has quit [Ping timeout: 260 seconds]
greedom has quit [Remote host closed the connection]
<ronan> I guess we should have PyType_Modified() regenerate the pypy-internal type and document it as being mandatory to call after any direct modification of the PyTypeObject
Julian has joined #pypy
ctismer has quit [Ping timeout: 250 seconds]
fijal has quit [Ping timeout: 252 seconds]
ctismer has joined #pypy
fijal has joined #pypy
<ctismer> ronan: I think it can work with a helper class spliced in.
<ctismer> But PyType_Modified would be a great simplification. And it would also enable my switchable features for PyPy !!
jacob22 has joined #pypy
Julian has quit [Quit: leaving]
mattip has quit [Ping timeout: 240 seconds]
slav0nic has quit [Ping timeout: 260 seconds]
stkrdknmibalz has joined #pypy