Library version of gnuplot [was: gnuplot projects, terminal modules]

[Ethan M. <merritt@u.washington.edu>]

On Thursday 08 March 2007 04:53, Timoth=E9e Lecomte wrote:

> Another interesting comment was the lack of=20
> a powerful and broadly available (i.e. for many languages) plotting
> library. I think gnuplot could be modified to achieve this goals if its
> parser was written as a layer above a real API. It looks like it is what
> can be found in the TODO file:

In my long-ago days, pre-gnuplot, I did a *lot* of programming with
graphics libraries, and to a lesser degree extending and maintaining
the libraries themselves.  I cannot begin to tell you how much relief
I felt at being able to ditch all that and instead use a scriptable
tool like gnuplot.   So my extensive experience with both approaches
leads me to believe that this desire for a library version is mis-placed.
It *sounds* reasonable, but when you actually try to use it you find
out that from a programming perspective it is a worse alternative than
a scripted interface.

The only possible advantage I see is the speed with which very large
data sets could be rendered.  In the case of a library you don't have to
pipe the data between two separate executables.  But if that were=20
sufficiently important we could implement it anyhow, admittedly in an
OS-specific manner, by shared memory regions.

=46urthermore, if you look at the most powerful visualization tools,=20
e.g. AVS, S+, Mathematica, you will notice they went the other direction
entirely.  These are not libraries of routines that you call from
an application program.  They are self-contained frameworks within
which you can embed your application.

So my personal evaluation of the proposal to make gnuplot a callable
library is that it would be a lot of work for almost no gain.
  =20
I would be much more interested in proposals to extend gnuplot in
the other direction, allowing it to call user-provided application
code.  One example of this kind of thinking is patchset #588805
(the oldest patch still active on our tracker).=20

	Ethan





>=20
> "longer term
>=20
> - break it into four layers:
>   : low level graphics  (some of term.c)
>   : plotting code, reading the setshow.h global variables
>   : parsing code - read a string, and parse and execute it
>   : front end, interact with terminal / gui"
>=20
> So, I think I'll try to work on this. I have a couple of milestones in
> mind, starting from the rewrite of the term->options functions so that the
> parser is not called from the terminals. Then maybe extract an API for the
> set/show functions to separate them from the parsing code.
>=20
> Well, that's it. Don't forget to comment on the modular architecture, and
> thanks for reading.
>=20
> Best regards,
>=20
> Timoth=E9e

=2D-=20
Ethan A Merritt            Courier Deliveries: 1959 NE Pacific
Dept of Biochemistry
Health Sciences Building
University of Washington - Seattle WA 98195-7742