Distinction between output and result messages

[nthiery]

Hi,
I just noticed with @takluyver that the xeus-cling output's are not prefixed with [Out ??] prompts:

In [1] 1 + 1
(int) 2

instead of

In [1] 1 + 1
Out[1] (int) 2

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.

[SylvainCorlay]

In fact, the xeus library (implementing the protocol) supports both streaming cout and cerr to the front-end displaying execute results, which are the two types of outputs involved here

But for the xeus-cling kernel, we don't use execute results. The reason is that we capture all the standard and error stream content, including the output, so we avoid the duplication by not using the returned value for an execute_reply message.

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.

[gouarin]

I think we can have the same behavior. The execute_reply will happen in xeus-cling only if the last line doesn't have a semicolon.

And cling must be able to give us this information because the behavior is different if you have or you don't have this semicolon. If not, we can add a regexp to know if the last string is followed by a semicolon or not.

Or I missed something ...

[SylvainCorlay]

I don't think you missed anything!
Ideally, I would prefer not to rely on more regex parsing the code.
Ideally, the behavior should be configurable with the cling API.

[nthiery]

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!
No rush though, since we won't be able to put a new xeus-cling version in production before the end of the semester.

[nthiery]

Any thoughts about the error message situation?

[SylvainCorlay]

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...

[takluyver]

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.

[SylvainCorlay]

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).

[takluyver]

• Error message on IOPub.
• Error fields in the execute_reply message on the shell channel.

It looks like we're not going to clean up the duplication, so it's best to send both.

[gouarin]

I looked at the cling source code. It seems difficult to have the information from cling to know if the end of the last string line is a semicolon or not. It is internal stuff in cling interpreter.

@takluyver could you give two Python examples to illustrate the behavior of the error messages ? one for Error message and one for Error fields.

[SylvainCorlay]

I looked at the cling source code. It seems difficult to have the information from cling to know if the end of the last string line is a semicolon or not. It is internal stuff in cling interpreter.

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.

[takluyver]

could you give two Python examples to illustrate the behavior of the error messages ?

Here's an example in bash_kernel. The call to send_response sends the error message on IOPub, and the return value is the content which will become the execute_reply message.

https://github.com/takluyver/bash_kernel/blob/0966dc102d7549f5c909c93de633a95b2af9f707/bash_kernel/kernel.py#L163-L169

[SylvainCorlay]

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, (int) 2 would be printed twice, once without the Out[] prompt, then once with it. I would just like to disable the printing of this in the redirected standard output. Ideally, there would be no regex involved...

[gouarin]

@SylvainCorlay you're right. So the idea could be to add an output stream in the Value class of cling in order to specify the output when we call Value::dump. This is this function which adds the output of the last line without semicolon. The default value could be cling::outs and in xeus-cling we can change this output stream.

I can open an issue in cling if you are ok with this solution.