Re: [PATCH #8316] Variable Editor

[Daniel J Sebald]

Hello Rüdiger,

Thanks for working on this.  I haven't tried it out yet (busy time of 
the year), but I'll give some feedback below.

On 02/13/2014 03:20 PM, Rüdiger Sonderfeld wrote:
> Hello,
>
> I've started writing a Variable Editor for the new GNU Octave GUI.  I have an
> initial patch ready and submitted here:
>
> https://savannah.gnu.org/patch/index.php?8316
>
> (Quoted from above)
>
> It is not finished but I wanted some input before continuing with it.

Yes, before continuing some words of caution.  I don't want to 
discourage you from working on this, but at the same time it probably 
would be best to hold off perfecting things until the issue of sending 
data from one thread to another is worked out.

John Eaton made a good start on a variable editor, so you may want to 
see if there is anything in common there at some point.


> The biggest issue right now is that the editor does not detect changes
> happening to the variable inside Octave. It will continue displaying the old
> value. I don't know if there is a way in Octave to intercept changes to
> certain variables or how this could be implemented. The simplest way would be
> to update the display completely once `octave_link::set_workspace' gets
> called. But this would only update the view when Octave has finished and is
> waiting for new input. Maybe that would be good enough at least for an initial
> release.

I always fear putting going in a direction that is "good enough for 
now", especially if it is something fundamental to the way the program 
operates.  The tendency in open-development programs is to follow 
someones code lead and push the paradigm as far as it goes.  The danger 
is down the road it doesn't provide the flexibility needed for making 
nice features.


> There are some other issues
>
>      Paste not working
>      Inserting/removing rows/cols not working
>      No support for structure arrays (completely untested)
>      No subeditor opens for internal structures (but the input is eval'd so it
> is somewhat usable at the moment)
>      Plotting doesn't work for cell arrays.
>      Delete does not support shifting and always inserts 0 (should be [] for
> cell arrays)
>      No variable from selection or transpose feature
>      No window splitting
>      No data brush
>      No printing
>      No undo support
>      No sort
>      ...
>
> And a potential thread safety issue. I call `symbol_table::varval' in
> `main_window' from the GUI thread to get the `octave_value'. It could be
> safely passed via signal but that would require registering `octave_value' as
> Qt metatype and I don't know what implications that would have (See 
> http://qt-project.org/doc/qt-4.8/qmetatype.html#qRegisterMetaType).

Calling symbol_table::varval is probably in the callback function 
paradigm.  Qt discourages callbacks, and I don't think the Octave 
developers are that keen on them either (at least I'm not) because they 
entangle the GUI and the core code too much.

Your idea of registering has been a point of discussion in the past. 
There is nothing wrong with registering something like octave_value, but 
octave_value is probably the wrong thing to transfer via signal across a 
thread.  The reason has to do with atomic count and how that is 
inherently modified by creation, copying, etc.  If that count is 
modified asynchronously on one thread, it causes a conflict on the 
thread that manages clearing memory based upon the atomic count vanishing.

Through tests, however, I've established that sending pointers to 
octave_value across the thread via signal does not modify the atomic 
count.  But this requires temporarily putting the worker (octave core) 
in a sleep state for microseconds while the GUI copies the data it wants.

This might be a good discussion topic for OctConf '14 if the issue 
hasn't been resolved up to then.  In summary, a solid, flexible 
mechanism for transferring data is needed before going too much further.

In my view, I think that really all that is need is a way to process an 
Octave command in the "background", i.e., the result doesn't appear in 
the command window.  (And of course, the results are sent back to the 
GUI via signal using octave_value pointer...I've don't this, removing 
callbacks, seems to work.)  For example, when a file is opened in the 
editor, the GUI could request in the background all the breakpoints for 
that file.  There is such an Octave script/command already.

In the case of the variable editor, I think after the completion of a 
command the editor just asks for the contents of the variable and 
updates those that have changed, then that is all that is needed.  But I 
would suggest to do so efficiently.  Rather than asking for all 
variables, just ask for those displayed, e.g., x(6:30,17:25) if it is 
only those that are displayed.  To have the core indicate what variables 
it has modified is most efficient, but I'm not sure if we should start 
there.  First see how the above strategy works.

Dan


> Please give it a try and comment.
>
> Regards,
> Rüdiger