Input() command for the discord bot

[ghost]

Hey Makers of the RTFMbot! Just wanted to say I admire the work you have put into the bot, it works amazingly on my server! But i have a question/request: Would it be possible to integrate the input() command from python into the bot so that when running the code, the bot asks for input to enter in its code? Thank you very much Morgan Penny

[Unactived]

The bot intends to work in a one code-execution / one output paradigm, which serves well its intent to primarily work as a source of actual examples and really quick tests which can run on their own. Inputs, if known in advance, can be supplied in the command (see wiki). The API used by the bot to perform code-execution, TryItOnline, cannot support an interactive approach and, besides the fact that he is currently occupied, I do not think its creator and maintainer would want to add it, the first sign being the 60-seconds limit to all executions originating from a lot of attempted abuse (which the bot suffers from too).

A REPL would only mean for the API to maintain active connections, but for the bot it would also mean keeping track of discord users invoking commands for extended periods of time while also maintaining alive sessions with the website (which can only be interacted with through the stateless HTTP protocol).

In the current state of the API, which feeds inputs line by line as the running program asks for it, no input results in an EOF which then produces varying behaviours among languages. For instance in Python you literally get an EOFError, while in Ruby the program carries on while gets returns nil instead of a string. For a feeling of REPL the bot would have to manipulate the result of the execution given to the end-user, ask for a missing input, then go through the whole execution again, adding the missing input, as he does not have access to the execution state (which would also be a cost to store if it had).

Moreover detecting these unfulfilled inputs after execution is not only strongly language-dependent but also hard in practice and in a lot of edge-cases. What if the Python's EOFError is caught in an except making the program crash at a different point? How will the bot tell it was because of a missing input? Another way would be to tell before executing, (or actually before aborting the execution since we conclude it would not work anyway). This means introducing an overhead prior to all executions of the language having the feature in order to parse the user code, inputs and even compiler flags and command-line options. A parsing which is furthermore non-trivial, since you would have to tell functions from strings, and anticipate control flow which adds multiple inputs from a single call in the source, or no input because of a call not reached, this being without also taking in account edge-cases which can lead to input calls without even having the word input in the code. In the end we really are running the program twice just in order to tell an input isn't filled.

Thus this feature is not possible, as telling inputs somewhat reliably requires doing exactly what the language does, or making assumptions from the output of executions.

[ghost]

Thank you so much for the explanation and consideration! I understand that it would not be possible at this time, and i appreciate the help.

On 19. Oct 2020, at 18:53, FrenchMasterSword notifications@github.com wrote:

 The bot intends to work in a one code-execution / one output paradigm, which serves well its intent to primarily work as a source of actual examples and really quick tests which can run on their own. Inputs, if known in advance, can be supplied in the command (see wiki). The API used by the bot to perform code-execution, TryItOnline, cannot support an interactive approach and, besides the fact that he is currently occupied, I do not think its creator and maintainer would want to add it, the first sign being the 60-seconds limit to all executions originating from a lot of attempted abuse (which the bot suffers from too).

A REPL would only mean for the API to maintain active connections, but for the bot it would also mean keeping track of discord users invoking commands for extended periods of time while also maintaining alive sessions with the website (which can only be interacted with through the stateless HTTP protocol).

In the current state of the API, which feeds inputs line by line as the running program asks for it, no input results in an EOF which then produces varying behaviours among languages. For instance in Python you literally get an EOFError, while in Ruby the program carries on while gets returns nil instead of a string. For a feeling of REPL the bot would have to manipulate the result of the execution given to the end-user, ask for a missing input, then go through the whole execution again, adding the missing input, as he does not have access to the execution state (which would also be a cost to store if it had).

Moreover detecting these unfulfilled inputs after execution is not only strongly language-dependent but also hard in practice and in a lot of edge-cases. What if the Python's EOFError is caught in an except making the program crash at a different point? How will the bot tell it was because of a missing input? Another way would be to tell before executing, (or actually before aborting the execution since we conclude it would not work anyway). This means introducing an overhead prior to all executions of the language having the feature in order to parse the user code, inputs and even compiler flags and command-line options. A parsing which is furthermore non-trivial, since you would have to tell functions from strings, and anticipate control flow which adds multiple inputs from a single call in the source, or no input because of a call not reached, this being without also taking in account edge-cases which can lead to input calls without even having the word input in the code. In the end we really are running the program twice just in order to tell an input isn't filled.

Thus this feature is not possible, as telling inputs somewhat reliably requires doing exactly what the language does, or making assumptions from the output of executions.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.