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

[<tim...@en...>]

> On Thursday 08 March 2007 04:53, Timothée Lecomte wrote:
>
>> Another interesting comment was the lack of
>> 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.

You're probably right, you have much more experience than me in that domain.
However, what I tend to see is that a 'libgnuplot' written in C could have
bindings to whatever scripting language, including the fashioned python,
ruby, and friends.


>
> 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
> sufficiently important we could implement it anyhow, admittedly in an
> OS-specific manner, by shared memory regions.
>
> Furthermore, if you look at the most powerful visualization tools,
> 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.

Maybe because to develop a business model around a proprietary plotting
library. Companies tend to sell complete solutions instead.

Also note that Mathemetica, Matlab, etc. are more for repetitive
simulation/analysis tools. What I had in mind was more the experimental
side, with live acquisition and analysis. That's what LabView, LabWindows
and other GPIB-oriented solutions (for those who don't know, GPIB is a
standardized bus for scientific data acquisition) are written for. Those
are basically programmation languages with graphic libraries, including
plotting libraries. And they seem to quite popular.


>
> 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.

Reusability. That would be the key word in such a project. For gnuplot
features to be useful to more people, they have to be accessible in more
ways that they are today.
Currently, it's tricky to include a gnuplot graph in a data acquisition
program (I mean in the same window, of course), it's unnatural to use
gnuplot from another language than gnuplot native one (think python,
ruby), and it's very difficult to build a useful general-purpose GUI on
top of gnuplot (think xgfe).

>
> 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).

This one is interesting. At least I see that what I wrote with GLib for my
terminals-as-plugins could be done from scratch ;)

Best regards,

Timothée


>
> 	Ethan
>