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

Python editor should display stdout on error. #692

Open
NALStudio opened this issue Aug 30, 2023 · 0 comments · May be fixed by #694
Open

Python editor should display stdout on error. #692

NALStudio opened this issue Aug 30, 2023 · 0 comments · May be fixed by #694

Comments

@NALStudio
Copy link

NALStudio commented Aug 30, 2023

I have two small gripes with the Python editor in digabi. As they are relatively different, I've decided to split them into two separate issues. The other can be found here: #693. I might take a crack at implementing these myself over the coming days and I'll make a single pull request for them both if I manage to succeed.

The problem

While programming, we often run into crashes where knowing more than just the line the exception happened is crucial to debugging. Consider the below scenario:
image
Here we are only able to see which iteration crashed and we have no context on how many iterations were ran before crashing. Not being able to read the stdout really hinders our debugging efforts since we have no way of logging to the console how many times the function ran before crashing. The reason for the crash becomes much more obvious in a regular terminal where we have more context on what had ran before the crash happened:
image

Seeing the stdout would also make debugging ValueErrors much easier since the offending function's arguments could be dumped to the console before running the function.

On the contrary, when the application doesn't crash, the hidden stderr might omit some crucial information printed on stderr without an exception being raised. Consider this for example:
image
The "Test 2" print message has completely disappeared and without knowing that a message should have been printed, the user would be completely oblivious to the fact that something was even printed on stderr. This is how it looks on a normal terminal instance where "Test 2" is also printed:
image

Possible solutions

Solution 1: Always show stderr when it has content

Hide both stdout and stderr before running an application and only show them if they contain any text. (Make them visible on every call to printStdout or printStderr) This solution seems to be the easiest to implement and the one I will more likely steer to if/when I decide to try to implement these two issues if no maintainers of this repo have a strong bias towards either of these two solutions. The only problem I see with this approach is that it doesn't provide a clear relation between stdout and stderr and will make it hard to determine whether a message on stderr came before or after a specific message on stdout.

Solution 2: Merge stderr with stdout

Solution 2 mimics more the way different terminals like to handle stderr, which is to merge them with stdout and show both on the same output. Like PowerShell for example:
image
As this might be confusing for people who do are not very versed in Python and its errors, the stderr messages should probably be coloured red to separate them from stdout and make it easier for Python novices to read. I personally like this idea more as it resolves the problems in Solution 1, but the scope of this change feels a tiny bit too big to be practical to implement. Especially since my HTML skills are non-existent. I might still experiment with implementing this if there is no clear preference on Solution 1 over Solution 2, but I'll more likely fall back on Solution 1 as it's much easier to retrofit onto this codebase and doesn't require any changes to HTML.

Edit: Regarding Solution 2, colouring the stderr shouldn't be a problem since ANSI colour codes don't work anyways and thus we don't need to be afraid of breaking anything or do any runtime colour checks:
image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
1 participant