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
<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
<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: