Menu
▾
▴
gnuplot-beta
|
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: 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: 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: <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: 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: 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: 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 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-02 15:47:37
|
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 |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-03-01 21:49:01
Attachments:
sizes.pdf
|
(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-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: 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: Ethan M. <merritt@u.washington.edu> - 2005-07-12 19:21:53
Attachments:
termsizes.png
termsizes2.png
|
Here is an updated analysis of the affect of various configuration
options on the size of the gnuplot executable. All trials were
compiled using gcc 3.3.2 with CFLAGS "-g -O2" on a 32-bit Athlon.
"text" contains the code section itself
"data" contains initialized constants (e.g. string constants)
"bss" contains static declared storage (e.g. int foo[BIG])
"dec" is the total text+data+bss
# 11 Jul 2005
#----------------------------------------------------------------
text data bss dec filename
#----------------------------------------------------------------
912159 83428 34144 1029731 gnuplot_default
904447 83428 34048 1021923 gnuplot_nostrings -0.8%
893205 83188 34144 1010537 gnuplot_noimage -2%
817009 78380 30912 926301 gnuplot_nopm3d -10%
681291 60492 17920 759703 gnuplot_shortterm+gd -26%
666013 59620 14304 739937 gnuplot_shorttermlist -28%
605467 55304 17664 678435 gnuplot_dumb+gd+x11 -34%
The first 4 were all built with the default set of terminal drivers
(including pdf and gd). The last three were built with default
configuration options, but a reduced set of terminal drivers
"shortterm+gd" = dumb post estimate x11 gd
"shortterm" = dumb post estimate x11
"dumb+gd+x11" = dumb x11 gd
Bottom line conclusion:
If you want to reduce the size of the gnuplot executable, there is
very little to be gained by disabling configuration options. Disabling
pm3d (which automatically disables with-image and binary-polygon also)
reduces the size by only 10%.
On the other hand, the driver set is huge. In a default build, 40% of
the total size of the gnuplot executable is in term.o (not shown).
For fun, I re-compiled term.o many times with only a single driver
enabled each time. The resulting sizes (minus the base size of the
core code in term.c itself) are shown in the attached plots.
Notes:
This analysis reveals that omitting a small set of drivers, for
example (corel tgif tkcanvas tpic), has more effect on size than
configuring with --disable-pm3d --disable-with-image
The recent changes to pslatex.trm have made it impossible to omit
the pslatex driver from a gnuplot build without hacking the code
in several places. I'll rant on this in a separate Email.
This analysis does not show the effect of compilation options on
dynamically allocated storage, but this should be a very small
effect.
--
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-07-12 20:21:14
|
Ethan Merritt wrote: > Here is an updated analysis of the affect of various configuration > options on the size of the gnuplot executable. All trials were > compiled using gcc 3.3.2 with CFLAGS "-g -O2" on a 32-bit Athlon. termsizes.png would be a good plot for the web page. Dan |
|
From: Petr M. <mi...@ph...> - 2005-07-13 13:15:23
|
> 904447 83428 34048 1021923 gnuplot_nostrings -0.8% > 893205 83188 34144 1010537 gnuplot_noimage -2% > 817009 78380 30912 926301 gnuplot_nopm3d -10% Candidates for being always in gnuplot are: #define EAM_DATASTRINGS 1 #define EAM_HISTOGRAMS 1 #define GP_MACROS 1 #define GP_STRING_VARS 2 #define GP_FIT_ERRVARS 1 They do not change "too many" places of the code. Next candidate is #define PM3D 1 It appears in many places of the code, but anyway, I'm in favor to remove this #define as well. Shall we do it? --- PM |
|
From: Hans-Bernhard B. <br...@ph...> - 2005-07-13 15:16:34
|
Petr Mikulik wrote: > Candidates for being always in gnuplot are: > #define EAM_DATASTRINGS 1 > #define EAM_HISTOGRAMS 1 > #define GP_MACROS 1 > #define GP_STRING_VARS 2 > #define GP_FIT_ERRVARS 1 > > They do not change "too many" places of the code. Careful with this conclusion, please. Changing few or many places of the code is only one side of the issue. The other is possible incompatibility with existing user scripts. That's e.g. why I made FIT_ERRVARS optional in the first place: it intrudes on the namespace for user-defined variables by creating new ones previous versions of gnuplot didn't touch. Now that there's also "set fit noerrorvariables", this is no longer an issue, so this option can go away. By the same reasoning, I'm quite sure it would be premature to make the string variables and macros stuff unconditional right now. It would at least require a run-time switch that turns off all options that may break existing scripts, before the compile-time option can be disposed of. > Next candidate is > #define PM3D 1 > It appears in many places of the code, but anyway, I'm in favor to > remove this #define as well. I'm not --- I still haven't fully given up revitalizing the 16-bit builds yet (I've got DOS16 to link with OW, a third-party linker and some serious modifications...). These 10 percent of extra load could easily kill those. What might make more sense it so collect several existing options into a single new one. I.e. PM3D could be subsumbed under the ancient "small gnuplot" option, #define LITE. This won't make the source code any prettier, but reduce the complexity of the build process (less --enable/--disable switches in configure). |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-07-13 16:01:20
|
Petr Mikulik wrote: > Candidates for being always in gnuplot are: > #define EAM_DATASTRINGS 1 > #define EAM_HISTOGRAMS 1 > #define GP_MACROS 1 > #define GP_STRING_VARS 2 > #define GP_FIT_ERRVARS 1 > #define PM3D 1 On Wednesday 13 July 2005 08:17 am, Hans-Bernhard Broeker wrote: > > I still haven't fully given up revitalizing the 16-bit > builds yet (I've got DOS16 to link with OW, a third-party linker and > some serious modifications...). These 10 percent of extra load could > easily kill those. I think that effort would be a total and utter waste of your time. Anyone runinng 16-bit DOS can just live with version 3.7 Surely the effort is better spent supporting current operating environments than it is retro-fitting to obsolete ones. I have not looked at GP_FIT_ERRVARS in detail, and don't have an opinion on it. The rest of them should go in IMHO. In particular PM3D is now so integral to many new features that I think it would make no sense for anyone to upgrade past version 4.0 and *not* include PM3D. Why go out of our way to support a combination of options that doesn't make any sense? So yes, I think the PM3D code should be made unconditional. If you like, I can resurrect the earlier patch pulling the PostScript prolog and character-encoding text blocks out of the driver and make them separately loadable files. That should gain about half of the PM3D size back right there, and it has other benefits unrelated to 16-bit support. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Robert H. <en...@no...> - 2005-07-14 10:45:07
|
On Wed, 2005-07-13 at 17:17 +0200, Hans-Bernhard Broeker wrote: > I'm not --- I still haven't fully given up revitalizing the 16-bit > builds yet (I've got DOS16 to link with OW, a third-party linker and > some serious modifications...). These 10 percent of extra load could > easily kill those. You're kidding right? Why?! Is there any demand for this at all? or is it just for fun? By all means do this if you really want to - but I can't see any justification for letting this hold back *real* gnuplot development. Rob -- Robert Hart <en...@no...> University of Nottingham This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. |
|
From: Petr M. <mi...@ph...> - 2005-07-13 16:14:11
|
>> Candidates for being always in gnuplot are: > >> #define EAM_DATASTRINGS 1 >> #define EAM_HISTOGRAMS 1 >> #define GP_MACROS 1 >> #define GP_STRING_VARS 2 >> #define GP_FIT_ERRVARS 1 >> #define PM3D 1 > > On Wednesday 13 July 2005 08:17 am, Hans-Bernhard Broeker wrote: >> >> I still haven't fully given up revitalizing the 16-bit >> builds yet (I've got DOS16 to link with OW, a third-party linker and >> some serious modifications...). These 10 percent of extra load could >> easily kill those. > > I think that effort would be a total and utter waste of your time. > Anyone runinng 16-bit DOS can just live with version 3.7 I think so too. Those old PC's are not used for image processing anyway, so they have no reason to switch to gnuplot >= 4.0. > I have not looked at GP_FIT_ERRVARS in detail, and don't have an > opinion on it. The rest of them should go in IMHO. We should avoid having too many gnuplot versions depending on ./configure options. It's better to on/off these features by some "set ..." switches. Was there any report of a broken script? > In particular PM3D is now so integral to many new features that I > think it would make no sense for anyone to upgrade past version 4.0 > and *not* include PM3D. Why go out of our way to support a > combination of options that doesn't make any sense? > > So yes, I think the PM3D code should be made unconditional. I will do this change within one week if there is no really strong objection. > If you like, I can resurrect the earlier patch pulling the PostScript > prolog and character-encoding text blocks out of the driver and make > them separately loadable files. That should gain about half of the > PM3D size back right there, and it has other benefits unrelated to > 16-bit support. The problem with loadable files is there to install them. Gnuplot supports too many OSes. Gnuplot load path is a candidate, but ... e.g. usual MSW users do not have any idea about setting environmental variables. --- PM |
|
From: <ha...@on...> - 2005-07-15 05:47:50
|
On Wed, Jul 13, 2005 at 06:14:02PM +0200, Petr Mikulik wrote: > > > >On Wednesday 13 July 2005 08:17 am, Hans-Bernhard Broeker wrote: > >> > >>I still haven't fully given up revitalizing the 16-bit > >>builds yet (I've got DOS16 to link with OW, a third-party linker and > >>some serious modifications...). These 10 percent of extra load could > >>easily kill those. > > > >I think that effort would be a total and utter waste of your time. > >Anyone runinng 16-bit DOS can just live with version 3.7 > > I think so too. Those old PC's are not used for image processing anyway, > so they have no reason to switch to gnuplot >= 4.0. > ... > > >In particular PM3D is now so integral to many new features that I > >think it would make no sense for anyone to upgrade past version 4.0 > >and *not* include PM3D. Why go out of our way to support a > >combination of options that doesn't make any sense? > > > >So yes, I think the PM3D code should be made unconditional. > > I will do this change within one week if there is no really strong > objection. > Has there been a consensus on such a change in the direction of gnuplot development? From the gnuplot home page "Gnuplot is a portable command-line driven interactive data and function plotting utility for ...many platforms ... has grown to support many non-interactive uses, including web scripting and integration as a plotting engine for third-party applications like Octave." PM3D support adds image processing but that is an option in v4.0. Users who have no need for the image processing features, who do not have graphics hardware to support PM3D graphics, or to whose OS PM3D is not ported can build a v4.0 executable without PM3D support. You seem to be taking the position that portability and local configurability of gnuplot are no longer goals, rather that newer versions of gnuplot are intended solely for systems capable of being used for image processing and that, consequently, other improvements which might be of value for data and function plotting on older platforms (e.g., expanded features for labels, keys, strings, and the postscript terminal, font selection, the histogram style, multi-plot layout, etc.) will not be made available to users unless they can and do build with PM3D support. While it is an additional burden on developers to code and test w/ and w/o PM3D support, and building w/o PM3D support on Linux platforms may have little impact on resources, I believe requiring gnuplot users to include PM3D support is a major change that may affect portability. Since PM3D is still conditional in the cvs build, I would advocate not removing the build option until after a v4.1 release so that the other new features may be made available to a broader user base and at which time some user feedback can be obtained about the impact of requiring PM3D on other platforms. - Lucas Hart Oregon State University Corvallis, Oregon USA |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-07-13 19:23:18
|
On Wednesday 13 July 2005 09:14 am, Petr Mikulik wrote: > > If you like, I can resurrect the earlier patch pulling the PostScript > > prolog and character-encoding text blocks out of the driver and make > > them separately loadable files. > > The problem with loadable files is there to install them. Gnuplot supports > too many OSes. Gnuplot load path is a candidate, but ... e.g. usual MSW > users do not have any idea about setting environmental variables. That was the objection raised before. Where is the help file kept on these platforms? I would have thought we could put these extra files in the same directory as the help file. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Petr M. <mi...@ph...> - 2005-07-14 07:04:26
|
>> The problem with loadable files is there to install them. Gnuplot supports >> too many OSes. Gnuplot load path is a candidate, but ... e.g. usual MSW >> users do not have any idea about setting environmental variables. > > That was the objection raised before. > Where is the help file kept on these platforms? I would have thought we > could put these extra files in the same directory as the help file. Yes, it is in the same dir as the executable, so your approach will work. --- PM |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-07-13 21:34:57
|
On Wednesday 13 July 2005 02:25 pm, Daniel J Sebald wrote: > > After that, I'd propose making the BINARY_DATA_FILE permanent too. > It would unify the code flow for ASCII, binary, 2D, 3D. > I can put together a patch for that down the road. I am opposed to removing the EXPERIMENTAL warnings on that one. The binary data file code is still very messy, and having it set off by conditional flags is the only way anyone will ever be able to find pieces for cleanup. Which reminds me... I did some small amount of such cleanup recently. You might have a look and see how much of the special-casing of the BINARY code is not necessary. What I really hope to see is gradual cleanup and consolidation of the binary and ascii code, to the point that there are hardly any special BINARY_DATA_FILE pieces remaining. At that point removing the warning and the conditional coding would make sense. -- 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-07-13 22:03:40
|
Ethan Merritt wrote: > On Wednesday 13 July 2005 02:25 pm, Daniel J Sebald wrote: > >>After that, I'd propose making the BINARY_DATA_FILE permanent too. >>It would unify the code flow for ASCII, binary, 2D, 3D. >>I can put together a patch for that down the road. > > > I am opposed to removing the EXPERIMENTAL warnings on that one. > The binary data file code is still very messy, and having it set off > by conditional flags is the only way anyone will ever be able to find > pieces for cleanup. What I am proposing is pulling out the mess. I think what I have done (when the new binary data file is active) is just what you propose. You suggested a while back that ASCII and binary be kept as separate functions. I did that, yet retained the same "flow"... similar function calls; in fact, in the new setup the 2D/3D portions of the code don't even know what type of data file the data has come from. That wasn't the case in the old code; limiting in 2D from what I recall. In that patch, I've left all the old code for binary exactly as it was so that when BINARY_DATA_FILE is deactivated the code is just as it always was. That means one would not only remove the BINARY_DATA_FILE flags, but all the extraneous old code. Also, the "bin_hook.c" will get tossed. That was only for the purpose of including or excluding the binary code that is compiled into a special test program. The old routines could be dedicated to that program and not used in gnuplot anymore. > > Which reminds me... I did some small amount of such cleanup recently. > You might have a look and see how much of the special-casing of the > BINARY code is not necessary. > > What I really hope to see is gradual cleanup and consolidation of > the binary and ascii code, to the point that there are hardly any > special BINARY_DATA_FILE pieces remaining. At that point removing > the warning and the conditional coding would make sense. I believe the new code is active by default in the CVS version and people have been using it for a year or more. Once people are comfortable with the idea of discarding the old bits, it is easy cleanup. #ifdef BINARY_DATA_FILE <keep this portion> #else <all this code gets tossed along with the ifdef's> #endif Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-07-13 22:24:42
|
On Wednesday 13 July 2005 03:07 pm, Daniel J Sebald wrote: > >>After that, I'd propose making the BINARY_DATA_FILE permanent too. > > > > I am opposed to removing the EXPERIMENTAL warnings on that one. > > The binary data file code is still very messy, and having it set off > > by conditional flags is the only way anyone will ever be able to find > > pieces for cleanup. > > I believe the new code is active by default in the CVS version and > people have been using it for a year or more. Do you really have a handle on how much use it has seen? I think it is more fair to say that people have been using the non-binary data path of the new code. As to the actual binary data path, I've been finding bugs in it even though I don't actually use it for anything. I just trip over them while working on other code parts, or when I hit compiler warnings. > Once people are comfortable with the idea of discarding the old bits, it is easy cleanup. > > #ifdef BINARY_DATA_FILE > <keep this portion> > #else > <all this code gets tossed along with the ifdef's> > #endif But there is something strange about having that sort of code in the first place. If the BINARY_DATA_FILE code were properly integrated, that second code segment would be empty. The common functionality should be factored out and removed from the conditional brackets altogether. Ideally there would be no #else sections to remove. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
