gnuplot development

On Tuesday 22 February 2005 05:11 pm, Jingzhao Ou wrote:
> 
> I installed Gnuplot 4.0 on a RedHat Linux box. It seems to be working fine from
> the bash command line. 

OK
 
> I ran a gnuplot script test.dem on PHP as the following:
> 
> system("gnuplot test.dem");
> 
> However, I failed to get any output from Gnuplot even though running "gnuplot
> test.dem" directly in the bash command line would give me the desired result. I
> tried also CGI written in Perl. I can run the Perl script on the bash command
> line and generate the desired ps file. However, when I run it through CGI, I
> got nothing!

It would help if you showed us the gnuplot script itself.

Does your http daemon have write access to the directory where 
you are trying to create a postscript file?

Are there error messages in the http daemon's error log file?

Does the 'test.dem' script refer to any data files, and if so are they 
in the daemon's default directory?

And a separate comment:
Postscript is probably the wrong output format for displaying on a web page.
Have you considered creating a PNG image instead, or emitting in-line
SVG code as part of a dynamic http document?


> Can any one kindly give me a hand! Thanks a lot for your help!!!

Here is a fragment from a working perl-script in daily use on my web site:

    open(GNUPLOT,">$tempfile.gnu");
    if ($y_fixed eq "on") { print GNUPLOT "     set yrange [0:$y_range]\n" ; }
    print GNUPLOT <<EOFgnu;
        set data style linespoints
        set style line 1 lt -1 lw 3 pt 7
        set style line 2 lt  3 lw 3 pt 9
        set style line 3 lt  1 lw 3 pt 5
        set style line 4 lt  4 lw 3 pt 6
        set title 'Distribution of anisotropy by atom class'
        set xlabel 'Anisotropy'
        set ylabel 'Fraction of atoms' -1
        set label '$PLOT_LABEL' at graph 0.025, graph 0.95 left
        set format y '%4.2f'
        set size 1.00, 1.00
        set term png $png_options
        set output '$tempfile.png'
        plot $proteinplot
             $naplot
             $solventplot
             $hetatmplot
EOFgnu
    close(GNUPLOT);




-- 
Ethan A Merritt       merritt@...
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

On Tuesday 22 February 2005 05:29 pm, Ethan Merritt wrote:
>
> Here is a fragment from a working perl-script in daily use on my web
> site:

for which I forgot the opening and final commands....

   $gnuplot = '/usr/local/bin/gnuplot';

>     open(GNUPLOT,">$tempfile.gnu");
...
>     close(GNUPLOT);

   system "$gnuplot $tempfile.gnu" ;

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington 98195-7742

Dear Ethan,

Thanks a lot for your useful information. I figured out the reason from your
second email. I forgot to use the full path name for gnuplot. Sorry for my
silly mistake.

Now, every thing becomes perfect again!!! :-)

Best regards,
Jingzhao

--- Ethan Merritt <merritt@...> wrote:

> On Tuesday 22 February 2005 05:29 pm, Ethan Merritt wrote:
> >
> > Here is a fragment from a working perl-script in daily use on my web
> > site:
> 
> for which I forgot the opening and final commands....
> 
>    $gnuplot = '/usr/local/bin/gnuplot';
> 
> >     open(GNUPLOT,">$tempfile.gnu");
> ...
> >     close(GNUPLOT);
> 
>    system "$gnuplot $tempfile.gnu" ;
> 
> -- 
> Ethan A Merritt
> Biomolecular Structure Center
> University of Washington 98195-7742

Hi,

You wrote
> I planned to use Gnuplot for online plotting, some thing like what is showing
> on the following URL:
>
> http://www.srcf.ucam.org/~sea31/

I'd just like to warn you that gnuplot is almost certainly *not*
secure against malicious inputs.  That is, it is very likely that
malicious commands could crash or buffer-overflow gnuplot.  You sould
look very carefully at the security risks of allowing untrusted people
to provide gnuplot commands -- they might well be able to take over
control of the gnuplot process and use it for malicious purposes.

ciao,

-- 
-- Jonathan Thornburg <jthorn@...>
    Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut),
    Golm, Germany, "Old Europe"     http://www.aei.mpg.de/~jthorn/home.html
    "Washing one's hands of the conflict between the powerful and the
     powerless means to side with the powerful, not to be neutral."
                                       -- quote by Freire / poster by Oxfam

Hi, Jonathan,

Thanks a lot for your warning. I am going to invoke Gunplot indirectly through
another numerical processing program. So, hope that it will be safe enough. :-)


Best regards,
Jingzhao

--- Jonathan Thornburg <jthorn@...> wrote:

> Hi,
> 
> You wrote
> > I planned to use Gnuplot for online plotting, some thing like what is
> showing
> > on the following URL:
> >
> > http://www.srcf.ucam.org/~sea31/
> 
> I'd just like to warn you that gnuplot is almost certainly *not*
> secure against malicious inputs.  That is, it is very likely that
> malicious commands could crash or buffer-overflow gnuplot.  You sould
> look very carefully at the security risks of allowing untrusted people
> to provide gnuplot commands -- they might well be able to take over
> control of the gnuplot process and use it for malicious purposes.
> 
> ciao,

Ethan Merritt wrote:

>Which is preferable?
>
>(1) Leave the new options dependent on PM3D
>
>(2) Move the data structures and utility routines out of the
>    #ifdef PM3D  brackets, so that the new feature are available
>    even if for some reason you don't want PM3D
>
>Leaving things the way they are is obviously less work, but it
>kind of offends my sense of esthetics to have useful code features
>unecessarily dependent on unrelated options. 
>  
>

Didn't we run into something similar with the image code and pm3d?  
I.e., we found that some things are used by the image code that if PM3D 
is not enabled, the image software won't compile.  So we just decided to 
condition image code on PM3D being defined... but I too would opt for 
preference 2 if someone wanted to do that.

Dan

> Which is preferable?
>
> (1) Leave the new options dependent on PM3D
>
> (2) Move the data structures and utility routines out of the
>     #ifdef PM3D  brackets, so that the new feature are available
>     even if for some reason you don't want PM3D

Or even (3): remove all #ifdef PM3D. Now, this functionality is an inherent
part of gnuplot, so it does not make sense any longer to separate its source
code pieces visually by #ifdef PM3D ... #endif.

Same for USE_ULIG_FILLEDBOXES, USE_ULIG_RELATIVE_BOXWIDTH, and maybe
something more?

What do you think?

---
PM

Petr Mikulik wrote:
>> Which is preferable?
>> 
>> (1) Leave the new options dependent on PM3D
>> 
>> (2) Move the data structures and utility routines out of the #ifdef
>> PM3D  brackets, so that the new feature are available even if for
>> some reason you don't want PM3D

> Or even (3): remove all #ifdef PM3D. Now, this functionality is an
> inherent part of gnuplot, so it does not make sense any longer to
> separate its source code pieces visually by #ifdef PM3D ... #endif.

That's not all the #ifdef's are for.  The key purpose of --disable-pm3d
nowadays is to allow people to build a special version of gnuplot
without pm3d, if (they think) they have to, in some special
circumstances.  E.g. if the system is too small to support a full, big
current gnuplot.

I thus object to throwing out the #ifdef's. But I offer yet another option:

(4) add an --enable switch for the new features, and change those
particular #ifdef's from #if PM3D to #if WANT_THESE_ROUTINES,
and enable that define if either PM3D or the new toggle is enabled.

Obviously, this only makes sense if the code in question is only a
relatively small part of the #if PM3D code.

> I thus object to throwing out the #ifdef's. But I offer yet another option:
>
> (4) add an --enable switch for the new features, and change those
> particular #ifdef's from #if PM3D to #if WANT_THESE_ROUTINES,
> and enable that define if either PM3D or the new toggle is enabled.

I don't like adding new --enable unless it is really really necessary for
some testing. Either the feature is approved, or not. (People don't care
about --enable too much, and editing config/{config.xxx, makefile.xxx} is
ugly.)

---
PM

Petr Mikulik wrote:

