Menu ▾ ▴

#528 Need ability to interrupt plot causing a stream of error messages

None
closed-accepted
nobody
Windows (3)
5
2022-07-12
2022-01-27
Ulrich Windl
No

Trying to plot a datafile with more than 50000 lines, I made a mistake using the correct timeformat.
As a consequence gnuplot outputs a (seemingly) endless stream of error messages (one per line).
"warning: bad time format in string"

To make matters worse, the scrolling speed of the output is rather slow (like roughly 10 lines per second).

In the Windows version I'd like to interrupt the current plot command to be able to correct the format string.

Version being used in 5.2 patch level 8.

Discussion

  • Ulrich Windl

    Ulrich Windl - 2022-01-27

    Well, just after having finished this enhancement request, Gnuplot reacted with a delay of something like 10 minutes or so:
    Ctrl-C detected!

     

  • Ethan Merritt

    Ethan Merritt - 2022-01-27

    Gnuplot itself receives the interrupt generated by ctrl-C immediately, at least compared to the time it takes for you to recognize the problem and mash two keys. The problem is that by then the program has already sent those thousands of messages to stderr and they are in flight through the operating system buffers (probably fast enough to tolerate) and the physical output on the terminal display device (slow in your case). The error message "Ctrl-C detected" was appended to end of that same outgoing queue when you sent the interrupt. There is no way for the program to make it jump to the head of the queue. So far as the program is concerned, the stuff being printed is already out the door and the door has been closed behind it.

    Caveat: I do not know anything about Windows internals, so there might possibly be a fix there that is not available under linux.

    Possible work-around: Under linux, many terminal emulators will run through queued output faster if the terminal window is minimized and therefore not visible. I don't know whether that's true under Windows. If so, you can maybe avoid the 10 minute wait by minimizing the window after hitting Ctrl-C and then re-opening it a few seconds later.

     

  • Tatsuro MATSUOKA

    Tatsuro MATSUOKA - 2022-01-27

    Which gnuplot are you using? gnuplot.exe or wgnuplot.exe ?
    As far as I remember CTRL+C implementation is different on which gnuplot users use.

     

  • Bastian Märkisch

    Bastian Märkisch - 2022-01-28

    On Windows, these Ctrl-C interrupts can only be handled asynchronously for both console-mode and GUI variant. Internally, this works by setting a flag ctrlc_flag. Actions are only interrupted when this flag is tested a certain ponits. This is currently the case during pause or fit commands or when checking for mouse or key events in check_for_mouse_events() for example. The behaviour could be improved by adding checks elsewhere.

    The drawing speed of the wgnuplot terminal is indeed rather low, possibly due to a mutliple redraws. This normally isn't a bug problem though.

     

    • Ethan Merritt

      Ethan Merritt - 2022-01-28

      Windows is stranger than I knew.
      So probably the check for ctrlc_flag should go in both int_warn() and int_error() ?

       

      • Bastian Märkisch

        Bastian Märkisch - 2022-01-29

        The technical reasons differ for both variants: the GUI version reads Ctrl-C as a normal keystroke. Also console mode gnuplot programs have no native concept of signals. There's a handler for Ctrl-C, but it runs in a different thread and we cannot bail_to_command_line() from there.

        I have now put a check in int_warn() as suggested. int_error already bails to the command line, so no need there.

         

  • Bastian Märkisch

    Bastian Märkisch - 2022-02-14
    • labels: --> Windows
    • status: open --> pending-accepted
    • Group: -->
     

  • Ethan Merritt

    Ethan Merritt - 2022-07-12
    • status: pending-accepted --> closed-accepted
     

Log in to post a comment.