Do eval and exec for repl evaluate requests

[karthiknadig]

This change is part of the debug REPL changes needed for VS

[DonJayamanne]

I'll have to check how this works with VSC as well. That because when evaluating expressions in the VSC debug console context=repl (My plan was to use CMD_CONSOLE_EXEC though that seemed to write to stdout and stderr with results).

Just out of curiosity, what happens if we enter an invalid variable or expression, such as xyz or print(xyz. Does the error message get printed out, the old debugger used to print the error message (if it was an invalid syntax of invalid variable), this is what happens when CMD_CONSOLE_EXEC is used.

[karthiknadig]

Yep the error will be printed to the output.

[DonJayamanne]

If we're sending the traceback, then we need to filter the traceback to hide the internals.
Currently we're sending too much (internal) information back to the user. I would have thought just the error message would suffice. what's the current behaviour in VS. In VSC we just display the error message.

[karthiknadig]

Actually the comment there is incorrect. When i had initially written this it was returning trace back. but this is what you will see:

[karthiknadig]

The traceback you see in #219 comes from exec itself. We may have to do a bit of trickery to avoid this. I tried using sys.displayhook to capture this info but that did not help. @int19h has a few ideas on how to fix that.

[DonJayamanne]

I had a similar idea (when using CMD_CONSOLE_EXEC) but that's where I got stuck this evening. Gets complicated when you evaluate a function that starts a thread which prints stuff (sounds too far fetched).
Anyways, would like to see how it is that the stack trace isn't printed for your code, but only for VSC. Is it because you're ignoring what comes from output event?

[karthiknadig]

The traceback is printed in the console output, in the REPL window we print what is returned via the protocol. the screen sot was from the REPL window.

[int19h]

In REPL scenarios, everything that normally goes into stdout/err is supposed to go to REPL - it just isn't wired yet. But once we do, we will have that problem.

[DonJayamanne]

• Whey aren't we using CMD_CONSOLE_EXEC command, after all the value for context is repl

• it just isn't wired yet. But once we do, we will have that problem.

  • I think I understand, VSC is getting the stdout/stderr messages via the protocol as VSC is passing in the value true for the setting redirectOutput. I'm assuming VS doesn't use this.

[karthiknadig]

I will give CMD_CONSOLE_EXEC a try in the morning, and update this PR if it seems better.

[karthiknadig]

CMD_CONSOLE_EXEC does not work the way we want it. For the following REPL statements, this is the result we get:

In REPL window:

>>> random.random()
False
>>> import random
False
>>> random.random()
False
>>> 

In Console Window:

Traceback (most recent call last):
  File "c:\git\ptvsd\ptvsd\pydevd\_pydevd_bundle\pydevd_exec2.py", line 3, in Exec
    exec(exp, global_vars, local_vars)
  File "<input>", line 1, in <module>
NameError: name 'random' is not defined
<xml><var name="" type="bool" qualifier="builtins" value="False" />
</xml>

<xml><var name="" type="bool" qualifier="builtins" value="False" />
</xml>

0.9210117288960727
<xml><var name="" type="bool" qualifier="builtins" value="False" />
</xml>

XML response received from pydevd:

>>> random.random()
<xml><var name="" type="bool" qualifier="builtins" value="False" />
</xml>

>>> import random
<xml><var name="" type="bool" qualifier="builtins" value="False" />
</xml>

>>> random.random()
<xml><var name="" type="bool" qualifier="builtins" value="False" />
</xml>

As you can see it always return false.

[DonJayamanne]

All good at my end 👍