cfbolz changed the topic of #pypy to: #pypy PyPy, the flexible snake | IRC logs: and | so many corner cases, so little time
Atque has quit [Remote host closed the connection]
Atque has joined #pypy
Atque has quit [Ping timeout: 240 seconds]
Atque has joined #pypy
Techcable has joined #pypy
lritter has joined #pypy
<ctismer> cfbolz: does PyPy work with some packer, like cx-freeze? I would like to test on my wife's Windows machine without installing more that a single application.
Atque has quit [Quit: ...]
<cfbolz> ctismer: I don't think so :-(
<cfbolz> ctismer: but note that you do not need to install pypy, afaik
<cfbolz> you can unzip it and run it from that folder
<ctismer> cfbolz: yes, but I need to bundle it with all the QT stuff, to create an app that can run Mandelbrot. I hope to show that my colleague did something wrong, so I need to test on a naked Windows.
<cfbolz> ctismer: unzip it on your machine, pip-install qt, re-zip it. I am fairly sure that would just work
<ctismer> I think I can do it with an extra tool.
<cfbolz> I mean, install qt in whatever manner
slisnake has joined #pypy
otisolsen70 has joined #pypy
otisolsen70 has quit [Remote host closed the connection]
otisolsen70 has joined #pypy
<ctismer> cfbolz: the QT stuff is solved. I created a PyPy PySide with QtCore, QtGui and QtWidgets with --standalone as 3 wheels. Now I need to add the mandelbrot script, and do the PyPy installation, which itself needs a bootstrap. Will build something around that, myself and try with a second, clean virtual.
<cfbolz> cool
<krono> ctismer: seems like an interesting alternative for deployment (not just windows stuff)
<ctismer> krono: Yes, possibly. Maybe I even can mount the wheels as zip archives and run scripts from there. The dll files need to be unpacked, sill. Unless I manage to write a tool that executes them, because they are just a file with an offset 😃
<ctismer> cfbolz: incredible: I created a clone of my virtual without anything left of Python or PyPy. Then I installed the created wheels and tried the mandelbrot example. NOW I get the bug, myself!!!
<cfbolz> heh
<ctismer> ok, now is at least my wife out of the game 😂
<ctismer> so I will install VSCode on the new virtual and debug, hoping that the bug does not vanish...
<ctismer> the clone was almost the same machine. I only removed drive D: with all installed programs.
<ctismer> cfbolz: I have no line numbers, yet. But the calling sequence is
<ctismer> abort (@abort:21)
<ctismer> PyPyNumber_Long (@PyPyNumber_Long:1166601)
<ctismer> Shiboken::GilState::GilState(void) (@Shiboken::GilState::GilState(void):8)
<ctismer> PyPyNumber_Long (@PyPyNumber_Long:1166601)
<ctismer> 180210466 (@7ff95d6c0466..7ff95d6c04f3:3)
<ctismer> void QThread::start(enum QThread::Priority) (@void QThread::start(enum QThread::Priority):286)
<ctismer> BaseThreadInitThunk (@BaseThreadInitThunk:9)
<ctismer> RtlUserThreadStart (@RtlUserThreadStart:12)
<cfbolz> right, but it shows that you really make threads in C
<cfbolz> so my theory from yesterday is plausible
<ctismer> Shiboken::GilState::GilState is just:
<cfbolz> ok
<cfbolz> so my theory is that our PyGILState_Ensure does not do the right thing you you start your own threads from C
<ctismer> yes, your theory is right. PyPy is touching nonsense, no idea when and why.
<ctismer> what is exactly wrong, I don't know.
<cfbolz> ctismer: I think I know what is wrong. But what I cannot easily do (because I don't know enough threading in C) is how to write a small example extension that starts a thread
<ctismer> at least we know that this was no nonsense, and it will soon be fixed
<cfbolz> ctismer: do you want an untested patch for pypy to try to rebuild and see whether my theory is right?
lritter has quit [Ping timeout: 272 seconds]
<cfbolz> hm, I am not sure I can successfully write that patch :-(
<ctismer> cfbolz: sure, I would take it :-D
* ctismer already reading around in the rpython source, no idea if that makes sense
<cfbolz> ctismer: the code is in some complicated meta-programming in pypy/module/cpyext
<cfbolz> we need to call rgil.acquire_maybe_in_new_thread for some functions, instead of rgil.acquire
<cfbolz> but I would really like to test this
* ctismer is walking the dog 🐕
<cfbolz> ctismer: I made an issue at least:
<ctismer> cfbolz: Thanks a lot! Unfortunately, we now cannot publish our stuff until there is an officially fixed version. Do you think there is an intermediate work-around trick possible, so I can patch from our side?
<cfbolz> ctismer: not easily :-(
<cfbolz> I suppose you cannot somehow start the thread yourself from python?
<ctismer> cfbolz: so the point is to start a thread from Python and then morph it into a QTread, without touching GIL stuff?
<cfbolz> ctismer: yes, it's only about starting the thread
<ctismer> what is probably what I need to avoid in
<ctismer> GilState::GilState()
<ctismer> if (Py_IsInitialized()) {
<ctismer> {
<ctismer> m_gstate = PyGILState_Ensure();
<ctismer> }
<ctismer> m_locked = true;
<ctismer> }
<ctismer> the Py_IsInitialized or the PyGILState_Ensure?
<cfbolz> ctismer: no, the problem really is earlier
the_drow has quit [Quit: You have been kicked for being idle]
<cfbolz> you start the thread from C
<cfbolz> and at the moment this is really broken in cpyext
the_drow has joined #pypy
<cfbolz> I am not sure it's possible to work around that
the_drow has left #pypy [#pypy]
<ctismer> ah, so I must use a Python thread and only that, or morph it somehow. Son' Mist.
<cfbolz> sorry :-(
<cfbolz> I can probably try to do a fix relatively soon, but it would only be in a nightly, not an official release
<ctismer> I'm wondering why this works on macOS, and on my Windows build machine, and if I can enforce that state.
<lazka> would calling Is PyEval_InitThreads() be a workaround?
<lazka> that used to fix similar issues in old CPython
<ctismer> lazka: Is that still in PyPy? In Python 3.10, PyEval_InitThreads is a no-op.
Techcable has quit [Ping timeout: 256 seconds]
<ctismer> cfbolz: Solved! I simply have to create a normal thread and run it.
<ctismer> import threading
<ctismer> when I execute this at the beginning of a script, things work:
<ctismer> threading.Thread(target=lambda:42).start()
<cfbolz> ctismer: right
<ctismer> I can hide such a patch until it is officially fixed 🐍
slav0nic has joined #pypy
<lazka> ctismer, according to the source it's not a no-op. Maybe that is part of the problem and some tests use it and depend on it.
<ctismer> lazka: OK! I will test that tomorrow. Great that it is easily solvable, so we can publish.
<ctismer> lazka: thanks!
<lazka> (I'm just guessing, not a pypy dev)
greedom has joined #pypy
greedom has quit [Remote host closed the connection]
greedom has joined #pypy
greedom has quit [Remote host closed the connection]
slav0nic has quit [Ping timeout: 256 seconds]
otisolsen70 has quit [Quit: Leaving]
dmalcolm has quit [Remote host closed the connection]
dmalcolm has joined #pypy
dmalcolm has quit [Remote host closed the connection]
dmalcolm has joined #pypy
dmalcolm has quit [Remote host closed the connection]
isuruf has joined #pypy