>>Which is preferable?
>>
>>(1) Leave the new options dependent on PM3D
>>
>>(2) Move the data structures and utility routines out of the
>>    #ifdef PM3D  brackets, so that the new feature are available
>>    even if for some reason you don't want PM3D
>>    
>>
>
>Or even (3): remove all #ifdef PM3D. Now, this functionality is an inherent
>part of gnuplot, so it does not make sense any longer to separate its source
>code pieces visually by #ifdef PM3D ... #endif.
>

I'm fine with that.  There should still be the natural division of color 
attribute code, pm3d drawing code, etc.  That may already be the case, 
and #ifdef PM3D happens to comment out more than it really should.  Just 
double check that things are organized well.

Dan

> >Or even (3): remove all #ifdef PM3D. Now, this functionality is an inherent
> >part of gnuplot, so it does not make sense any longer to separate its source
> >code pieces visually by #ifdef PM3D ... #endif.
> >
>
> I'm fine with that.  There should still be the natural division of color
> attribute code, pm3d drawing code, etc.  That may already be the case,
> and #ifdef PM3D happens to comment out more than it really should.  Just
> double check that things are organized well.

That #ifdef PM3D is there since 1999 when I developed pm3d plotting mode as
a completely new feature with new terminal entries. Nowadays, that #ifdef
PM3D does not make too much sense because much more functionality has been
added to it (i.e., not only "splot with pm3d"), and we see that it has
become an inherit part of the gnuplot core: #ifdef PM3D is not only for
3D, but also for 2D -- so, it makes really no sense as __3D.

Well, there are people who use gnuplot on servers, but what would they want?
To comment the whole "3D plotting" completely? That would make more sense.

Is there anybody else who would like not to compile it in? 16bits are not
supported any longer.

So, I would remove #ifdef PM3D.

--
PM

Petr Mikulik wrote:

>>I thus object to throwing out the #ifdef's. But I offer yet another option:
>>
>>(4) add an --enable switch for the new features, and change those
>>particular #ifdef's from #if PM3D to #if WANT_THESE_ROUTINES,
>>and enable that define if either PM3D or the new toggle is enabled.
>>    
>>
>
>I don't like adding new --enable unless it is really really necessary for
>some testing. Either the feature is approved, or not. (People don't care
>about --enable too much, and editing config/{config.xxx, makefile.xxx} is
>ugly.)
>  
>

I agree with this.  Gnuplot is a fairly small program compared to many.  
I'd say if people complain about needing memory space then add 
conditional compiles.  Most comments I see are from users who see a 
patch on S.F. and say "I can use this!"; or from people who just want 
things to compile seamlessly.  I've yet to see someone complain about 
bloatedness... except for some of us who think gnuplot uses too much 
space storing data internally, say no more.  :-)

Dan

(I'm cc'ing people directly because I'm not sure the attachment will
 make it onto the list)

> Or even (3): remove all #ifdef PM3D. Now, this functionality is an inherent
> part of gnuplot, so it does not make sense any longer to separate its source
> code pieces visually by #ifdef PM3D ... #endif.
> 
> Same for USE_ULIG_FILLEDBOXES, USE_ULIG_RELATIVE_BOXWIDTH, and maybe
> something more?

I have wanted to remove USE_ULIG_RELATIVE_BOXWIDTH since before
the 4.0 release. It protects a grand total of about 20 lines of code,
and half of those are just an additional test inside an existing if() statement.
There is no run-time penalty in memory use.

The code supporting USE_ULIG_FILLEDBOXES is slightly bigger, but not much.
Again there is no run-time penalty in memory use that I can see.

So yes, I would favor removing the  #ifdef and configuration options
for both of these.


Here are some size comparisons for different configuration options:

    text     data      bss      dec    hex filename
#-----------------------------------------------------------------------
  946764    83476    34016  1064256 103d40 gnuplot_default
  930054    83216    33888  1047158  ffa76 gnuplot_no_strings_histograms
  941086    81168    33984  1056238 101dee gnuplot_no_aed_regis_tek
  934260    83196    34016  1051472 100b50 gnuplot_nofilledboxes
  929010    83204    34016  1046230  ff6d6 gnuplot_noimage
  848734    78364    30816   957914  e9dda gnuplot_noimage_nopm3d
  688172    59708    14208   762088  ba0e8 gnuplot_termshortlist
  614196    54616    13920   682732  a6aec gnuplot_onedriveronly
  599186    55632    13504   668322  a32a2 gnuplot_nopm3d_termshortlist

