Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
Ian Hunt-Isaak
@ianhi
If saved widget state is unchecked then I think I'm with @martinRenou that it would be nice if widgets could also save a png repr that would displayed when the notbeook is reopened, rather than just model not found
Jason Grout
@jasongrout
The idea is that if save widget state is unchecked, then the widget manager should not touch the notebook metadata. If it is checked, then it should replace the notebook widget metadata with the current widget state.
If we want something else to happen (like asking widgets for an output representation), perhaps it makes sense to do that as a separate decision? Like a new "Save widget image snapshot" or something (that's a terrible name...)
Because (a) it would be writing to a different part of the notebook (the outputs, vs the metadata), and (b) if taking an image snapshot is intensive, people may not want to do so
Also, the thing I've struggled with philosophically is: should we take the snapshot when the widget is initially created (so it represents what happens when the cell is run), or should the snapshot be taken when the file is saved (so it represents the current view of the document, but does not necessarily reflect the code cell above it)?
Jason Grout
@jasongrout
It's kind of bringing to the forefront the natural tension widgets introduces into the notebook paradigm, of having something in the output that does not just reflect the code in the cell above.
Ian Hunt-Isaak
@ianhi
That's a thorny issue :/
But for ipympl at least the situation is worse than choosing the lesser of two evils. Currently you get something that doesn't represent either the initial state or the modified state
you just get the information that there was once a plot there, which makes it far more difficult to share a notebook document to tell a story
Jason Grout
@jasongrout
Is that because of https://github.com/matplotlib/ipympl/issues/290#issuecomment-768515509, i.e., the initial widget state is not enough to draw the plot?
Ian Hunt-Isaak
@ianhi
yes
Jason Grout
@jasongrout
because there has to be communication from the frontend about the capabilities (i.e., the dpi)
Can that dpi ratio be changed dynamically?
Can you always assume 1, and then adjust to 2 if needed?
Ian Hunt-Isaak
@ianhi
So js sends that information back to python
but I think there is already a png saved in the widget state
but it gets hung up waiting for a message from the frontend
Earlier in that thread I proposed sending the widget several messages from the backend before the widget is initialized, which seems to work but I think relies on the queuing behavior of the comms which maybe isn't garunteed?
I've been meaning to ask you or someone else knowledgeable about comms if that is a safe thing to do (send message to the frontend before it's finished being created)

Can you always assume 1, and then adjust to 2 if needed?

I think there is something in the matplotlib webagg backend about only setting this once. But that must be workaroundable

Ian Hunt-Isaak
@ianhi
Actually maybe it's even simpler for the issue of no plots on a restarted kernel, I think the frontend only ever draws when it receives new data, there is no check to see if it already has data and in that case to make a draw

Also, the thing I've struggled with philosophically is: should we take the snapshot when the widget is initially created (so it represents what happens when the cell is run), or should the snapshot be taken when the file is saved (so it represents the current view of the document, but does not necessarily reflect the code cell above it)?

It seems to me that the latter encompasses the former. If you are careful then the final state can encompass the initial state, but the converse is not necessarily true. Further, for story telling via emailing someone a notebook I at least would want to include an by hand modifications I made to a widget (e.g. highlighting part of a display)

Jason Grout
@jasongrout

I've been meaning to ask you or someone else knowledgeable about comms if that is a safe thing to do (send message to the frontend before it's finished being created)

Messages are queued in the frontend and processed in order, and wait for each other to be done processing. The comm object pauses message processing until it is created. Does that answer your question?

Ian Hunt-Isaak
@ianhi
I think? I guess I was worried about sending the messages potentially before the widget sets up it on_message callbacks
Jason Grout
@jasongrout
comm creation pauses message processing until the comm is created, then more messages are processed
(that was a very subtle bug to track down several years ago :)
Ian Hunt-Isaak
@ianhi
I somehow missed that part of the sentence the first time I read :grimacing: - reading too fast + too much caffeine..
that does answer my question thanks!
Jason Grout
@jasongrout

It seems to me that the latter encompasses the former. If you are careful then the final state can encompass the initial state, but the converse is not necessarily true. Further, for story telling via emailing someone a notebook I at least would want to include an by hand modifications I made to a widget (e.g. highlighting part of a display)

Yes, I think what is most intuitive to users is to save whatever is currently on the page (i.e., current widget snapshot).

I still wish there was some way to accommodate the ethos of the notebook - that outputs are reproducible from the inputs
or at least signify that the assumption is violated for this particular output
Ian Hunt-Isaak
@ianhi
It's more than just that one output though? Because subsequent outputs can also depend on the widget from a cell above, and be executing out of order
like this mind-boggle:
image.png
Would all of those cells get that signification?
This is a problem without a global optimum? i.e. there is no perfect way to keep the outputs reproducible from inputs? Short of recording all mouse and keyboard interactions
(which you can do with matplotlib figures :D https://github.com/ianhi/mpl-playback)
Jason Grout
@jasongrout
Furthermore, in the above example, some of the later cells can also set the slider value, which affects cells above it.
Furthermore, we already have this problem in the jupyter display protocol (even without widgets) with the display update mechanism
Ian Hunt-Isaak
@ianhi
🤯
Jason Grout
@jasongrout
Yeah, definitely a thorny issue
Thomas Aarholt
@thomasaarholt
Maybe just make it clear that this choice is down to the programmer who writes the notebook? The existence interactable cell output almost by definition render it not possible to always have a "run cell to reproduce output" approach.
Jason Grout
@jasongrout
Yes, on the one hand, we don't want to be so strict (e.g., knitR) about reproducibility that it prevents interactive exploration. On the other hand, it would be great if there was a way to have reproducibility, or signify it.
Perhaps this is a larger conversation about adapting tools to workflows
Thomas Aarholt
@thomasaarholt

signify it.

I like the idea of that

Jason Grout
@jasongrout
And perhaps there are ways that we can accommodate both a strict workflow and a not-so-strict workflow
Anyways, I've been thinking about these things for a long time, as I suppose many others have.
agoose77
@agoose77:matrix.org
[m]
@jasongrout I feel that a saved notebook should represent the state of the document as seen by the author before pressing save. Therefore, saved interactive outputs should reflect their state immediately following their last update (e.g. User input, eventful code, cell execution).
This doesn't solve saved notebook widgets being non interactive, but I think that's an acceptable 'you need to execute the notebook' stopping point
Simeon H.K. Fitch
@metasim
Sorry for the n00b question, but I can't seem to find the API/Reference docs (not the User Manual). Are they being generated and published along with the User Manual (and it's right in front of me), or am I looking for something that doesn't exist?