On Wed, Apr 28, 2010 at 12:56:59AM -0700, Alan Irwin wrote:
> On 2010-04-27 00:11+0100 Andrew Ross wrote:
> > The xwin problem [for the interactive octave examples] is simple - and nothing to do with the p?? examples. Your
> > script called figure with a file name set. This doesn't make sense for
> > interactive drivers.
> Thanks for fixing this. As a result, -dev xwin is now our best interactive
> octave device so I have expanded the number of p examples accordingly
> (revision 10941). p11, p14, p19, and p20 still have some showstopper
> issues with -dev xwin so had to be dropped from the list until those issues
> are fixed. Also, p21 produces a blank black page which is also probably an
> error (although not a showstopper).
I've fixed the issue with p11.
p14 does not display properly for me (for reasons I don't understand).
The axes rather than the mesh are animated. It works fine if called
directly from octave in the bindings/octave directory so it is something
about the way the test script works.
I've changed example 12 so that you no longer have to press a button in
example 20 to get the last plot (was this your issue?)
All other xwin examples are fine - I do not see your issues with 19 or 21.
Which version of octave are you using? I have tested with 3.2.
For qtwidget those examples which rely on calling plGetCursor (12, 17, 18)
fail as qtwidget does not support this. Otherwise qtwidget works as for
> You have only mentioned -dev tk in passing so I thought I had better mention
> that your fix to the script still leaves -dev tk crashing immediately for p1
> for me. Here is the resulting error messages.
> software@...> make test_octave_tk
> Generate interactive octave results for tk interactive device
> Testing interactive octave examples for device tk
> error: fp' undefined near line 213 column 11
> error: evaluating argument list element number 1
> error: evaluating if command near line 207, column 2
> error: evaluating if command near line 186, column 7
> error: evaluating if command near line 92, column 5
> error: evaluating if command near line 86, column 3
> error: called from figure' in file
> error: evaluating for command near line 6, column 1
> make: *** [examples/CMakeFiles/test_octave_tk] Error 1
> make: *** [examples/CMakeFiles/test_octave_tk.dir/all] Error 2
> make: *** [examples/CMakeFiles/test_octave_tk.dir/rule] Error 2
> make: *** [test_octave_tk] Error 2
Well it looks like choosing tk as a driver just does not work at the
moment with octave and probably hasn't for a fair while. figure.m contained
code which called extensions in the tk driver for this particular case.
The current build system certainly does not generate octave bindings for
these, hence the failure. I've commented out these extensions and octave
now works with just the standard tk driver again. Results are comparable
to the xwin driver since tk support plGetCursor. I don't propose to do
anything more with the tk support since I don't fully understand it, I
don't use it, and clearly no-one else does with tk or they would have
filed a bug report a long time ago.
> > I think a lot of the other issues are to do with the interactive aspects.
> > Only the xwin and tk drivers support xor mode which is required. I could
> > work round this (as example 20 does), but this hides the issue. It would
> > be really nice to add this capability to qtwidget and xcairo.
> Agreed. xor capability would be nice for -dev wincairo as well. Once these
> three devices had xor capability, then you could also use the -xor example 1
> option for them. BTW, I haven't looked at the example to see why, but -xor
> for example 1 doesn't seem to erase anything for -dev xwin. Instead, a
> circular cursor is moved slowly over the second sub-page, but leaves the
> plot looking identical. Could that example 1 option be made into a more
> convincing demonstration of xor capability?
I'll try and check this out too.