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

"No renderer could be found for output" message in outputs #6216

Closed
BenRussert opened this issue Apr 18, 2019 · 14 comments · Fixed by #6559
Closed

"No renderer could be found for output" message in outputs #6216

BenRussert opened this issue Apr 18, 2019 · 14 comments · Fixed by #6559
Labels
good first issue status:resolved-locked Closed issues are locked after 30 days inactivity. Please open a new issue for related discussion.
Milestone

Comments

@BenRussert
Copy link

Describe the bug
When using the scrapbook package, the glue function anywhere in a cell produces a confusing message:

No renderer could be found for output. It has the following MIME types: application/scrapbook.scrap.json+json

No outputs are expected for the glue function alone.

To Reproduce
Steps to reproduce the behavior:

# !pip install nteract-scrapbook
import scrapbook as sb
sb.glue("hello", "world")

or

# in the same cell:
x = "world"
sb.glue("hello", x)
x

You would expect "world" in output, but not the message. The message is prepended however:

Screenshots

jupyter-lab-no-render-message

Expected behavior
No output or warning message

@jasongrout jasongrout added the tag:Extension Idea Ideas for interesting extensions that live outside of JupyterLab core. label Apr 18, 2019
@jasongrout jasongrout added this to the Reference milestone Apr 18, 2019
@jasongrout
Copy link
Contributor

It sounds like this would be a great mimerender extension to provide a renderer for this mimetype. I'm a little surprised that scrapbook doesn't seem to provide a text/plain representation to show in frontends that don't understand that mimetype.

@MSeal
Copy link

MSeal commented Apr 18, 2019

Since the display type is meant to recall data pragmatically, it doesn't give a plain text mimetype representation. Scraps with display contents (like images) will give the normal mimetype representations one would expect to render. None of the jupyter interfaces currently render the scrapbook data mimetype, but it might be interesting to enable such rendering at some point in the future to view the data. It's intended purpose is to allow for capturing data or references to data in the notebook object that can be recalled by another process, thus an invisible rendering was the original approach.

@jasongrout
Copy link
Contributor

Ah, thanks. So what I'm hearing is that JupyterLab shouldn't try to be helpful here in rendering an error?

@jasongrout
Copy link
Contributor

(I'll note for myself and others that the message spec only mandates text/plain in mimebundles in a pager or execution_result message, not in display_data messages)

@jasongrout jasongrout modified the milestones: Reference, 1.1 Apr 18, 2019
@jasongrout
Copy link
Contributor

No output or warning message

Sorry, I think I misread the desired behavior above. It seems the answer is: "yes, don't render any output or error."

Bumping to a good first issue for 1.0.

@jasongrout jasongrout modified the milestones: 1.1, 1.0 Apr 18, 2019
@jasongrout jasongrout added good first issue and removed tag:Extension Idea Ideas for interesting extensions that live outside of JupyterLab core. labels Apr 18, 2019
@MSeal
Copy link

MSeal commented Apr 18, 2019

Yep, was just giving some context. The "yes, don't render any output or error." is correct.

@MSeal
Copy link

MSeal commented Apr 18, 2019

Thanks!

@saulshanabrook
Copy link
Member

@jasongrout So to be clear, is your suggestion that if we cannot find any renderer, we simply don't render an output instead of displaying this error message?

@jasongrout
Copy link
Contributor

jasongrout commented Apr 22, 2019

@jasongrout So to be clear, is your suggestion that if we cannot find any renderer, we simply don't render an output instead of displaying this error message?

Correct (which is what was asked in the OP as well as asked by @MSeal).

@jasongrout
Copy link
Contributor

This is now marked as a good first issue. The error message is generated at

widget.node.innerHTML =
`No ${model.trusted ? '' : '(safe) '}renderer could be ` +
'found for output. It has the following MIME types: ' +
Object.keys(model.data).join(', ');

@vidartf
Copy link
Member

vidartf commented Apr 28, 2019

Maybe it still makes sense to display this message if the notebook is not trusted, and a valid renderer would have been available if it was?

@jasongrout
Copy link
Contributor

Maybe it still makes sense to display this message if the notebook is not trusted, and a valid renderer would have been available if it was?

That makes sense to me. In that case, the error message should probably reflect the idea that the trust status caused it not to render.

@saulshanabrook
Copy link
Member

saulshanabrook commented May 22, 2019

The classic notebook does not create an output div when there is no renderer available. The consensus in the meeting is that we should do the same, if we cannot render an output, then we could not create a div.

But this might be slightly painful to change, based on Phosphor messages lining up with DOM children. For 1.0, it would be good to look into this change.

For now, to get around this, you could try outputting a text/plain with an empty body.

jasongrout added a commit to jasongrout/jupyterlab that referenced this issue Jun 12, 2019
… types.

Fixes jupyterlab#6216

This does render a div for outputs corresponding to things we can’t render, since we need the list of widgets to correspond to the output messages.
@lock
Copy link

lock bot commented Aug 6, 2019

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

@lock lock bot locked as resolved and limited conversation to collaborators Aug 6, 2019
@jasongrout jasongrout added the status:resolved-locked Closed issues are locked after 30 days inactivity. Please open a new issue for related discussion. label Aug 9, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
good first issue status:resolved-locked Closed issues are locked after 30 days inactivity. Please open a new issue for related discussion.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants