current status - 20180705

[stefanofornari]

A first bunch of known issues have been fixed and the console is now ready for prime time. Basic features are:

• line editing just as one would expect
• history
• tab-completion of vars and functions/methods
• proper handling of Ctrl+C
• customization initialization script in scripts/init.bsh read at start-up

TODO:

1. release a not-snapshot version with distribution package(*)
2. better tab-completion based on PR https://github.com/stefanofornari/BshConsole/pull/3

(*) I am not sure yet which version of beanshell I can include. It cannot be a snapshot, therefore maybe it will be b06 until a not-snapshot of beanshell is tagged.

[stefanofornari]

Today's status:

• Updated the way prompt is managed and displayed: with a few tweaks of jline, now prompt is directly displayed upon need, making synchronization between beanshell and jline not needed.This means that if the statement executed takes time, you will not see the prompt until the statement ends execution.
• Better tab completion as per pull request #3 has been implemented.

TODO:

• being able to interrupt the current execution (as long as it is interruptable): I am thinking about identifying two states for beanshell interpreter: PARSE and EXECUTE; a statement will then be run in a separate interruptable thread; upon Ctrl+C, if the interpreter is in PARSE status, the current input will be discarded as it is now; if instead the interpreter is in EXECUTE status, the exec thread/task is interrupted. (@nickl- this may be interesting for beanshell)
• release a not-snapshot version with distribution package(*)

(*) I am not sure yet which version of beanshell I can include. It cannot be a snapshot, therefore maybe it will be b06 until a not-snapshot of beanshell is tagged.

[nickl-]

identifying two states for beanshell interpreter: PARSE and EXECUTE; a statement will then be run in a separate interruptable thread; upon Ctrl+C, if the interpreter is in PARSE status, the current input will be discarded as it is now; if instead the interpreter is in EXECUTE status, the exec thread/task is interrupted.

Or if you just always treat it as "EXECUTE" you solve both problems and in a supported fashion without hacking the parser.

[stefanofornari]

yeah, that is how it is today. which forces you to shutdown the Interpreter (not the parser) in all cases. Instead, I would like to interrupt the running thread when the interpreter is in EXECUTE and just re-initialize the parser when it is in PARSE. there is no need to shutdown the Interpreter and then recreate it.

[stefanofornari]

At the end no additional status was needed for now, I am just checking if there is a task running. @nickl-, let me know if you are interested into a PR for this. I see it as a minimal compatible change: it just moves node.eval() in a separate thread using an executor. in the future we may think of having something like Ctrl+Z to send the execution of a command in the background. No changes to the interface are needed.

[nickl-]

@stefanofornari I am not sucre what exactly you are referring to, please assist by pointing me to the code in question.

[stefanofornari]

@nickl-, sorry if I was not clear. you may refer to this commit https://github.com/stefanofornari/BshConsole/commit/22715379119e6a30ddb2bb35376b2ec583c8a851 , in particular:

                    Object ret = null;
                    will = executor.submit(new Callable() {
                        @Override
                        public Object call() throws Exception {
                            return node.eval(callstack, THIS);
                        }
                    });
                    try {
                        ret = will.get();
                    } catch (Throwable t) {
                        if (t.getCause() instanceof TargetError) {
                            throw (TargetError)t.getCause();
                        }
                    }

[nickl-]

@stefanofornari it seems overly complicated =(