From bug-request at octave dot org Fri Apr 14 14:32:59 2006 Subject: Re: legend.m vs. gnuplot-4.1 From: Joe Koski To: "John W. Eaton" CC: "bug at octave dot org" Date: Fri, 14 Apr 2006 14:20:57 -0500 on 4/14/06 11:25 AM, John W. Eaton at jwe at bevo dot che dot wisc dot edu wrote: > 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 > > John, Paul Kienzle pointed out that he had modified legend.m since the last octave-forge-2006.03.17 version, and told me where to get his cvs version. I got the revised version of legend.m, and the problem went away. Except for a standalone use of gnuplot-4.1 for surface fitting, my gnuplot-4.1 has functioned perfectly with and without octave. For my surface fit case, the color map is different, but I suspect I just need to find the correct commands to restore the gnuplot-4.0 color map before I plot. I don't want to ask the gnuplot folks about that until they have an official version. (Their list is definitely less user friendly than octave's.) I've thought about joining the maintainers list, but, while I'm a relatively competent Fortran 77 programmer, I don't know as much as I would like about C, C++, etc. (meaning very little). I guess I could do some "friendly octave user testing," but I would need to get more up to speed on my cvs retrieval skills and building octave-2.9.x first. If that's ok, I could monitor the maintainer list and see if there are things I could try as a Mac user. Ideas? Joe ------------------------------------------------------------- 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 -------------------------------------------------------------