yikes.

I believe there is already a PR open addressing the short arrows.

What were you doing that you hit all of these and how many are regressions and how many never worked?

What commit are you evaluating off of?

Is the mouse movement slow with all backends or just qt5? If it is just qt5 a possible fix ( #4894 ) went in for that this morning and #4612 may have reduced the number of draws.

I think #4738 has a fix for the animation blitting issue.

FYI We have a fairly complicated Qt GUI that plots data in large batches (50,000+ points) as well as updates in real time as data is read over a network. Data can be in a variety of units and the user can lasso and interact w/ points (blitting issues). We recently updated the app to use PyQt5 and were retesting all of it's features to make sure things were working. So it's hard to tell exactly when things failed - there may be items that were broken but no one was using and we wouldn't know about it. I think there are probably two major groups of problems. The Qt backend (as well as the mouse move bug in qt itself) seem to be reworked recently and GUI's are difficult to test. The unit support has been an issue in the past as (newer?) people change things and don't realize that unit'ized data is possible so it's not tested (@jrevans tends to fix those as soon as we find them). I believe @jrevans is going to start submitting fixes for a lot these items tomorrow.

Ah, you are probably also interest in #4813 and #4878 which work extra hard to highlight the qt5 mouse handling change.

I am mostly concerned about the stale-related issues as that is a new feature which could have fatal flaws. Regressions and GUI issues, while bad, worry me less (as I have more faith they are fixable).

It would be really helpful if someone who understands the unit handling
could write a unit tutorial and integrate the unit example code that is
already in the library into the automated tests.

On Mon, Aug 10, 2015, 9:36 PM Ted Drain [email protected] wrote:

FYI We have a fairly complicated Qt GUI that plots data in large batches
(50,000+ points) as well as updates in real time as data is read over a
network. Data can be in a variety of units and the user can lasso and
interact w/ points (blitting issues). We recently updated the app to use
PyQt5 and were retesting all of it's features to make sure things were
working. So it's hard to tell exactly when things failed - there may be
items that were broken but no one was using and we wouldn't know about it.
I think there are probably two major groups of problems. The Qt backend (as
well as the mouse move bug in qt itself) seem to be reworked recently and
GUI's are difficult to test. The unit support has been an issue in the past
as (newer?) people change things and don't realize that unit'ized data is
possible so it's not tested (@jrevans https://github.com/jrevans tends
to fix those as soon as we find them). I believe @jrevans is going to
start submitting fixes for a lot these items tomorrow.

—
Reply to this email directly or view it on GitHub
#4897 (comment)
.

@tacaswell I think there are already tests with units - the issue is that they need to cover the whole plot API which is a big job. We can certainly help write expand them (more tests are always better of course) but it's going to take some time.

How much difference would exist between the tests? Could we for instance write a "one test to test them all", searching through the plot API, and running a test on each of them?

I have just ticked off the items already merged in the opening comment.

Ideally, we'd test every plot command, axis manipulations (limits, etc), and the various artists. They all have different API's so you can't write one test. We might be able to refactor existing tests to have a "generate data" function were we can replace that function with regular data and unitized data before the main part of the test runs.

If there are tests, I am not sure where they are and they are not listed in https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/__init__.py#L1403 so they are not getting run on travis. The examples are being run (due to being part of the docs http://matplotlib.org/devdocs/examples/units/index.html) but it only checks that they run with out exceptions, not that they are correct.

There is code in
https://github.com/matplotlib/matplotlib/tree/master/lib/matplotlib/testing/jpl_units that is used a couple of places in test_axes.

If I understand correctly, the datetime handling is done through the unit framework, but some of the issues reported it is not clear how to map date-time to them.

@TD22057 Damn, I had a bad feeling you were going to say that... ;).

From what I have seen of the code (and I slowly work my way through the code base), that it looks like the emphasis has been on quick fixes, rather then working on the underlying flaws. The good news though, I have a feeling that a lot of this will get addressed in 2.x though. From MEP22 and 27 dealing with the backend widgets, through to refactoring the Artists, including the Axes, which I have a suspicion will get made more generic so it can better handle Axes3d, etcetera.

I ticked off 3 (mouse movement, animation blitting, and stale + remove) that I think are fixed, can you verify?

Can you be any more specific about what is wrong with qt and if it applies to both qt4 and qt5?

I have verified that 'mouse movement is very slow' issue that we were seeing is a result of three things:

1. A Qt Bug #40889
2. The usage of numpy.MachAr as per: use numpy.finfo instead of numpy.MachAr for speedup #4828
3. 'hitlist' being called for all mouse moves as per Prf mouse move hitlist #4813 & PRF: only check some artists on mousemove #4878 (+1 to make this an option)

I have checked a couple more things off, I think the only point there isn't an open PR to address is the first one?

Would it be possible to have on the "Milestones" page of github a re-forecast of the release date ?

If you click [that link](https://github.com/matplotlib/matplotlib/milestones/next point release) through, you will see only 23 issues/PRs left to close before we release a PR... that kind of gives you an idea of time...

Wasn't it 25 about 1 week ago ? If I draw a line and remove "not a blocker", it looks like mid-october. I hope I'm wrong (so I ask)

The issues blocking the RC at this point are #3937, #4488, #4666, #4803 and #4829 .

#4666 Needs a bit more strait forward development work (@stonebig if you have time this would be a good place to invest it)

#3937 and #4829 are awaiting final review

#4488 is still being bike-shedded

#4803 is blocked by #4829 but is other wise strait forward

Everything else tagged in the milestone is bug-fixes of non-regressions or documentation both of which can be merged as part of the the RC cycle, but any help getting them sorted out would be greatly appreciated.

One way to look at this issue is that @jrevans and @TD22057 did an RC0 round for us that we are just about finished with.

@tacaswell thanks for the update ! Sorry I'm not the expert numpy guy you need to solve #4666

any hope of a release for this Week-end ?

There was a large list of critical bugfixes as a result of rc2. I hope to get rc3 out today, which hopefully should be identical or extremely close to the final release.

Moved to next bug-fix release target.

This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!