bugGNU Octave - Bugs: bug #47585, GUI editor does not show already...

 
 

bug #47585: GUI editor does not show already active breakpoints when a file is opened

Submitted by:  Mike Miller <mtmiller>
Submitted on:  Thu 31 Mar 2016 03:38:05 PM UTC  
 
Category: GUISeverity: 2 - Minor
Priority: 5 - NormalItem Group: Incorrect Result
Status: NoneAssigned to: None
Originator Name: Open/Closed: Open
Release: devOperating System: Any

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Tue 12 Apr 2016 07:06:27 PM UTC, comment #10:

See some follow-up as regards comment #2 in bug #33411

Philip Nienhuis <philipnienhuis>
Project Member
Mon 11 Apr 2016 04:24:45 AM UTC, comment #9:

After looking at Dan's framework again, I've decided I won't have a go at this after all. I don't think I understand well enough what should be signals and what should be function calls.

Dan, when you have written up how things should work, I may revisit this.

Lachlan Andrew <lachlan>
Project Member
Mon 11 Apr 2016 03:20:57 AM UTC, comment #8:

Dan, I agree entirely with your first sentence in comment #7.

If you have clear idea of what the "proper framework conventions" should be, please document them. I'll be happy to try to work within it, even if it is by writing kludge shims to be replaced when the proper framework is developed as you suggest. I just have don't really know what the framework should look like. For this particular bug, I'll have a go at what you suggested, but it would be nice to have something more general written down.

Arguing about whether or not a cross-thread fix makes the code "less buggy" is a bit like arguing whether or not Lewis Carol was right that a clock with stationary hands is "better" than one that looses one minute per day. (The one with stationary hands is exactly right twice a day, which is much more often than the other one is right, but the one with moving hands is more useful.)

The structure returned by all functions is an octave_value_list. I'm not convinced that the best approach is simply to allow CLI commands to be run by the GUI. It would be useful to have a more generic thread-safe way to make a core function callable from the GUI. You have pointed out that this is harder to debug than the more restrictive CLI-like interface. There's always a tradeoff, with multiple useful combinations.

Lachlan Andrew <lachlan>
Project Member
Mon 11 Apr 2016 12:38:26 AM UTC, comment #7:

Indenting and identifying parse errors would save a lot of user hours, it's just that it would be easier to do these things if there were a nice framework for doing so.

It's a caught-between-a-rock-and-a-hard-place type of situation, really. The major contributors have to be the ones to implement/test some generic way of GUI/core, cross-thread communication.

As I see it, the program isn't made less buggy by calling core routines directly across a thread. At worst, it is leaving a potentially difficult bug for some future user to understand, plus not a path to robust, dependable code. It would also be nice to stay withing the GUI's framework. If anything, isolating dodgy code to some hack or kludge file would be good. Say, creating some bogus command process that calls "dbstatus('justopenedfile')" command for which the framework could send a signal and get back an octave_value_list. That is,

That way, the file-editor-tab.c/h files could be programmed to the proper framework conventions and the dodgy cross-thread code could be kept somewhere else for eventual replacement. From what I remember, that returned structure for dbstatus is in an octave_value_list.

Dan Sebald <sebald>
Sun 10 Apr 2016 10:51:28 PM UTC, comment #6:

Dan, I wasn't meaning to be dismissive by calling the design principles "niceties". (I meant it in the sense of "requiring careful treatment" rather than "fine points".) I agree that they are important in the long term.

However, I don't see the need to have Octave buggy while we are waiting for the proper framework to be developed. Perhaps it would be good to have a comment at each place the cross-thread actions happen so that it is easy to fix them once the correct mechanisms are available. There were already instances of that within the debug/dbstop code before I started working on it.

I share your concerns on some matters. I would like the editor to have access to the parse tree, to get things like folding and auto-indent working properly, and to get a "warning bar" like Matlab has in the RHS gutter. I am resisting because I don't consider them sufficiently critical to fudge the cross-thread interaction you are working to allow.

If there is something I can do to get the right architecture in place, let me know. However, I wouldn't know where to start.

Lachlan Andrew <lachlan>
Project Member
Sun 10 Apr 2016 09:26:52 PM UTC, comment #5:

I wouldn't call what I'm proposing "niceties"; more like a design principle.

The designers of Qt came up with the signals and slots concept because they often found the callback routine approach to be limiting and sometimes became a bottleneck. There is discussion about this on the web if one does a search for Qt and callbacks.

