-
Notifications
You must be signed in to change notification settings - Fork 303
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
Distinction between output and result messages #67
Comments
In fact, the xeus library (implementing the protocol) supports both streaming But for the If we find a way in the API of the cling interpreter to get that content without it being sent to the standard output, we could have a behavior closer to the one of the python kernel. |
I think we can have the same behavior. The And Or I missed something ... |
I don't think you missed anything! |
I just realized that this issue is very relevant for teaching. Grasping the distinction between printing and returning is one of the main difficulties for our beginning students. Anything that enhance visually the distinction will help. So a solution will be very welcome! |
Any thoughts about the error message situation? |
xeus-cling does not do much more about errors than printing into the error stream, which is redirected to the front-end (styled in red in the notebook). Maybe @takluyver / @ivanov / @ellisonbg would have an opinion about this. We would be happy to follow a better practice. Regarding the standard output stream versus execute reply, as detailed above, this was a workaround for the redirection of the standard output which also prints the returned value... |
Is it possible to detect whether execution caused an error or not? If so, it would be useful to send back an indication that the error occurred. There are currently two ways to do that, and we're just working out if it's possible to condense them down to one. |
Yes! we catch exception in the kernel layer. How would you like errors to be indicated in the messages (besides outputing things in the error stream). |
It looks like we're not going to clean up the duplication, so it's best to send both. |
I looked at the @takluyver could you give two Python examples to illustrate the behavior of the error messages ? one for |
This is not really what I would like to do. Instead, I would just like to be able to disable the use of the standard output for execution results by cling, which would be cleaner. |
Here's an example in bash_kernel. The call to |
It is not a problem to have exactly the same behavior as in IPython with xeus cling. The only thing issue is that with the current way we interact with cling, |
@SylvainCorlay you're right. So the idea could be to add an output stream in the Value class of I can open an issue in |
This is fixed in master. |
@takluyver @nthiery we released xeus-cling We also support displaying rich output as per example: Check out the binder! |
Yippee! Thanks! |
I am really excited about rich rendering of outputs. Beyond widgets and images, we can display arbittary mime types for which we have a renderer in jupyterlab or the classic notebook... |
I just tested xeus-cling 0.2.2, and can confirm that Steps to reproduce:
Watch out students, gonna grade you :-) |
We should also update |
Hi,
I just noticed with @takluyver that the xeus-cling output's are not prefixed with [Out ??] prompts:
instead of
This suggests that the output messages are not tagged as "execute_result" as one would expect.
Potentially related: we noticed with @gouarin that nbgrader does not pick error messages when grading
xeux-cling
notebooks. @takluyver just mentionned that there are two types of error messages which is a regular source of confusion between kernels and frontends. Maybe that's what's happening here, with nbgrader expecting one type, and xeus-cling sending the other.The text was updated successfully, but these errors were encountered: