input() not supported

[DrXyzzy]

GNU Octave input() function appears not to be supported. Note that IPython kernels support python input() and raw_input().

Other terminal input functions, menu(), yes_or_no(), and kbhit(), are also unsupported. But input() is probably the one that adds most value.

[dsblank]

input() should be doable, I think. We'd just have to have a way of identify an input prompt for pexpect, and then hooking that up to ask the interface (notebook or console) for the input. That already exists for non-pexpect-based metakernel notebooks.

[DrXyzzy]

Thanks. Looks as if emacs octave mode is doing an expect type of approach. So this might help. https://github.com/emacs-mirror/emacs/blob/master/lisp/progmodes/octave.el

[blink1073]

Thanks @DrXyzzy, this line looks promising: https://github.com/emacs-mirror/emacs/blob/d40073f017ffb3dee2266f356c127ef587c40b71/lisp/progmodes/octave.el#L616. Worst case, we can override the input() method and force it to add a marker to the end.

[DrXyzzy]

Cool. I looked for a hook for terminal input in Octave sources with idea of adding a marker, but didn't see one, e.g. http://octave.org/doxygen/4.0/de/d4c/input_8cc_source.html#l00746. I wasn't sure you could override (aka "monkey patch") a built-in method in Octave without losing access to the original one.

[blink1073]

AFAIK only a raw keyboard call produces a predicable debug> prompt, which we are already catching. Yep, see this thread: http://octave.1599824.n4.nabble.com/overriding-builtin-functions-td1624376.html.

[DrXyzzy]

@blink1073 looks as if dispatch() was removed from Octave in 2010 :-( http://octave.1599824.n4.nabble.com/deprecated-function-dispatch-td3094067.html

Regarding replacement, there is advice to use @CLASS... http://octave.1599824.n4.nabble.com/Dispatch-function-td4676945.html

[blink1073]

Where there's a will there's a way 😉

[blink1073]

Thanks for looking into that!

[blink1073]

Confirmed, this totally works:

## -*- texinfo -*-
## @deftypefn  {Function File} {} input ()
## @deftypefnx {Function File} {} input (@var{PROMPT})
## @deftypefnx {Function File} {} input (@var{PROMPT}, 's')
## Print PROMPT and wait for user input
##
## @end deftypefn

function ANS = input (varargin)
    % let the builtin handle the nargin error
    if (nargin == 0)
      builtin('input')
    end
    varargin{1} = sprintf('%s__stdin_prompt>', varargin{1});
    ANS = builtin('input', varargin{:});
endfunction

[blink1073]

Updated the above to actually do what we want. By Jove, this is going to work!

[blink1073]

Notes:

• For menu, we have to search for "Select a number: ".
• For yes_or_no we have to search for "(yes or no) ".
• For kbhit we override and stuff in a prompt if nargin == 0 (otherwise it doesn't wait).
• For keyboard and pause we override and always stuff in a prompt.
• For pause and kbhit we add in a note about entering any value.
• Copy the texinfo from the original file found as find . -name <foo>.m.

[blink1073]

Actually, menu uses input(), so we get that for free!

[DrXyzzy]

Sweet. The builtin menu() doesn't even work with CLI octave unless you have working JVM and X11. But input() alone will cover a large number of missing use cases.

[DrXyzzy]

Note: My comment about menu() requiring Java applies to GNU Octave 4.0.0 running on SageMathCloud, Ubuntu 15.10, from command line or emacs octave mode.

[blink1073]

WIP in #60.

[haraldschilly]

could anyone check if this works in 0.24.5? i.e.

x = input("x = ")
2*x+1

gives 5 for input 2

[blink1073]

This is what I see locally (and what I'd expect):

I'm running on OSX 10.11.6.

[haraldschilly]

hmm, our notebook server is a bit older, maybe that's the problem.

[blink1073]

You haven't rolled out the new kernel on SMC, correct?

[haraldschilly]

well, I did, for about 10 minutes, but the above just hangs at "x =" and that's it. So I rolled back to 0.21.0 (what it was before the update, and there input works)

There are also a couple of other libraries involved, maybe it's a bad combination of them.

[haraldschilly]

Below is what pip installed in python2 when it broke. After that, I just changed octave-kernel back to 0.21.0 and it works. Maybe there are also other libs involved not in that list. My primary suspect is of course metakernel :-)

• appdirs-1.4.0
• certifi-2017.1.23
• metakernel-0.18.4
• octave-kernel-0.24.5
• packaging-16.8
• pathlib2-2.2.1
• pygments-2.2.0
• pyparsing-2.1.10
• setuptools-34.0.2

[blink1073]

The difference between this version and 0.21.0 is 0.21.0 used the add_input_event_hook function to get the prompt to work. However, that function does not work on Windows, so I instead overloaded the input function directly. Looks like we may have found a place where that does not work either.

[blink1073]

Which OS and version of Octave are you running?

[haraldschilly]

a slightly outdated Ubuntu 15.10, Octave is 4.0.0

I don't remember, do you have an account on SMC and a dev project? You could check those details there, and I could even see to set it up in a way that it is broken.

[blink1073]

Drat, I just confirmed the behavior in Ubuntu 14.04. I do have a SMC and a test project. I'll get this working on Ubuntu 14.04 and report back (might not be until this weekend).

[DrXyzzy]

I am not sure add_input_event_hook http://octave.org/doxygen/4.0/de/d4c/input_8cc_source.html#l01179 gives a robust solution on ubuntu. The comments say

Add the named function or function handle @var{fcn} to the list of functions
to call periodically when Octave is waiting for input.

I sometimes see hundreds of calls to the input hook function for a single call to octave input() with octave_kernel 0.21.0 on ubuntu 15.10 when using jupyter_client. I'm still trying to make the problem reproducible.

[blink1073]

Yep, another reason I stopped using that function.

[DrXyzzy]

Also I wonder if pause with no arguments might be more user-friendly if hitting Enter could also break the pause so users could break the pause from keyboard. I understand waiting for any key is problematic. It would be the equivalent of input(""). This could help with sage worksheet support for octave_kernel.

[blink1073]

That is the behavior of pause in 0.24.5.

[blink1073]

But it still relies on the function override working...

[DrXyzzy]

LOL. Ok, I will wait. As @haraldschilly noted above, there are problems installing the most recent kernels on SMC. When I install octave_kernel as non-root using pip install --user..., the override functions @input etc don't seem to be installed under ~/.local/ along with the rest of the package.

[blink1073]

That would do it!

[blink1073]

Wow, this is definitely a case of "works on my machine". I was not including any of those files in the wheel or the tar releases. Nice catch, @DrXyzzy!

[blink1073]

The tarball has them, but not the wheel.

[blink1073]

I just tried 0.24.6 on Ubuntu 14.04 and all is right in the world ;).

[DrXyzzy]

Works in jupyter notebook with user install on SMC, including friendly pause. Nice! It will be later today before I can try the interface with sage worksheets. I was seeing a problem not receiving the message on jupyter message protocol stdin channel with jupyter_client. This is with code that works with python's input() from jupyter_client.

[blink1073]

This kernel is using the raw_input from ipykernel under the hood.