From bug-request at octave dot org Fri Apr 14 12:25:14 2006 Subject: legend.m vs. gnuplot-4.1 From: "John W. Eaton" To: Joe Koski Cc: "bug at octave dot org" Date: Fri, 14 Apr 2006 13:25:06 -0400 On 6-Apr-2006, Joe Koski wrote: | I've been test driving (via Paul Kienzle) a revised image.m, etc. with the | development version of gnuplot-4.1. When gnuplot-4.1 becomes available, | there will be a large improvement in image type plots from octave. | | One side effect that I have noticed is that legend.m and gnuplot-4.1 do not | get along well. With gnuplot-4.0, I occasionally get an error when using | octave-forge legend with octave-forge print: | | error: invalid row index = 0 | error: evaluating argument list element number 1 | error: evaluating argument list element number 1 | error: evaluating prefix operator `!' near line 189, column 7 | error: if: error evaluating conditional expression | error: evaluating if command near line 189, column 3 | error: called from `legend' in file `/Users/jakoski/Codes/Histograms via | Octave/legend.m' | error: evaluating for command near line 48, column 1 | error: called from `run_temp_pdf_radius' in file | `/Users/jakoski/Codes/Histograms via Octave/run_temp_pdf_radius.m' | | The errors clears by redoing the run, and, usually, the second time, the | legend command works normally. With gnuplot-4.1, the error occurs much more | frequently, but not all the time, and I have yet to complete a run involving | seven legends without the error stopping the run. When I switch back to | gnuplot-4.0, the run finishes. | | I looked at the legend.m routine, and there is no if statement with ! | anywhere near line 189. The routine requires pipes, grep, awk, and sed to do | its job, and I couldn't see an easy fix. I suspect if there were an easy | fix, it would have been done already. The Octave Forge legend function executes a gnuplot "save" command, extract the plot command from the resulting output file, modify it, then issue it again. You are probably seeing a failure becuase of some kind of race condition, and that's probably why it sometimes works. The proper fix is to have Octave's plotting commands save the state of the current plot in some data structure so that it can reliably reissue plot commands after something has changed. If you'd like to help, then please revive the following discussion: http://velveeta.che.wisc.edu/octave/lists/octave-maintainers/2006/147 jwe ------------------------------------------------------------- Octave is freely available under the terms of the GNU GPL. Octave's home on the web: http://www.octave.org How to fund new projects: http://www.octave.org/funding.html Subscription information: http://www.octave.org/archive.html -------------------------------------------------------------