These are respectively

- default configuration of current cvs (includes gd and pdf terminals)
- ./configure --disable-histograms --disable-stringvariables --disable-datastrings
- comment out some really old terminal drivers
- ./configure --disable-filledboxes
- ./configure --disable-with-image
- ./configure --disable-pm3d
- build only shortlist terminals (dumb epslatex/pslatex/post/pstex table x11)
- one terminal driver only (x11 dumb table)
- shortlist terminals and no pm3d no image


And a plot attached (which of course could not have been produced
if all these great options were disabled :-)  
*** NOTE LOG SCALE ON Y ***

As you can see, the code and data sizes are far more sensitive to
choice of terminal drivers than to the code configuration options.
Building without pm3d+image gains you 10% in size
Building without most of the other post-4.0 features gains about 2% 
Building with a short list of terminals gains you 28% in size

In the extreme case of an embedded environment with a fixed display,
the further reduction to a single terminal driver (I used x11
for convenience to test the size) gains you 36%


-- 
Ethan A Merritt       merritt@...
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Ethan Merritt wrote:

> 
> Here are some size comparisons for different configuration options:
> 
>     text     data      bss      dec    hex filename
> #-----------------------------------------------------------------------
>   946764    83476    34016  1064256 103d40 gnuplot_default
>   930054    83216    33888  1047158  ffa76 gnuplot_no_strings_histograms
>   941086    81168    33984  1056238 101dee gnuplot_no_aed_regis_tek
>   934260    83196    34016  1051472 100b50 gnuplot_nofilledboxes
>   929010    83204    34016  1046230  ff6d6 gnuplot_noimage
>   848734    78364    30816   957914  e9dda gnuplot_noimage_nopm3d
>   688172    59708    14208   762088  ba0e8 gnuplot_termshortlist
>   614196    54616    13920   682732  a6aec gnuplot_onedriveronly
>   599186    55632    13504   668322  a32a2 gnuplot_nopm3d_termshortlist
> 
> These are respectively
> 
> - default configuration of current cvs (includes gd and pdf terminals)
> - ./configure --disable-histograms --disable-stringvariables --disable-datastrings
> - comment out some really old terminal drivers
> - ./configure --disable-filledboxes
> - ./configure --disable-with-image
> - ./configure --disable-pm3d
> - build only shortlist terminals (dumb epslatex/pslatex/post/pstex table x11)
> - one terminal driver only (x11 dumb table)
> - shortlist terminals and no pm3d no image

Interesting.

> And a plot attached (which of course could not have been produced
> if all these great options were disabled :-)  

:-)

> *** NOTE LOG SCALE ON Y ***

It appears to me that the bars of this PDF overlap slightly.  It's as though the bars have lines 
along the outside occupying the same coordinates.  Is there a "no line" option where the inside 
"fill" can go right up against the coordinates as computed by the histogram routine?  Or is that 
what the -1 below does?

        set style fill solid 1.0 border -1

Or should the histogram suggestion be to use "noborder"?  I think that is probably the case because 
the histogram groups in the

  set title "Immigration from different regions\n(give each histogram a separate title)"

demo in histograms.dem looks fairly good.  (It uses "noborder".)

So, maybe change the histogram help documentation to read "noborder" rather than "border -1".  Also, 
I'd suggest "noborder" as the default for solid fill style.  (Or would that be too confusing with a 
fill style that defaults to no fill? In which case, one would want a border to appear.)

Dan

> I have wanted to remove USE_ULIG_RELATIVE_BOXWIDTH since before
> the 4.0 release. It protects a grand total of about 20 lines of code,
> and half of those are just an additional test inside an existing if() statement.
> There is no run-time penalty in memory use.
>
> The code supporting USE_ULIG_FILLEDBOXES is slightly bigger, but not much.
> Again there is no run-time penalty in memory use that I can see.
>
> So yes, I would favor removing the  #ifdef and configuration options
> for both of these.
>
>
> Here are some size comparisons for different configuration options:

Great report.
I wish to remove USE_ULIG* and PM3D.

---
PM

Petr Mikulik wrote:
>>>Or even (3): remove all #ifdef PM3D. Now, this functionality is an inherent
>>>part of gnuplot, so it does not make sense any longer to separate its source
>>>code pieces visually by #ifdef PM3D ... #endif.
>>>
>>
>>I'm fine with that.  There should still be the natural division of color
>>attribute code, pm3d drawing code, etc.  That may already be the case,
>>and #ifdef PM3D happens to comment out more than it really should.  Just
>>double check that things are organized well.
> 
> 
> That #ifdef PM3D is there since 1999 when I developed pm3d plotting mode as
> a completely new feature with new terminal entries. Nowadays, that #ifdef
> PM3D does not make too much sense because much more functionality has been
> added to it (i.e., not only "splot with pm3d"), and we see that it has
> become an inherit part of the gnuplot core: #ifdef PM3D is not only for
> 3D, but also for 2D -- so, it makes really no sense as __3D.
 >
 > Well, there are people who use gnuplot on servers, but what would they want?
 > To comment the whole "3D plotting" completely? That would make more sense.

Right.  The more natural division is between 2D and 3D.  But given what Ethan has shown in the 
compile stats, I doubt removing the 3D portion of the code will do much; also keeping in mind I plan 
to integrate 2D/3D plot layout more smoothly, I doubt people will care later on about removing 3D.

Dan

> 2005-02-09  Harald Harders  <h.harders@...>
>
>         * share/: New directory.
>
>         * share/LaTeX/Makefile share/LaTeX/README share/LaTeX/gnuplot.cfg:
>         New directory LaTeX/. New files for supporting the epslatex terminal.
>
> I can't find this directory.

It is there:

$find gnuplot/share -name "*"
gnuplot/share
gnuplot/share/CVS
gnuplot/share/CVS/Root
gnuplot/share/CVS/Repository
gnuplot/share/CVS/Entries
gnuplot/share/CVS/Entries.Log
gnuplot/share/LaTeX
gnuplot/share/LaTeX/CVS
gnuplot/share/LaTeX/CVS/Root
gnuplot/share/LaTeX/CVS/Repository
gnuplot/share/LaTeX/CVS/Entries
gnuplot/share/LaTeX/Makefile
gnuplot/share/LaTeX/README
gnuplot/share/LaTeX/gnuplot.cfg


---
PM

Ethan Merritt wrote:
> By the way, in trying to build gnuplot without the postscript
> terminal driver I discovered that the recent commingling of
> postscript/pslatex/epslatex has made this impossible.
> 
> In particular I object to the following contamination of core
> routines with terminal-specific code.  If we need a new terminal
> entry for this, then so be it. But having the core code writing
> this garbage is just really really ugly.

Oo, yes.  Don't start this sort of thing.  There must be a good solution to this inside the terminal 
driver, e.g., static variables for remembering when to put this string in the LaTeX file.  Harald?

> -    /* Print \includegraphics here when using back option for text */
> -    if (term->name=="epslatex" && gpoutfile)
> -       fprintf(gpoutfile, "    \\put(0,0){\\includegraphics{%s}}%%\n",
> -               pslatex_auxname);

Dan

in "bug for cgm term mono?" 
   "Tatsuro MATSUOKA <matsuoka@...

>When I tested the 'cgm term mono' on wgnuplot 4.0 and 4.1 using the following
>
>set term cgm mono
>set out 'test.cgm'
>test
>set out
>
>Points whose number 4 to 13 is not visible because those colors are white.

In the gnuplot thread in Japan, Prof. Matsuda@... Denki Univ. reported that the bug above can be 
corrected by modification of cgm.trm.

**********************************************
original
if (cgm_monochrome || linecolor == cgm_color)
return;


modified：
if ( cgm_monochrome ){
cgm_color = linecolor = 1;
return;
}
else if (linecolor == cgm_color){
return;
}
***********************************************
I appreciate Prof. Matsuda.