#pyqtgraph
1 messages · Page 5 of 1
the duration for dropping python is 6 months shorter than before. Since NEP-29 was released, Python has gone to a more scheduled release cadence, doesn't surprise me that they'd shorten the duration for supporting versions of python.
Anything you want to see in the next release? (that's not currently in master)
There's a parameter tree warning on the tests
Something about default values
And the deprecation supposedly expires on 2025
There's a trivial parameter bug identified in #3229
#2994
yeah those warnings have been annoying me, but if Nathan has a newborn at home, probably won't get to see him much for a while...
something so rewarding about deleting python 2 style print statements
your screenshot in that point cloud discussion pijyoi reminds me of those old desktop linux systems that you could assign a virtual desktop to each side of the cube, and rotate the cube and get that fancy animation.
yes I remember those days when frivolous special effects were the rage
Wobbly desktop
The 0.13.7 GLScatterPlotItem was half shader half fixed pipeline
Don't think you could find tutorials that demonstrated such a usage
were the rage
pretty sure they still are 😄
I'm trying to write a test to catch the bug in #3229... and while I can see the change the poster makes is indeed the correct one, as it works in their example, I can't get my test code to fail (before I submit the fix)
oh huh, behavior is different for int vs str, for my test suite I was using a str which was passing but when I switched to an int then it blew up ...
Hmm, #3263 opengl question was asked on stackoverflow first. That's the 2nd pyqtgraph opengl question asked in 2 months on stackoverflow first
not to say that people jump right away when new issues are opened, but years back, SO had a lot more activity with regards to getting help with pyqtgraph vs. the issue tracker.
on one hand, I have no idea how DateAxisItem works, on the other, this PR, adding more functionality to it, looks pretty good 😂
@wide prism you've looked at AxisItem more than anyone else recently, feel like looking this PR over?
Potentially, distro builds of PySide6 could suffer the same issue as #3265
ugh ...ugh...
@twin spire not sure you're around these parts, but a significant memory leak was reported affecting pyside, and @fervent vale tracked it down to here: https://code.qt.io/cgit/pyside/pyside-setup.git/tree/sources/pyside6/PySide6/glue/qtcore.cpp#n825
Here's a link to the issue and the identification of the problematic area: https://github.com/pyqtgraph/pyqtgraph/issues/3265#issuecomment-2689480190
Probably doesn't affect many people. Just don't get a memoryview on QByteArray
But official builds of PySide are always using the Limited Api, so that even further narrows down the number of people affected
So this does turn out to be true
I think PySide2 probably defaults to non-limited-api build. Qt builds it so that a single binary can be used across multiple Python versions
back to pyside2 deprecation, forgot pyside2 was available on conda forge with python 3.11 ... we should support that...
Hmm. ArchLinux PySide 6.8.2.1 suffers from the leak too. So in all likelihood, distros would build with non-limited api as they are targeting only one Python version
Unless the leak gets fixed by Qt company, we may have to use the workaround for both PySide2 and PySide6
I got interested in this limited api thing, and there are quite a few places in PySide where conditional compilation takes place depending on whether limited api is in use
I must admit I am curious what the intent is.. ...
that said, if pyqt6 is ever made available on conda-forge, this is the qt feedstock that will be used: https://github.com/conda-forge/qt-main-feedstock
The leak isn't with Qt, it's with PySide
Just tested out OpenSUSE tumbleweed
No leak.
Fedora 40 doesn't have PySide6 packages.
In the beginning there wasn't such a thing as limited api. Every python extension needed to be compiled separately for each version of python they wanted to support
Then Python defined a limited api to guarantee forwards abi compatibility
ahhhh
So extension authors would only need to produce 1 binary extension that would work for all supported python versions, including future versions
However, for big extensions like PySide, the api provided by the limited api was not sufficient for their needs
So under the hood some shenanigans need to be done
Now the question is why PySide provides 2 compilation paths? Surely one of them is going to suffer bit-rot
From what I gather, FreeCAD has some issues with PySide6 compiled with limited api
So conda and distros then decide to compile PySide6 with non-limited api in order to satisfy FreeCAD
I’m a wee bit surprised that pyside is using the python limited API. With cibuildwheel I would have thought it wouldn’t be that much work to release wheels for each version of python
The binaries are huge. Building just one copy for all supported python versions makes a lot of sense
But to be clear, it's not the limited api or non-limited api that is directly causing the issue.
Qt might not be motivated to fix the bug since the bug won't trigger on their binaries
The bug is present in all the distros providing PySide2 5.15.x where x >= 3
Because compiling for limited api for PySide2 is opt-in
Whereas it is opt-out for PySide6
Yea…
@mortal grotto hey, so I'm patching up the warning for missing default value when value is set that Parameter is emitting all over the place. I do have a question about the potential implementation. If I don't pass a value but do pass a default, is it expected that the value is automatically set to what is specified in default ?
what is working is you specify a default and you can override that with passing in value, but when you don't pass value I would anticipate the default values to automatically apply, but that's not happening.
A more concrete example:
# I would anticipate this parameter to have no items checked by default
p = pt.Parameter.create(name='checklist', type='checklist', limits=[1, 2, 3], default=[])
# but that's not true, 1, 2, and 3 are checked
this does work
# I would anticipate this parameter to have no items checked
p = pt.Parameter.create(name='checklist', type='checklist', limits=[1, 2, 3], default=[1, 2, 3], value=[])
# and indeed, no items are checked
offending lines; REALLY don't think that limits should be enabled by default, and definitely not at the expense of setting a default value
pyqtgraph/parametertree/parameterTypes/checklist.py lines 165 to 167
limits = opts.setdefault('limits', [])
self.forward, self.reverse = ListParameter.mapping(limits)
value = opts.setdefault('value', limits)```
alright, gonna call it a night, something is still up w/ interactive.py, it's creating parameters with value in **opts but no default so it's blowing up on me...
I think it was Martin that added the concept of a "default" value.
@obsidian sapphire ☝️
<@&831776746206265384> 👆(not sure what’s going on here)
Voice gate?
you need 50 messages on the server before you can unmute in a voice channel. People try to get around that by spamming nonsense
Ahhhh
which just earns them a temporary voice ban 🤷♂️
Ok that explains so much
why voice
Just succeeded in implementing "hello teapot" with QRhiWidget
The pain/difficulty was absorbed during the transition from fixed pipeline opengl to shaders
The concepts in QRhi are quite the same once you have been weaned off the fixed pipeline
while I'm good w/ moving Qt6 support to Qt 6.7 before too long, killing off Qt5 support is going to be a tougher sell.
I won't lie, being able to migrate to QRhiWidget so we don't have to worry about the particularities of opengl specifics on each platform would be REALLY nice
suppose we could hide hardware acceleration behind qt6 6.7+
It only works for GLViewWidget. It wouldn't work for QOpenGLWidget in QGraphicsView.
yeah, wonder what that's about...
also looks like the spike was exclusively python 3.11 (and on linux)
Actually Qt 5.15 is eol in the end of May
oh...huh...that's ...that's going to force us to make an interesting decision
Plus PyQt6 doesn't have bindings for QRhi
In GLGraphicsItem, you will see that all 3 pre-defined GLOptions have CULL FACE set to false. It would make sense for opaque to have cull face set to True
At least for rendering solid meshes
However if you set it to True and then run GLSurfacePlot example, it demonstrates clearly that pyqtgraph has clockwise polygons
oh right, ... Phil doesn't want to add anything in development preview
saw this a while ago but couldn't remember where; asked the folks at Napari where it was and they kindly linked me to it: https://czaki.github.io/blog/2024/09/16/preventing-segfaults-in-test-suite-that-has-qt-tests/
Our test suite is quite stable now, but still lots of good info here.
PySide6-Addons needs to be installed in order to get the qsb utility needed for compilation of the shaders
I’ll give it a go on macOS in a bit
i'm a n00b w/ make files..
qrhi-experiments ❯ make all
Makefile:4: *** missing separator. Stop.
ahh, had to replace the space indentations w/ tabs
wait, how am i supposed to use the make file?
Sorted it out!
Hmm, I had whipped up the Makefile on Windows, but had forgotten that nmake is incompatible with gmake
So it's been 6 years since a proof of concept QRhi backend for QPainter had been made
But not published or not ready for prime time
Yeah seems like this has been a long time coming
Hopefully it will exit technical preview sometime soon so pyqt will include it
I think it is out of technical preview. Just that Qt reserves the right to break the API
I added an example (on a working branch) that demonstrates the use of compute shaders for image rescaling. Basically, the image data only gets uploaded once and all rescaled data reside on the GPU where it gets displayed directly.
It is faster and more responsive than what can be achieved with pyqtgraph’s ImageItem
The use of cupy still requires a gpu-to-cpu round trip
So far it works on the OpenGL backend but fails really badly with DirectX on the same laptop. Bad as in possible to make the system unusable.
Gotta try on other computers to see if it’s just my AMD laptop’s problem
the image-viewer worked on my apple laptop
The compute shader one is under a branch called "imageview"
Under a directory called "image-rescale"
It makes use of a pg.HistogramLutWidget
I’ll give it a go in a few hours.
thanks for making the makefile work on not-windows 😄
(have a few minutes this morning, will test now)
segfault
qrhi-experiments ❯ python main.py
initialize
MSL shader compilation failed: program_source:22:27: error: C-style cast from 'const device void *' to 'const constant buf *' converts between mismatching address spaces
constant auto& _60 = *(constant buf*)spvBufferAliasSet0Binding0;
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
zsh: segmentation fault python main.py
There's also a HLSL compilation error
So far it only works on my Windows amd gpu laptop when forced to use OpenGL backend
I got a black screen on a Linux intel gpu system
Got a segfault on my RPI5
I have a PyOpenGL compute shader version and it works on all the systems mentioned above
So I tested on 3 Windows systems: Nvidia, Amd, Intel. QRhiWidget compute shader works with OpenGL backend
The non-compute shaders work with DirectX, OpenGL and Vulkan
It seems like the transpilation from GLSL shader to the other backends is not such a battle-tested path?
maybe, hard to say, ... I mean QRhi's whole thing is to work w/ different backends, so I don't feel like this is some niche edge case that slipped through the cracks.
I got it working on Linux (opengl) and Windows (opengl) including the RPI5. HLSL still doesn't work but at least it no longer messes up the display
It's now on the main branch
Okay it's now working for both HLSL and OpenGL. So it should work for Metal
There are now 2 versions of the ImageRescaleRhiWidget
One using compute shaders and the other not.
For such a simple operation, there's no need for a compute shader
In fact, the version using compute shader uses double the memory
I’ll give them a try in a few hours
would you look at that!
image-rescale-compute works too
is there a large-ish example file you like working w/ for trimesh loads? was going to test something with a lot of points
There's a --size argument to image-rescale program. The largest texture size supported for nvidia was 16384.
That's where I got a really large mesh file
But my standard test file is the Utah teapot model
I think you need to zoom out for the skeleton
The default calculated view distance clips away a lot
loaded the skeleton in STL format, wow...this is fast/smooth
viewing via a touchpad ...doesn't feel right but then again navigating a 3d space w/ the touchpad would feel awkward in the best of circumstances
man, this parameter tests with value is specified, but default is not present is killing me ... been chipping away at these for a while but ...so many places.
who merged this default/value for parametertrees without ensuring there were no warnings 😛
ok, took a while but I got to the underlying bit of code that was making everything fail ... but now have a weird error:
================================================================================================================================== FAILURES ===================================================================================================================================
_____________________________________________________________________________________________________________________________ test_export_dialog ______________________________________________________________________________________________________________________________
tests/exporters/test_exporter_dialog.py:9: Failure: Qt messages with level WARNING or above emitted
---------------------------------------------------------------------------------------------------------------------------- Captured Qt messages -----------------------------------------------------------------------------------------------------------------------------
QtWarningMsg: The cached device pixel ratio value was stale on window expose. Please file a QTBUG which explains how to reproduce.
should be noted that I made Qt warnings be errors:
qt_log_level_fail = WARNING
doesn't fail in CI tho so I guess that's good...
I don't understand the rationale for requiring default to be set if value is set
#2954 indicates that "value" is more or less required to be set
The changes in your PR have converted "value" to "default"
Is the new syntax such that users will now specify "limits" and "default" instead of "limits" and "value"?
Because this would be yet another breaking syntax change?
I didn't merge because I wanted to have a think on this when I wasn't tired; but I think I need to review why that deprecation got introduced to begin with
@obsidian sapphire you around? Would love to discuss the parameter default vs. value attribute and the motivation behind not supporting the use of value absent default attribute.
One issue is that the deprecation warning does not show up when normal users run their code
So users get caught by surprise when the deprecation expires and becomes an error
A few users were caught by the "values" to "limits" change and had to be pointed to #2954
on further reflection, I don't like requiring default is you specify value, ...seems like it makes enough sense if a default value is not specified, that the default should be set to whatever the value that is passed into is (like the current behavior) ... not sure why that needs to be removed.
Prior to this PR, “default”, if not provided, would just take on “value”. This logic meant that “default” ended up being always considered to be provided. The PR seems to want to remove that side effect.
But if “default” becomes a required argument, that’s going to break existing use. A lot of busy work just to add “default” to all existing code.
Yeah I agree
Alright, chatted with @mortal grotto (sorry for the ping). We are all in agreement, this deprecation is more trouble than it’s worth. I’ll scrap my PR and make a new one that doesn’t try and change everything and instead sets the default based on the value
Going to sneak a few more PRs in and then cut a release, want to get to the bottom of #3226 (fix regression to GraphicsLayout.removeItem()
if @mortal grotto could spare some time for #3203 that would be great 😄 (but I'm not on the verge of doing a release do not urgent)
I'll do my darndest; it's a fair ask
should we close pyqtgraph/pyqtgraph#3233 ?
Ok I have closed it
so I know pyqtgraph/pyqtgraph#2883 is a year and a half old, but you think it's still worth merging?
(I'm in a mood to get the PR count down, being over 50 for a while was causing too much anxiety)
@mortal grotto know I'm nagging you on a big PR already, but if you have 2-3 minutes, mind glancing at the diff of pyqtgraph/pyqtgraph#3288 ? (change to slider parameteritem, adds a lot of conditionals) ...thinking that's a lot of conditionals in that if statement and wondering if there is a better check we could make.
pyqtgraph/pyqtgraph#3288
@fervent vale I know this PR you made (and we merged) is over a year old, but would you say #2944 superseeds/addresses the issue that #2881 was intended to fix?
oh, I should probably get #2614 fixed and then merged before the next release 😬
Yes it does
eh, almost got done cleaning up the ASV PR, but still some lingering issues...
for some reason numba acceleration isn't running:
============== ============== ============ ========= ========== ============ ============ ============
-- lut_length
--------------------------------------------------------------- --------------------------------------
size acceleration use_levels dtype channels uint8 uint16 None
============== ============== ============ ========= ========== ============ ============ ============
...
(4096, 4096) numba True uint8 1 n/a n/a n/a
(4096, 4096) numba True uint8 3 n/a n/a n/a
(4096, 4096) numba True uint16 1 n/a n/a n/a
(4096, 4096) numba True uint16 3 n/a n/a n/a
(4096, 4096) numba True float32 1 n/a n/a n/a
(4096, 4096) numba True float32 3 n/a n/a n/a
(4096, 4096) numba False uint8 1 n/a n/a n/a
(4096, 4096) numba False uint8 3 n/a n/a n/a
(4096, 4096) numba False uint16 1 n/a n/a n/a
(4096, 4096) numba False uint16 3 n/a n/a n/a
(4096, 4096) numba False float32 1 n/a n/a n/a
(4096, 4096) numba False float32 3 n/a n/a n/a
...
Latest numba only supports numpy 2.1.x
your ears must have been burning, this was on my screen not 5 seconds earlier
ok, so I should setup different environments for numba vs. non-numba ....
...or I could just use the older version of numpy
huh, wish I understood why, but the latest numpy keeps being installed....even though I don't specify numpy at all (and pyqtgraph just has the minimal version specified)
The minimal version bound only specifies what version below which you do not support
https://asv.readthedocs.io/en/stable/asv.conf.json.html#matrix
The keys of the "req" are the names of dependencies, and the values are lists of versions (as strings) of that dependency. An empty string means the “latest” version of that dependency available on PyPI. Value of null means the package will not be installed.
I'm even specifying numpy 2.1 here, and it's still installing 2.2...
PS C:\Users\ogi\Developer\pyqtgraph> .\.asv\env\f805a76c1f0b2fa61d39fb029488cfae\scripts/activate
(f805a76c1f0b2fa61d39fb029488cfae) PS C:\Users\ogi\Developer\pyqtgraph> pip list
Package Version
------------------ -----------
asv_runner 0.2.1
build 1.2.2.post1
colorama 0.4.6
cupy-cuda12x 13.4.1
fastrlock 0.8.3
importlib_metadata 8.6.1
llvmlite 0.44.0
numba 0.61.0
numpy 2.2.4
packaging 24.2
pip 25.0.1
Pympler 1.1
pyproject_hooks 1.2.0
PyQt5 5.15.11
PyQt5-Qt5 5.15.2
PyQt5_sip 12.17.0
PyQt6 6.8.1
PyQt6-Qt6 6.8.2
PyQt6_sip 13.10.0
pyqtgraph 0.14.0.dev0
PySide6_Essentials 6.8.2.1
pywin32 310
setuptools 78.1.0
shiboken6 6.8.2.1
wheel 0.45.1
zipp 3.21.0
the config file json looks like
"matrix": {
"env_nobuild": {
"PYQTGRAPH_QT_LIB": [
"PySide6",
"PyQt5",
"PyQt6"
]
},
"req": {
"pyqt6": [
""
],
"pyqt5": [
""
],
"PySide6-Essentials": [
""
],
"numba": [
""
],
"numpy": [
"2.1"
],
"cupy-cuda12x": [
""
]
}
},
"include": [
{
"python": "3.10",
"req": {
"pyside2": [
""
],
"numba": [
""
],
"numpy": [
"2.1"
]
},
"env_nobuild": {
"PYQTGRAPH_QT_LIB": [
"PySide2"
]
}
}
],
There's an ImageView example using numba in #1512. If you bump up the size to 8192x8192, on a fast system it's still smooth without numba. Provided you have numpy >= 2.1. That's the version with the clip improvement
If you go up to 16384x16384, you can feel the lag
That's where the QRhi image-rescale example is still smooth
"must go even bigger!"
16384 is the largest supported texture dimension
ha!
That's already 1GB of memory
ok, think I got numpy to not install the latest version, issue was w/ pyqtgraph specifying numpy as a dependency in setup.py; numba was installed beforehand so there was no check for numba compatibility with numpy. ... so installing pyqtgraph with --no-deps seems to work.
channels / lut_length
size acceleration use_levels dtype 1 / uint8 1 / uint16 1 / None 3 / None
============== ============== ============ ========= ============ ============= ============= ============
(4096, 4096) numpy True uint8 206±5μs 207±5μs 176±0.9μs 65.4±0.9ms
(4096, 4096) numpy True uint16 21.8±0.2ms 41.2±0.8ms 21.6±0.2ms 66.6±0.7ms
(4096, 4096) numpy True float32 23.5±2ms 66.9±0.8ms 22.8±0.2ms 67.3±0.4ms
(4096, 4096) numpy False uint8 191±3μs 192±2μs 73.5±1μs 71.8±1μs
(4096, 4096) numpy False uint16 22.2±0.2ms 41.5±1ms 70.5±0.1μs 67.9±0.8ms
(4096, 4096) numba True uint8 199±3μs 200±4μs 173±2μs 32.8±1ms
(4096, 4096) numba True uint16 11.2±0.3ms 18.4±0.4ms 10.3±0.2ms 31.7±0.4ms
(4096, 4096) numba True float32 10.9±0.7ms 25.3±0.4ms 9.32±0.3ms 29.0±0.3ms
(4096, 4096) numba False uint8 n/a 190±2μs n/a n/a
(4096, 4096) numba False uint16 10.8±0.2ms 17.5±0.2ms n/a 31.3±0.3ms
(4096, 4096) cupy True uint8 4.81±0.2ms 4.61±0.04ms 4.49±0.09ms 14.4±0.5ms
(4096, 4096) cupy True uint16 5.52±0.2ms 16.3±0.5ms 5.72±0.07ms 15.3±0.8ms
(4096, 4096) cupy True float32 5.77±0.2ms 16.8±0.8ms 5.38±0.1ms 15.4±0.5ms
(4096, 4096) cupy False uint8 n/a 4.61±0.1ms n/a n/a
(4096, 4096) cupy False uint16 5.40±0.4ms 14.8±0.6ms n/a 13.9±0.3ms
this is ... not sure which Qt bindings this is for... one of them...point is it's running
you think we should up the sizes to 8192x8192 ?
ok, updated the PR, works on windows, need to test on macOS and make sure it doesn't blow up there. Very open to using changing what the benchmark is testing if you think that would be worthwhile
Probably not worth going beyond 4096x4096
hmm...asv config needs a litlte mroe tweaking, or docs update, it blows up w/ my pyenv setup
:incoming_envelope: :ok_hand: applied timeout to @flat sphinx until <t:1743073770:f> (10 minutes) (reason: emoji spam - sent 21 emojis).
The <@&831776746206265384> have been alerted for review.
ok, pyside2 is just being too annoying in the config, going to ditch it...
<@&831776746206265384> OP got a 10 minute timeout, consider a longer ban for spam? 👆
!pban 693228208367337525 spam
:incoming_envelope: :ok_hand: applied ban to @flat sphinx permanently.

thank you 🙏
realized that the benchmark suite didn't test 4-channel Images ... given how long this thing is taking to run, I'm wondering if I should not bothering running the test across all the supported versions of python, just the current version perhaps...
or perhaps just oldest/newest supported versions...
need to look at this more closely, but wonder why 3 channels is so much slower than 1 or 4 channels for dtype=uint16 and use_levels=False
Most of the 3 and 4 channel paths fallback to makeARGB
On closer look, the code enters functions_qimage.py lines 183 to 189
It could be speeded up by special-casing uint16 RGB at lines 143 to 151
You could convert it to a RGBA64 format instead by adding an alpha channel
Then no rescaling needs to be done
But this could just as well have been done externally by the user
But real live 16-bit data doesn't usually come pre-scaled to the full 16-bit dynamic range
So it ends up that uint16 + levels=None combination is not such a useful combination
Besides, the display mechanism may just choose to drop the lowest 8 bits prior to display
@proud dagger Your message has been removed for being off topic and for breaking rules 5 and 6. Please refer to both the #rules and #code-of-conduct
I’m thinking this is the right approach. On one hand feels like a waste of memory but the performance improvement I feel is worth it.
I created #3293. You could try running asv on it
My testing shows that changing to RGBX64 format is not faster, slightly slower even
Just got back from a several day trip. Will try and test out tomorrow morning
You have thoughts on what versions of Python we should run asv on? I suppose running on all the supported Python versions that can be found is probably the way to do it
Perhaps uint16 3 channel should just be delegated to makeARGB. It doesn't seem like this is a configuration that can be optimised
running the suite now comparing branches... (will probably take ~20 minutes to run)
I was thinking that perhaps some kind of table/chart/diagram may be warranted to highlight which combinations of inputs can be reidrectly rendered to Qt, and which combinations have cupy and/or numba acceleration.
could do a flow-chart diagram with mermaid... or do a series of tables (say one table for each dtype) ...
on your branch.
Looks faster than the old asv benchmark, but still substantially slower than 1 or 4 channel variants
Curious why asv is showing a 2x improvement but you’re seeing a performance loss
I was using VideoSpeedTest as a benchmark. asv only times the creation of a QImage, it doesn't include the time needed for Qt to display the QImage on screen
Ultimately, Qt would need to scale the 16-bit image for display
ahh right
So the original version that scales it to uint8 makes it easier for Qt to display downstream
alright, might as well close out your PR and I'll merge my ASV PR ...
thanks for entertaining me on that
looking at NonUniformImage, trying to come up w/ a description of x and y values and how they correspond to the colors of Z, ... getting the wording right is tricky! the image here is helping (drew InfiniteLines at each x and y value)
"The correct interpretation is that the provided coords are supposed to be the sampled data points, while the drawn polygons are shaded to the nearest coord's Z value."
yeah, I'll go w/ that sentence vs. the confusing mess that is the ASCII art I'm trying to create
Hi
ugh, this NonUniformImage PR needed more work than I thought... will still wrap it up hopefully in a few days... would like to get a few other PRs merged and then cut the next release.
Agh, finally done! So sorry it took this long 🙈
I'll give the contributor of 3288 the opportunity to make the change themselves, but if they don't in a day or so, I'll make the change for them.
Also those multiple condition if-statements, ... I have a hard time reading those unless they're on different lines. I may change the format even if they update their PR accordingly
my PR to sphinx-contrib/images started getting attention after years of sitting idle ... so yeah hopefully we'll be able to upgrade to a recent version of sphinx soon
(PSA: pyside 6.9.0 was released yesterday in case you want to give it a try 👍 )
Thanks for the heads up!
I don't imagine you all are supporting the free threaded python yet?
(sorry for asking here and not searching in the issue tracker first!)
in the initial betas, we had a working example with a patch by Christian Tismer https://codereview.qt-project.org/c/pyside/pyside-setup/+/459935 , we recently tried it again and there was a regression that sam gross is addressing https://github.com/python/cpython/pull/131989 but we are still working on a proper support
As long as you are fine of using this channel, I'm happy to reply 😛
QtWarningMsg: The cached device pixel ratio value was stale on window expose. Please file a QTBUG which explains how to reproduce.
I've seen this periodically... usually seems to be associated with new versions of macOS that get released
this does happen only on one test, so I'll spend some time trying to reproduce, otherwise our test suite passes on 6.9!
yeah, I have seen that message somewhere :/
the test that blows up is pretty straight forward.. but this is a pattern we use everywhere, so likely not an issue with the test itself, but the underlying dialog.
https://github.com/pyqtgraph/pyqtgraph/blob/master/tests/exporters/test_exporter_dialog.py
also I'm fairly certain this test isn't a new failure, but newly reported failure (as we just added pytest-qt as a dependency which raises these warnings to failed tests)
"...there is a greater-than-zero chance that we might get (RHI backend for QPainter and QWidgets) in the future."
wouldn't that be something!
while pushing a change to NonUnfiromImage PR I'm workign on, I encountered this test failure, only on linux:
=================================== FAILURES ===================================
_________________ testExamples[ MouseSelection.py - PySide2 ] __________________
[gw0] linux -- Python 3.10.16 /opt/hostedtoolcache/Python/3.10.16/x64/bin/python
Traceback (most recent call last):
File "/home/runner/work/pyqtgraph/pyqtgraph/pyqtgraph/Qt/OpenGLHelpers.py", line 109, in initializeGL
if not ctx.isOpenGLES() and ctx.format().version() >= (3, 1):
AttributeError: 'PySide2.QtGui.QOpenGLExtraFunctions' object has no attribute 'isOpenGLES'
Failed MouseSelection Example Test Located in MouseSelection.py
----------------------------- Captured stdout call -----------------------------
MouseSelection
Traceback (most recent call last):
File "/home/runner/work/pyqtgraph/pyqtgraph/pyqtgraph/Qt/OpenGLHelpers.py", line 109, in initializeGL
if not ctx.isOpenGLES() and ctx.format().version() >= (3, 1):
AttributeError: 'PySide2.QtGui.QOpenGLExtraFunctions' object has no attribute 'isOpenGLES'
=========================== short test summary info ============================
FAILED pyqtgraph/examples/test_examples.py::testExamples[ MouseSelection.py - PySide2 ] - Failed:
Traceback (most recent call last):
File "/home/runner/work/pyqtgraph/pyqtgraph/pyqtgraph/Qt/OpenGLHelpers.py", line 109, in initializeGL
if not ctx.isOpenGLES() and ctx.format().version() >= (3, 1):
AttributeError: 'PySide2.QtGui.QOpenGLExtraFunctions' object has no attribute 'isOpenGLES'
Failed MouseSelection Example Test Located in MouseSelection.py
============== 1 failed, 95 passed, 3 skipped in 78.96s (0:01:18) ==============
I should note there is no pyside2 runner on macOS, and this test passes on windows.
Something very wrong has happened for PySide2 to have returned the wrong object type
yeah don't think that's our issue ...curious if you've encountered this before
yeah ... guess we can chalk it up to a cosmic ray particle
not seeing anything different on the debug info sections of each run.. so ...yeah ...not much we can do haha
well, cleaned up all the sphinx warnings, numpydoc warnings/errors .... let's see what the rendered output looks like!
....ewwww
til that enum.Flag is a thing. Nice use of it!
I think it's an anti-pattern to be using 1 VBO per attribute
the documentation ecosystem, combined with type hinting is such a minefield... so many config options create breakages in other stuff ...
I'm trying to get it to the point that if the docstring has no type-annotation for an argument, but there is an annotation in the function signature, that is used instead...
so far, QRhi seems to run best on Windows. D3D, OpenGL and Vulkan all run with no issues on Windows. Running Vulkan on Ubuntu (wayland) ends up with a window with no window decorations
Linux, always the odd one
@rough furnace we started to have our first users confused between the new plot module in Qt, that's replacing Qt Charts, called Qt Graphs, with this project 🙂
Maybe we will include a "dissambiguation" note on the binding's page for the module 😛
Hahahah I saw that Qt Graphs allowed for zoom via the mouse? A huge portion of the value of this project is the ViewBox module we provide, if Qt Graphs provides that, I’ll have to look into what we provide that it doesn’t 😅
I should take a closer look at that Qt Graphs to try and differentiate what it offers (or see if it would be worthwhile to integrate).
By examining the source for Qt Charts we realized how to make “fast” line plots with thick lines (using QPainter::drawLines vs QPainter::drawPath). I should test scatter plot performance of Qt Graphs and see if there is something for us to learn from there for our scatter plots.
QtGraphs is GPL / Commercial only
That too 😅
but it's purely naming coincidence, it's not real "an alternative" though
it never crossed my mind that the name will for sure make people confused 😦
Looked through overview, looks like an extension of Qt Charts (not that I was that familiar with it before).
is pyqtgraph an alternate of matplotlib?
Both are plotting libraries, but matplotlib is generally meant for static plots. They have a huge array of options,m/plot types; pyqtgraph is usually used for interactive applications where plots either need to be updated frequently and/or user updates interaction with the plot is wanted (ability to scroll/zoom). Pyqtgraph doesn’t come close to offering the plot types that matplotlib offers.
:incoming_envelope: :ok_hand: applied timeout to @copper lily until <t:1746461575:f> (10 minutes) (reason: duplicates spam - sent 4 duplicate messages).
The <@&831776746206265384> have been alerted for review.
Hello is it ok if I post a syntax of my visualization here as well as my visualization itself?? I really don't know what pyqtgraph is all about but it seems where visualization can be posted
pyqtgraph is a specific visualization library
Oh I see...noted
f
Seems like PySide 6.9.1 has broken ViewBox in a major way
saw the issue, wondering if ViewBox is doing something really weird, or if this is a legit breakage on PySide's side...
I have an MWE now
Looks like it's been fixed upstream and the fix will be in 6.9.2
Thanks for the MWE pijyoi
6.9.2 is going to be more than 2 months away
🤷♂️ I'm not feeling motivated to introduce more code complexity due to an upstream breakage that has a fix coming, even if its months away.
If it's a big enough of an issue, they may release a 6.9.1.1 (they've done that w/ other releases before)
IMO there's no possible workaround
I remember seeing some commented out itemChanged methods with a comment saying something about it not working on pyside bindings ... can probably find those if you look at a git tag of a release from years back.
<@&831776746206265384> seems pretty suspicious here ^
!cpban 537521207273324566
:incoming_envelope: :ok_hand: applied ban to @devout hinge until <t:1750112661:f> (4 days).
Thanks
Hi all!
Looking at https://github.com/pyqtgraph/pyqtgraph/pull/3318
the tests throw a bunch of errors for the newer Python versions. This looks to be
NumPy 2.3.0 as it may crash. To support both 1.x and 2.x
versions of NumPy, modules must be compiled with NumPy 2.0.
Some module may need to rebuild instead e.g. with 'pybind11>=2.12'.```
Err... Is that something that is known to happen, currently?
The tests that got cancelled due to timeout are due to PySide6 6.9.1
The tests that fail are due to numpy 2.3.0
But not because of the warning shown above
Older versions PySide6 are compiled against numpy 1.x
However, because we do not make use of the portions of PySide6 that accept ndarrays, it doesn't affect us
Hmm. Any run of the tests on a relatively new version (3.11 to 3.13?) of Python fails due to TableWidgetItem doing something that looks like mixing native bools and numpy bools?
And in addition, anything with Pyside on 3.12 and 3.13 times out. Ok, I see that.
Trying to replicate it locally
Thank you! Sorry, I am still at work and only have half an eye on this.
I am just hoping to get an idea what to expect with the tests 🙂
There is some issue with numpy 2.3.0 and the TableWidget example which uses a numpy structured array
If we change it to just a 2d list, the error doesn't get triggered
Or if I remove the _defersort decorator, it also doesn't get triggered
So possibly an issue with numpy 2.3.0
But I don't know if anyone even uses pg.TableWidget
hehe, I guess that may be true. Numpy 2.3.0 is just newly arrived?
Let me admit that I am at this point mostly trying to figure out if #3318 can get merged, or if there is anything to look out for that might be hiding behind the numpy issues.
I am not really expecting anything, since the PR doesn't touch anything numpy OR pyside related...
... but when 2/3 of the tests come back red, I felt it's best to ask what's currently going on 😁
@wide prism feel free to pin pyside6 to 6.9.0 (you'd only have to pin the unpinned version)
For the TableWidget thing, my summary of the issue would be: With numpy 2.3.0, if a structured array is to be used with TableWidget, then all the fields must be of type "object"
structured arrays are annoying to work w/, if a 2D array works just as well, let's do that.
The TableWidget example is actually demonstrating that it can handle structured arrays
‘np.bool’ scalars can no longer be interpreted as an index (deprecated since 1.19)
That’s what is causing pyqtgraph test failures
Okay, if PR3333 gets merged, pipelines will be green again. I have blacklisted PySide6 6.9.1
j9ac9k keeps trying to get me to push the button. So...
Thank you for hunting that down and getting the tests back.
Not sure how I feel about the numpy datatypes (np.floating) leaking into the value field, but the final cast to bool seems like the least invasive solution. 👍
Now somebody please teach me how to write a proper commit subject and info 🫣
For structured types, the numpy scalar types end up in the field
The comparison between numpy scalar types yield a numpy boolean scalar
I looked through the code, and half of TableWidget seems to believe that self.value is a python float, and half of it seems to think it can be whatever it wants.
And somehow PySide and PyQt want to use this numpy boolean as an index
Probably for pikcing / blanking out some subset? That's the only place where I have run into that.
It feels like the dangerous bit is data that was originally in a numpy table spreading the redundant numpy data formats to parts of the code that do not expect them.
But the only alternative I would have seen is to make sure that "value" is always a float, but that certainly would break somebodies existing code.
The TableWidget example really seems to be advertising its ability to accept structured arrays
Not something that I would have expected to work
That seems fine to me, but I am not quite sure why the structured array is so keen to report back np.floating types rather than python float. np.array doesn't do that for the standard types.
If you wanted to express that it was a python float, you would have used "object" as the data type
Hmm. Doesn't the regular numpy array have the same basic problem and works around that?
Actually I have no idea what's really going on. Even if in the structured array you specify an exact size type like float32, int32, it will end up generating np.bool
Whereas a homogeneous array apparently doesn't trigger this issue
I think numpy doesn't love the structured array as much as the regular one. Thank yuo for checking the float32 case, I was JUST wondering if we brought this on ourselves by making the test array "floating" dtype.
Looking at stuff my colleague is doing with it, it seems that the structured array case is mostly in the hands of pandas dataframes now.
Congratulations @wide prism on pushing the button
I think the cleanest solution would be to sanitize input at setData(), but that just seems to leave too many ways how that might get confused and mess up someone's data.
StackOverflow has a magic solution:
https://stackoverflow.com/questions/9452775/converting-numpy-dtypes-to-native-python-types
...and it would still require the bool(...) cast at the exit because some types do not convert, I think.
So your fix remains the best practical solution I can see. Thank you!
Please, feel free to do more of that
Clear statement is very appreciated. 🙇
After some more investigation, the issue does also get triggered by numpy homogeneous arrays, and is not limited to numpy structured arrays
What happens is that pg.TableWidget automatically sorts by the 1st column if the data has a column header. This is true for structured arrays but not homogeneous arrays
For homogeneous arrays, we can subsequently trigger the problem by clicking on one of the row header labels to activate a sort
If you want to try this out, try it with PyQt6. PySide6 has some additional weird behavior. On PySide6, the issue only gets triggered if the sorting was activated programmatically (i.e. calling the method directly). It doesn't get triggered if it got activated by clicking
In either case, np.bool was generated; so it's really weird behavior for PySide6
I wonder if it's pure coincidence that there are 2 new issues raised about OpenGL...
I hope so 😅
I tested conda locally on Windows and Ubuntu. pyqtgraph OpenGL works on Windows but not on Ubuntu. A bit strange that the CI passes.
By OpenGL, I mean the code that makes use of pyopengl. So MouseSelection that uses purely Qt OpenGL works.
Mystery solved! conda builds only come with x11 plugin, no wayland...
Error doesn't appear on CI since it presumably uses x11
way to track that down! I'm wondering if there is something we should do in this regard; like...should we modify the cond build recipe to include the relevant wayland package
https://github.com/conda-forge/pyqtgraph-feedstock/blob/main/recipe/meta.yaml ...not seeing a good place to add that wayland package
It was only 2 years ago that conda gained qt-wayland
Hi
bad news: just tried out PySide6 6.9.2 snapshot and it segfaults on both Windows and Linux on plotting that makes use of QGraphicsView. i.e. OpenGL examples still run
Sometime after the fix for PYSIDE-3115, some other regression has been introduced
Given that PySide6 6.9.2 is going to be released next week or so, we are going to end up with PySide6 >= 6.9.1 unusable with pyqtgraph
Ugh… I’m briefly on the grid but going off the grid again in a few hours. I guess I have something else to look into this next week
After some more testing, 6.9.2 seems to run fine on Python 3.11. It segfaults on Python 3.12 and 3.13. This is true on both Windows and Linux. 6.9.1 and lower did not segfault on Python 3.12 and Python 3.13. (notwithstanding that 6.9.1 was unusable with pyqtgraph)
managed to come up with a pyqtgraph-free MWE https://github.com/pyqtgraph/pyqtgraph/issues/3357
Thanks, when I get back to land I’ll report in the qt bug tracker
@twin spire 👆
Normally wouldn’t tag you Cristian, but I probably won’t be at a computer (where I can write up the bug report) until the release
Yo
oh no worries @rough furnace good that you tagged me !
I can check it out, but the multiple inheritance is always an issue 😢 we do encourage people to have the QObject-related base class first
yeah, we do have a few codes like that, but for mixins, we do have classes with QObject at the end: https://code.qt.io/cgit/pyside/pyside-setup.git/tree/sources/pyside6/tests/pysidetest/mixin_signal_slots_test.py
ah nvm it's fixed: https://codereview.qt-project.org/c/pyside/pyside-setup/+/668587
Looks like your team jumped on it in short order!
I'm hate Qt
why bro
Hello
Ya
In the example above with OpenGL enabled, I am seeing that master branch is slightly more than 10x faster than 0.13.7
(On 0.13.7, you also have to set enableExperimental=True)
That’s awesome you can see such improvement based on your work on OpenGL!
!res
The Resources page on our website contains a list of hand-selected learning resources that we regularly recommend to both beginners and experts.
Does anyone know how to create graphs for state machines using QT or some other graphical interface lib?
Qt did have a state machine module, but I haven’t actually seen it used, and definitely not in the context of pyqtgraph.
There seems to be a 50% loss in performance in QPainter.drawPath in Qt 6.10
That; is not good
Really surprised that there would be a regression here. Graphics view has been remarkably stable for quite a while
The performance loss seems limited to Windows wheels but not Linux wheels. x64 builds anyway.
how did you install the 6.10 preview? I'll check on macos
You can use the invocation used in https://github.com/pyqtgraph/pyqtgraph/blob/master/.github%2Fworkflows%2Fcheck_prereleases.yml
But replace "dev" with "6.10"
for testing, do I need to use the branch you made a PR for?
No need
It's only the enableExperimental qpainter path
You can set the environment variable PYQTGRAPHPROFILE=MonkeyCurveItem.paint
Then run PlotSpeedTest --nsamples=100000 --iterations=10
pytest-qt 4.5.0 drops support for PySide2
Yeah saw that; holding off on merging that change until this next release. This coming release being the last to suppose pyside2
pyqt5 has been well supported, getting updates so and so on; so not too worried about it so much
@rough furnace PySide6 6.10 is out, the blog post with the official announcement will go out tomorrow.
nice
Thanks for the heads up! Congratulations on the release
what's this
.
Read the description of this channel...
strangely, there's a website pyqtgraph dot com
Every now and then, the CI fails at one particular test on Linux PySide2.
Traceback (most recent call last):
File "/home/runner/work/pyqtgraph/pyqtgraph/pyqtgraph/Qt/OpenGLHelpers.py", line 109, in initializeGL
if not ctx.isOpenGLES() and ctx.format().version() >= (3, 1):
AttributeError: 'PySide2.QtGui.QOpenGLExtraFunctions' object has no attribute 'isOpenGLES'
Something very wrong here. "ctx" is supposed to be a QOpenGLContext object but somehow the bindings got confused and thinks it's a QOpenGLExtraFunctions object
Thanks for looking at this. I saw the intermittent failures and thought it was something funky but as we are removing pyside2 support soon I wasn’t too worried about it
Seems like the dot com website above got banned and removed
Yeah, whomever ran that domain operated a bunch of other sites referencing different libraries as well; pretty sure it was some kind of scam operation.
omg the CI is going to be soooo backlogged
besidees boxplot PR, anything eels eyou think should make its way in before I cut the next release?
Don’t think so
I’ll start on the changelog today then
184 merged PRs since the last release 😬
ok, I definitely let this linger way too long
lmao
that's not that bad
You'll be fine, it just means a lot of new features 🙂
Yea it’s a behemoth of a release for sure
alright, done segmenting the changelog into different sections, should probably do a little re-ordering; but that's going to have to wait until after work...
and shipped
@fervent vale this is an amazing release in large part to your efforts, not only overhauling the OpenGL implementation within the library, but providing feedback for other PRs. That really took a major load off of me and I can't thank you enough 🙏
I was convinced I was going to wake up this morning to an avalanche of new issues pointing out some regression 🤣
It's a breaking change for any users who created their own GLGraphicsItem
Also a breaking change for any users that create their own GraphicsObject and call deviceTransform, presumably to create scale invariant items
Not too worried about those folks, if they’re proficient enough to subclass like that they’ll get themselves sorted out soon enough.
Is thick lines (glLineWidth) the only thing requiring legacy OpenGL at this point?
On macOS, yes, because it only has Core Profile. Windows and Linux OpenGL drivers can run with compatibility profile and still have thick lines
I keep wondering if I have too much of a reckless mentality regarding breaking stuff for existing users... I guess I'm of the mindset that I remember when the PR queue was way backlogged and trying to minimize breakages for existing folks caused a significant drain on time (not to mention code complexity) that it was overwhelming ...
Anyway feel free to teell me if you think I'm being too reckless in that regard
The issue is whether all methods are considered public interface and over-ridable by users. Sometimes even member variables are accessed by users
yeah' ... i do want to make better use of "private" methods; ... i think member variables/attributes are fair game to change up unless explicitly documented.
I left the GL_SELECT behind even though it's super deprecated and didn't even work on anything but nvidia drivers
man, how can folks even keep up with what opengl functions work on what drivers...
I tried it on amd, intel and nividia
I guess I have access to all those platforms myself...
Can't remember if it worked on RPI5
There's a OpenGL debug logger that can be enabled. On some drivers (nvidia I think), it warns you whenever an operation is taking a slow emulated path. GL_SELECT was one of them
oh, that's useful
per SPEC-0, we're now numpy 2.0+ and python 3.12+ ... will strip out pyside2 code here as well
bumping up min Qt6 version to 6.6 (open to suggestions if it should be different)
oooo good thought
hmm...debating if I should set it to 6.5 now, or if I should set it to 6.8, assuming we won't be doing a major release in the next 4 months...
eh, set to 6.5 now, can change to 6.8 later
you have opinions on preserving PyQt5 support?
I seem to recall that pypi PySide6 6.5.3 wheel has an issue that makes it not work with pyqtgraph
that sounds familiar, I mean, we can support 6.5.2 I suppose
Probably can keep PyQt5 for now
PySide6 6.10.1 is supposed to support Python 3.14
6.10.1 is supposed to be released today
gonna take me a while to prune some pyside2 stuff so probably won't have a commit ready for another day or so (so hopefully not until after 6.10.1 is out)
Maybe you could do it in 2 steps? First remove PySide2 from the CI without actually deleting any PySide2 code?
yeah that would be the way to do it
waiting on pyside6 6.10.1 before I push my cocmmit bumping up versions of things...
don't know when it happened, but the cards on our docs now suddenly stretch horizontally way more than intended
I really should learn CSS at some point
ok, bumped all the documentation and test dependencies; fixed a handful of documentation issues, just going to hold off on pushing until 6.10.1 is out
Got delayed by 2 days apparently
hmm.... i may just exclude the python3.14/pyside matrix option on CI then
When PySide2 gets dropped, we can remove the code snippets "obj.exec() if hasattr(obj, 'exec') else obj.exec_()"
PyQt5 has "exec()"
looking forward to seeing the diff 😂
but we still can't remove the "obj.position() if hasattr(obj, 'position') else obj.posF()"
eh, between removing those cases, your diff from pyqtgraph/pyqtgraph#3359 that part of the codebase is gonna be so much better
Actually I thought that in the same vein, GraphicsWidget could just remove boundingRect() and shape()
a lot of that code was getting either ancient versions of Qt4 working, or Qt 5.6-5.9 working which were never ...great for us.
since the overridden implementation is the same as the C++ default implementations
ahh yeah may as well delete it then
there was a slight issue though, the ViewBox's boundingRect fudging itself to increase by 1 pixel
that was to make the InfiniteLine not disappear behind the axes
ViewBox.py I swear is the bane of my existance ... it's like there needs to a mountain of ViewBox.py tests and then start trimming that class down... I bet there are so many code paths that are never reached...
so much of that code is so fragile (not to mention absolutely ancient) ... I keep wanting to redo many portions of it but it's so ...finicky that I'm awlays worried I'm going to break something very subtle
it's not clear to me that fudging ViewBox's boundingRect() was the "right" thing to do
oh I'm almost certain it wasn't 😂
I think I saw that certain rects computed in different ways were different because of that fudging
that was while I was doing the glScissor PR
any numpy < 2.0 related code you think we can trim out?
None really
I think the QtTest.QTest.qWait shim can be removed. It got added in some version of PySide6
ooo right
I nuked all my virtual environments; I'll be sure to test it with pyside6 6.5.2
lmao
@fervent vale any idea why CI wouldn't be running on this PR? https://github.com/pyqtgraph/pyqtgraph/pull/3418
oh, i have a typo in my main.yml, probably blew up
sure enough, that was it,, sorry for the noise
oh, that's interesting; doesn't look like the .whl for pyside6 6.5.2 will install on python 3.12
looks like the PyQt6 6.5 wheel installs to 3.12 just fine; so I guess we do have a Qt 6.5 version we can test against...
now to try and get rid of those annoying conda environment setup warnings...
ok, one of those warnings I just can't seem to work around, so I guess we'll just wait until it's patched upstream 🙃
huh, looks like a segfault: https://github.com/pyqtgraph/pyqtgraph/actions/runs/19515149190/job/55864959798 maybe testing pyqt6 6.5 on python 3.13 wasn't a great idea...
ok, I'm getting tired, heading to bed, but I can't replicate that failure on my system with the same python environment
went to a different version of pyqt6-qt6 and got this error:
Traceback (most recent call last):
File "/Library/Frameworks/Python.framework/Versions/3.13/lib/python3.13/site-packages/matplotlib/backends/backend_qt.py", line 266, in eventFilter
if event.type() == QtCore.QEvent.Type.DevicePixelRatioChange:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: type object 'Type' has no attribute 'DevicePixelRatioChange'
________________________________________________________________________________
Exceptions caught in Qt event loop:
will look into this after the kids head off to school
But that's a matplotlib error
Yeah, but they usually support some ancient versions of Qt, and I’m not getting the same error on different OSs.
hmm...getting the same error on linux, probably less of a matplotlib issue but a mismatch of PyQt6/PyQt6-Qt6 versions.... gonna try and go back to 6.5.x versions of both and remove matplotlib and see if that runs
actually, i bet it's a pyqt6 issue, as I'm installing to python 3.13, I'm not sure python 3.13 was available when 6.5.x was released so probably was never tested...
ok will test qt 6.5.x on python 3.12, and test pyqt5 on 3.13...
ugh qt6 6.5 is also hanging on python 3.12 on macOS .... but again, can't reproduce locally
I think a possible issue is that PyQt6-sip works across multiple versions of PyQt6
oh good call, yeah should probably look into downgrading to whatever the version was at the time qt6 6.5 was released
However that's not something that users do. You would at most specify the versions for PyQt6 and PyQt6-Qt6
it's not, but I don't think users would pip install pyqt6==6.5.2 at this point; the case I want to capture is where they have PyQt 6.5 from a linux package manager or something like that
hmm...even specifying older sip it's still hanging ...
The QEvent class is the base class of all event classes. Event objects contain event parameters.
DevicePixelRatioChange is since Qt 6.6
that's not the issue (I mean it is an issue when I have PyQt6==6.5.2 and PyQt6-Qt6=6.6.x)
gonna try a few other things but I'm getting close to just testing 6.6+ at this point
blerg, I can't get PyQt6 6.5.x to run reliably in CI across platforms... gonna set it to 6.6+ for now.
I probably should add a CI job that tries to use the apt-packages of pyqt6, but that's a future me task
hmm..ubuntu 24.04's python3-numpy apt package is 1.26 :/
SPEC-0 doesn't care about distro packages
yeah; question now is if I care enough about them or not 😂
strange, mybinder mouse zoom and pan no longer works
uh-oh!
not sure when that happened
hmm... looks like in jupyter_rfb in recent versions they did edit some of the mouse events
trying out a manual bisect
man, I'm really bike-shedding right now; debating if I want to test pyqt6 6.5 and just exclude the test on macOS, just test 6.6 across the board...
or since 6.5 support is going away so soon (4 months) should I just move up to 6.8+ ?
alright, going to 6.8+ ...feels like an aggressive bump, but if someone is downloading new versions of pyqtgraph, they can download a relatively newish version of its dependencies... if they need an older version that's what 5.15 is for...
😅
PySide6 is nowadays a rolling release
There isn't really a notion of "LTS" for open source users
yeah, ... still would be nice to have a deprecation policy that is a bit more clear that isn't just "current release" (as often we have breakages there too 😂 ) not sure what the right balance there is. I certainly don't want to try and support versions that are old enough that they're annoying to install in CI
Right now, I wouldn't purposely install any Qt6 version lower than 6.8
only reason I could think of being in that situation is if I had an existing application and have Qt constriants outside of pyqtgraph
Pyqtgraph doesn't really have hard Qt version requirements
Nor numpy version either
So you could mostly get away with pip --no-deps
just realized we no longer have distutils; so have to rework the asv configuration command
looks like pyside6-essentials 6.10.1 is out
if i can't do a quick fix to the asv command/setup.py thing I'll just update the PR w/o that change and merge to get going and figure out what to do about asv later...
okay, the mybinder pan/zoom issue is due to https://github.com/pyqtgraph/pyqtgraph/issues/3419
how convinient an issue was made!
well, that PR came quick; ...question now is should I merge this and cut 0.14.1 ?
Nothing to cut. It’s just to make the mybinder badge work
ahh right
Users who run Jupyter notebook locally have to apply the workaround on their own
If I understood what was happening, the QApplication and the PlotWidget are being instantiated by 2 different threads
ooof...
So the suggested workaround of signaling the main thread doesn’t apply
whew, I can replace distutils.core.Command with setuptools.Command 😅 not that I'm a bit fan of that mechanism
got rid of so much stuff that hasn't worked in god knows how long....
oh whoops I broke something
huh, and now all of the sudden I can't download the mesa drivers for windows; claiming not a valid archive ...
looks to be intermittent ...some windows jobs are passing... anyway I'll switch to a newer version of the drivers, why not, I'm updating everything else
finally got rid of that stupid conda warning...
ok, i'm making an environment variable with the URL to the mesa drivers, tha'ts like the 3rd time I've updated them for pip or conda, but not the other...
If you have some time pijyoi,, take a look at pyqtgraph/pyqtgraph#2777 I think that one would be a good one to merge; drawing lots of separate lines seems to have triggered some performance issues before; ...PR is pretty old at this point so I'll likely need to resolve merge conflicts but curious what you think of the diff.
#2777 refers to #1039
And #1039 says something about slowness for interactive use
Maybe the updated OpenGL would help here
That PR needs a MWE that demonstrates the slowness
Fair enough!
Looking at #2777, it is implementing a use-case where all the curves share the same x-values. It doesn't seem like it would be useful for such a scenario to involve so many curves. They would just plot over and obscure one another.
Also would either require lots of modifications to the OpenGL path, OR fallback to CPU when such input is provided
But a clarifying example of the intended use-case of this PR would be helpful
Was hoping to prune through more PRs today but my day is packed.
I’m really reluctant to merge stuff requiring big changes to OpenGL code paths, you just got those in great shape
I added two runnable examples to #1039. It seems usable to me with the current version of pyqtgraph.
There were some timings added by you that timed the addition of curves to the plot at ~16 secs. I got ~230ms without doing anything particularly special.
There was a comment that "addItem" was the culprit in making it slow and a trick was to add the curves to a group first. I didn't do that and things just worked fine anyway.
Between the 2 extremes of 1 PlotCurveItem for everything vs 1000 PlotCurveItems, one could group the plots by unique color. So if you only have 10 unique colors, you only need 10 PlotCurveItem and you would get snappy performance
Grouping by color is a good idea, we do that in pcmi too right?
Or maybe I’m thinking of scatterplotitem
yes it's done in the cpu path for pcmi, but it's still quite slow
For scatterplotitem, it's beneficial to share QBrushes as the id is part of the hash to determine symbol uniqueness
oh man, reaeding through the diff of pyqtgraph/pyqtgraph#3423 just brings a smile to my face. ... so many workarounds being removed... it's ...it's wonderful
It does demonstrate that there isn't a need to hard kill PySide2 yet
i'm just not sure who continued pyside2 support would be for at this point... I can see having an alternative for LGPL licensing, but pyside6 has been a thing for quite some time now... suppose pyside2 + conda still provides a path to install on python 3.12+
To be clear, there's no support for it going forward
I don't like the gray zone of "we don't support it, but if you use it thing should work so we're going to leave a bunch of code in-place so things may be still work for you"
that said, we did just remove support so suppose there's no harm in having a "wind down period" to give the straggling users more time to migrate over
Removing exec_() will be the nail in the coffin
I sort of like what GDAL does when they're considering removing support for something; ...
they raise the equivalent of a NotImplementedError but in the message they say "We're planning on removing support for this, if you need this working set <whatever> environment variable and rerun to bypass this error, open an issue if you need continued support for this feature moving forward".
Won’t lie, I laughted when I saw you remove ActionGroup from the dictionary file
Did I do something wrong?
I found a bug in the hidpi enablement code for Qt5 5.15. The lines previously used for Qt5 5.12-5.13 should also be set for Qt 5.15. Previously, icons would look blurry when run on PyQt5 on a hidpi screen. This includes the "Auto" button and also the invisible eye icon in Legend. The effect is more striking with the invisible eye icon.
you think you're done w/ that branch or are there more changes you plan to make?
It's done
Found a crashing bug that goes all the way back to 1 year ago. #3179
Run parametertree example. Expand until ColorMapButton gets used
Call of drawText is missing one parameter
How did that get missed?
It crashes on PyQt 5,6 but not on PySide6
Haven't used pyqtgraph in at least 5 years... Good to know it's still being maintained!
Saw the PR, I’ll merge tonight
Yup! Still getting work done!
There's a regression with PySide6 6.10.1. The ColorMapMenu will not change colormap after a menu selection
<@&831776746206265384> ☝️
!cleanban @quiet veldt scam
:incoming_envelope: :ok_hand: applied ban to @quiet veldt permanently.
Hey @rough furnace I hope you are doing fine 🙂
We got a question in the telegram group for Qt for Python:
Hi everyone. I have a pyside6 app for signal processing with interactive plots using pyqtgraph.
On windows there is no problem at all.
But on ubuntu, it can not show the plots that have too many points , like 60000 points in a plot, or even more.
Can I do something to solve it or it is what it is?
Not sure if the user will arrive here, but I recommended him to join this channel
Huh, we have no known major difference in performance across platforms that I know of… hopefully they’ll come here
A known scenario where the above happens: using version < 0.14.0 and useOpenGL but not enableExperimental
Oh right, that awkward combination of config options would cause … issues
TIL about Python “developer mode” https://docs.python.org/3/library/devmode.html
Anaconda now bundles PySide6 6.9.2 and PyQt5 5.15. Looks like PySide6 will become the defacto binding
Is that on defaults or conda-forge ?
Defaults I suppose. It's what comes included in the base installer without further creating any environment
Defaults is of little concern to me, almost everyone I know that uses conda is dependent on conda-forge, we don’t even use defaults in our CI.
Some places/corporations walled off from the Internet provide an Anaconda installation. That provides quite enough to do something useful.
Offhand, there's Spyder, scipy, matplotlib, h5py, ipython, jupyter, numba bundled.
So even if you aren't allowed to install anything else, you can still do something
Since anaconda inc. Started charging money to use the defaults most OSS folks that work in the conda ecosystem stopped messing with defaults and just use miniforge (conda but with defaults channel replaced with conda-forge)
that said, there is the whole Anaconda distribution (naming is so confusing!) which does include those packages; ...was pyqtgraph ever included in that?
Right, by "base installer", I was referring to the Anaconda distribution. It does not include pyqtgraph.
But it includes many of the scientific packages
yeah; the conda ecosystem is a bit of a mess as it targets some very different groups; in geospatial, we're tethered to conda, but despise what Anaconda Inc. has done w/ the defaults channel ; so we all use miniforge with conda-forge channel exclusively . I forgot there was a whole Anaconda distribution with a whole built-in library; but yeah that's definitely geared more towards their enterprise customer base.
I've tried to get updated versions of pyqtgraph into the defaults branch before; nobody from Anaconda Inc. seem'd to be interested in picking up new releases, so I left it alone and to their own schedule; I know they modify the code in some of the packages to ensure stuff works... but I'm really not feeling inclined to put extra effort into making sure the latest pyqtgraph works w/ the current Anaconda distribution.
I mean, I won't go out of my way so it doesn't work... but tough to know ahead of time what their decisions are regarding bundling Qt (for a long time they didn't upgrade for anything newer than PyQt 5.9, I even asked the matplotlib dev to lobby them to bump that up). Maybe I'm still a little bitter.
I think a few years ago, they were the ones able to bundle numpy and scipy linked against MKL
yup! I remember when that happened, I was in grad school at the time; and using Miniconda with numpy+mkl was the latest hotness 😂
Except that MKL defaults to using up all cpu cores
So I found that even an array copy using numpy was invoking MKL
Causing extremely heavy system load
I haven't tracked that so much recently; is that still an issue?
I guess I was under the impression that the SIMD optimizations sort of made MKL fall out of favor ...but admittedly I don't know how any of that low level stuff works
I have the impression that is still the default
For me, the number crunching is not in python. Python is used for visualisation. I certainly do not want the UI to be chewing cpu cycles
has the opengl stuff helped w/ your work?
The issue is that MKL uses openmp and keeps its thread pool "warm" by spinning the cpu threads for a short while in the hope that another job will be scheduled soon
So the default behaviour is that all cpus get occupied without the program running any faster than a single threaded program
Not so much
I can see being annoyed when doing a numpy operations freezes your GUI even for a fraction of a second...
oh it's not that. Just want the UI to be lightweight and not compete with other services
I think they compile the fortran portions of scipy with ifort
my boss said he would sponsor a trip to SciPy for me next summer if I got a pyqtgraph talk accepted (still working on seeing if he would accept a tutorial session) ... probably need to figure out a way to tie some geospatial or point cloud stuff into it tho
wait why is there a channel specifically for pyqtgraph
because we asked for one?
f
There is a CI failure with PyQt6 6.10.2 + PyQt6-Qt6-6.10.2, macOS, OpenGL examples that set OpenGL version to 4.1 Core.
GLGraphItem is the only exception. (it does enable OpenGL 4.1 Core)
The errors disappear if I change the bindings to PyQt6 6.10.2 + PyQt6-Qt6 6.10.1
So chances are that PySide6 6.10.2 (when it releases) will have the same issue
So the “fix” would be to disable the use of glLineWidth?
Probably should hide that call behind an if check for platform and comparability profile … and just disable it on macOS with Qt 6.10.2+
It's not glLineWidth. The failure occurs at the first PyOpenGL call which is glClearColor
i.e. it's not any one call. All calls would fail
#3458 fixes the issue
hello guys would anyone be intersted in heping me develop a simple python script (im very new to coding and i wanna get this script done but im not sure how to)
dm me
Wrong channel
My Qt bug report referenced in #3471 got tagged as P1 critical
@fervent vale
nobody has spoke in here for over a month
Maintainer here, life is a bit upside down for me, my kids and I got evacuated from the Middle East due to the war there. Kid and work duties are consuming all my time 🙁
Someone has volunteered to "review/maintain" the parameter tree portion of pyqtgraph in https://github.com/pyqtgraph/pyqtgraph/pull/3479#issuecomment-4197286733
Oh thanks for the heads up on that one! I’ll take a closer look this weekend
Hey @rough furnace! I've made this channel so we can thrash out some details of this event you'd like to run. Could you let us know who else is in your team, so we can get them in here? 🙂 (cc @rapid kestrel)
Also! We can create a voice channel and you'll have screen sharing permissions for you to use. It's easy for us to create those on the fly.
Yes! The only limitation of Discord VC streams is that they're currently limited to 25 watchers, so depending on the expected size we could always switch over to a youtube stream
hey folks, I'll reply in a bit as I have to get kids to school and such, but the other members AFAIK are not members of this server, but they do have discord accounts, I can provide user-info too.
i doubt the stream will be that interesting, we review PRs 😆
we are all on slack, so I'll get some discord names, I don't have a list handy so they'll trickle in, first one I have is: NilsNemitz#8915
I'll get him onto this server
Nice 😄
(he is in Japan's time-zone, so he may have called it a day already)
Ah that's understandable
last time we did this we had 3-6 people on at any given time; so we're not talking a huge influx of individuals here
Thank you all for your willingness to host us!
No problem! So to get the ball rolling, is the idea that over some weekend you'll all join a vc and do a mini-sprint on the repo?
pretty much; we've only done this once before during SciPy sprints but it worked out so well we wanted to do it quarterly.
What are the logisics on that, is there usually a few hours you say, this is where everyone is joining, or is it more of a 24 hour thing where people drop in and out
During the SciPy sprints we had active members on more or less around the clock (I'm sure we had some hours with zero activity) in time zones with higher levels of activity, we took the opportunity to review some bigger PRs together.
Ah alright cool, I'm just thinking how to market it to our members, the in-discord events calendar has proved very useful for the last few events we ran
so in terms of "new to pyqtgraph" users, we have a handful of "good first issue" topics, we have a contributing.md, and while I don't speak for everyone in the group, but I'm certainly willing to help new members contribute
I think we could have a few events in the calendar, one that marks the start of the sprint, then a few more that mark the planned higher levels of activity
I can be more specific with what libraries/familiarity would be beneficial (openGL, pytest, sphinx, etc)
It may be worth only marketing like a "pyqtgraph intro to contributing" since it'll be visible server wide
there isn't much we have that is good for people new to programming/python in general (I'm sure there probably is something, I'll just have to look, we picked a lot of the low-hanging fruit)
also, some neat features we have built in here is pyqtgraph/pyqtgraph#2002
Yea, that could be good, say the event will be round the clock, maybe suggesting hours that may be higher activity
(automatic issue and pull request linking!)
I believe an admin can also add in a hook to relay certain events from github to here too, depending on how integrated you want things
Yea, I think having a VC where only staff can speak, but anyone can join, and then having this as a voice chat for people to ask questions would work well
Yea, we can add a github hook here, similar to what's in #dev-log
The only limitation is that only 25 people can watch a given stream, so during the active hours there may be a bottleneck
I'll keep that in mind; but I'd be really surprised if there is that level of activity; I mean, the streams would be to go over the diff in something like a PR like this: https://github.com/pyqtgraph/pyqtgraph/pull/1625
That's where I really wish we could have video stage events. I know they are coming, but not fast enough for my liking :P
They created an experiment, so hopefully soon\™
but yea, the only reason I'm concerned is that when we put an event in the calendar, it often gets hundreds of rsvps
It's a pretty heavy attrition rate though
I can elaborate a bit on what skills/experiences would be useful for contributing; and link to relevant issues if it would be helpful.
Yeah. Ideally we would do a YouTube stream, maybe one of the pygraph maintainer could handle that at the same time? I guess it also depends, since you can only stream one screen at once while you can have many people screen sharing
I wouldn't mind handling that, but I'm not sure what would be involved w/ that.
I think a youtube stream maaay be a bit overkill for a first attempt at this
Yea we could give it a go with Discord, it's not too hard to setup, so we could transition to youtube mid event if needed
(mostly due to all the stuff kat has already setup in streamyard 😄 )
Having streamyard as a backup sounds nice
@quartz tiger can you invite outofculture#8604 ?
!u outofculture#8604
@obsidian sapphire 👋
No prob 😄
@quartz tiger can you invite NilsNemitz#8915
!u NilsNemitz#8915
@wide prism
only admins can assign roles unfortunately
np
but feel free to keep pinging me 😄
just trying not to unnecessarily burden you all
It's no problem, it's just a right click and a left click 😛
Also, I only pinged them so that I could assign the roles, so it's likely they didn't actually get a notification
@obsidian sapphire @wide prism This is the channel 😄
Welcome! 🙂
@quartz tiger can you invite ntjess#5054 please?
!u ntjess#5054
@mortal grotto 👋
see, we do exist 😆
hah!
👋 Thanks for the invite!
@wide prism they seem to think we might break the 25 user limit for streaming in the voice channel 😆
(to be fair we have a lot of people on this server)
At least at the start of the event there is no way you don't pass the limit haha
yeah, this server does h ave a lot of people ...w/o a doubt the largest discord server I've joined to
!server
... 260,000 people x_x
264k members!
wow...that's ....that's a lot more than I thought
I thought it was a lot!
No wonder it took its time to load the members list...
I think it'll be fine for the majority of the event, especially as you get deeper into the sprint. But when people see folks streaming and chatting and it looks interesting they to join and lurk
A year ago we had a bit under 100k, so we've seen a lot of growth
@wide prism turns out @rapid kestrel is actually a pyqtgraph user, our users exist in the wild!
I've been converting people where I can~ I have my whole work team defaulting to it now
Happy to hear that!
Thanks for helping me out, but unfortunately it's time to run off an sleep some. I'll be back to look around on the weekend! 👋
💤
@quartz tiger can you invite Luke Campagnola#2343 ?
I'm afk atm, could another <@&267628507062992896> grab this please? 😀
Just assign the pyqt contrib role and community role
for those that don't know, @violet basin is the original author of pyqtgraph ...all praise the founder!
Don't try to flatter me, usurper!
Fore those that don't know, @rough furnace has been the lifeblood of pyqtgraph for years.
I just push the merge button, ...as evidence by log-handling, sometimes with consequences that should really have been foreseen 😆
thanks again for hosting us; at some point (doesn't have to be now) we should discuss how to "advertise" this event. As I mentioned earlier, totally welcome to have others join us, but probably not a great event for completely new to python/programming folks. This library can be a bit tricky to test locally on your system due to the different combination of dependencies we support.
We could spin this event as a "welcome to open source contributions" where we focus on what it's like contributing to in-use libraries vs new to python/programming. "Looking to apply your python skills and give back to the open source community" type thing.
you all have run events here before, so I'll go with your suggestions, but something like that sounds good.
I'll spruce up the contributing guide; but some things we can use help with is developing MWE's for some existing issues, testing out some existing PRs to find edge cases where things break.... things of that nature
So I think some good info to have is:
- What is pyqtgraph and a quick paragraph/example of its use case
- What this sprint is hoping to accomplish
- Quick breakdown of your tech stack / things you use to contribute
- Link to the "first good issues"
- A specified time where folks can drop in and ask questions/get set up
I'll draft up something and attach it here in the next day or so
when were you roughly planning on having this sprint?
I'm eyeing Nov 13-14
if not that weekend, then the weekend before or after; but probably that weekend (like unless everyone suddenly is unavailable that weekend, that's the weekend we're doing it)
Alright cool, so we've got time~
@rapid kestrel if you want to implement the quiver plot you were mentioning earlier, would love to assist w/ that contribution
@quartz tiger when you get a chance can you add @timber stirrupnden#1436 and @fervent vale
Added the roles to pijyoi, I don't think ksunden is in the guild yet
@plush fulcrum 
I think there is one more person to bring over; but probably not going to happen tonight
Hello
👋
Another thought here, should we loop in Keith for reddit reach?
Keith?
Sorry, was aiming that at Kat mostly. @hexed tundra is a mod in /r/python
We work with him quite often for events like this
I just want to throw out how thankful I am that Kat is involved here, given her existing knowledge of the library and the community here.
@rapid kestrel is great 😄 We'd be lost without her lmfao
yes please! I'd love to see Keith and also ichardhere
Done 😄
I'm working on the writeup for the questions Kat brought up earlier right now
I reviewed 4 merge requests at work this morning so I should have a little time 😆
@half jewel some context! Requested adding you here because pyqtgraph maintainers are looking to do a sprint for their repo and also do it as an event where folks can drop in and get contributing. We've talked about this more than a bit, so figured you'd want to also chime in
👀 DataViz?
I'm sorry yes hello how can I help I love this
👋
Learning curves are tough on me and I've been really itching for a reason to take on PyQtGraph, so I don't know what's going on yet, but I'm on board and I'll be learning about the library these next couple of weeks 😄
pyqtgraph maintainer here, feel free to ping me if I can be of help
You can help by spreading the love!
I believe what Chris and Kat are looking for is some reddit outreach for the event
To the reddit side of things, I just need a bit of heads up and I can draft any announcement and run it by everyone. We typically sticky the announcement on the top of the sub. It gets various levels of engagement but we're more than happy to help out!
the 'event' will take place november 13-14, I'm drafting up more of a writeup right now
Awesome! We're on board to help however you'd like!
So we at least have the date pinned somewhere :D
😆
so ...first off, I'm super thankful for the outreach/marketing/advertisement, but just fyi sounds like this event may be growing in size (user wise) to a number significantly larger than we anticipated 😆 ...not sure the existing maintainers will be able to do too much handholding with forking/branching/PR-submission/venv-creation and things of that nature.
for context, we have 6-7 active maintainers of the library, and a handful of very regular contributors... we're spread out time-zone wise such that we're concentrated on Asia/Pacific and America/Pacific
Knowing our user base, you can most probably expect some people that both never contributed to any projects and some who is already at their thousandth contribution. That said, for stuff like that you can always redirect them to help channel for Python related questions (#❓|how-to-get-help) and off-topic (#ot0-psvm’s-eternal-disapproval to ot2) if you don't want/cannot deal with them.
Ah of course! I've been super duper busy (well more like enough so that I have no energy) so I haven't been able to either clear out the blockers I have nor get back to planning psf/black's intro-to-oss event. Just for context for who I am: I'm Richard aka ichard26 and I co-maintain psf/black (I'm also staff here but that's not as relevant). I'm the documentation and developer experience lead so improving the experience for beginners is totally up my alley. And yeah Kat and I have talked about this kind of stuff before ^^
k, perhaps I should check in w/ regulars at #❓|how-to-get-help to give them a heads up that they may get an influx w/ those kinds of questions
Oh don't worry, it isn't gonna be much compared to our average :D just a bit busier than usual
In the announcement I can put a blurb on what I expect participants in the event to be able to do by themselves?
For context, #❓|how-to-get-help is our general help system
One of the highest traffic things we have
Sure, that sounds like a good idea to write some prerequisites
k, would appreciate some feedback on the wording, as I don't want to come across as someone that's trying to gate-keep
Oh intros are a good idea! I'm Keith, I help moderate the Python Subreddit. We've been partnering a lot with the discord to help manage different kinds of events, and outreach across both platforms. To the event--this discord staff is really good at distributing workload, so from my perspective I wouldn't worry too much about being overwhelmed. They're really good at directing users to either seek help or offer help at the level the user is at, and they're experienced in managing influx due to different events.
Could start off the announcement something like:
Do you have experience working with python, but would like to get started in the open source world? Join us for...
..
For those interested in joining, make sure you have experience with:
- x
- y
- z
@hexed tundra I'm /u/ogi010 on reddit; thanks for maintaining the subreddit. I am one of the maintainers of pyqtgraph and after the success of our first/last sprint session during SciPy 2021, we decided we wanted to make the sprint a more regular thing.
I should point out during the SciPy sprints we didn't have any new-comers to the library participate, but it was the first time a bunch of maintainers and a regular contributor were able to collaborate in real-time.
As far as I can tell the general plan looks good to me. One thing I'll note is that how easy it is to set up a development environment is incredibly important, especially as if you're targeting new to the open-source world .. who might not be similar with the workflows of Python OSS. Although it really depends on much you want to focus on the "get contributing: newcomers to OSS welcome!" side of it.
If you want, we could come up with a list of readings to put somewhere (other than the announcement to not clutter it?) to brush up those skills
yeah as I'm drafting this, I'm seeing some overlap we already have a contributing guide; it's a little bare bones, but sufficient IMO https://github.com/pyqtgraph/pyqtgraph/blob/master/CONTRIBUTING.md
I would be a bit weary to make it sound too much a first step into open source if that's not what you want to do
yeah I don't think this is a good event for complete noobs to open source contributing ... I mean we have some low-hanging issues in docs, where to be real, newcomers can be very helpful for identifying pain points within the documentation.
Yeah, yeah totally. I forgot to mention that even though it did seem that's where this is heading but I did want to add my 2cents as that's literally the main reason I'm here :p
...also there will be periods during this weekend where all maintainers may be offline, I'm trying to clear the weekend, but still have kids that do require my attention... I'll try and have issues tagged in the repo tho
Family is more important than anything else 
(sorry now I'm a little worried and trying to tamper expectations 😆 )
haha, it's scary running an event, especially if you're new to it!
Don't worry, we don't expect you to do anything other than having a nice weekend
If you don't have fun this is where it gets real 
😛
so ...about that 25 user limit, if there is an influx from reddit, we could likely break through that number; ...
The reddit side of things has been really hard to predict, there could be maybe two users from there, there could be lots.
I wish I had a better handle on it, but because of the way reddit manages notifications and rankings of posts, it's kind of just based on luck to a certain degree
I honestly am sure that just from the event notification we will get more than 25 people 
last time we did this, the screen-share was useful for reviewing a PR, ...depending on the audience size, we may not do that...
Because the way it works is user can add a reminder before the start of the event and get a nice push notification when it starts
we have a couple of monster PRs that individually we've been scared to review 😆
YouTube could be an alternative to this limit, but that's one more thing to handle
I will say, the sprint comes first. So if there's an issue with audience size being too big to allow screen sharing that's something we could potentially solve in advance, maybe with gating a role that allows people access to the voice channel. So you could invite regular users who are interested in contributing or similar.
During the dedicated time for newcomers to the library (if that's still something you're interested in), that could be transitioned to a stage channel to allow a bigger audience size, although no screen share there. I do want to steer us away from youtube as that's a whole thing in and of itself.
For the reddit post, that's something I'm pretty keen on doing because I do think it will bring out the intermediate user base a bit more. The cross over from reddit isn't too high, but if it brings in a few really interested people that would be clutch.
I'm absolutely fine for spinning this event towards folks who are more experienced with python and contributing. Like expecting people to know git, how manage venvs and the like. We have plenty of content for beginners, less so for people sort of "in the middle".
I think having dedicated hours for newcomers is a great idea.
i'm good w/ avoiding youtube, the streams I don't think will be that interesting, last time we did it was for someone to scroll through a diff, and gave the author of a PR to explain stuff in real-time with questions from other maintainers
first draft - I don't think I even ran the spell checker in my editor here, sorry in advance!
ok, I have to get back to work/errands...thanks again you all!
That's quite a good message you have there, I assume it is for Reddit?
This is a response to what Kat suggested I write up a bit earlier here: #pyqtgraph message
Righto, we can probably write a discord and reddit announcement from that
I can expand/refine sections
I'll take a look today~ It's nice to have as a sort of basis to provide people and to know the details of it too
@rapid kestrel sharing some bit of pyqtgraph related news, we're about to we just merged a PR incorporating our biggest feature request in some time; as a user-this may be of interest.
As you know, line plots in pyqtgraph are pretty fast, you may or may not know, as soon as the pen width > 1.0 pixels, that speed plummets (unless you're using the openGL renderer, but that has its own set of issues). Our own benchmark goes from 500 fps to 0.5 fps the moment the line thickness goes from 1.0 pixels to 1.1 pixels.
We're about to merge a PR that boosts plot performance with thick lines so that on the same benchmark, it's ~100 fps (so 5x slower than pixel thickness of 1 or less, but not 4 orders of magnitude). I doubt we will be able to get performance parity, but at least it's usable now.
I had a quick look over the sprint outline and wiggled some words around:
Maybe you want to incorporate some of that into your draft. Overall it seems nice already, though!
You have a gift with writing; I'll likely incorporate your changes when I see them. Will wait until I'm off of mobile to do so
I'm reading through the changes, they're all good; I'm incorporating them all. Reading through them I realized some other points I forgot to mention, which I'll add in. I'll post an updated version shortly
@rapid kestrel updated version
I will take a look during my lunch!
this is great!!
So I figure we can post this with some slight modifications in r/Python (cc: @hexed tundra) when we get closer to the event date.
I figure there can be a post with this info in either #python-community or #python-events. If you want we can do one in #announcements as well, although I would recommend against the at-announcements ping.
We can also create an Event for it so that it'll appear at the top event tab. This will let you easily share the event with other people. Although, for this. Do you want an event for the sprint in general or just the "welcome new contributors" section?
Do you have a general idea of schedule or do you prefer to keep it a bit more free-flowing as to what you tackle when?
Schedule wise, I think the only thing we should do is have some kind of "office hours" period where we'll try to have our efforts aimed at bringing newcomers "up to speed" with greater ease... not sure how else to phrase it, ...but basically time I will plan on not doing dev work directly but answering questions/directing people/etc.
I think I can do something like 11am-1pm PST on both days or something like that...
I plan on being online/available the majority of the weekend; and I'll certainly be willing to help folks outside of those hours.... but I'd be willing to reserve that time for providing greater assistance/etc.
(I'm trying to schedule babysitters for that weekend so my wife doesn't resent me for being "at the computer" all weekend while she's watching the kids 😆 )
okay cool, I'll make an event for that then!
So some more logistics thing for during the sprint.
- You will have a voice channel where you can screenshare and then this accompanying channel. If necessary, we can lock we the voice channel to only people with certain roles (in case you hit a full voice channel and the people there aren't really engaging with y'all). Do you want a functionality where you can give a role to a person to allow them in?
I guess this is me asking if there are non-maintainer contributors to the repo that might need access to the VC (or even this channel) if we find we need to lock it down slightly due to too much off-topic chatter
generally, I think having voice only to people with roles being good, and I'm not seeing the need to have the ability to give other people roles either...
I can also make myself available during then in case any role intervention is required
I may ask to give a few people a role if they jump in ... but if I do, I wouldn't expect immediate responses... and the people that I would do that for are like, ...pytest maintainers, or maybe a vispy maintainer if they hop on.
I can also make it available to anyone with the Python Community role, so pytest maintainers would have access based on that. And any other crucial maintainer can get their own fancy role here~
oh, that would be perfect
due to time-zone spread, I really doubt there will be significant usage of voice/screen-share, ...it will likely be limited to a time period where there is significant overlap between our availability
@quartz tiger another person to add to the pyqtgraph role if you have a moment, @torn coyote could be brought here please
unless some contributors/maintainers come out of hiatus, I think that should do it
Not Chris but have added them 😄. Hello @torn coyote
:t-hanks:
to not pick on any one of you admins, should I be @-ing at a group instead when I could use some non-urgent assistance?
Pinging the role would be fine for this sort of thing, yeah
@Admins ?
Yeah
👍
@rapid kestrel so what should we do next here; or is there some rewording we should change with respect to the announcement?
so they next thing is to do is pick a time for the new to pyqtgraph contributors session. Otherwise, we hang tight until Nov 1 which is when I'll get rolling with announcements + posts + all that good stuff.
Otherwise, any prep y'all need to do to get together a list of issues or anything like that is something you're more than welcome to do here
We will certainly handle the labeling of issues and such... annoyingly I'm unable to get a babysitter for that Saturday, but do have one for that Sunday.
For the "contributors session" I'm going to recommend 1300-1500 PM PST ... we'll have folks around before/after but I think that's probably the time I can make myself most available.
Announcements going live Nov 1st sounds good, I'm starting to do some prep work on my end regarding announcements, but don't want to do too much until I can link somewhere else 👍
At about what time tomorrow would you like the reddit announcement post to go live?
For this, I'll take the suggestions of those more experienced than me. I reside in the U.S. west Coast, I can be intermittently online to answer questions all day
also feel free to tag me on the post, I'm /u/ogi010 on reddit
Hi! I will be making some posts in a few hours once I am feeling less ill and can breathe a bit better
didn't know you were under the weather! glad you're feeling a bit better, hope you're back to normal soon!
Yeah, a very persistent cough that has stolen my voice. Rather annoying but otherwise fine~
persistent coughs are the worst
Just so I'm on the same page--today we're announcing the sprint for Nov 13th-14th correct?
yes
awesome! Just making sure I had my ducks in a row
Would you like me to draft an announcement in the format of this: #announcements message that way you can rest more?
let me know if I can help here; not sure what the easiest way to do it would be ... I have some meetings but I can certainly read/edit/write
Thank you, I'm nearly done with with draft then you can tell me what needs to be changed. I'll ping you and post the draft here when it's ready
👍
#PyQtGraph Code Sprint!
Join us on November 13th and 14th for a code sprint with the developers of PyQtGraph!
* https://github.com/pyqtgraph/pyqtgraph
PyQtGraph frequently finds a use in scientific computing/research applications where it is valuable to view incoming data in real-time, and we'll be hosting a coding sprint to tackle open issue and to submit pull requests which address them. We'll have office hours at 1300-1500 PST on Saturday where [LIST OF NAMES] will be available to help make the sprint go smoothly and answer any questions you might have.
During the sprint we hope to achieve some of the following:
* submit PRs that address existing open issues
* test, review and merge existing PRs
* identify documentation that can be improved, and submit PRs to do so
If you're interested in joining and helping contribute to this awesome library, make sure you familiarize yourself with the Contribution Guide:
* https://github.com/pyqtgraph/pyqtgraph/blob/master/CONTRIBUTING.md
And make sure you're familiar with the use of virtual environments and have the necessary dependencies outlined in the README installed and ready to go.
It needs some work, but @rough furnace let me know what you think, and let me know the times and timezones you'll be available during, and @rapid kestrel give it a look over and let me know what changes would work to be more inline with standard discord announcements
for [TIMES] I would recommend 1300-1500 PST on Saturday and 1000-1200 PST on Sunday if a second time is needed.
I can/should write up a blurb on what we could use help with cough openGL cough
In terms of list of names, Ogi Moore for sure, @plush fulcrum @obsidian sapphire would 1300-1500 PST Saturday the 13th be a good time to hold an "office hour" for you two?
oh, forgot to tag @mortal grotto with the question above ☝️
Awesome, added the saturday time slot in and will add names once everyone is ready
Also Spookiekatj9--if you had something drafted feel free to disregard mine. I just took a shot at it in case you weren't able to get it
I've got a few things to work around that day, which aren't entirely under my control, but probably? If it gets pushed around, will that be hard to coordinate with?
eh, as long as one of us is there to answer some basic questions I think that's fine, Saturday mornings are pretty tough due to kid events; but the afternoon is usually a bit lower key, this was a window I felt I could most certainly make myself available; anyway if you're busy that day, I wouldn't worry about it @obsidian sapphire
No, yeah, I have hours of time to give then, I just don't know exactly when they'll be.
@rough furnace that time should work for me as well, thanks
I think these times are around 6AM on Sunday and 3 AM on Monday in my time zone. So I think I'd prefer not to promise my availability right then. Sorry 🙂
haha yeah I counted you out on that one 😛 the times you are available (mornings) are really tough for me on Saturday, and I could make it work on Sunday but figured we should have something on the first day of the weekend... also my evenings can be a bit unpredictable
I am not the best person to help with setup / getting started issues anyway. But I have tried to clear that weekend as much as possible, so I will be around as much as possible.
If the intro happens in this channel, I can scroll up later 🙂
This channel will most probably stay internal, even during the event
New public facing channels will/can be made for the event
not to get all nag-ey, but ...well is there anything I can do to help w/ getting the announcement posted?
it's happening today! today as in like within the hour
aaaand we're off!
This channel will still remain private to y'all in case you need a non-public area to discuss things
huge thank you to everyone involved here!
Let me know when you want me to open the flood gates and allow people to type in #pyqtgraph-sprint-chat
@quartz tiger I think that would be fine, leave the pinned message up, I'll answer questions throughout the day.
I'll let you all know if it's overwhelming, ...in which case I may draft up a FAQ or something
thank you all for all this, I really appreciate it
@hexed tundra let me know once the reddit post goes live and I'll link on twitter and such. I can't thank you all enough for supporting us on this!
Join the [PyQtGraph](https://github.com/pyqtgraph/pyqtgraph) maintainers on November 13th and 14th for a code sprint hosted by our sister community the [Python Discord](https://discord.gg/python)!
PyQtGraph (https://github.com/pyqtgraph/pyqtgraph) frequently finds use in scientific computing/research applications especially when you need to view data in realtime. The Python Discord be hosting a coding sprint on the server to tackle open issues and to submit and review pull requests in this very channel!
During the sprint we hope to:
• Submit PRs that address existing open issues
• Test, review and merge existing PRs
• Identify documentation that can be improved, and submit PRs to do so
Office hours will be at November 13, 2021 3:00 PM (2100-2300 UTC on Saturday, November 13) where j9ac9k (u/ogi010), ntjess, outofculture will be available to answer any questions you might have while contributing!
If you're interested in helping contribute to this library then check out the following:
• Read and abide by the code of conduct https://github.com/pyqtgraph/pyqtgraph/blob/master/CODE_OF_CONDUCT.md
• Setup your contributing environment https://github.com/pyqtgraph/pyqtgraph/blob/master/CONTRIBUTING.md
• Get ready to have fun and support an awesome library!
How does this look? I removed the tags to avoid pinging everyone, but it's got an @ ahead of it in the actual post
sorry was in a meeting...reading now
no worries no rush
That looks good, is PyQtGraph in the second paragraph intentionally not hypter-linked? (I'm good with it not being so)
I'll hyperlink that! (Or would you prefer the second on link to the docs page?)
oh, good call on the docs page, it's pyqtgraph.readthedocs.io
Ok--one final thing.
Do you have any images you're particularly fond of to showcase the library?
sure, stand-by
November 13, 2021 3:00 PM
might wanna mention the timezone- or maybe it doesn't matter since you mention the time in UTC as well
"Basic Plotting Example"
PColorMeshItem
Scatter Plots
(one more)
Region of Interest
Ok, I should have the post ready. I've never played with embedding images so we might experience some fun bugs, but I'll be able to edit and fix them
looks great to me!
Awesome, it is now distinguished and sticked to the sub so it sits on the top of the page. Hopefully that'll help get some interested folks to help contribute!
Yeah I messed that up--let me deleted and repost 😄
😆
I love that mods have the same annoyances as users with not being able to edit titles
Haha it's such a pain but so it goes. Give me a minute and I'll get the new post setup
Ok let's try this again:
https://new.reddit.com/r/Python/comments/qm0bmz/pyqtgraph_code_sprint_on_november_13th_and_14th/
0 votes and 0 comments so far on Reddit
Does that look right?
72,727
191,708