Re: Please use this bug report instead... thanks.

[Daniel J S. <dan...@ie...>]

John W. Eaton wrote:

>On  4-Jul-2003, Daniel J Sebald <dan...@ie...> wrote:
>  
>
<snip>

>| the gnuplot group has discussed. I guess the main
>| issue to Octave developers might be "how could
>| such a thing work nicely through a pipe".
>
>Sorry for not responding until now.
>

That's fine John.  I see that the Octave developers have been doing a 
lot of stuff lately.

>I think image overlays on graphs might be interesting.  Binary data
>transer to gnuplot would also be nice, as would the elimination of
>temporary files.
>

I'm uploading a PDF version of the demo that goes along with the "with 
image" patch that is at Gnuplot's SourceForge site to my web page. 
 (Let's hope it all fits in my web space...)  If the file makes it, go 
to the web page listed below after removing the spaces I put in the 
address.  Look under "gnuplot stuff" and then look for the file 
"image.pdf"...  OK, it just finished transferring and is complete.

I and, I think, a lot of the Gnuplot list people using Octave don't like 
the temporary file solution either.

>Regarding elimination of temporary files, there were some problems
>with that when I tried it, related to the requirement that subsequent
>replot commands also need to pass the data back to gnuplot and Octave
>is not set up to handle that.
>

Yes, that is an issue.  This is something that has been discussed 
several times on the list.  Gnuplot's current paradigm is a "terminal". 
 Some have suggested having something more object oriented where all 
information necessary for replotting is kept internal to Gnuplot. 
 However, that is just an idea and if it were to happen it would be 
rather far down the road I think.

>Do you know if there will ever be another gnuplot release?  (I know,
>you could ask the same about Octave.)  It's easier for a package like
>Octave to use the new features of gnuplot if they appear in a released
>version.
>

Yes, the trend appears to be a non beta version, 4.0, in the near 
future.  The developers are putting a lot of work into seeking out any 
remaining problems.  Images and binary data will be after 4.0 because 
that is quite a bit of new syntax and hasn't been tested by too many 
developers, although some of the developers have added features such as 
PDF/PNG drivers and EDF data file access.

>Finally, do you think there will ever be a reasonably clean C
>interface to the gnuplot internals?  It would certainly be better than
>working through a pipe.  Alternatively, is there a reliable way to
>query gnuplot about its internal state from an external program?  It
>would be very useful if Octave could ask gnuplot what the current
>setting of the terminal type is, for example.  I'd rather not have to
>rely on parsing potentially arbitrary text output since that could
>easily change from version to version and then my output parser would
>quit working properly.
>
>If you have other ideas or questions, post them to the help-octave,
>octave-graphics, or octave-maintainers mailing list(s) as you feel
>appropriate.
>
>Thanks,
>
>jwe
>

Regarding the first issue of a C interface, my guess would be no.  The 
syntax is more the standard in Gnuplot, and from what I've observed of 
the code it doesn't resemble a library-like construction.  Personally, I 
don't find the pipe interface to be too bad, given that I have used 
Gnuplot for my own unrelated GUI program.  Oh BTW, the upcoming Gnuplot 
release should have the X11 sixteen plot limit removed, and there will 
be a way to label the window and a way to close a window.

I'm carbon copying to the gnuplot discussion list.  Someone there might 
know about the internal state issue.  I've read it discussed a few times 
but I hadn't paid too close attention.

Regards,

Dan

-- 

Dan Sebald
email: daniel . sebald @ ie ee . o rg
URL: ht tp://acer-access.c om/~dsebald @ acer-access.c om/