Thread: [PATCH] Unit tests don't use the local user's .gnuplot file

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

I'm attaching a patch to add a "-q" option to gnuplot to suppress parsing of
.gnuplot and gnuplotrc files. This is done primarily so that unit tests test the
stock configuration

dima

On Saturday, 20 October 2012, Dima Kogan wrote:
> I'm attaching a patch to add a "-q" option to gnuplot to suppress parsing of
> .gnuplot and gnuplotrc files. 

I like the idea of providing a way to suppress reading ~/.gnuplot.

Minor quibble: Isn't "-q" usually short for "--quiet" and interpreted
as a request to suppress output rather than input?
Not that I have a better letter of the alphabet to suggest....

> This is done primarily so that unit tests test the stock configuration

Hmm. I usually want the opposite.
E.g. if I want to make sure that "set someoption obscure" doesn't
trigger memory leaks, I put it in ~/.gnuplot and then run the
unit tests under valgrind.
For simple doesn't-crash sanity checks after applying a patch,
I usually add any relevant options to ~/.gnuplot and run
"make check".

	Ethan

On 10/20/2012 12:20 PM, sfeam (Ethan Merritt) wrote:
> On Saturday, 20 October 2012, Dima Kogan wrote:
>> I'm attaching a patch to add a "-q" option to gnuplot to suppress parsing of
>> .gnuplot and gnuplotrc files.
>
> I like the idea of providing a way to suppress reading ~/.gnuplot.
>
> Minor quibble: Isn't "-q" usually short for "--quiet" and interpreted
> as a request to suppress output rather than input?

Yes, save "-q" for "--quiet".

> Not that I have a better letter of the alphabet to suggest....

Tossing out some ideas:

   -n, --nostartup
   -s, --skip
   -f, --factory

No great ones there.  Any others?

Dan

PS:  I just noticed on the help output that there is a comma missing for 
the "-p" entry:

Usage: gnuplot [OPTION]... [FILE]
for X11 options see 'help X11->command-line-options'
   -V, --version
   -h, --help
   -p  --persist
   -e  "command1; command2; ..."

>
>> This is done primarily so that unit tests test the stock configuration
>
> Hmm. I usually want the opposite.
> E.g. if I want to make sure that "set someoption obscure" doesn't
> trigger memory leaks, I put it in ~/.gnuplot and then run the
> unit tests under valgrind.
> For simple doesn't-crash sanity checks after applying a patch,
> I usually add any relevant options to ~/.gnuplot and run
> "make check".
>
> 	Ethan
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

-- 

Dan Sebald
email: daniel(DOT)sebald(AT)ieee(DOT)org
URL: http://www(DOT)dansebald(DOT)com

> On Sat, 20 Oct 2012 10:20:32 -0700
> "sfeam (Ethan Merritt)" <eam...@gm...> wrote:
>
> On Saturday, 20 October 2012, Dima Kogan wrote:
> > I'm attaching a patch to add a "-q" option to gnuplot to suppress parsing of
> > .gnuplot and gnuplotrc files. 
> 
> I like the idea of providing a way to suppress reading ~/.gnuplot.
> 
> Minor quibble: Isn't "-q" usually short for "--quiet" and interpreted
> as a request to suppress output rather than input?
> Not that I have a better letter of the alphabet to suggest....
> 

The options I chose (-q, --no-init-file) are what emacs uses. If some other
program uses other letters, I'd be ok with those as well. I do feel we should
match SOME precedent, instead of making up our own.

> > This is done primarily so that unit tests test the stock configuration
> 
> Hmm. I usually want the opposite.
> E.g. if I want to make sure that "set someoption obscure" doesn't
> trigger memory leaks, I put it in ~/.gnuplot and then run the
> unit tests under valgrind.
> For simple doesn't-crash sanity checks after applying a patch,
> I usually add any relevant options to ~/.gnuplot and run
> "make check".

OK. Sounds like there are two different use cases. One for tests during
development (use case you described) and another for deployment, i.e. when a
distribution package maintainer is running the unit tests as part of the
packaging process. For the latter, it makes sense to run without user-defined
.gnuplot.

dima

On 20.10.2012 19:20, sfeam (Ethan Merritt) wrote:

> I like the idea of providing a way to suppress reading ~/.gnuplot.

Well, one could always just brush the file under the carpet, e.g.:

	env HOME=/some/where/else gnuplot

Look, Ma --- no need for a special option!

>> This is done primarily so that unit tests test the stock configuration

> For simple doesn't-crash sanity checks after applying a patch,
> I usually add any relevant options to ~/.gnuplot and run
> "make check".

I'm afraid that achieves rather a lot less than it's meant to.  Settings 
from ~/.gnuplot don't survive the first "reset" (at the end of simple.dem).

On Saturday, 20 October 2012, Hans-Bernhard Bröker wrote:
> On 20.10.2012 19:20, sfeam (Ethan Merritt) wrote:
> 
> > I like the idea of providing a way to suppress reading ~/.gnuplot.
> 
> Well, one could always just brush the file under the carpet, e.g.:
> 
> 	env HOME=/some/where/else gnuplot
> 
> Look, Ma --- no need for a special option!

That's true for the case of running "make check" or 
gnuplot 'all.dem'.  It's not necessarily true for running one's own
scripts since they may explicitly load files relative to $HOME.

> >> This is done primarily so that unit tests test the stock configuration

> > For simple doesn't-crash sanity checks after applying a patch,
> > I usually add any relevant options to ~/.gnuplot and run
> > "make check".
> 
> I'm afraid that achieves rather a lot less than it's meant to.  Settings 
> from ~/.gnuplot don't survive the first "reset" (at the end of simple.dem).

Some do, some don't.  But I take your point.

>> For simple doesn't-crash sanity checks after applying a patch,
>> I usually add any relevant options to ~/.gnuplot and run
>> "make check".
>
> I'm afraid that achieves rather a lot less than it's meant to.  Settings
> from ~/.gnuplot don't survive the first "reset" (at the end of simple.dem).

Unless there are "set term" options (it's easier to put them there instead 
of setting environmental GNUTERM).

---
PM

Thread: [PATCH] Unit tests don't use the local user's .gnuplot file

A portable, multi-platform, command-line driven graphing utility

gnuplot-beta