Re: small __uiobject_draw_axes__ bug fix

[Daniel J Sebald]

John W. Eaton wrote:
> On 22-Feb-2007, John W. Eaton wrote:
>
> | On 22-Feb-2007, Daniel J Sebald wrote:
> | 
> | | Oh this is strange.  There is more to this.  (And this seems to have just started happening within the last day.)
> | | 
> | | I updated CVS and cleared out all the local scripts that you updated.  Things are fine; can keep rerunning the same plot command.
> | | 
> | | However, as soon as I make a local copy:
> | | 
> | | cp -a /usr/local/share/octave/2.9.9+/m/plot/__uiobject_draw_axes__.m .
> | | 
> | | into a directory that is part of the Octave search path (no alterations to file), then I get the error messages.
> | 
> | OK, I think this is related to some recent changes I made in the way
> | Octave checks to see whether functions that are loaded in memory are
> | out of date compared to the corresponding .m files.  I'll take a look
> | at it.
>
> I checked in the following patch.  Can you see if it solves the
> problem for you?

(I was off to a county meeting which ran very very long.)

Works, thanks.

As for the flushing of the output thing, try copying the file above to a local 
directory and apply the first patch (run a fresh octave) and the second patch 
(run a fresh octave).  The first version I get

octave:1> plot([0:30])
octave:2> plot([0:30])
ans = hi
xautoscale =  1
octave:3>

The second version

octave:1> plot([0:30])
ans = hi
xautoscale =  1
octave:2> plot([0:30])
ans = hi
xautoscale =  1
octave:3>

That's probably not too startling and it really isn't that big of a problem.  
(Maybe I never understood how output inside scripts should work and that a 
fflush should always be used.)  It's just that I often do debugging by printing 
stuff out.  Also, when doing a simulation I'll occasionally print out a loop 
counter or something.

Dan