Tue 13 Jun 2017 12:18:58 PM UTC, comment #15:
Version 3.8.1 is very old and no longer supported. Please, try with 4.2.1 which is the current version of Octave.
|
Tue 13 Jun 2017 01:48:14 AM UTC, comment #14:
This still happens on my Ubuntu 14, octave version 3.8.1
|
Thu 15 Sep 2016 09:09:00 AM UTC, comment #13:
I can no longer reproduce this issue on Windows with 4.2.0-rc1.
|
Mon 09 Dec 2013 01:00:11 AM UTC, comment #12:
The problem is still present in Octave 3.6.4
|
Sat 22 Jun 2013 03:00:33 AM UTC, comment #11:
I'm wondering whether this is actually related to Ctrl+C behavior on Windows platforms. Bug #32380 reports that on MinGW using Ctrl+C places more than 1 character in the keyboard buffer.
It seems possible that this is the reason that pause() is apparently skipped because when it goes to look for keyboard input it finds an additional character left over from the Ctrl+C invockation. I would assume that pause() is flushing the keyboard buffer before it starts waiting, but maybe this is not the case.
|
Fri 07 Jun 2013 05:47:13 AM UTC, comment #10:
I have the same problem as you, and to solve it I fake a pause by asking data to the user with the following code:
input("Press enter");
|
Fri 31 May 2013 12:44:15 PM UTC, comment #9:
Still present in 3.6.4 compiled with GCC 4.6.2 on Windows 7 64 bit (newest binary release from http://sourceforge.net/projects/octave/files/Octave%20Windows%20binaries/Octave%203.6.4%20for%20Windows%20MinGW%20installer/ )
|
Wed 19 Sep 2012 09:53:36 PM UTC, comment #8:
I was wondering what was going on with my Octave.
I just tested this and this bug is still present in 3.6.2 (Visual Studio 2010 compilation) on a Win 7 64-bit computer.
|
Sun 17 Jun 2012 11:12:49 AM UTC, comment #7:
I can confirm that last Windows version available as today (June 2012) is still to this day showing the same behaviour.
Octave 3.6.1 (Visual Studio 2010 compilation)
System: Windows 7 SP1 64 bits
|
Wed 09 Nov 2011 02:34:52 PM UTC, comment #6:
Thank you, Fed. I have updated the bug status as confirmed on 3.4.3 Windows.
|
Wed 09 Nov 2011 07:11:07 AM UTC, comment #5:
3.4.3 Windows build has the same issue.
|
Wed 26 Oct 2011 03:29:24 PM UTC, comment #4:
Jordi, can you bring this issue over to the Octave mailing list? The problem, from my perspective, is that 3.2.4 is an unsupported, deprecated release regardless of what platform it is on. I don't have any time for investigating issues which turn out to to have been fixed over a year ago.
Looking at the Octave for Windows page (http://wiki.octave.org/wiki.pl?OctaveForWindows) it still lists the 3.2.4 release ahead of the 3.4.X series. Can't we delete 3.2.4 from the list? It seems from the traffic on octave-maintainers that people have had success building 3.4.3 on Windows platforms and we should point to those bundles
|
Wed 26 Oct 2011 04:25:10 AM UTC, comment #3:
Furthermore, I'm not even sure this isn't a problem on Windows. Did you test it? Windows seems to run a separate thread for catching signals and the behaviour observed by Victor is a race condition caused by this. See here:
http://octave.1599824.n4.nabble.com/Does-signal-trap-of-CTRL-CLOSE-event-allowable-to-be-used-on-windows-td3663185.html#a3666890
I'm going to reopen this bug until we have conclusive evidence that a 3.4.3 Windows build doesn't exhibit this problem.
|
Wed 26 Oct 2011 04:22:06 AM UTC, comment #2:
There is a problem here. Windows users don't have an easy way to run the 3.4.3 release because there is no binary readily available. I think we really need to pool our resources to make a Windows binary release, because telling users to upgrade to a newer release that they can't access only causes frutration.
|
Wed 26 Oct 2011 03:16:09 AM UTC, comment #1:
Happily, this has been fixed and is no longer a problem in 3.4.3, the latest release. The 3.2.4 release is deprecated and no longer maintained. Upgrade to the new release to fix this issue.
|
Sun 23 Oct 2011 07:18:18 PM UTC, original submission:
Run the following program
The normal flow would be: print the first message, wait for a key, display the other message, exit
Run the program and, when pause is executing (waiting for a key), press Ctrl+C.
Now run the program again.
Expected: the pause statement is executed and is waiting for a key
Actual: pause statement is ignored
|