Re: Passing variables up to the GUI

[Daniel J Sebald]

On 04/12/2013 09:45 PM, John W. Eaton wrote:
> On 04/12/2013 10:39 PM, John W. Eaton wrote:
> > On 04/12/2013 10:31 PM, Daniel J Sebald wrote:
> >
> > > There is no requirement that such a function behave exactly as the
> > > interpreter that the user has. As with the "corefeval" I proposed the
> > > other day, it is that underlying builtin code that is what the GUI has
> > > interest in. So, the commands that go from the GUI's internal access
> > > bypass that first level of indirection that otherwise would be M-script
> > > overrides, variable overrides, etc. Neither would these commands appear
> > > in the history list. The best way to describe "corefeval" is that
> > > builtins cannot be overriden.
> >
> > Maybe we can consider something like that later but I don't have time
> > now to think about that kind of change or try to make it work.
>
> But, one quick question about what you've proposed. If you send a
> command like
>
> clear x
>
> to the interpreter, how does it know to bypass variables for the symbol
> "clear" but not "x"? Perhaps you can describe something that will work
> for a simple case like this. Will it generalize to any arbitrarily
> complex list of statements?
>
> Since you are calling your function "corefeval", do you see this as
> something that is only intended to call functions, or is it supposed to
> evaluate arbitrary expressions?

It would be a C++ only function (user can't access), similar to the 
"feval" builtin.  But where feval builtin might be

octave_value& feval (command, ...)
  1) Look up where the source of command is.  I'm not
     certain how that works, but I assume there is some
     table that directs the code execution to some builtin
     code, or variable evaluation, or compiled script code--
     however the users sets up the environment.
  2) Evaluate the code and put it into an octave_value
     format.
  3) Handle that code based on how the user has set up the
     output variables.  If no output arguments, it gets
     formated, printed, sent to pager.  If output arguments,
     it gets saved in variables.

octave_value& corefeval (command, ...)
  1) Direct execution directly to core builtins.
  2) Evaluate the code and put it into an octave_value
     format.
  3) Make that octave_value data available to the GUI.

So, there would be that part on Octave core side.  Admittedly, I'm not 
sure how difficult it is and what issues would arise.  But, it is sort 
of simpler than the work that feval needs to do.  If right now the function
address of the builtin is lost once the user overrides, then that's a 
problem.

On the GUI side and interface, there is a bit more work.  I suppose 
there would need to be two queues, maybe one for the user input 
commands, and one for the "callback" commands.  The GUI needs to queue 
up the command and also what object wants the data.  The object that 
wants the data has to know what it asked for and how to interpret it. 
Maybe it asks for "x".  Or maybe it asks for "size(x)".  Or maybe 
"x(1:10,21:30)".

Dan