The following code, run with version 1.3 or with 1.5.dev1, sometimes produces an entirely blank plot. This happens randomly; rerunning the script multiple times eventually produces the right output. This is on Linux, running python 3.4.0.
If the markers have a color, that color always appears. The edge sometimes are there, and sometimes aren't.
@cpitclaudel What is your rough estimate of the frequency: is one outcome much more common, or do they seem equally likely? (It sounds like a timing issue, as if the plotting were being done in a thread and sometimes the file is written before the thread finishes--but of course this isn't it, because we aren't doing anything like that. Everything should be strictly sequential.)
The observation that this is only happening with py3.4 makes me very
suspicious. Of what? I haven't a clue, but something is fishy. We aren't
seeing these sorts of issues with Travis testing. Could we simplify the
code any further? Or is this strictly a problem with marker edges?
@cpitclaudelhttps://github.com/cpitclaudel What is your rough estimate
of the frequency: is one outcome much more common, or do they seem equally
likely? (It sounds like a timing issue, as if the plotting were being done
in a thread and sometimes the file is written before the thread
finishes--but of course this isn't it, because we aren't doing anything
like that. Everything should be strictly sequential.)
—
Reply to this email directly or view it on GitHub #4083 (comment)
.
There's nothing else going on in my scripts that the MWE I posted. I'm not sure if I can reduce it further The problem also appears with 3D scatter plots.
@tacaswell I ran your script. It never returns any output; the images are always consistent. Sometimes it makes 500 blank images, sometimes 500 images with circles.
I just re-ran my script and got 5k frames with no points shown....
The dependency on the process makes me think than someplace we are relying on ordering in a dictionary. Making key ordering in a dictionary random is one of the python 3 related changes iirc (to avoid DoS attacks on dictionaries).
Ah, a repro! I'm glad (and a bit sorry; one might have hoped my machines were just crazy). The dictionary is something I thought about earlier too, but I wasn't sure how to force the order of keyword arguments (ordereddicts didn't seem to help) :/ I didn't realize that python2 didn't behave the same way.
The issue is that the kwargs color and edgecolor are not explicitly handled by the ax.scatter method (but the kwarg c is) and are instead handled by a call to collection.update(kwargs) which in turn calls coll.set_color and coll.set_edgecolor. set_color sets both the face and edge color to be the same (in this case 'none'). If the keys came out in the order ['color', 'edgecolor'] it worked fine as the edge color overrides the empty color and your graph looks fine. If they come out in the other order the color value overrides the edge color and you get invisible dots.
I take back what I said about back-porting this to 1.4.3. It as a really annoying degeneracy in the input, but not a show stopper.
Activity
cpitclaudel commented on Feb 8, 2015
Here are two traces (strace python3 test.py): edges appearing properly | edges missing
And the two pdfs: edges appearing properly | edges missing
cpitclaudel commented on Feb 8, 2015
Extra note: This seems to happen independently of the backend
cpitclaudel commented on Feb 8, 2015
And this doesn't seem to happen when using python 2.7
graphics: Use python2 for scatter plots
tacaswell commented on Feb 8, 2015
My guess is that you are running into issues with the state-machine and not drawing to the figure you think you are drawing to.
Can you reporduce this with
cpitclaudel commented on Feb 8, 2015
Thanks for your answer. I get exactly the same results with your code: sometimes I get circles; sometimes not.
efiring commented on Feb 8, 2015
@cpitclaudel What is your rough estimate of the frequency: is one outcome much more common, or do they seem equally likely? (It sounds like a timing issue, as if the plotting were being done in a thread and sometimes the file is written before the thread finishes--but of course this isn't it, because we aren't doing anything like that. Everything should be strictly sequential.)
WeatherGod commented on Feb 8, 2015
The observation that this is only happening with py3.4 makes me very
suspicious. Of what? I haven't a clue, but something is fishy. We aren't
seeing these sorts of issues with Travis testing. Could we simplify the
code any further? Or is this strictly a problem with marker edges?
On Sun, Feb 8, 2015 at 2:52 PM, Eric Firing notifications@github.com
wrote:
tacaswell commented on Feb 8, 2015
I can not reproduce this at all with py34
does not print anything (which is confirmed by visually scanning the thumbnails).
What else is going on in your scripts?
cpitclaudel commented on Feb 8, 2015
I think about equally likely. I can reproduce this on two distinct Linux Mint machines
cpitclaudel commented on Feb 8, 2015
Could this be due to a memory corruption somewhere instead of a timing issue? Valgrind produces too many errors to be useful.
cpitclaudel commented on Feb 8, 2015
There's nothing else going on in my scripts that the MWE I posted. I'm not sure if I can reduce it further The problem also appears with 3D scatter plots.
cpitclaudel commented on Feb 8, 2015
@tacaswell I ran your script. It never returns any output; the images are always consistent. Sometimes it makes 500 blank images, sometimes 500 images with circles.
tacaswell commented on Feb 8, 2015
I just re-ran my script and got 5k frames with no points shown....
The dependency on the process makes me think than someplace we are relying on ordering in a dictionary. Making key ordering in a dictionary random is one of the python 3 related changes iirc (to avoid DoS attacks on dictionaries).
cpitclaudel commented on Feb 8, 2015
Ah, a repro! I'm glad (and a bit sorry; one might have hoped my machines were just crazy). The dictionary is something I thought about earlier too, but I wasn't sure how to force the order of keyword arguments (ordereddicts didn't seem to help) :/ I didn't realize that python2 didn't behave the same way.
7 remaining items
tacaswell commented on Feb 8, 2015
I am inclined to say that the fix for this needs to be stuck on top of the 1.4.3 rc.
tacaswell commented on Feb 8, 2015
Yup, the dict key ordering is the issue and
seems to consistently work.
cpitclaudel commented on Feb 8, 2015
@tacaswell Indeed! It doesn't work with color instead of c, though.
tacaswell commented on Feb 8, 2015
should also work consistently.
The issue is that the kwargs color and edgecolor are not explicitly handled by the ax.scatter method (but the kwarg c is) and are instead handled by a call to collection.update(kwargs) which in turn calls coll.set_color and coll.set_edgecolor. set_color sets both the face and edge color to be the same (in this case 'none'). If the keys came out in the order ['color', 'edgecolor'] it worked fine as the edge color overrides the empty color and your graph looks fine. If they come out in the other order the color value overrides the edge color and you get invisible dots.
I take back what I said about back-porting this to 1.4.3. It as a really annoying degeneracy in the input, but not a show stopper.
cpitclaudel commented on Feb 8, 2015
Indeed, that's correct! Fascinating bug. Thanks for the explanation.
tacaswell commented on Feb 19, 2015
This is fixed by #4079