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

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

I too had once imagined a library, mostly on the suggestion from someone else.  But as time goes by the more I think gnuplot is fine the way it is as a script interpretter.  Ethan mentioned the data/speed thing, which is true for large data sets.

I mean, I'm not against the idea of a library, header files, etc. (have to figure out how header files will be organized and where to break up routines), but I think it would be wiser to add/fix features to the point of having a very mature, robust system.  The combination of the two (scriptable and compilable library) is just too much to deal with on a part time basis.

Dan


Ethan Merritt wrote:
> 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.
> 
> 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.
> 
> 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.
>    
> 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). 
> 
> 	Ethan
> 
> 
> 
> 
> 
> 
>>"longer term
>>
>>- 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"
>>
>>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.
>>
>>Well, that's it. Don't forget to comment on the modular architecture, and
>>thanks for reading.
>>
>>Best regards,
>>
>>Timothée
> 
> 


-- 

Dan Sebald
phone: 608 256 7718
email: daniel DOT sebald AT ieee DOT org
URL: http://webpages DOT charter DOT net/dsebald/