Re: Testing MXE-Octave

[Daniel J Sebald]

On 02/11/2013 11:31 PM, Torsten wrote:
> On 11.02.2013 23:14, PhilipNienhuis wrote:
> > John W. Eaton wrote
> > > On 02/11/2013 01:38 PM, Philip Nienhuis wrote:
> > >
> > > > Here's some feedback on the most obvious glitches I found in the
> > > > previous version (with 3.7.1 snapshot):
> > > <snip>
> > > > - The GUI's workspace pane isn't functional - entering something like "a
> > > > = 10" doesn't make a show up in the workspace.
> > >
> > > Yeah, there are lots of problems with the GUI.  I don't think that these
> > > problems are specific to the MXE cross build.
> >
> > IIRC it worked OK with the 3.7.1 snapshot on Linux, so I suspect is *is*
> > related.
> > The UPM version (admittedly based on 3.6.2) doesn't have this issue. On all
> > recent Linux builds I've made the workspace pane works good as well.
>
> AFAIK the workspace is updated by a timer and the UPM version does not
> use timers (Israel, please correct me if I am wrong). This might explain
> why the workspace of the MXE version does not work when the start of a
> timer fails at the beginning.

Sorry, I was talking about the Command Line window in my previous post, 
i.e., the window for which I must move the window slider in order to 
make the text appear at the command line.

I just looked at the Workspace code.  Yes, there is a timer, single 
shot.  That is, the GUI waits a half second then updates the workspace 
variables.  When done, it restarts the timer.  However, it appears that 
the workspace is only updated when the core isn't busy doing something 
else.  So, minimum update of the Workspace tree is every half second, 
but conceivably longer.

What Torsten said is correct.  Although I don't know if there IS some 
way in which workspace_model::update_workspace_callback can fail to be 
called, other than

new octave_link ()

failing, once it fails the single shot timer will not be reset and there 
will be no more callbacks.

Given what I described, does it make sense to have the timer arrangement 
this way?  The timer updates every half second, but doesn't update if 
the core is busy.  What is the advantage of using this timer, then, as 
opposed to refreshing the state whenever Octave returns to the command line?

Is there some desire to have the Workspace updated while Octave core is 
processing?  That sort of thing would only be useful if the GUI would 
continuously display some variable, e.g., a variable used in a loop or 
something.  (In a long simulation, one might accomplish the same sort of 
thing by printing some loop counter to the command line from time to 
time.)  However, I'm not sure how well that would work if the GUI is 
refreshing the Qt tree every time.

Is this interaction with the symbol table and the core a good design?  A 
preferred way perhaps?  I know others have thought a bit more about this.

Dan