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

Merge stdin, stdout and stderr to better imitate a standard terminal #694

Draft
wants to merge 9 commits into
base: master
Choose a base branch
from

Conversation

NALStudio
Copy link

@NALStudio NALStudio commented Sep 2, 2023

Important

This is a draft PR as there still are some problems yet to be resolved. See Unresolved Problems for more info.

resolves #692
resolves #693

Behaviour Comparison

Previously raised issues

input() missing from output (#693)

image
Old Behaviour

image
New Behaviour

image
Console Behaviour

Program output swallowed by exception (#692)

[!NOTE]
The messed up exceptions are a bug/feature with boilerplate error string removal, but was left as is as it was out of the scope of this PR. I can fix this in another PR if needed.

image
Old Behaviour

image
New Behaviour

image
Console Behaviour

Error swallowed by program output (#692)

image
Old Behaviour

image
New Behaviour

image
Console Behaviour

New behavioural changes

Switch input() prompt from __repr__ to __str__

image
Old Behaviour

image
New Behaviour

image
Console Behaviour

Raise exception if input() cannot return a str object

image
Old Behaviour

image
New Behaviour

How input's behaviour is documented

image

As you cannot cancel the input operation on Console, we cannot really compare our behaviour to it. Instead we must compare it to the documented behaviour. While cancelling the operation isn't documented, I felt that raising an exception was the more sane option since type checkers such as Pyright (see below) define that an input must only return an object of type str.
image

[!NOTE]
We do not completely implement the input() spec as we do not raise the documented auditing events. This can be implemented in another PR if necessary, but was purposefully left out as it has such a niche usage, but would require extensive testing, for which I don't really have the resources right now.

Implementation Details

Usually I wouldn't explain the implementation, but I felt it was necessary due to the sheer amount of changes made.

General

The separate code-error element was removed and errors were redirected to the code-output element. The differentiation between stdout and stderr was removed and the code output is now just referenced as output. A colour can now be passed when printing an output which is currently used by stderr and input().

Stderr

As stdin and stderr is now consolidated to a single place, stderr has very little custom functionality over the standard stdout.
When a stderr message is printed, the code-output element is tagged as errored by adding a custom class to it. CSS will detect this class and format the output with a red border.
The message of stderr is forwarded to output with a red colour.

Stdin/input

The digabi's input() function was reworked to be more in-line with Python's inbuilt input(). This new function will override Python's default input() using the builtins module. All imports from overriding input() are now cleaned as well.
As we override the function in the builtins module, this forbids the user from using Python's builtin input(), but I felt that this wasn't such big of a problem as long as we can stick as close as possible to Python's default input() behaviour.

The new input() function behaves correctly when translating objects into prompts by using __str__ instead of __repr__ and writes the input prompt + value onto the output as blue.
Blue was chosen as from my limited research, it seemed to be the most distinct colour compared with error's red for people with colour blindness.

The new input() also raises an error when cancelled (we detect when prompt returns null) instead of returning None incorrectly. The error message looks kind of daunting and ugly since it's propagated from JavaScript. It can be looked into whether we can directly raise (against input()'s spec) a Python exception instead if the change is necessary. I personally think that the current format is good enough to be rolled out and can be changed later if needed.

To be able to pass this input() JavaScript function into Python, a custom digabi module was necessary. This module can be used in the future to expose more JavaScript functionality to the user if needed.

While input now skips stdin, there are still situations where stdin might be used (fileinput module for example). In these cases, we fall back on a basic JS prompt with a default message.

Input skipping stdin means that redirecting stdin does not work for input(),
but I don't see this as a problem since that functionality has never existed in digabi and I cannot come up with a scenario where one would run into the need to redirect stdin in digabi/Abitti if it's even possible.

Unresolved Problems

Accessibility

While I tried to retain the accessibility of the code editor, I am not certain whether everything is in order since I've never really programmed anything accessibility related before and my familiarity with this codebase isn't the best.

Tests

I wasn't able to run the provided Makefile or build the source successfully (I'm on Windows and the build tools seem to be have been made primarily for Linux) which means that I was implementing these features on a broken build. Due to this, I was not able to run any tests. These tests need to be rewritten due to the changes made to the code output, but as I can't run them, it wouldn't be wise to even try to write the tests myself.
If anyone who can get a working build of this repo would be able to write these tests, it would be massively appreciated.
As I wasn't able to run the Makefile, Pyodide needs to be updated by someone else as well if a new version is available.

While I'm very certain that I have tested all possible scenarios by hand, I cannot guarantee that this implementation is 100 % stable as my build was still broken. See below for what I mean by not being certain of 100 % stability.

Unknown Error

For some reason, I get spammed with errors every time I try to resize the code editor, but I decided to ignore this as it happens to me on earlier versions of koe-ohje as well.
This might just be an issue on my side as I wasn't able to compile the source successfully.

@NALStudio
Copy link
Author

NALStudio commented Sep 15, 2023

The damn npm scripts are all Linux-only... It seems like I've tried everything and I still can't get the tests to run.

I could try using WSL, but that's also a bit of a janky solution...

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

Successfully merging this pull request may close these issues.

Python editor should show stdin on output Python editor should display stdout on error.
1 participant