Tue 12 Apr 2016 07:06:27 PM UTC, comment #10:
See some follow-up as regards comment #2 in bug #33411
|
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.
|
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.
|
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.
|
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.
|
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.
|
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)
|
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.
|
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.
|
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
|
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:
|