Re: Passing variables up to the GUI

[Daniel J Sebald]

On 04/13/2013 03:43 PM, John W. Eaton wrote:
> On 04/13/2013 03:29 PM, Daniel J Sebald wrote:
>
> > The situation we are running into with the GUI is that the worker thread
> > is the one with delay. I tried this the other night with John's
> > workspace-variable-name-change feature. I set Octave to running a
> > two-minute command, then altered the name of the variable. The variable
> > name did not change upon hitting return. Upon Octave core finishing,
> > then the name of the variable mysteriously changed (i.e., my short term
> > memory doesn't work more beyond a minute). I don't think that is
> > unreasonable. Octave commands have to remain sequential; to do otherwise
> > would really get to be tricky programming.
>
> Yes, but what commands are "safe" to execute in this fashion?
>
> Let's say you are running some long script and you attempt to change the
> name of a variable with the GUI workspace browser. That appears to work
> when the request is queued, but what happens if the code you are running
> deletes the variable before your request is processed?

I don't believe that is a problem.  In the prototype:

   retval = eval_string (first_command->toStdString (), false, 
parse_status, first_nout);
   if (!parse_status && !error_state)
     {
       emit octave_command_result (first_qobject, retval);
     }

If the command fails, nothing is emitted back to the GUI, nor is any 
internal workspace variable modified.  Or it could send back the result 
with the first argument being success or fail.  The responsibility is on 
the GUI programmer to understand a bit about what is going on, but I 
think that is fine.

For example, if the user clicks on a variable meant to display its data 
while Octave core is processing and unbeknown to the GUI has been 
deleted.  It queues, in this case,

size(x);
x;

Since the Octave commands are handled sequentially, there won't be a 
situation of size(x) passing and x failing.  So the slots of the 
requesting object can be like a tiny state machine.  If the Octave 
core-side code doesn't emit that sequence of octave_value_list, then the 
slots for displaying data won't be called.  If another such variable is 
requested, the little state machine in the requesting object is reset.

Now, let's say it gets to the point where the GUI has acquired the data 
and want's to modify something.  It queues command

x(3,8) = <user input>;

Well, before changing that value in its display, it needs to get a 
signal that was successfully set.  Otherwise, the value remains 
unchanged.  Or maybe the signal could come back with the boolean result 
of unsuccess in which case the GUI can display "Variable has disappeared 
from workspace".

Dan