bugGNU Octave - Bugs: bug #56990, Hover mode for variables in...

 
 

bug #56990: Hover mode for variables in debugger

Submitter:  None
Submitted:  Fri 04 Oct 2019 01:23:20 AM UTC
   
 
Category:  GUI Severity:  1 - Wish
Priority:  1 - Later Item Group:  Feature Request
Status:  Fixed Assigned to:  None
Originator Name:  Joe Tusek Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * dev
Operating System:  * Any Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 20 Oct 2020 10:02:39 PM UTC, comment #20: 

Torsten,

Neither was I :-) I completely forgot.
It's just that I found it back when I was using Kai's web tool [*] for open bugs/patches for upcoming 6.1, see
https://octave.discourse.group/t/web-tool-for-overview-about-savannah-bugs/326

The patch is more than 4 years old ==> I also forgot it's features; Lachlan wrote a few things in his comment #0. My requests at the time for configurable options (active/inactive, display time, delay until display, etc.) still apply :-)
I've put up the binary 4.1.0+ installer I built on July 15, 2016, for you or --anyone else interested-- to play with so you can see for yourself:
https://prn183.stackstorage.com/s/aSMF5oTXIqVIolZO
(valid until next Saturday 24 Oct)

E.g., in the editor just type 'a = rand (10)' and then hover over the "a".

[OT]
[*] Kai's tool is great; I found back a lot of things I was working on but forgot, I started cleaning up here and there.
It also helps uncover some gems that (IMO unfortunately) have never been finalized and/or made it into core or some OF package. Often because they were contributed at the wrong time, like just before some Octave release :-)

Philip Nienhuis <philipnienhuis>
Group Member
Tue 20 Oct 2020 08:32:13 PM UTC, comment #19: 

Philip, I wasn't aware of this patch. The last comment says that it can not be applied to the current repo anymore. Which features does it provide?

Torsten Lilge <ttl>
Group Member
Tue 20 Oct 2020 12:38:02 PM UTC, comment #18: 

See also patch #9050.

Not wanting to spoil the party here; but I forgot about that patch while I had it working in my crossbuilds for a while.

Philip Nienhuis <philipnienhuis>
Group Member
Fri 09 Oct 2020 03:27:34 PM UTC, comment #17: 

I added a note about this new feature in the NEWS file here:
https://hg.savannah.gnu.org/hgweb/octave/rev/32dde927e59b

Markus Mützel <mmuetzel>
Group administrator
Fri 09 Oct 2020 02:58:11 PM UTC, comment #16: 

Thanks for the feedback, Markus.

The symbol values are taken from the list provided by the workspace model. Therefore, the values shown in the tool tips are identical to the ones shown in the workspace widget. Of course, more detailed, multi-line presentations are possible in tool tips compared to list cells.

This report is closed as fixed, leaving the above topic to specific reports.

Torsten Lilge <ttl>
Group Member
Fri 09 Oct 2020 11:31:59 AM UTC, comment #15: 

I agree with the other positive feedback here. This feature is very handy! Thank you very much for this improvement which I'm sure will be very much appreciated by users.

Imho this deserves an entry in the NEWS file.

There might be a few areas for minor improvements (e.g. showing the first few field and values for structures). But that is probably best handled in more specific reports.

Other than that, I believe this can be closed as fixed.

Markus Mützel <mmuetzel>
Group administrator
Thu 01 Oct 2020 08:42:04 PM UTC, comment #14: 

This error was potentially causing many different crashes whenever an event was triggered (mouse, resize, repaint, ...). When not a tool tip event, the event was delivered by mistake to the QWidget event handler instead of the one of QsicScintilla.

Torsten Lilge <ttl>
Group Member
Thu 01 Oct 2020 07:06:58 PM UTC, comment #13: 

And for me it is fixed too. TNX

Hg200 <hg200>
Thu 01 Oct 2020 05:30:35 PM UTC, comment #12: 

The crash on using the mouse wheel is also fixed.

Markus Mützel <mmuetzel>
Group administrator
Thu 01 Oct 2020 05:28:18 AM UTC, comment #11: 

John, thanks for fixing this. I actually forgot to update the  event's object from another event handler I took as a template.

I leave the report open for a while for further testing the new feature.

Torsten Lilge <ttl>
Group Member
Wed 30 Sep 2020 09:22:01 PM UTC, comment #10: 

I'm able to reproduce this crash.  It seems to happen when I resize and scroll in the editor window when debugging is active.  The stack trace looks the same, and seems to be an infinite loop.  I also notices that resizing the editor window doesn't seem to work properly.  I pushed the following changeset.  It seems to fix the problem for me.

http://hg.savannah.gnu.org/hgweb/octave/rev/751afb1ee1d0

John W. Eaton <jwe>
Group administrator
Wed 30 Sep 2020 05:13:58 PM UTC, comment #9: 

I also like this feature, thanks.

