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
shlomif has joined #pypy
Corbin has quit [Quit: zzz]
greedom has joined #pypy
greedom has quit [Remote host closed the connection]
graingert has joined #pypy
graingert[m] has joined #pypy
<graingert[m]> hello, is there a process for backporting stdlib fixes to older pypy releases?
<graingert[m]> eg will pypy 3.8 gain https://bugs.python.org/issue44962 ?
<cfbolz> graingert[m]: is that in some cpython 3.8.x?
<graingert[m]> but the bug exists in pypy 3.6+
<graingert[m]> cfbolz: it's only backported as far as 3.9
<cfbolz> graingert[m]: then we usually don't fix it. But if you were to open a pull request, we would probably merge it
<graingert[m]> awesome
<graingert[m]> cfbolz: do I just manually apply the patch or is there some magic to maintain history across git/hg I need to do?
<cfbolz> graingert[m]: manually, and you reference the bpo
<graingert[m]> cool
<graingert[m]> thanks
<cfbolz> Hodgestar: I looked into more advanced algorithms too, but they were slower and indeed we have some custom heuristics
<cfbolz> It does not matter anyway, cycle finding went from five min or so to a few seconds
<graingert[m]> <cfbolz> "graingert: then we usually don't..." <- I only mention because it seems to present worse on pypy due to differences in the GC
<graingert[m]> And pypy 3.9 seems way off
<cfbolz> Right, thanks for pointing that out
<graingert[m]> Oh I didn't mean to cast shade on 3.9 being way off! I'm very excited for 3.8!
jacob22 has quit [Quit: Konversation terminated!]
<Dejan> Same here - looks good so far
Atque has joined #pypy
Atque has quit [Remote host closed the connection]
Atque has joined #pypy
<cfbolz> graingert[m]: thanks, no worries
xcm has quit [Remote host closed the connection]
xcm has joined #pypy
amauryfa has quit [Ping timeout: 268 seconds]
amauryfa has joined #pypy
Atque has quit [Quit: ...]
amaury has joined #pypy
amauryfa has quit [Ping timeout: 268 seconds]
amaury has quit [Ping timeout: 252 seconds]
otisolsen70 has joined #pypy
amaury has joined #pypy
<LarstiQ> sometimes having your own buildbot install is a plus: https://twitter.com/peter_szilagyi/status/1437646118700175360
Atque has joined #pypy
amaury has quit [Ping timeout: 240 seconds]
<ctismer> ronan: Howdy! I got an annoying effect:
<ctismer> ronan: I have re-written the whole type creation in a way that PyType_Ready is called at the very last. What happened? Nothing, same errors! How can that be? The error must be still somewhere else.
<shlomif> cfbolz: hi again! did you take a look at https://github.com/shlomif/pypy3-code--slowdown yet?
<Dejan> buy faster computer
<Dejan> that should fix it
<Dejan> :D
<Dejan> (bad joke... i know)
amaury has joined #pypy
<ctismer> ronan: tr("Da steh ich nun, ich armer Tor, und bin so schlau als wie zuvor") 🤪
otisolsen70 has quit [Quit: Leaving]
<ronan> ctismer: I'm actually not sure there's any way to set a metaclass on a C-defined heaptype in pypy ATM
<ronan> ctismer: where is your new code?
<ctismer> I will show you. Do you want it plain, or should I instrument it?
<ctismer> ronan: it's a hackish implementation, but seems to be quite correct.
<ronan> plain is fine
<ctismer> ronan: Actually, it would be great if you are right.
<ctismer> ronan: Here is the gerrit link to open in a browser:
<ctismer> Here is the direct http link:
<ctismer> ronan: git fetch "https://codereview.qt-project.org/pyside/pyside-setup" refs/changes/76/343976/29 && git checkout FETCH_HEAD
<ctismer> I have taken the Python 3.7 implementation and stripped it down so it matches our needs.
<ctismer> ronan: Can the method from Josh Haberman eventually work? At the end of https://bugs.python.org/issue15870
<ronan> ctismer: that might work actually
<ronan> ctismer: how does it fail on pypy now? Your code should at least ensure `type(Shiboken.Object) is Shiboken.ObjectType`
stkrdknmibalz has joined #pypy
<graingert[m]> Is editing files via the heptapod UI disabled?
<marmoute> graingert[m]: for now, yes
<graingert[m]> Ah
<ctismer> ronan: exactly the same problem
<ctismer> >>>> type(Obj.__mro__[2])
<ctismer> <class 'type'>
<ctismer> <class 'Shiboken.Object'>
<ctismer> >>>> Obj.__mro__[2]
<ctismer> >>> Obj.__mro__[2]
<ctismer> <class 'Shiboken.Object'>
<ctismer> >>> type(Obj.__mro__[2])
<ctismer> <class 'Shiboken.ObjectType'>
<ronan> ctismer: that's weird, are you sure that the pypy-specific code actually runs?
<ronan> also, check that PyType_Ready() is actually called late
<ctismer> ronan: pypy3rc1 is running in a shell. How should I check PyType_Ready? Then I need to patch pypy?
jacob22 has joined #pypy
<ronan> you could add `assert(type->tp_flags & Py_TP_FLAGS_READY == 0);` just before the call
<ctismer> ronan: Ah, sure :)
<ctismer> >>>> def hugo():
<ctismer> >>>> Shiboken.getAllValidWrappers()
<ctismer> []
<ctismer> .... return Shiboken.getAllValidWrappers()
<ctismer> ronan: basic shiboken things work:
<ctismer> ....
<ctismer> >>>> hugo()
<ctismer> []
<ctismer> >>>> type(Shiboken.getAllValidWrappers)
<ctismer> <class 'builtin_function_or_method'>
<ctismer> >>>> type(hugo)
<ctismer> <class 'function'>
<ctismer> ronan: assertion fails!
<ctismer> ronan: Who could possibly set this?
<ronan> ctismer: I don't know, but some API functions call it implicitly
<ctismer> ronan: argh
<ctismer> ok will seek it
<ronan> ctismer: actually, there are a lot more functions that can do it on pypy
<ronan> (technically, they call type_realize() which creates the pypy object from the C struct)
<ronan> so I bet that PyObject_SetAttr does it
<ctismer> type->tp_name = spec->name;
<ctismer> ronan: even in my function, the flag is set at line 272, see here:
<ctismer> assert(type->tp_flags & Py_TPFLAGS_READY == 0);
<ctismer> /* Adjust for empty tuple bases */
<ctismer> if (!bases) {
<ctismer> ronan: Should I fiddle with that flag?
<ronan> ctismer: no, that would mess with cpyext
<ctismer> ronan: cannot use that flag. Even if I clear if, the assertion kicks in
<ctismer> ronan: that seems to be unsupported
<ctismer> ronan: Maybe I need to directly call PyType_Type.tp_new and prepare everything before?
<ctismer> ronan: unfortunately I don't know how to read the source
<ronan> ctismer: I don't understand how the flag can be set so early, it's not supposed to be
<ctismer> ronan: me neither, I just created the type and it is there. some cheating, methinks
Dejan has quit [Quit: Leaving]
<ctismer> ronan: what other extensions have been used with inheritance? Is there a working example? I'm quite lost after a lot of effort.
<ronan> ctismer: I'm not sure there any doing what you want to do. Maybe pybind11?
<ctismer> ronan: 😢
<ctismer> ronan: Ah?
<ctismer> ronan: is that used with PyPy? Then I'll have a look
<ronan> yes, they try to be compatible with pypy. Not sure what the current status is
<ctismer> ronan: Thank you! I will investigate that tomorrow
greedom has joined #pypy
greedom has quit [Remote host closed the connection]
greedom has joined #pypy
greedom has quit [Client Quit]
greedom has joined #pypy
shlomif has quit [Ping timeout: 265 seconds]
Atque has quit [Quit: ...]
amaury has quit [Ping timeout: 252 seconds]
greedom has quit [Remote host closed the connection]
Julian has joined #pypy
<antocuni> ronan, ctismer: re "I don't understand how the flag can be set so early". It looks like the perfect job for a gdb whatchpoint
amaury has joined #pypy
yizawa has quit [Quit: Connection closed for inactivity]
<ctismer> antocuni: I still don‘t understand how to debug a thing without source. 11 years out of the project have their impact 🤔
<antocuni> ctismer: I suggest to do an lldebug translation
<antocuni> maybe without JIT to save compilation time
<antocuni> it will be slow but I suppose you don't care at this point
<antocuni> ./rpython/bin/rpython -O2 --lldebug pypy/goal/targetpypystandalone.py
<antocuni> if you have already a translation lying around, you can just cd to the testing_1 directory and do "make clean && make lldebug"
<ctismer> antocuni: that is exactly what I need. Thank you so much!
<antocuni> you're welcome!
<ctismer> PySide inheritance is so crippled that it surely can be that PyPy cannot cope with it. Exactly that I must find out.
Julian has quit [Quit: leaving]