You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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:
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:
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:
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:
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:
The text was updated successfully, but these errors were encountered:
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:
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:
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:
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:
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:
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:
The text was updated successfully, but these errors were encountered: