bugGNU Octave - Bugs: bug #60469, F9 to run selected code stopped...

 
 

bug #60469: F9 to run selected code stopped working

Submitter:  Philip Nienhuis <philipnienhuis>
Submitted:  Wed 28 Apr 2021 07:54:33 PM UTC
   
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Fixed Assigned to:  None
Originator Name:  Philip Nienhuis Open/Closed:  * Closed
Release:  * dev Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 23 Feb 2022 08:02:10 PM UTC, comment #25: 

Done, see bug #62105.

Philip Nienhuis <philipnienhuis>
Group Member
Wed 23 Feb 2022 01:30:44 AM UTC, comment #24: 

@Philip: Why don't you file a different bug report about error messages not having the correct line number for code that is run with F9.

Rik <rik5>
Group administrator
Fri 03 Dec 2021 12:58:29 PM UTC, comment #23: 

Yes F9 works again these days.

But there's still a little issue: if a piece of "F9-ed" code leads tot errors or warnings in the terminal, the line number mentioned in the error/warning message refers to a temporary file, not the file from which F9 was pressed. So that often induces confusion during debugging.

Is a separate bug report required for this issue?

Philip Nienhuis <philipnienhuis>
Group Member
Wed 01 Dec 2021 07:08:21 PM UTC, comment #22: 

I haven't noticed any F9 issues on my windows builds since v6.2. Can the report be closed or should it remain open for the more general discussion?

Nicholas Jankowski <nrjank>
Group Member
Thu 27 May 2021 02:41:14 PM UTC, comment #21: 

One example is the color picker used for several configurable colors. It is derived from QPushButton and its "triggered" signal (which opens the color selection dialog) still works on Windows and Linux. The issue might be somehow related to the qscintilla lib.


Torsten Lilge <ttl>
Group Member
Thu 27 May 2021 01:12:12 PM UTC, comment #20: 

