Menu
▾
▴
gnuplot-beta
|
From: Hans-Bernhard B. <br...@ph...> - 2004-05-08 00:07:30
|
On Fri, 7 May 2004, Daniel J Sebald wrote: > I notice that the first demo in 'all.dem' is 'simple.dem'. There is no > "reset" at the start of 'simple.dem', Actually, most demos have the 'reset' at their end, not their start. And that's good, because it lets you try some effects by running them with some settings pre-changed. Arguable, the individual demos themselves shouldn't have a 'reset' at all, but leave it to 'all.dem' to reset betweeen any two of them. > Is this an issue? Should demos all have "reset" at the start? No. > (I think Ethan brought this up once before.) I suppose that may change > any setup the user has. The demos change the setup anyway, so there's really no point being subtle about it. Until we get around to implementing a 'push / pop' or other method of keeping an internal copy of the entire collection of settings, that is. -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-08-03 19:18:11
|
On Thursday 03 August 2006 12:10 pm, Daniel J Sebald wrote: > > > Better yet would be to figure out a way to make all.dem itself > > recognize and skip unsupported demos, but to my recollection past > > discussions never came up with a reasonable way to do that. > > I think a function that allows executing a command without falling > back to the command line would be nice. Say "attempt" Maybe, but it wouldn't actually help in the case of all.dem. Falling back to the command line would leave you in the middle of a sequence of now-useless commands. What we need for the demo case is some way of skipping the demo altogether. Hmm. I've got an idea that wouldn't have been possible before. Now that we have all these GPVAL_*** variables, maybe we should load one with the conditional compilation flags as reported by "show version long". gnuplot> print GPVAL_COMPILE_OPTIONS -READLINE +LIBREADLINE +HISTORY +BACKWARDS_COMPATIBILITY +BINARY_DATA +GD_PNG +GD_JPEG +GD_TTF +GD_GIF +ANIMATION -NOCWDRC +X11 +X11_POLYGON +MULTIBYTE +USE_MOUSE +HIDDEN3D_QUADTREE +DATASTRINGS +HISTOGRAMS +OBJECTS +STRINGVARS +MACROS +IMAGE Then we could do if (strstrt(GPVAL_COMPILE_OPTIONS,"+IMAGE")) load "image.dem" Anyone see anything wrong with this approach? -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
|
From: Daniel J S. <dan...@ie...> - 2006-08-03 19:35:50
|
Ethan Merritt wrote:
> On Thursday 03 August 2006 12:10 pm, Daniel J Sebald wrote:
>
>>>Better yet would be to figure out a way to make all.dem itself
>>>recognize and skip unsupported demos, but to my recollection past
>>>discussions never came up with a reasonable way to do that.
>>
>>I think a function that allows executing a command without falling
>>back to the command line would be nice. Say "attempt"
>
>
> Maybe, but it wouldn't actually help in the case of all.dem.
> Falling back to the command line would leave you in the middle of
> a sequence of now-useless commands. What we need for the demo
> case is some way of skipping the demo altogether.
Well, that sort of is the limitation. I mean,
if attempt("plot 'foo.dat' with foos") load 'foo.dem' : print "no foo"
would be sort of like putting the first line of your demo inside "all.dem", which is a bit silly. But if there were some way of calling a command that would verify the existence of the support, i.e., "set style"... eh, still nothing elegant.
>
> Hmm. I've got an idea that wouldn't have been possible before.
>
> Now that we have all these GPVAL_*** variables, maybe
> we should load one with the conditional compilation flags as
> reported by "show version long".
>
> gnuplot> print GPVAL_COMPILE_OPTIONS
> -READLINE +LIBREADLINE +HISTORY +BACKWARDS_COMPATIBILITY
> +BINARY_DATA +GD_PNG +GD_JPEG +GD_TTF +GD_GIF +ANIMATION -NOCWDRC
> +X11 +X11_POLYGON +MULTIBYTE +USE_MOUSE +HIDDEN3D_QUADTREE
> +DATASTRINGS +HISTOGRAMS +OBJECTS +STRINGVARS +MACROS +IMAGE
>
>
> Then we could do
>
> if (strstrt(GPVAL_COMPILE_OPTIONS,"+IMAGE")) load "image.dem"
>
> Anyone see anything wrong with this approach?
Sounds alright to me. This would be a variable the user can't alter, right? I like it.
Would you want to specifically require the + and - settings? I'm thinking of "backward" and "forward" compatibility here. In later versions of gnuplot, some of these options may no longer be present because they are no longer options... So that means we'd want to condition on the "negative presence" of an option? I.e.
if (!strstrt(GPVAL_COMPILE_OPTIONS,"-IMAGE")) load "image.dem"
I think (?)
Dan
|
|
From: Daniel J S. <dan...@ie...> - 2006-08-03 19:46:52
|
> So that means we'd want to condition on the "negative presence" of an option? I.e. > > if (!strstrt(GPVAL_COMPILE_OPTIONS,"-IMAGE")) load "image.dem" > > I think (?) No, that would mean not "way backward" compatible because "image.dem" would still be run on older versions of gnuplot... which maybe isn't a concern. Whatever; so long as the CVS version of the demos works with the same CVS version of gnuplot. Dan |
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-08-04 04:45:58
|
On Thursday 03 August 2006 12:56 pm, Daniel J Sebald wrote:
> > if (!strstrt(GPVAL_COMPILE_OPTIONS,"-IMAGE")) load "image.dem"
> No, that would mean not "way backward" compatible because "image.dem"
> would still be run on older versions of gnuplot...
Not a problem. Here's a variant that checks for version compatibility:
if (GPVAL_VERSION == 4.1 && strstrt(GPVAL_COMPILE_OPTIONS,"+IMAGE")) \
load 'image.dem'
Of course, this requires that string variables are configure in
(now the default). But it you want it even more foolproof then use
if (defined(GPVAL_COMPILE_OPTIONS)) \
if (GPVAL_VERSION == 4.1 && strstrt(GPVAL_COMPILE_OPTIONS,"+IMAGE")) \
load 'image.dem'
That is safe even in the absence of string variables (although
it doesn't actually run the demo).
I've put such on SourceForge. Please have a look.
It's pretty non-intrusive (all it does is add a new GPVAL_*** variable),
and it will allow us to protect all the configuration-dependent demos
in all.dem that are run by "make check".
--
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742
|
|
From: Petr M. <mi...@ph...> - 2006-08-04 07:22:03
|
>>> if (!strstrt(GPVAL_COMPILE_OPTIONS,"-IMAGE")) load "image.dem" >> No, that would mean not "way backward" compatible because "image.dem" >> would still be run on older versions of gnuplot... > > Not a problem. Here's a variant that checks for version compatibility: > > if (GPVAL_VERSION == 4.1 && strstrt(GPVAL_COMPILE_OPTIONS,"+IMAGE")) \ > load 'image.dem' > > Of course, this requires that string variables are configure in > (now the default). But it you want it even more foolproof then use > > if (defined(GPVAL_COMPILE_OPTIONS)) \ > if (GPVAL_VERSION == 4.1 && strstrt(GPVAL_COMPILE_OPTIONS,"+IMAGE")) \ > load 'image.dem' Unfortunately, this is not portable. I've just tried a windows version compiled with all of the "default" #defines in makefile&config.mgw, including IMAGE; but its "show version long" reports only: Compile options: +READLINE -LIBREADLINE +GD_PNG +GD_TTF -NOCWDRC +USE_MOUSE and thus it is not updated to options set from within config.h. Cannot the string for the "compiled options" be concanated according to #define's? --- PM |
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-08-04 15:06:44
|
On Friday 04 August 2006 12:21 am, Petr Mikulik wrote: > > Unfortunately, this is not portable. I've just tried a windows version > compiled with all of the "default" #defines in makefile&config.mgw, > including IMAGE; but its "show version long" reports only: > > Compile options: > +READLINE -LIBREADLINE +GD_PNG +GD_TTF -NOCWDRC +USE_MOUSE > > and thus it is not updated to options set from within config.h. > Cannot the string for the "compiled options" be concanated according to > #define's? I see no windows-specific code in show_version(), so I am at a loss to explain how this could go wrong. If a windows build does not correctly report its configuration, that's a bug all by itself and should be fixed. But yes, we would need to to solve that problem first. show.c: #include "alloc.h" alloc.h: #include "syscfg.h" syscfg.h: #include "config.h" How can this fail? (and how can the build succeed if it does?) -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Petr M. <mi...@ph...> - 2006-08-04 15:25:38
|
>> Unfortunately, this is not portable. I've just tried a windows version >> compiled with all of the "default" #defines in makefile&config.mgw, >> including IMAGE; but its "show version long" reports only: >> >> Compile options: >> +READLINE -LIBREADLINE +GD_PNG +GD_TTF -NOCWDRC +USE_MOUSE >> >> and thus it is not updated to options set from within config.h. >> Cannot the string for the "compiled options" be concanated according to >> #define's? > > I see no windows-specific code in show_version(), so I am at > a loss to explain how this could go wrong. I'm sorry, it was a false alarm. I was launching wgnuplot from July ... but 2004 on this computer ... so all is fine, and I vote for the proposed new GPVAL_. --- PM |
|
From: Daniel J S. <dan...@ie...> - 2006-08-04 16:34:20
|
Petr Mikulik wrote: >>>Unfortunately, this is not portable. I've just tried a windows version >>>compiled with all of the "default" #defines in makefile&config.mgw, >>>including IMAGE; but its "show version long" reports only: >>> >>>Compile options: >>>+READLINE -LIBREADLINE +GD_PNG +GD_TTF -NOCWDRC +USE_MOUSE >>> >>>and thus it is not updated to options set from within config.h. >>>Cannot the string for the "compiled options" be concanated according to >>>#define's? >> >>I see no windows-specific code in show_version(), so I am at >>a loss to explain how this could go wrong. > > > I'm sorry, it was a false alarm. I was launching wgnuplot from July ... but > 2004 on this computer ... so all is fine, and I vote for the proposed new > GPVAL_. So it did what it was supposed to do and you misinterpretted. That's the developers trap: always doubting if thing are programmed correctly. :-) It seemed to work for me, very useful, good idea Ethan. And the sure-fired conditional script in all.dem is the way I'd go. (Remember, part of scripts is to be tutorial and from the users standpoint that is helpful to see.) I will keep thinking about future compatibility issues, but I think it should be fine... Couple things. First, could this "gnuplot-defined variables" be made a permanent thing? I think I've been asked if gnuplot somehow could return its version. (The trick I use now is to lauch gnuplot, get that startup info and sort through that looking for the version. Or is there already a better way?)... Second, is what you've done, Ethan, easy enough so that a user might be able to program their own special version of gnuplot and add a custom variable to identify their version? Or don't we want to encourage that sort of thing?) Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-08-04 16:51:10
|
On Friday 04 August 2006 09:43 am, Daniel J Sebald wrote: > First, could this > "gnuplot-defined variables" be made a permanent thing? I do not understand the question. > I think I've been asked if gnuplot somehow could return its version. gnuplot --version gnuplot -V > Second, is what you've done, Ethan, easy enough so that a user might > be able to program their own special version of gnuplot and add a > custom variable to identify their version? Or don't we want to > encourage that sort of thing?) My recommendation would be that any locally-modified version should change the contents of the PATCHLEVEL file. Everything else will be handled automatically. Perhaps this should be documented somewhere (INSTALL? README?) -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
|
From: Daniel J S. <dan...@ie...> - 2006-08-04 17:02:57
|
Ethan Merritt wrote: > On Friday 04 August 2006 09:43 am, Daniel J Sebald wrote: > >>First, could this >>"gnuplot-defined variables" be made a permanent thing? > > > I do not understand the question. You said: "Of course, this requires that string variables are configure in (now the default)." But string vars are something different. The GPVAL_VERSION is always present then and can't be configured out of gnuplot some how? (I haven't followed the GPVAL_ threads.) >>I think I've been asked if gnuplot somehow could return its version. > > > gnuplot --version > gnuplot -V That helps a little bit in the sense that it weeds out a lot. But it still isn't at the command line... eh, let user demand drive this. If more people ask, then I'll raise the issue again. >>Second, is what you've done, Ethan, easy enough so that a user might >>be able to program their own special version of gnuplot and add a >>custom variable to identify their version? Or don't we want to >>encourage that sort of thing?) > > > My recommendation would be that any locally-modified version should > change the contents of the PATCHLEVEL file. Everything else will > be handled automatically. OK. Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-08-04 17:17:17
|
On Friday 04 August 2006 10:12 am, Daniel J Sebald wrote: > Ethan Merritt wrote: > > On Friday 04 August 2006 09:43 am, Daniel J Sebald wrote: > >>First, could this > >>"gnuplot-defined variables" be made a permanent thing? > > > > I do not understand the question. > > You said: "Of course, this requires that string variables are > configure in (now the default)." But string vars are something > different. The GPVAL_VERSION is always present then and can't be > configured out of gnuplot some how? (I haven't followed the GPVAL_ > threads.) I still don't understand the question. GPVAL_VERSION is a floating point number, and is always defined. But GPVAL_COMPILE_OPTIONS is a string, so it can only be loaded into a variable if string support is configured. > >>I think I've been asked if gnuplot somehow could return its > >> version. > > > > gnuplot --version > > gnuplot -V > > That helps a little bit in the sense that it weeds out a lot. But it > still isn't at the command line... Er, then what do you mean by "command line"? -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
|
From: Daniel J S. <dan...@ie...> - 2006-08-04 17:43:44
|
Ethan Merritt wrote: > On Friday 04 August 2006 10:12 am, Daniel J Sebald wrote: > >>Ethan Merritt wrote: >> >>>On Friday 04 August 2006 09:43 am, Daniel J Sebald wrote: >>> >>>>First, could this >>>>"gnuplot-defined variables" be made a permanent thing? >>> >>>I do not understand the question. >> >>You said: "Of course, this requires that string variables are >>configure in (now the default)." But string vars are something >>different. The GPVAL_VERSION is always present then and can't be >>configured out of gnuplot some how? (I haven't followed the GPVAL_ >>threads.) > > > I still don't understand the question. > > GPVAL_VERSION is a floating point number, and is always defined. > > But GPVAL_COMPILE_OPTIONS is a string, so it can only > be loaded into a variable if string support is configured. RIght, I sort of figured that out when I thought twice about "string" qualifier. The GPVAL_VERSION is always present. So the user can do a print(GPVAL_VERSION) and get the value back. >>That helps a little bit in the sense that it weeds out a lot. But it >>still isn't at the command line... > > > Er, then what do you mean by "command line"? I guess I meant the "gnuplot prompt". Slightly different ways of getting the same thing. But both ways are available, so whichever method a programmer might prefer is currently available. Good. Dan |
|
From: <br...@ph...> - 2006-08-04 21:30:56
|
Ethan Merritt wrote: > My recommendation would be that any locally-modified version should > change the contents of the PATCHLEVEL file. Everything else will > be handled automatically. Perhaps this should be documented somewhere > (INSTALL? README?) It's actually sort-of required, by the Copyright statement. It says that any modified binary distributed to others has to report itself as a modified version, and give the contacts of the person who modified it. |
|
From: Daniel J S. <dan...@ie...> - 2004-05-08 05:53:17
|
I'm not sure if any changes have been made to CVS since 4.0 release, but the latest I've checked out still is labeled as: gnuplot 4.0 patchlevel 0 It might be wise to change the version to some beta number right away so that the only version that prints out 4.0 is the one tagged 4.0. Dan |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X