FTR, I can fully Hg200's observations in comment #7.
In my case repainting the editor pane could take many seconds but did happen (maybe a clue).
A little later the crash comes completely unpredictively. Octave just disappears, there's not even the "helpful" Windows popup confirming that the program has crashed ("Octave stopped working" or "illegal instruction at ...").
I haven't checked if the crash comes just by itself after a while or after a number of user actions in the editor.


Philip Nienhuis <philipnienhuis>
Group Member
Wed 30 Sep 2020 02:05:37 PM UTC, comment #8: 

I've also seen crashes recently when using the mouse wheel to scroll down "over" the end of a file in the editor. That might be related.

Markus Mützel <mmuetzel>
Group administrator
Wed 30 Sep 2020 12:17:52 PM UTC, comment #7: 

Thank you for providing this feature. I will definitely use this feature very often. However, I get segfaults in the cset:


changeset:   28799:6aba3944b608
date:        Sun Sep 27 22:03:25 2020 +0200
summary:     fix deleting pointer when octave exists


But I can't force any segfaults in the cset:


changeset:   28797:ac5461b59b93
date:        Sun Sep 27 12:29:11 2020 -0400


I have attached a backtrace taken from the more recent cset:


changeset:   28809:03c0024f95c7
date:        Mon Sep 28 21:57:01 2020 +0200
summary:     avoid using bare pointers for symbol lists in editor (bug #56990)


To force the fault i open a .m file and do regular work. Sometimes it takes several minutes, sometimes it crashes immediately. Especially resizing the GUI with the mouse seems to be a problem. It should be emphasized that the scroll bars / editor area is also not "rescaled" and "updated" when the GUI is resized or the separator in the middle is moved. Can you please take a look at the attached backtrace?

Thanks!


(file #49894)

Hg200 <hg200>
Mon 28 Sep 2020 08:58:06 PM UTC, comment #6: 

I have pushed cset http://hg.savannah.gnu.org/hgweb/octave/rev/03c0024f95c7 which avoids bare pointers.

Torsten Lilge <ttl>
Group Member
Mon 28 Sep 2020 04:45:39 AM UTC, comment #5: 

The access to the workspace model for the tool tips is read only and the pointers are valid until octaves shutdown. However, I agree that future extension might use the pointers in a way that is not yet foreseen. I will change to code such that the current workspace symbols are requested each time a tool tip is requested.

Torsten Lilge <ttl>
Group Member
Mon 28 Sep 2020 03:04:59 AM UTC, comment #4: 

In the patch, I noticed the following code in the octave_qscintilla constructor:


  m_symbol_names (m_octave_qobj.get_workspace_model ()->get_symbol_names ()),
  m_symbol_values (m_octave_qobj.get_workspace_model ()->get_symbol_values ()),


The get_symbol_names and get_symbol_values functions return pointers to data members in the workspace_model class.  When I see code that uses bare pointers this way, I always wonder whether the pointers will be valid later on when they are used, or that the object they point to might be modified in one thread (in the workspace model, for example) while it is being accessed in another (in the editor, for example).  Maybe that's not possible now, but it could be that in the future these to parts of the GUI operate in separate threads?

Instead of storing these pointers, is it possible for the editor to query the workspace model to get the info when needed?  For example, by emitting a signal to request the variable and providing a slot to update or display the tooltip text when the variable info is available?  I admit that I don't fully understand the way tooltips work, so maybe this is not possible?

John W. Eaton <jwe>
Group administrator
Sun 27 Sep 2020 07:31:56 PM UTC, comment #3: 

Cset http://hg.savannah.gnu.org/hgweb/octave/rev/82ccc4e69ba3 provides this feature, i.e. showing the value when hovering over a variable in the editor during debug mode.

Torsten Lilge <ttl>
Group Member
Fri 11 Oct 2019 04:47:25 PM UTC, comment #2: 

Yes, in the console window, there is no need for the debug mode, but in the editor. I think, the OP was targeting for the editor where this feature would really help during debugging.

Torsten Lilge <ttl>
Group Member
Fri 11 Oct 2019 09:05:24 AM UTC, comment #1: 

Why only in debug mode as the title seems to suggest?

Maybe change title into "Hover mode for variables in command window" ?

Philip Nienhuis <philipnienhuis>
Group Member
Fri 04 Oct 2019 01:23:20 AM UTC, original submission:  

It would be every useful during debugging if Octave was to emulate a hover mode (like Matlab), so that when the mouse pointer is over a variable, it displays its value in a small box beside the mouse pointer.

Anonymous

 

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

Attach Files:
   
   
Comment:
   

Attached Files

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by hg200 (Updated the item)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by siko1056 (Updated 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 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-10-09 ttl StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2020-09-30 hg200 Attached File- Added backtrace_set_03c0024f95c7.txt, #49894
    2020-09-27 ttl StatusConfirmed Ready For Test
    2019-10-04 siko1056 Severity3 - Normal 1 - Wish
        Priority5 - Normal 1 - Later
        StatusNone Confirmed
        Release5.1.0 dev

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code