For my most recent build for Windows, I disabled symbol visibility attributes and the signals/slots failed to be connected (the build was made using an Octave revision prior to 81be7e4ddb0f.  So I guess the problem is related to inheritance, not visibility.  If it is an issue with signals and inheritance, I still don't understand why it works on Linux and not on Windows.  Don't we have other cases where we derive an object and connect to signals that are defined for the base class and everything works just fine?

John W. Eaton <jwe>
Group administrator
Thu 27 May 2021 08:28:07 AM UTC, comment #19: 

I am not sure if this would help in this case. Only signals from the base class QsciScintilla are affected, even when they are connected directly in octave_qscintilla. Signals that are added in the derived class octave_qscintilla can be connected using the new syntax.

Torsten Lilge <ttl>
Group Member
Thu 27 May 2021 08:13:27 AM UTC, comment #18: 

Re comment #16: I can't rule out that symbol visibility is causing issues here.

I noticed that since the changes related to symbol visibility made around the end of last year on the default branch, we are not exporting some symbols from liboctinterp that we probably should. (We should probably get that sorted out some time before Octave 7 hits stable. But that is trickier than one might expect.)
I wouldn't be surprised if the same holds for some symbols from liboctgui.

I don't know how these signal slot connections are working and how symbol visibility might interfere. So this is just a guess:
Does it help to add the OCTGUI_API attribute to the octave_qscintilla class for this particular issue?

Markus Mützel <mmuetzel>
Group administrator
Thu 27 May 2021 07:32:28 AM UTC, comment #17: 

Just verified that the fix from comment #9 works (on my windows box). I just tried the <F9> thing and noted the the "Step" button wasn't greyed out anymore after selecting code.

I'll leave it to you to close this bug or continue the discussion.

Philip Nienhuis <philipnienhuis>
Group Member
Wed 26 May 2021 08:00:44 PM UTC, comment #16: 

Or, it is possible that symbol visibility is causing trouble here?  I really don't know.

John W. Eaton <jwe>
Group administrator
Wed 26 May 2021 07:58:45 PM UTC, comment #15: 

Torsten: It seems that way, at least when the base and derived objects come from different DLLs?

John W. Eaton <jwe>
Group administrator
Wed 26 May 2021 07:55:29 PM UTC, comment #14: 

Thanks for clarifying this. This means each time we are connecting a signal of the base class in a derived class we have to use the syntax from comment #12 or the old  SIGNAL/SLOT syntax?

Torsten Lilge <ttl>
Group Member
Wed 26 May 2021 05:31:03 PM UTC, comment #13: 

I should also note that the cast and the use of the base class name to refer to the signal method are both required.  Although they both compiled, neither of the following worked for me:


    connect (m_edit_area, &QsciScintilla::copyAvailable,
             this, &file_editor_tab::handle_copy_available);



    connect (dynamic_cast<QsciScintilla*> (m_edit_area),
             &octave_qscintilla::copyAvailable,
             this, &file_editor_tab::handle_copy_available);


John W. Eaton <jwe>
Group administrator
Wed 26 May 2021 05:26:56 PM UTC, comment #12: 

I did some checking and it works for me if I use the following pattern with the new signal/slot connection method:


    connect (dynamic_cast<QsciScintilla*> (m_edit_area),
             &QsciScintilla::copyAvailable,
             this, &file_editor_tab::handle_copy_available);


for the signals that are emitted from the base QsciScintilla object itself.

As noted earlier, this problem only occurs on Windows systems.  Is it related to the way pointers are handled in DLLs?  Or is it just a difference in the way pointers are handled in a class like this where signals are inherited?  I'm not sure whether it is the connection or the execution of the signal/slot connection that fails.

I suppose it is good that there is a way to use the new signal/slot syntax in this case, but it seems quite bad to me that there is no warning for an inherited signal like this.

John W. Eaton <jwe>
Group administrator
Wed 26 May 2021 12:59:24 PM UTC, comment #11: 

No, I want to eliminate SIGNAL/SLOT macros where we can but I noted that we need to be careful so that any explicit calls to disconnect() use the same method as the corresponding signal connection.

John W. Eaton <jwe>
Group administrator
Wed 26 May 2021 11:48:03 AM UTC, comment #10: 

Thanks, I'll give it a try tonight. If it works I can again use the latest bleeding-edge crossbuilds, currently I'm "stuck" with one from April 14 (the last one I built where <F9> still worked).

BTW, didn't JWE prefer to revert all signal-slot connection changes rather than just a few? ISTR remember him mentioning s/th like that.

Philip Nienhuis <philipnienhuis>
Group Member
Wed 26 May 2021 10:44:48 AM UTC, comment #9: 

Cset http://hg.savannah.gnu.org/hgweb/octave/rev/81be7e4ddb0f fixes this for my Win 7 by reverting the signal/slot connections of all native qscintilla signal back to the old syntax.

Torsten Lilge <ttl>
Group Member
Sat 08 May 2021 07:55:51 PM UTC, comment #8: 

I wasn't successful with searching the internet for known issues with signal/slot connections using the new syntax. I suggest to revert the changes affecting Qscintilla

@jwe, what do you think?

Torsten Lilge <ttl>
Group Member
Mon 03 May 2021 07:05:20 PM UTC, comment #7: 

It looks like the connection of QScintilla's own signals is failing, among them &octave_qscintilla::copyAvailable (causing this bug) or, e.g., signals for indicating file mofification or updating line and row indicator in the status bar.

When octave is started with the environment variable "OCTAVE_SHOW_GUI_MESSAGES=1", there are altogether 13 occurrences of the error message "QObject::connect: signal not found in octave::octave_qscintilla" for each opened editor file.

Could the way how Qscintilla is linked to octave in the mxe build might prevent the new signal/slot connection method from finding the signals?

Torsten Lilge <ttl>
Group Member
Sun 02 May 2021 07:25:55 PM UTC, comment #6: 

As I wrote, it happened somewhere between 14th and 20th of April. The cset Rik refers to fits in perfectly.

Philip Nienhuis <philipnienhuis>
Group Member
Sun 02 May 2021 04:51:30 PM UTC, comment #5: 

comment #4:

> This might be related to jwe's attempt to get rid of SIGNAL/SLOT usage.


I was thinking about this, too and am starting to look for the break in the signal chain. But whatever the result will be, interestingly only Windows is affected. Let's see.

Torsten Lilge <ttl>
Group Member
Sun 02 May 2021 02:22:45 PM UTC, comment #4: 

This might be related to jwe's attempt to get rid of SIGNAL/SLOT usage.  See this cset


changeset:   29542:3d34b70b5a49
user:        John W. Eaton <jwe@octave.org>
date:        Fri Apr 16 23:06:32 2021 -0400
summary:     connect many Qt signals and slots without SIGNAL and SLOT macros


Using 'hg bisect' for Windows is slow because it takes so long to cross-build through the MXE system.  But this might be a clue.

Rik <rik5>
Group administrator
Sun 02 May 2021 01:58:44 PM UTC, comment #3: 

After a complete rebuild of my MXE envrionment (I had to do a "make clean" after a system upgrade), I was finally able to test this on my windows virtual machine.

The "Run selected code" action remains disabled even when text is selected. The same holds for the copy action, which stays disabled, too, although selected text is available. From this, it seems that the signal chain that should inform the main editor widget from state changes in the current tab's qscintilla area is not working anymore in Windows.

Torsten Lilge <ttl>
Group Member
Thu 29 Apr 2021 06:19:39 PM UTC, comment #2: 

I will do a recent windows build (will take some time) and test on my virtual box.

Torsten Lilge <ttl>
Group Member
Wed 28 Apr 2021 09:59:57 PM UTC, comment #1: 

FWIW, I tried on a Linux system with the text 'x = pi' and F9 worked fine.  This is with cset


parent: 29565:7733ca1db419
 use shared_ptr to manage memory for mutex object


Rik <rik5>
Group administrator
Wed 28 Apr 2021 07:54:33 PM UTC, original submission:  

Steps to reproduce;

  • In GUI editor, enter any command, e.g.: a = 1
  • Select it  & press F9
  • expected result: code is executed in command window
  • observed result: nothing


The last version I built where it worked is from April 14.
The next version I built is from April 20, doesn't work there.

It does still work in the 6.2.1 nightlies

Philip Nienhuis <philipnienhuis>
Group Member

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by nrjank (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by ttl
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by philipnienhuis (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
    2022-02-23 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2021-05-26 ttl StatusConfirmed Ready For Test
    2021-05-08 ttl Carbon-Copy- Added jwe
    2021-05-02 ttl StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code