Thu 03 Dec 2015 04:27:16 AM UTC, comment #13:
The code for kbhit/pause is completely different than the code for kbhit/pause. I fixed the behavior on Windows in this cset http://hg.savannah.gnu.org/hgweb/octave/rev/a8ee668e7fd7. This will be a part of the 4.0.1 bug fix release.
|
Tue 02 Jun 2015 04:43:34 PM UTC, comment #12:
Retagging release from 4.0.0-rc2 to 4.0.0.
|
Sat 04 Apr 2015 07:28:41 PM UTC, comment #11:
My guess is there is no easy solution. Pause is a tricky issue, along with Cntrl-C/signaling, and the pager is another one I suppose. These are low-level things that haven't been worked out in the GUI's asynchronous paradigm.
|
Wed 01 Apr 2015 06:04:32 PM UTC, comment #10:
Is there something simple here, an option to the Windows Terminal, which sets line buffering and which we could disable when we create the terminal?
|
Mon 30 Mar 2015 06:16:07 PM UTC, comment #9:
OK, thank you. Sounds like a low level bug only made more confusing by the presence of the GUI. Seems like a 4.0-critical issue if Windows is playing a more significant role now.
|
Mon 30 Mar 2015 07:52:10 AM UTC, comment #8:
Sorry, the sentence
"(so I am using octave.exe as the starting executable)"
had no sense because I was also using octave-cli.exe and octave-gui.exe.
What I wanted to say was that I was not starting by the vbs...
Thanks
Giorgio
|
Mon 30 Mar 2015 07:39:51 AM UTC, comment #7:
Here I am.
Gone to the windows line command (cmd) then
cd C:\Octave\Octave-4.0.0-rc2\bin
(so I am using octave.exe as the starting executable)
then:
(1) octave-cli
I launch test_pause.m by Rik, everything is ok, four <enter> key strokes, each welcome by a number 1 to 4
BUT keys different from <enter> don't make the pause finish: they are bufferized and taken by the subsequent pause command.
(2) octave
the GUI opens, I launch test_pause.m: I need only two <enter> key strokes, and numbers appear in pairs: after the first <enter> I see 1 then 2, after the second <enter>, I see 3 then 4. Again, key strokes different from <enter> don't oblige the pause to finish, and are bufferized for the future...
(3) octave --no-gui
like (1)
(4) octave --no-gui-libs
like (1)
The automatically created Windows desktop start links to octave use octave.vbs in
C:\Octave\Octave-4.0.0-rc2
instead of directly calling the various octave executables in
C:\Octave\Octave-4.0.0-rc2\bin
but the results (as said in the previous messages) are alike.
Thanks
Best regards
Giorgio
|
Mon 30 Mar 2015 06:35:41 AM UTC, comment #6:
Could you try your same test with a couple more cases?
[system@] octave
You've indicated this configuration has problems
[system@] octave --no-gui
You've indicated this configuration has problems
[system@] octave --no-gui-libs
[system@] octave-cli
The first two cases activate the com interface with the Qt environment. The latter two don't, if I recall correctly.
|
Mon 30 Mar 2015 05:46:47 AM UTC, comment #5:
I also checked the CLI version (that is, starting with octave.vbs --no-gui).
The behavior is almost identical.
Almost everything works the same: pause() returs only if I type <enter> and it does not return after any other key, bufferizing them all (so that they are taken by the following pause()s).
The difference is that the <enter> key does not leave the LF bufferized, so that the sequence:
pause <enter> [command starts and waits]
<enter> [command exits as expected]
pause <enter> [command starts and waits, no LF bufferized]
<enter> [command exits as expected]
works fine. But when you insert a <any other key>, pause() does not exit, while the subsequent pause() exits immediately.
So for me the problem is not limited to the GUI: it is only the interpretation of the <enter> key that is different.
Best
Giorgio
|
Mon 30 Mar 2015 04:11:36 AM UTC, comment #4:
There is something definitely wrong with the GUI and the terminal. pause() is supposed to be a character-oriented input and any key hit, not just <RETURN>, should terminate the input. However, on Windows it appears that the input is line-buffered. I can type a whole sentence after running pause() and it is only when I hit <RETURN> that it is processed.
In the same vein, kbhit is supposed to return a single character and it too waits until a <RETURN> is pressed.
|
Mon 30 Mar 2015 01:13:51 AM UTC, comment #3:
Attached is a straightforward test script test_pause.m.
You should need to press Enter 4 times to proceed through the script and each key stroke will be numbered. Executing on Linux in the CLI or GUI is fine. On Windows XP, the CLI works fine. It is only the GUI on Windows XP which has a problem.
Just to confirm, perhaps Giorgio can test whether running the CLI works for him. If so, then this is a GUI terminal interaction problem.
(file #33484)
|
Sun 29 Mar 2015 06:28:38 PM UTC, comment #2:
Hi Dan, thanks for your reply.
Trying with any other keys (say "p" just to fix ideas) confirms imho that pause() really has buffering problems.
Pause() should return immediately after typing "p", but it doesn't. The key is buffered and pause() returns only when I press <enter>.
Here is what happens:
pause <enter> [octave waits as it has to]
p [octave still waits]
<enter> [octave returns, possibly for the "p"]
pause <enter> [octave returns immediately, possibly for the CR]
pause <enter> [octave returns immediately, possibly for the LF]
pause <enter> [octave waits and finally does its duty]
and so on.
If I enter more letters (e.g. "pp" instead of only one "p") and begin the same game, one more pause() will return immediately after being given.
Thanks
Best regards
Giorgio
|
Sun 29 Mar 2015 05:55:04 PM UTC, comment #1:
That sounds plausible. pause() is supposed to respond to any key. What happens if you type a key other than Enter, say, 'p'? Does pause() work as expected then?
|
Sun 29 Mar 2015 01:18:37 PM UTC, original submission:
Hi all, here is the strange behavior of the "pause" command, when used with no parameter, that I am experimenting in Windows.
In a sequence of "pause" commands, the first "pause" works (it waits until I press "enter"), the second doesn't (and returns immediately), the third works, the fourth doesn't... and so on.
IMHO, and without knowing anything about octave internal working, I'd suppose that the CR+LF given by the "enter" key is acting as a double entry, so that the CR makes the first "pause" to return, while the LF remains buffered, and is eaten by the second "pause", which returns as soon as it is issued.
Thanks
Giorgio
|