You can subscribe to this list here.
2001 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(83) |
Nov
(57) |
Dec
(111) |
2004 |
Jan
(38) |
Feb
(121) |
Mar
(107) |
Apr
(241) |
May
(102) |
Jun
(190) |
Jul
(239) |
Aug
(158) |
Sep
(184) |
Oct
(193) |
Nov
(47) |
Dec
(68) |
2005 |
Jan
(190) |
Feb
(105) |
Mar
(99) |
Apr
(65) |
May
(92) |
Jun
(250) |
Jul
(197) |
Aug
(128) |
Sep
(101) |
Oct
(183) |
Nov
(186) |
Dec
(42) |
2006 |
Jan
(102) |
Feb
(122) |
Mar
(154) |
Apr
(196) |
May
(181) |
Jun
(281) |
Jul
(310) |
Aug
(198) |
Sep
(145) |
Oct
(188) |
Nov
(134) |
Dec
(90) |
2007 |
Jan
(134) |
Feb
(181) |
Mar
(157) |
Apr
(57) |
May
(81) |
Jun
(204) |
Jul
(60) |
Aug
(37) |
Sep
(17) |
Oct
(90) |
Nov
(122) |
Dec
(72) |
2008 |
Jan
(130) |
Feb
(108) |
Mar
(160) |
Apr
(38) |
May
(83) |
Jun
(42) |
Jul
(75) |
Aug
(16) |
Sep
(71) |
Oct
(57) |
Nov
(59) |
Dec
(152) |
2009 |
Jan
(73) |
Feb
(213) |
Mar
(67) |
Apr
(40) |
May
(46) |
Jun
(82) |
Jul
(73) |
Aug
(57) |
Sep
(108) |
Oct
(36) |
Nov
(153) |
Dec
(77) |
2010 |
Jan
(42) |
Feb
(171) |
Mar
(150) |
Apr
(6) |
May
(22) |
Jun
(34) |
Jul
(31) |
Aug
(38) |
Sep
(32) |
Oct
(59) |
Nov
(13) |
Dec
(62) |
2011 |
Jan
(114) |
Feb
(139) |
Mar
(126) |
Apr
(51) |
May
(53) |
Jun
(29) |
Jul
(41) |
Aug
(29) |
Sep
(35) |
Oct
(87) |
Nov
(42) |
Dec
(20) |
2012 |
Jan
(111) |
Feb
(66) |
Mar
(35) |
Apr
(59) |
May
(71) |
Jun
(32) |
Jul
(11) |
Aug
(48) |
Sep
(60) |
Oct
(87) |
Nov
(16) |
Dec
(38) |
2013 |
Jan
(5) |
Feb
(19) |
Mar
(41) |
Apr
(47) |
May
(14) |
Jun
(32) |
Jul
(18) |
Aug
(68) |
Sep
(9) |
Oct
(42) |
Nov
(12) |
Dec
(10) |
2014 |
Jan
(14) |
Feb
(139) |
Mar
(137) |
Apr
(66) |
May
(72) |
Jun
(142) |
Jul
(70) |
Aug
(31) |
Sep
(39) |
Oct
(98) |
Nov
(133) |
Dec
(44) |
2015 |
Jan
(70) |
Feb
(27) |
Mar
(36) |
Apr
(11) |
May
(15) |
Jun
(70) |
Jul
(30) |
Aug
(63) |
Sep
(18) |
Oct
(15) |
Nov
(42) |
Dec
(29) |
2016 |
Jan
(37) |
Feb
(48) |
Mar
(59) |
Apr
(28) |
May
(30) |
Jun
(43) |
Jul
(47) |
Aug
(14) |
Sep
(21) |
Oct
(26) |
Nov
(10) |
Dec
(2) |
2017 |
Jan
(26) |
Feb
(27) |
Mar
(44) |
Apr
(11) |
May
(32) |
Jun
(28) |
Jul
(75) |
Aug
(45) |
Sep
(35) |
Oct
(285) |
Nov
(99) |
Dec
(16) |
2018 |
Jan
(8) |
Feb
(8) |
Mar
(42) |
Apr
(35) |
May
(23) |
Jun
(12) |
Jul
(16) |
Aug
(11) |
Sep
(8) |
Oct
(16) |
Nov
(5) |
Dec
(8) |
2019 |
Jan
(9) |
Feb
(28) |
Mar
(4) |
Apr
(10) |
May
(7) |
Jun
(4) |
Jul
(4) |
Aug
|
Sep
(4) |
Oct
|
Nov
(23) |
Dec
(3) |
2020 |
Jan
(19) |
Feb
(3) |
Mar
(22) |
Apr
(17) |
May
(10) |
Jun
(69) |
Jul
(18) |
Aug
(23) |
Sep
(25) |
Oct
(11) |
Nov
(20) |
Dec
(9) |
2021 |
Jan
(1) |
Feb
(7) |
Mar
(9) |
Apr
|
May
(1) |
Jun
(8) |
Jul
(6) |
Aug
(8) |
Sep
(7) |
Oct
|
Nov
(2) |
Dec
(23) |
2022 |
Jan
(23) |
Feb
(9) |
Mar
(9) |
Apr
|
May
(8) |
Jun
(1) |
Jul
(6) |
Aug
(8) |
Sep
(30) |
Oct
(5) |
Nov
(4) |
Dec
(6) |
2023 |
Jan
(2) |
Feb
(5) |
Mar
(7) |
Apr
(3) |
May
(8) |
Jun
(45) |
Jul
(8) |
Aug
|
Sep
(2) |
Oct
(14) |
Nov
(7) |
Dec
(2) |
2024 |
Jan
(4) |
Feb
(4) |
Mar
|
Apr
(7) |
May
(2) |
Jun
(1) |
Jul
|
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Petr M. <mi...@ph...> - 2005-03-02 08:29:58
|
> 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 |
From: Daniel J S. <dan...@ie...> - 2005-03-02 01:04:59
|
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 |
From: Ethan M. <merritt@u.washington.edu> - 2005-03-02 00:55:50
|
from the ChangeLog entry for 2005-02-09 Harald Harders <h.h...@tu...> * 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. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
From: Daniel J S. <dan...@ie...> - 2005-03-01 23:25:07
|
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 |
From: Ethan M. <merritt@u.washington.edu> - 2005-03-01 22:33:43
|
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. --- gnuplot/src/graphics.c 2005-02-24 12:14:16.000000000 -0800 +++ gnuplot-cvs/src/graphics.c 2005-03-01 12:49:19.368297032 -0800 @@ -1482,11 +1482,6 @@ /* PLACE ARROWS */ place_arrows( 0 ); - /* Print \includegraphics here when using back option for text */ - if (term->name=="epslatex" && gpoutfile) - fprintf(gpoutfile, " \\put(0,0){\\includegraphics{%s}}%%\n", - pslatex_auxname); - /* WORK OUT KEY SETTINGS AND DO KEY TITLE / BOX */ if (lkey) { /* may have been cancelled if something went wrong */ /* just use keybox.xl etc worked out in boundary() */ --- gnuplot/src/graph3d.c 2005-02-13 15:55:37.000000000 -0800 +++ gnuplot-cvs/src/graph3d.c 2005-03-01 12:49:02.316889240 -0800 @@ -739,11 +739,6 @@ /* PLACE ARROWS */ place_arrows3d(0); - /* Print \includegraphics here when using back option for text */ - if (term->name=="epslatex" && gpoutfile) - fprintf(gpoutfile, " \\put(0,0){\\includegraphics{%s}}%%\n", - pslatex_auxname); - #ifndef LITE if (hidden3d && draw_surface && !quick) { init_hidden_line_removal(); -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
From: Ethan M. <merritt@u.washington.edu> - 2005-03-01 21:49:01
|
(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@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
From: Daniel J S. <dan...@ie...> - 2005-03-01 17:51:19
|
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 |
From: Petr M. <mi...@ph...> - 2005-03-01 17:40:15
|
> >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 |
From: Daniel J S. <dan...@ie...> - 2005-03-01 16:58:08
|
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 |
From: Petr M. <mi...@ph...> - 2005-03-01 16:44:46
|
> 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 |
From: <br...@ph...> - 2005-03-01 15:51:01
|
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. |
From: Jonathan T. <jt...@ae...> - 2005-03-01 13:38:37
|
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 <jt...@ae...> 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 |
From: Petr M. <mi...@ph...> - 2005-03-01 11:38:45
|
> 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 |
From: Daniel J S. <dan...@ie...> - 2005-02-28 22:29:31
|
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 |
From: Ethan M. <merritt@u.washington.edu> - 2005-02-28 21:46:54
|
I've been working on a more complete set of options for controlling the color of a line separately from its dot/dash pattern. Details when I finish polishing it a bit more. The question at hand is the following. This code (and the earlier RGB color code and filled-curve code) is implemented on top of some of the PM3D data structures and utility routines. Therefore the new options are only available if gnuplot is built with ./configure --enable-pm3d But the ability to separate line color and dot/dash has nothing intrinsically to do with PM3D, and arguably the ability to specify individual rgb colors doesn't either. 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. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
From: Tatsuro M. <mat...@nu...> - 2005-02-26 00:40:04
|
in "bug for cgm term mono?" "Tatsuro MATSUOKA <mat...@nu...>"wrote >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@Tokyo 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. |
From: Tatsuro M. <mat...@nu...> - 2005-02-25 12:49:14
|
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. However once I execute color cgm term like below, it looks like working well. set term cgm color set out 'test.cgm' test set out set term cgm mono set out 'test.cgm' test set out The same phenomena was happened in the cygwin gnuplot (v4), and another person confirmed the similar phenomena in linux gnuplot 4.1. *************************************************************** Tatsuro MATSUOKA E-mail mat...@nu... **************************************************************** |
From: Jingzhao Ou <ja...@ya...> - 2005-02-23 04:47:36
|
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@u.washington.edu> 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 |
From: Ethan M. <merritt@u.washington.edu> - 2005-02-23 03:12:44
|
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 |
From: Ethan M. <merritt@u.washington.edu> - 2005-02-23 01:29:59
|
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@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
From: Jingzhao Ou <ja...@ya...> - 2005-02-23 01:11:22
|
Dear all, I installed Gnuplot 4.0 on a RedHat Linux box. It seems to be working fine from the bash command line. 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 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! I searched Google. It seems that quite some people encountered similar problems. But I failed to find out the answers to the question. Can any one kindly give me a hand! Thanks a lot for your help!!! Best regards, Jingzhao |
From: Jingzhao Ou <ja...@ya...> - 2005-02-23 00:58:14
|
Dear Hans, Thanks a lot for providing me with such useful information. Gnuplot is really powerful these days! I am now switching from MATLAB to Gnuplot for ploting purposes. Have a nice day! Best regards, Jingzhao --- Hans-Bernhard Broeker <br...@ph...> wrote: > Jingzhao Ou wrote: > > > difficulties figuring out what is showing on the GUI. I wonder if there is > any > > settings that I can change the fonts? I fail to find it on the Gnuplot > menus. > > It's in the context menu (where you found it, in the meantime...), and > also accessible in a rather unusual place: the "system menu", i.e. the > menu that opens up if you single click on the icon in the upper left > corner of the window. This menu also serves as the right-click menu of > the taskbar icon (if your Windows has a taskbar ;-). The gnuplot window > has two additional entries in that menu: "Options", and "About". The > "Options" pop-up menu is the same as the right-click context menu of > that window. > > Now, for the text window, that's not particularly interesting, but it's > a very neat trick if you need to access the *graph* window's context > menu, but have mousing enabled --- regular right-click access to the > context menu won't work then, but the system menu entries are still > accessible. > |
From: Hans-Bernhard B. <br...@ph...> - 2005-02-21 10:45:31
|
Jingzhao Ou wrote: > difficulties figuring out what is showing on the GUI. I wonder if there is any > settings that I can change the fonts? I fail to find it on the Gnuplot menus. It's in the context menu (where you found it, in the meantime...), and also accessible in a rather unusual place: the "system menu", i.e. the menu that opens up if you single click on the icon in the upper left corner of the window. This menu also serves as the right-click menu of the taskbar icon (if your Windows has a taskbar ;-). The gnuplot window has two additional entries in that menu: "Options", and "About". The "Options" pop-up menu is the same as the right-click context menu of that window. Now, for the text window, that's not particularly interesting, but it's a very neat trick if you need to access the *graph* window's context menu, but have mousing enabled --- regular right-click access to the context menu won't work then, but the system menu entries are still accessible. |
From: Petr M. <mi...@ph...> - 2005-02-21 09:36:03
|
> >What about, rather for a future > >set shape rect .... > >set object rect ... > >if we want hexagons, circles, ...? > > I originally hoped to implement this without using the > pm3d polygon routines, which meant limiting it to rectangles. > But I ended up using pm3d routines heavily so yes, extending > it to other polygons would not be difficult. > > It would be easy to modify the syntax to > set polygon from <xy0> to <xy1> to <xy2> ... > for an arbitrary number of vertices. The only real change > needed is to allocate the vertices dynamically rather than > simply reserved space for the 2 corners of a rectangle. For regular polygons, I though about: set shape rect from x1,y1 to x2,y2 set shape rect origin x0,y0 size dx,dy [rotated 45] set shape triangle origin x0,y0 size dx,dy [rotated 180] set shape ellipse origin x0,y0 size dx,dy sampling 100 and for arbitrary: set shape polygon corners 1,2,3,4,5,6 ... > > Could the above-mentioned size be given as "stringwidth"? > > Then we could give "size" in the "character" units. > > Very few drivers can pass back enough information to do this in the > core code. > I was thinking instead that a future bit of work could implement > > set label "foo" ... {box|nobox} > > That way drivers (PostScript, gd, pdf) with an internal notion of > textbox size could just stroke the textbox after writing the label text. > The enhanced text code *tries* to keep this information in a generic way, > but it does an imperfect job. That would be useful, and would help to print labels over already printed parts of graph. --- PM |
From: Jingzhao Ou <ja...@ya...> - 2005-02-21 05:50:57
|
Dear Tatsuro, I found the option menu by right clicking in the gnuplot text area! This is really tricky! Now, every thing is perfect! Thanks a lot! Best regards, Jingzhao --- Tatsuro MATSUOKA <mat...@nu...> wrote: > >I am new to Gnuplot. I just downloaded the 4.0 win32 version. It can plot > >graphs. However, the fonts on the main GUI get messed up. I have great > >difficulties figuring out what is showing on the GUI. I wonder if there is > any > >settings that I can change the fonts? I fail to find it on the Gnuplot > menus. > > > This is a very famous for gnuplot win32 for Windows XP or 2000 users in > Japan. > In our cases, we can change the font of command window via the option menu. > The option menu can be open to click the icon on the window bar of the > command window. > Please do not for fotget uptate wgnuplot.ini that also will be found in the > option menu. > > *************************************************************** > Tatsuro MATSUOKA > E-mail mat...@nu... > **************************************************************** |