[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Please use this bug report instead... thanks.
From: |
Daniel J Sebald |
Subject: |
Re: Please use this bug report instead... thanks. |
Date: |
Sat, 20 Dec 2003 22:23:17 -0600 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 |
John W. Eaton wrote:
On 4-Jul-2003, Daniel J Sebald <address@hidden> 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/
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: Please use this bug report instead... thanks.,
Daniel J Sebald <=