-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unpin package dependencies #350
Conversation
@willfurnass the Travis build for Python 3.6 seems to have failed for some server reason - are you able to do a local Tox test as part of your review please? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jarmarshall With unpinned dependency versions changing widgets for e.g. model2.integrate()
result in the creation of a new figure rather than the updating of an existing figure. I think this is distinct from #158 but it may be related.
I suspect the cleanest approach to addressing this could be to minimise the use of the stateful matplotlib API in favour of the cleaner OO API and pass references to Axes
objects to functions that need to update matplotlib plots.
A meeting in person may be the quickest way to bootstrap my understanding of how MuMoT currently handles plotting inc figure updates.
Also, the Travis CI build with Python 3.6 seemed to fail because of a timeout at Travis' end so I've restarted that job. |
Codecov Report
@@ Coverage Diff @@
## master #350 +/- ##
==========================================
+ Coverage 68.92% 70.73% +1.81%
==========================================
Files 9 9
Lines 5766 5967 +201
Branches 1572 1748 +176
==========================================
+ Hits 3974 4221 +247
+ Misses 1398 1363 -35
+ Partials 394 383 -11
Continue to review full report at Codecov.
|
@willfurnass so that's not working properly on Linux - what version of Python are you on? I agree the stateful logic needs checking but be good to find out why this works on Mac but not on Linux - I am using Python 3.7.4 with the following environment. If we can identify the differences and some further, minor, pinning, maybe on minimum versions, then perhaps that will be sufficient for now.
|
Hmm, I can't spot any obvious differences between your conda env and my auto-generated tox env that might explain this: $ .tox/py37/bin/python -m pip freeze
alabaster==0.7.12
antlr4-python3-runtime==4.7.2
atomicwrites==1.3.0
attrs==19.1.0
Babel==2.7.0
backcall==0.1.0
bleach==3.1.0
certifi==2019.9.11
chardet==3.0.4
codecov==2.0.15
colorama==0.4.1
coverage==4.5.4
cycler==0.10.0
decorator==4.4.0
defusedxml==0.6.0
docutils==0.15.2
entrypoints==0.3
gitdb2==2.0.5
GitPython==3.0.2
graphviz==0.13
idna==2.8
imagesize==1.1.0
importlib-metadata==0.23
ipykernel==5.1.2
ipython==7.8.0
ipython-genutils==0.2.0
ipywidgets==7.5.1
jedi==0.15.1
Jinja2==2.10.1
jsonschema==3.0.2
jupyter==1.0.0
jupyter-client==5.3.3
jupyter-console==6.0.0
jupyter-core==4.5.0
kiwisolver==1.1.0
MarkupSafe==1.1.1
matplotlib==3.1.1
mistune==0.8.4
more-itertools==7.2.0
mpmath==1.1.0
mumot==1.0.0
nbconvert==5.6.0
nbdime==1.1.0
nbformat==4.4.0
nbval==0.9.2
networkx==2.3
notebook==6.0.1
numpy==1.17.2
packaging==19.2
pandocfilters==1.4.2
parso==0.5.1
pexpect==4.7.0
pickleshare==0.7.5
pluggy==0.13.0
prometheus-client==0.7.1
prompt-toolkit==2.0.9
ptyprocess==0.6.0
py==1.8.0
PyDSTool==0.90.3
Pygments==2.4.2
pyparsing==2.4.2
pyrsistent==0.15.4
pytest==5.1.3
pytest-cov==2.7.1
python-dateutil==2.8.0
pytz==2019.2
pyzmq==18.1.0
qtconsole==4.5.5
requests==2.22.0
scipy==1.3.1
Send2Trash==1.5.0
six==1.12.0
smmap2==2.0.5
snowballstemmer==1.9.1
Sphinx==2.2.0
sphinxcontrib-applehelp==1.0.1
sphinxcontrib-devhelp==1.0.1
sphinxcontrib-htmlhelp==1.0.2
sphinxcontrib-jsmath==1.0.1
sphinxcontrib-qthelp==1.0.2
sphinxcontrib-serializinghtml==1.1.3
sympy==1.4
terminado==0.8.2
testpath==0.4.2
tornado==6.0.3
traitlets==4.3.2
urllib3==1.25.5
wcwidth==0.1.7
webencodings==0.5.1
widgetsnbextension==3.5.1
zipp==0.6.0 @jarmarshall If you run jupyter within a tox environment using the following then do you experience the same issue with duplicate plots (rather than updated plots)? $ tox -r
$ .tox/py37/bin/jupyter notebook |
OK - @willfurnass are you able to isolate which command causes the duplicate figure to appear? This would involve looking into |
Looking in the replot function for field views, there is also |
Just noted this warning for multi controllers:
|
OK - so I thought to point MyBinder at the |
OK, so looking at this on binder I now think that the problem probably lies with the nbagg backend to matplotlib, which handles notebook rendering of interactive figures; the usual interactive figure buttons are missing... Also, we're only using TkAgg under OS X, which may help explain why the issue still manifests on Linux, but apparently not on Mac... |
Yup, that's it... still need to find a Windows tester |
@jarmarshall Your removal of that call to create a new figure has fixed the duplicate figure issue on Linux. NB your attempt to force TkAgg hasn't worked for me: |
Which call? As long as it works... |
Your removal of |
Interesting - I think I may have done that by accident - I am now surprised that the right figures get updated when there are multiple figures being interacted with, but on OS X it seems correct - can you please check on Linux? The failure mode would be create controller1, then controller2, interact with controller1 again and the other controller's figure is updated... |
Since some progress has been made with updating packages I decided to see what happened when all pinnings were removed. The results were encouraging in that issue #210 did not manifest again on Mac in Safari. I played a little and saw only one problem... interacting repeatedly with controller
vector1
in the user manual resulted in the following warning recurring after a while:@willfurnass could you review, play with these settings, and consider if this is indeed a complete fix? Be good to get @joefresna trying to break it too...
Should close #349 when merged