I can understand the desire for making the breakpoints work, but I wouldn't advocate this patch. One has to keep in mind that the GUI is running in a different thread and calling core routines asynchronous with what the core may be doing requires some type of semaphore or mutex. Otherwise, there is a the remote possibility of the core changing something, in this case, in the breakpoint table, at the same time the GUI is trying to access it. And these types of obscure bugs are really difficult to locate because they are near impossible to reproduce when someone reports a problem.

I see a lot of quick-fix, workarounds that push a problem into some other corner but never completely solve the problem in graphics, breakpoints, dialog boxes, etc. If all that effort had been put into a good design principle early on, it would have been more productive.

Dan Sebald <sebald>
Fri 08 Apr 2016 05:29:49 AM UTC, comment #4:

For a while now, I have been using the attached patch.

It ignores the architectural niceties that Dan points out, by calling "core" functions directly from the GUI.

I've noticed some breakpoint-related oddities recently (mainly with breakpoint conditions changing unexpectedly) which may be related to this patch, but I haven't had a chance to track them down.

(Philip, I have posted a fix for bug #33411. If you run into that problem often, let me know if the patch helps.)

(file #36860)

Lachlan Andrew <lachlan>
Project Member
Mon 04 Apr 2016 02:19:14 AM UTC, comment #3:

Yes, related, but only in the sense that there needs to be communication in both directions across the GUI "boundary", be it a thread or some other configuration. I put together a detailed description at one point, classifying the various actions in the whole framework.

When it is the GUI side initiating action, there is a wealth of commands for getting breakpoints, getting variables, setting variables, getting properties, setting properties, etc. All these can be accessed via some command/return I described in a previous post.

Then there is the case where an action is initiated in the core--or maybe I should say initiated from the command line via the core. What's a nice way of handling that? A way that doesn't require writing all kinds of GUI-specific code in the core? A way that any number of GUI frameworks could make use of? I propose a means to "override" the command-line function very similar to the way C++ derived classes can override the base class function (and still call that function if necessary). I would imagine that almost exists already because we can create our own functions having the same name as some existing function in Octave. The thing that is missing is the ability to still call the built-in functions somehow.

The GUI when launched would install its own set of functions that need to cause some kind of GUI action from the command line. As an example:

INSTALLABLE_FUNCTION_CLASS(dbclear) qt_gui_dbclear(void)
{
BASE_FUNCTION(dbclear);
send_signal_to_GUI_to_update_breakpoints();
}

Something like that. GUI frameworks other than Qt could make use of this very generic layout in the same way.

Dan Sebald <sebald>
Sun 03 Apr 2016 08:54:37 PM UTC, comment #2:

Maybe related, maybe also a little related to bug #33411, but I see the other way round as well (when testing again for bug #33411) with the dev version:

function [ ret ] = foo ()
printf ("Hello!\n");
endfunction

but after the "dbclear foo" command the breakpoint is cleared (foo.m runs to the end) but in the editor the breakpoint is still visible. It cannot be cleared either (neither with "toggle breakpoints", "clear all breakpoints" or clicking on it).
Only exiting the editor (or closing the foo.m editor tab) and reopening foo.m in the editor helps.

Philip Nienhuis <philipnienhuis>
Project Member
Sun 03 Apr 2016 05:53:06 AM UTC, comment #1:

I pointed out several years ago that this would be a problem because the callback functions for breakpoints and such is driven from the core side of things and the core does not know the editor has opened a file. The only thing really needed for all sorts of functionality is a way to send commands to the core and eventually get an octave_value_list return value for that processed command. In this case, the editor would initiate a "dbstop" and when the signal (not a function call, but a signal) comes back from that processed command with the list of breakpoints in an octave_value_list then the editor would add the breakpoints. See

https://savannah.gnu.org/patch/?func=detailitem&item_id=8016#options

Dan Sebald <sebald>
Thu 31 Mar 2016 03:38:05 PM UTC, original submission:

When a file with breakpoints already set is closed and then re-opened in the editor, active breakpoints are not shown but are still active.

Example:

Mike Miller <mtmiller>
Project Administrator

 

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

Attach File(s):
   
   
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 lachlan (Updated the item)
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by mtmiller (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 11 Apr 2016 04:24:45 AM UTClachlanStatusPatch Submitted=>None
    Sun 10 Apr 2016 12:27:10 AM UTClachlanStatusNone=>Patch Submitted
    Fri 08 Apr 2016 05:29:49 AM UTClachlanAttached File-=>Added bug_47585_load_breakpoints.cset, #36860

    Back to the top


    Powered by Savane 3.1-cleanup1