[Pkg-octave-devel] Bug#408188: Bug#408188: octave2.1-forge: legend doesn't wait long enough for gnuplot

[Thomas Weber]

Am Mittwoch, den 24.01.2007, 14:48 +0000 schrieb Reuben Thomas:
> So, back to this bug. I have cut down the script as follows:
> 
> clear
> x = randn(65536, 1);
> x = x / max(abs(x));
> XR = 20*log10(abs(fft(2*hanning(65536).*x(1:65536), 65536)));
> XP = 20*log10(abs(fft(2*hanning(65536).*x(1:65536), 65536)));
> XS = 20*log10(abs(fft(2*hanning(65536).*x(1:65536), 65536)));
> w = [0:65535]/65536 * 44100;
> plot(w, XR, w, XP, w, XS)
> hold on
> axis([0 22050 -100 80])
> text(5000, -50, '4 kHz: Upper Limit of Data');
> legend('Rabbit','Polyphase','Resample')
> plot([4000 4000], [-100 80], 'g')
> plot([44100 - 4000 44100 - 4000], [-100 80], 'g');
> title('Rate Convert From 8 kHz to 44.1 kHz Of Random Noise');
> ylabel('Magnitude of Spectrum in dB')
> xlabel('Frequency in kHz');
> xlabel('Frequency in Hz');
> hold off
> print RandomNoiseUpsample.pbm
> 
> and I still get the error "gnuplot not responding", presumably because of 
> the same problem with timing out.

Sigh, this problem is more persistent than expected. I tried this on an
old machine and can reproduce it there. Patching legend.m is not
sufficient, I hit similar problems in gget; the problem is known
(comment from the file):

# FIXME:
# this (tries) to prevent a race condition where the file exists,
# but is not yet completely written. This is a stupid hack.
# Limit is 10 seconds of waiting.  This may not be enough in windows,
# but that's moot since windows gget doesn't seem to work.

	Thomas