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
Merged

DynamicMap #278

merged 74 commits into from
Nov 19, 2015

Conversation

philippjfr
Copy link
Member

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 30 commits June 28, 2015 01:04
Open mode can be used quickly and easily with inline generators whereas
'closed' interval mode requires ranges on all the key dimensions.
Open mode can be used quickly and easily with inline generators whereas
'closed' interval mode requires ranges on all the key dimensions.
Iter causes unexpected behaviour in many places because
HoloViews generally expects to be able to iterate over
Elements in a HoloMap type.
@philippjfr philippjfr mentioned this pull request Nov 10, 2015
42 tasks
@jlstevens
Copy link
Contributor

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.

@jlstevens
Copy link
Contributor

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
Copy link
Member Author

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 added a commit that referenced this pull request Nov 19, 2015
@philippjfr philippjfr merged commit edfb83a into master Nov 19, 2015
@jlstevens
Copy link
Contributor

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 December 7, 2015 15:37
Copy link

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 26, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
type: feature A major new feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants