11:39 <ctismer> mattip: I checked that the homebrew version is up-to-date enough.

11:39 <mattip> thanks, but I prefer linux

11:40 <ctismer> mattip: So you can simply do `brew install Qt` and don't need an account. (that's the good thing)

11:41 <ctismer> on the testing: The tests are built in a way that they forcibly run on a build folder.

11:43 <ctismer> mattip: But many of them can also be run on an install with wheels. The tests that don't work are only 23. I can give a list if you want to try.

11:44 <mattip> other than my curiosity, what is the goal of me trying the build?

11:47 <ctismer> mattip: The idea was to show what works and what doesn't. For instance, I got weird behavior on this example: `./examples/corelib/threads/mandelbrot.py`

11:50 <ctismer> mattip: There must be still something that is not allowed with PyPy, and I need someone with a sharpened PyPy-eye to find the last bug. I am at the end of my wisdom 🤪

11:51 <mattip> ok, so how do I build and run that example?

11:51 <mattip> can I just run it with the wheel you uploaded?

11:52 <ctismer> mattip: `pypy examples/corelib/threads/mandelbrot.py`

11:52 <ctismer> mattip: sure, but you still need Qt, this did not work in `--standalone`

11:53 <ctismer> but I can try to package a better one...

11:54 <ctismer> mattip: when mandelbrot works, then I can publish PyPySide, because that was the goal :)

11:55 <ctismer> mattip: you can run it with the wheel, if Qt is installed, unfortunately.

11:56 <mattip> weird, I get "ImportError: dlopen(<path>/Shiboken.pypy37-pp73-darwin.so, 6): Symbol not found: _PyPyDescr_NewGetSet

11:56 <mattip> when running with pypy3.7 v7.3.7

11:58 <mattip> but I think that was exposed years ago

11:59 <ctismer> mattip: I used a recent nightly build where you (or cfbolz?) had fixes.

12:02 <mattip> with a nightly I get something about missing qt libraries

12:02 <ctismer> the numbering is not very exact. There was a fix that defined `PyDescr_NewGetSet`

12:02 <mattip> ImportError: dlopen(<path>/PySide6/QtCore.pypy37-pp73-darwin.so, 6): Library not loaded: @rpath/QtCore.framework/Versions/A/QtCore

12:03 <ctismer> mattip: that's good, as said, it needs Qt. I failed to build a --standalone, but will try again.

12:07 <mattip> ahh, got it "brew install Qt"

12:08 <mattip> but even after I do that I still get the same error

12:09 <ctismer> mattip: yes, that's the cakewalk thing. Then you need a setting:

12:10 <ctismer> mattip: `export PATH=/usr/local/Cellar/qt/6.2.2/bin:$PATH`

12:14 <mattip> nope, still the same

12:15 <mattip> maybe whatever the macOS equivalent of LD_LIBRARY_PATH is?

12:16 <ctismer> mattip: possible. I never set something like that.

12:18 <ctismer> mattip: actually, a wheel install of PySide should work, immediately?

12:18 <ctismer> mattip: `pip install PySide6`

12:19 <mattip> it is already installed

12:20 <ctismer> mattip: so "python3 -c "from PySide6 import *"` works?

12:20 <ctismer> mattip: so `python3 -c "from PySide6 import *"` works?

12:21 <mattip> no. it gives me

12:21 <mattip> ImportError: dlopen(<path>/site-packages/PySide6/QtCore.pypy37-pp73-darwin.so, 6): Library not loaded: @rpath/QtCore.framework/Versions/A/QtCore

12:22 <ctismer> I was talking of the python install, as a starter

12:22 <[Arfrever]> MacOS has DYLD_LIBRARY_PATH and DYLD_FRAMEWORK_PATH variables...

12:23 <ctismer> [Arfrever]: yes, but I think the pip install works out-of-the-box?

12:24 <mattip> cool. "export DYLD_FRAMEWORK_PATH=/usr/local/Cellar/qt/6.2.2/lib" makes that error go away

12:24 <[Arfrever]> I never used MacOS anyway :) .

12:26 <ctismer> env

12:29 <mattip> now I get a segfault in the example, after printing something about

12:29 <mattip> "endPaint() called with active painter"

12:29 <mattip> "QPainter::begin: A paint device can only be painted by one painter at a time"

12:30 <mattip> QPainter::setCompositionMode: Painter not active

12:30 <ctismer> mattip: yes, that happens sometimes, then I get a black screen and nothing happens.

12:30 <ctismer> mattip: with Python, this works fine.

12:30 <mattip> seems like a painter is not getting collected after deletion

12:32 <ctismer> mattip: now I have a standalone wheel, but no more needed.

12:32 <ctismer> mattip: you should be able to run the example with Python, because you installed with pip.

12:35 <mattip> all I get is the segfault 100% of the time

12:36 <ctismer> mattip: I had that, too. After a reboot, it was different. No idea how to control that.

12:38 <ctismer> mattip: I am trying hard with running debuggers in parallel, in order to figure out when and why they diverge.

12:39 <mattip> why would it call endPaint more than once?

12:40 <ctismer> mattip: I'm afraid there is something wrong because it does not recognise certain things

12:42 <ctismer> mattip: the same with other errors where PyPy did not understand, like the `ob_dict` problem. This finding removed over 50 errors.

12:42 <ctismer> mattip: there is one such thing still, which I do not know.

12:45 <ctismer> mattip: I am currently investigating `sources//pyside6/tests/pysidetest/homonymoussignalandmethod_test.py`

12:46 <ctismer> mattip: weird behavior with multiple inheritance, where internal flags don't get set. I guess that is related. Seeking since last Thursday

14:33 <ctismer> mattip: This bug seems to be access to uninitialized memory, that can result in a crash or not, whatever happens to be there in memory. Should do a debug build

14:34 <mattip> PyPy is not initializing the memory and CPython is initializing the memory?

14:34 <mattip> which memory?

14:38 <ctismer> mattip: nooo, we are falsely accessing something that CPython handles correctly, while PyPy does not understand and does not initialize, somehow. It is hard to argue logically, because PyPy's logic is not completely defined for me.