bugGNU Octave - Bugs: bug #55854, Pause deactivated permanently...

 
 

bug #55854: Pause deactivated permanently after making (gui) interpreter - console the active window

Submitter:  Tasos Papastylianou <tpapastylianou>
Submitted:  Thu 07 Mar 2019 03:57:29 PM UTC
   
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Regression
Status:  Fixed Assigned to:  None
Originator Name:  tpapastylianou Open/Closed:  * Closed
Release:  * 5.1.0 Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 23 Oct 2019 08:05:38 PM UTC, comment #12: 

I reverted the fix for bug #45003 on the default branch

https://hg.savannah.gnu.org/hgweb/octave/rev/35f9ffb13fd6

As I said, I think this change was causing more problems than benefits. This will no longer move the cursor when clicking, but it will also no longer break the pause function or insert extra meta characters into the input stream.

Mike Miller <mtmiller>
Group Member
Wed 27 Mar 2019 11:07:20 PM UTC, comment #11: 

We probably never should have made the change to qterminal to support this concept of a mouse click turning into cursor movement escape sequences, that just needlessly diverges our baseline further away from upstream qterminal / qtermwidget.

If we revert that change, this bug goes away, right? I would support that, in the interest of fixing this, simplifying the code, and improving our changes of unifying with qtermwidget someday, if the command window isn't completely rewritten in the meantime.

Mike Miller <mtmiller>
Group Member
Sun 17 Mar 2019 11:16:50 PM UTC, comment #10: 

Yes, click very close to the cursor and only 2 more kbhit calls will be needed to flush the pending [ and C characters.

Pantxo Diribarne <pantxo>
Group Member
Sun 17 Mar 2019 10:48:41 PM UTC, comment #9: 

Yeah, I can confirm that on my system.

So for this bug, does that mean that after some number of calls to pause or kbhit, the backlog is cleared out and pause resumes working again?

Mike Miller <mtmiller>
Group Member
Sun 17 Mar 2019 09:28:07 PM UTC, comment #8: 

@Mike: You are right this bug has nothing to do with the other. Sorry but I got lost again: does "kbhit" without argument work in glibc 2.28? If so, you should be able to reproduce this bug by doing


kbhit (); ## Click after the current cursor.
## -> ans =
kbhit ()
## -> ans = [
kbhit ()
## -> ans = C
kbhit ()
## -> ans =
kbhit ()
## -> ans = [
kbhit ()
## -> ans = C
...


The problem here is that clicking on a potentially editable area of the command window (after the current cursor) now emits as many "\E[C" (key Right) keyboard events as necessary to reach the clicked position.


Pantxo Diribarne <pantxo>
Group Member
Sun 17 Mar 2019 05:48:37 PM UTC, comment #7: 

@pantxo No, this patch behaves very similarly to the last one I tested on bug #55029.

The behavior of this bug doesn't have much in common with bug #55029 at all, other than they are both pause with no timeout.

In bug #55029, pause does not change behavior after the first failure, it always fails to return on any keypress and pauses infinitely, it can only be killed with SIGINT. After interrupting pause, it's the kbhit function that does change behavior, it never returns a valid keypress after that.

Mike Miller <mtmiller>
Group Member
Sun 17 Mar 2019 04:45:34 PM UTC, comment #6: 

The common point between bug #55029 and this one is that pause always returns immediately after the first failure.

The attached patch (derived from previous tentative on bug #55029) fixes this part of the bug.

@Mike: does it have any effect on libc-2.28 and bug #55029?


The fact that a click triggers a keyboard event is probably related to this cset:


changeset:   25988:976e7346abf4
user:        Stefan Miereis <stefan.miereis@gmx.de>
date:        Fri Feb 12 01:23:43 2016 +0100
summary:     Make gui command line mouse compatible for non-windows systems (bug #45003)





(file #46564)

Pantxo Diribarne <pantxo>
Group Member
Sun 17 Mar 2019 04:05:34 PM UTC, comment #5: 

Actually, "figure" is not even needed, just clicking bellow the current line in the command window triggers the bug.

Pantxo Diribarne <pantxo>
Group Member
Wed 13 Mar 2019 09:45:36 AM UTC, comment #4: 

facing the same problem post installing version 5.1.0. Was working fine with an older octave version (forgot which version i had on my old machine)

Saurabh Sharma <sausha80>
Sun 10 Mar 2019 10:35:41 PM UTC, comment #3: 

I can confirm this bug with libc-2.27.so

So the new implementation of "pause ()" using kbhit and sleep provokes regressions with both libc-2.27 and libc-2.28.

Until we have a clue on how to fix this, I'd tend to revert part of cset f7b205562f1d and reopen bug #53729.

Pantxo Diribarne <pantxo>
Group Member
Thu 07 Mar 2019 05:58:50 PM UTC, comment #2: 

@Mike: /lib/x86_64-linux-gnu/libc-2.27.so

Tasos Papastylianou <tpapastylianou>
Thu 07 Mar 2019 05:35:06 PM UTC, comment #1: 

This does not sound like bug #55029, but just for clarity: which version of glibc is Octave linked with?


system (sprintf ("grep 'libc-2\\.' /proc/%d/maps", getpid ()))


On my system, with glibc 2.28, the pause function never returns until Ctrl+C interrupts it, that is bug #55029, so I'm unable to reproduce this.

Mike Miller <mtmiller>
Group Member
Thu 07 Mar 2019 03:57:29 PM UTC, original submission:  

Steps to reproduce:

1. Run the following snippet ON A SINGLE LINE:
    plot(1:10); pause;

This should cause a new figure window to come up as the active window

2. Without closing the figure window, click with the mouse back on interpeter / console window to make it the active window.

Bug: pause effect ends, and any subsequent calls to pause have no pause effect (but without affecting the pause toggle state; in other words, 'pause query' will still return 'on')

Expected behaviour: The pause effect should not have ended just by clicking on the interpreter window, and also, subsequent calls to pause should not have been affected

This is a regression bug for me, I have not experienced similar behaviour using octave 4.4.1 on the same OS instance.

Tasos Papastylianou <tpapastylianou>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #46564:  clear_cin3.patch added by pantxo (5KiB - text/x-patch)

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by sausha80 (Posted a comment)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by tpapastylianou (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-10-23 mtmiller StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2019-10-10 pantxo Dependencies- bugs #56976 is dependent
    2019-03-17 pantxo Attached File- Added clear_cin3.patch, #46564
    2019-03-10 pantxo StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code