[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH #8316] Variable Editor
From: |
Daniel J Sebald |
Subject: |
Re: [PATCH #8316] Variable Editor |
Date: |
Thu, 20 Feb 2014 01:00:06 -0600 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16 |
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