Skip to content
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

DynamicMap #278

Merged
merged 74 commits into from Nov 19, 2015

Conversation

Projects
None yet
3 participants
@philippjfr
Copy link
Contributor

philippjfr commented Oct 1, 2015

This PR adds the new DynamicMap class, which allows generating frames on the fly when working with widgets. The DynamicMap has two operating modes or intervals:

  • 'open': In open mode the ScrubberWidget allows the user to request a new frame via the play and next frame buttons. When creating the DynamicMap in open mode the user should supply an iterator that returns a new key and Element when next is called. This mode allows for streaming data for example from a simulator.
  • 'closed': In closed mode the user should define the valid Dimension ranges or values. Using the SelectionWidget the user may then select any value in the space defined by the Dimensions, allowing much larger parameter spaces with near continuous sampling to be explored.

Both modes already work but there are a few to-do items left:

  1. Currently the cache is infinite which means that all frames are buffered both server-side and client-side, there should be options to limit the buffer size and only buffering every n-th frame.
  2. Currently nothing communicates a StopIteration to javascript so the scrubber will continue running and expand the slider even when the DynamicMap has run out of new frames.

jlstevens and others added some commits Jun 28, 2015

Set default interval mode to 'open' as it is the simplest mode to use
Open mode can be used quickly and easily with inline generators whereas
'closed' interval mode requires ranges on all the key dimensions.
Set default interval mode to 'open' as it is the simplest mode to use
Open mode can be used quickly and easily with inline generators whereas
'closed' interval mode requires ranges on all the key dimensions.
philippjfr philippjfr
philippjfr philippjfr
philippjfr philippjfr
philippjfr philippjfr
Initializing DynamicMaps in 'open' mode, removed iter
Iter causes unexpected behaviour in many places because
HoloViews generally expects to be able to iterate over
Elements in a HoloMap type.

@philippjfr philippjfr referenced this pull request Nov 10, 2015

Merged

Data API #284

42 of 42 tasks complete

Philipp Rudiger added some commits Nov 10, 2015

Philipp Rudiger Philipp Rudiger
philippjfr philippjfr
philippjfr philippjfr
Merge branch 'master' into dynamic
Conflicts:
	tests/testwidgets.py
Philipp Rudiger Philipp Rudiger
@jlstevens

This comment has been minimized.

Copy link
Contributor

jlstevens commented Nov 19, 2015

I've been working through the proposal above and making good progress. One quick bug report for Dimensions though:

kdims=[hv.Dimension('size', range=(1,5), type=float)

This results in a slider that snaps to integers despite the explicit type declaration saying otherwise.

Philipp Rudiger and others added some commits Nov 19, 2015

@jlstevens

This comment has been minimized.

Copy link
Contributor

jlstevens commented Nov 19, 2015

Ok, I've gone and rewritten DynamicMap according to the proposal above.

I am quite happy with it! Not having the specify the mode explicitly is very nice, making DynamicMap easier to use. It is currently working with all the tests I have for all the different modes.

As it is working with an improved API, I am happy to see it merged whenever you like. There are a few outstanding issues, most of them are minor:

Bug fixes

  • The dimension type issue above.
  • An odd bug where the first frame is the same as the last frame.

To implement

  • When using __getitem__ with a key set, DynamicMap should regenerate the data (closed mode only).
  • Caching needs to be improved on the client-side (i.e in the Javascript code).

These are all small jobs that I am happy to see implemented on master.

@philippjfr

This comment has been minimized.

Copy link
Contributor Author

philippjfr commented Nov 19, 2015

Okay I've fixed all the bugs you mentioned and have got the tests passing. The other two items are features and can be implemented on master (or as separate PRs). I'll go ahead and merge.

philippjfr pushed a commit that referenced this pull request Nov 19, 2015

Philipp Rudiger Philipp Rudiger

@philippjfr philippjfr merged commit edfb83a into master Nov 19, 2015

2 of 3 checks passed

coverage/coveralls Coverage decreased (-0.7%) to 71.26%
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details
@jlstevens

This comment has been minimized.

Copy link
Contributor

jlstevens commented Nov 19, 2015

Ok great! We may still want to use this PR to decide how we want caching on the client-side to work...

@jlstevens jlstevens deleted the dynamic branch Dec 7, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.