gnuplot-beta — Developers and beta testers of new gnuplot code

Re: Plot size in postscript/epslatex/ps(la)tex terminals

[Hans-Bernhard B. <br...@ph...>]

On Wed, 20 Oct 2004, Harald Harders wrote:

> On Tue, 19 Oct 2004, Ethan Merritt wrote:
> 
> > My expectation for *.eps files is that they will by default be small enough
> > to use as an inset figure within an normal page.  So I would not like this
> > to change.
> 
> Ah, it seems I have not been clear enough. I do not want to change the
> size of the postscript terminal (neither in ps nor in eps mode). At the
> moment, the epslatex and ps(la)tex terminals use different sizes than the
> eps mode of the postscript terminal. 

Are you sure of that?  What are the sizes, actually?  I seem to remember 
them to be 5x3 inches for both pslatex and 'post eps'; not sure about 
epslatex though.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: [RFC] Distro script for Mac OS X

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:

>On Thursday 21 October 2004 10:08 am, Per Persson wrote:
>  
>
>>Nobody is questioning your ability to type ./configure;make but some 
>>users prefer a double-clickable standard installer. 
>>In case I choose not to devote time to this project anymore, 
>>at least there would be a way to create an installer for Mac OS X
>>from a point release by running a script.
>>    
>>
>
>How stable is this standard installer?
>

This is what I was going to ask.  My faith in GUI installers isn't 
strong.  But I hear plenty of good things about OS X, so...

Dan

Re: Changes to stable branch?

[Daniel J S. <dan...@ie...>]

Per Persson wrote:

> Maybe I missed something, but I thought that the reason for branching 
> the sources was that there would be a bugfix release of gnuplot 4.0 at 
> some point in the future.
> My question was if changing the default terminal was something that 
> you'd like to see in a bugfix release. 


I haven't been following, sorry.  How does this default work?  It seems 
to me that a "default terminal" is something that the user should be 
able to configure without having to recompile anything.  I know there is 
some reluctance to add default mechanisms to gnuplot.  Is there some way 
already of automatically loading a file at startup?  For example, an 
environment variable

GNUPLOTLOADFILE = "/myhomedirectory/.gnuplotstartup"

or some such thing.  (And then add command line documentation under 
"help load" or "help defaults" about building a startup load file.)

Dan

Re: [RFC] Distro script for Mac OS X

[Ethan M. <merritt@u.washington.edu>]

On Thursday 21 October 2004 10:08 am, Per Persson wrote:
> 
> Nobody is questioning your ability to type ./configure;make but some 
> users prefer a double-clickable standard installer. 
> In case I choose not to devote time to this project anymore, 
> at least there would be a way to create an installer for Mac OS X
> from a point release by running a script.

How stable is this standard installer?

If no one maintains the OSX-specific files in your new directory,
will we risk losing the benefit of your work because the installer
files themselves no longer function under Tiger or its successor?

I'm not objecting to including it, but I'd like a better feel of
how much benefit it is to future work.

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

Re: [RFC] Distro script for Mac OS X

[Per P. <per...@ma...>]

On Oct 21, 2004, at 18:08, Ethan Merritt wrote:

> On Thursday 21 October 2004 05:00 am, Per Persson wrote:
>> Hi,
>> I've cleaned up my distro script for Mac OS X and would like to add it
>> and it's supporting files to CVS.
>>
>> I suppose the top dir rather than src/ is the appropriate location for
>> a directory with the files?
>> Any objections to naming that dir "MacOSXDistro"?
>
> I'm not objecting, at least not yet, but I'm curious exactly what files
> these are.  I managed to install gnuplot on OSX directly from the 
> existing
> tree, and I am a total novice user to OSX.  What is needed beyond
> what is there already?

I'm talking about a script and supporting files to create the binary 
installer
and documentation in PDF that people right now are downloading from SF.

Nobody is questioning your ability to type ./configure;make but some 
users prefer a
double-clickable standard installer. In case I choose not to devote 
time to this
project anymore, at least there would be a way to create an installer 
for Mac OS X
from a point release by running a script.

This was previously discussed:
On Oct 2, 2004, at 13:15, Hans-Bernhard Broeker wrote:

>
>> In the long term, should I add the script (that creates installers) 
>> and
>> a few (3 at the moment) supporting files to gnuplot or should I keep 
>> it
>> separate?
>
> I think they should go into gnuplot.  We already lost at least one
> complete Macintosh port because its source never was integrated with
> the mainline source.  No good reason to let that happen again.

Well, It might happen again.

>> It relies on a GPL'd utility to pack stuff up. AINAL, but that should
>> not AFAICT cause any license violations. Comments?
>
> The existing build chain uses many GPL utitilities (gmake, autoconf, 
> etc).

This was in response to a question raise by HBB in a previous mail.


/Per

Re: Changes to stable branch?

[Per P. <per...@ma...>]

On Oct 21, 2004, at 18:03, Ethan Merritt wrote:

> On Thursday 21 October 2004 03:18 am, Per Persson wrote:
>> Hi,
>> I'm considering adding code to make aqua the default terminal to the
>> stable branch, as in CVS HEAD, but I'm not sure if that qualifies as a
>> *neccessary* change.
>
> This makes zero sense to me.
> As I recall you are telling people to download the development
> version of aquaterm, so why balk at telling them to download the
> development version of gnuplot to go with it?
> The one is no harder than the other.

Maybe I missed something, but I thought that the reason for branching 
the sources was that there would be a bugfix release of gnuplot 4.0 at 
some point in the future.
My question was if changing the default terminal was something that 
you'd like to see in a bugfix release.

I don't mind telling people to go with 4.1, in fact I'd encourage it.

/Per

Re: [RFC] Distro script for Mac OS X

[Ethan M. <merritt@u.washington.edu>]

On Thursday 21 October 2004 05:00 am, Per Persson wrote:
> Hi,
> I've cleaned up my distro script for Mac OS X and would like to add it 
> and it's supporting files to CVS.
> 
> I suppose the top dir rather than src/ is the appropriate location for 
> a directory with the files?
> Any objections to naming that dir "MacOSXDistro"?

I'm not objecting, at least not yet, but I'm curious exactly what files
these are.  I managed to install gnuplot on OSX directly from the existing
tree, and I am a total novice user to OSX.  What is needed beyond
what is there already?

> It relies on a GPL'd utility to pack stuff up. AINAL, but that should 
> not AFAICT cause any license violations. Comments?

The existing build chain uses many GPL utitilities (gmake, autoconf, etc).
 
-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Changes to stable branch?

[Ethan M. <merritt@u.washington.edu>]

On Thursday 21 October 2004 03:18 am, Per Persson wrote:
> Hi,
> I'm considering adding code to make aqua the default terminal to the 
> stable branch, as in CVS HEAD, but I'm not sure if that qualifies as a 
> *neccessary* change.

This makes zero sense to me.
As I recall you are telling people to download the development
version of aquaterm, so why balk at telling them to download the 
development version of gnuplot to go with it?
The one is no harder than the other.

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

[RFC] Distro script for Mac OS X

[Per P. <per...@ma...>]

Hi,
I've cleaned up my distro script for Mac OS X and would like to add it 
and it's supporting files to CVS.

I suppose the top dir rather than src/ is the appropriate location for 
a directory with the files?
Any objections to naming that dir "MacOSXDistro"?

It relies on a GPL'd utility to pack stuff up. AINAL, but that should 
not AFAICT cause any license violations. Comments?

(I'm changing jobs next week so I'd like to get this out of the way 
before then.)

/Per

Changes to stable branch?

[Per P. <per...@ma...>]

Hi,
I'm considering adding code to make aqua the default terminal to the 
stable branch, as in CVS HEAD, but I'm not sure if that qualifies as a 
*neccessary* change.

Opinions?

/Per

Qt Wrapper for gnuplot

[Ian R. G. <ge...@kd...>]

Greetings,
I have been working on a KDE interface to Octave, when I found that there
was no nice KDE wrapper around gnuplot.  So I started one.

I am mostly looking for people who are interested in helping me that are
familiar with gnuplot.  I only really know how to do pretty simple things
with it, but I did most of the dirty work already, so anyone with minor
C++ knowledge, and a good gnuplot background would work.

The following C++ code generates the graphic at
http://www.geiseri.com/kdevelop/gnuplot.png

	KGNUPlotWidget *wid =3D new KGNUPlotWidget();
	LineStyle line(2);
	line.setLineType( 4 );
	line.setLineWidth( 1 );
	line.setPointType( 6 );
	line.setPointSize( 3 );

	LineStyle border( 3 );
	border.setLineType( 9 );
	border.setLineWidth( 2 );

	FillStyle fill;
	fill.setType( FillStyle::pattern );
	fill.setFillPattern( 2 );
	fill.setBorderStyle( &border );

	FunctionPlot *plot =3D new FunctionPlot( "sin(x)" );
	plot->setTitle( "Test Plot of sin(x)" );
	plot->setStartRange( -1 );
	plot->setEndRange( 2 );
	plot->setPlotStyle( PlotBase::linespoints );
	plot->setLineStyle( &line );

	wid->addLineStyle( &border );
	wid->addLineStyle( &line );
	wid->addFillStyle( &fill );

	wid->show();
	wid->resize(400,300);
	wid->setXLabel("Test X Label");
	wid->setYLabel("Test Y Label");
	wid->setFormats(KGNUPlotWidget::X, "%g");
	wid->setFormats(KGNUPlotWidget::Y, "%.2f");
	wid->plot(plot);

Currently line styles, arrows, and arrow styles are supported.  Fill is
sort of supported, and plot for data or functions will work with most
simple cases.  I think the big issues that remain are the ones I am not
aware of ;)

Currently there is a small dependency on KDE, but I have plans to remove
it, and the remainder works on Win32 or Unix.

So who wants to play?  I'm not on the list so please CC me.

-ian reinhart geiser
--=20
KDE - Unix is ready for the desktop
http://www.kde.org

Re: Plot size in postscript/epslatex/ps(la)tex terminals

[Daniel J S. <dan...@ie...>]

Harald Harders wrote:

>On Tue, 19 Oct 2004, Ethan Merritt wrote:
>
>  
>
>>My expectation for *.eps files is that they will by default be small enough
>>to use as an inset figure within an normal page.  So I would not like this
>>to change.
>>    
>>
>
>Ah, it seems I have not been clear enough. I do not want to change the
>size of the postscript terminal (neither in ps nor in eps mode). At the
>moment, the epslatex and ps(la)tex terminals use different sizes than the
>eps mode of the postscript terminal. The question is whether to use the
>eps size also for epslatex and ps(la)tex plots. Doing so would increase
>consistency, not doing so would preserve compatibility to old versions.
>Postscript and eps plots will stay unchanged.
>
>What do you think?
>

My guess is that it would be fine to do that.  I think most commands for 
importing PS-related graphics into LaTeX allow scaling, i.e, one can 
specify something like the figure width being 0.5\textwidth, etc.  So my 
guess is that few people use the "natural" size of the figure.

There are some obvious differences between EPS and combined PS/LaTeX. 
 The latter is probably a bit trickier in getting the font to scale 
appropriately with the EPS portions, but for the most part it matches 
pretty well.

Dan

Re: Plot size in postscript/epslatex/ps(la)tex terminals

[Harald H. <h.h...@tu...>]

On Tue, 19 Oct 2004, Ethan Merritt wrote:

> My expectation for *.eps files is that they will by default be small enough
> to use as an inset figure within an normal page.  So I would not like this
> to change.

Ah, it seems I have not been clear enough. I do not want to change the
size of the postscript terminal (neither in ps nor in eps mode). At the
moment, the epslatex and ps(la)tex terminals use different sizes than the
eps mode of the postscript terminal. The question is whether to use the
eps size also for epslatex and ps(la)tex plots. Doing so would increase
consistency, not doing so would preserve compatibility to old versions.
Postscript and eps plots will stay unchanged.

What do you think?



> On Monday 18 October 2004 12:21 pm, Harald Harders wrote:
> > When analizing my (e)ps(la)tex terminal patch, Theo Hopman noticed that
> > the patch changes the plot size of the epslatex terminal towards the same
> > size as the pure postscript terminal. My question is now whether all
> > postscript related terminals should have the same plot size or if they
> > should preserve their old size.
> >
> > The same plot size is more consistent and makes it easier to change
> > between the different versions while different sizes preserve
> > compatibility to old gnuplot versions.
> >
> > What do you think is better?
> >
> > Harald
> >
>
> --
> Ethan A Merritt       merritt@u.washington.edu
> Biomolecular Structure Center
> Mailstop 357742
> University of Washington, Seattle, WA 98195
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>
>

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: Plot size in postscript/epslatex/ps(la)tex terminals

[Ethan M. <merritt@u.washington.edu>]

My expectation for *.eps files is that they will by default be small enough
to use as an inset figure within an normal page.  So I would not like this
to change.


On Monday 18 October 2004 12:21 pm, Harald Harders wrote:
> When analizing my (e)ps(la)tex terminal patch, Theo Hopman noticed that
> the patch changes the plot size of the epslatex terminal towards the same
> size as the pure postscript terminal. My question is now whether all
> postscript related terminals should have the same plot size or if they
> should preserve their old size.
> 
> The same plot size is more consistent and makes it easier to change
> between the different versions while different sizes preserve
> compatibility to old gnuplot versions.
> 
> What do you think is better?
> 
> Harald
> 

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

Re: "set label" with "linestyle"

[Ethan M. <merritt@u.washington.edu>]

On Tuesday 19 October 2004 10:34 am, Juergen Wieferink wrote:
> 
> is there any reason that 'set label "foo" point ls 5' does not work?

It breaks the duplicate specification checking logic in the parser
(see below),  but that isn't a very strong reason.  
I'll make the change.

Incorrect error-checking:

 set style line 1 pt 4 ps 3 lt 6
 splot 'foo' with labels left point pt 3 ls 1 
	# no error message, but ls is ignored
 splot 'foo' with labels left point ls 1
	# works as expected

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

"set label" with "linestyle"

[Juergen W. <wie...@fr...>]

Hi,

is there any reason that 'set label "foo" point ls 5' does not work?
OK, to set the linestyle for a point doesn't /sound/ very useful,
but the way gnuplot works, it would be, I think.  [I had half an
hour of work today to work around this in my scripts.  I would have
changed the code instead, if I had known how easy it is.]

If it would be an effort to allow it, but it seems a simple


             if (almost_equals(c_token, "po$int")) {
                 int stored_token = ++c_token;
             struct lp_style_type tmp_lp;
 
-            lp_parse(&tmp_lp, 0, 1, -2, -2);
+            lp_parse(&tmp_lp, 1, 1, -2, -2);
             if (stored_token != c_token) {
                 loc_lp = tmp_lp;
                 loc_lp.pointflag = 1;


in set.c:4402 (parse_label_options) would suffice, wouldn't it?


Greetings,
Juergen

one question about gnuplot

[Luca B. <luc...@st...>]

Hi, =20
=20
  my name is Luca Bellarosa and I am a PhD student.=20
  I often use gnuplot for my plottings and I found the new version 4.0 re=
ally =20
  nice. I have only one problem: if I set the xtics with font "arial,36" =
=20
  ('cause I have to do huge images) the numbers (not the xlabel) that by =
=20
  default are on the x axis overlay the axis itself.=20
  Is there any way, any keyword, any command to move these numbers down? =
=20
  I checked carefully the FAQ questions but, as long as I could see, ther=
e=20
  is no trace about this specific problem.=20
  Thank you in advance, =20
=20
Luca=20
=20

Enhanced text for aquaterm

[Per P. <per...@ma...>]

Hi,
Just FYI I have added enhanced text support (sans overprint) for 
aquaterm, also added doc and ChangeLog entry.

In case anyone would like to check it out, you need a recent CVS 
version of AquaTerm. It _will_ work with the current release, but some 
features are missing.

/Per

Plot size in postscript/epslatex/ps(la)tex terminals

[Harald H. <h.h...@tu...>]

When analizing my (e)ps(la)tex terminal patch, Theo Hopman noticed that
the patch changes the plot size of the epslatex terminal towards the same
size as the pure postscript terminal. My question is now whether all
postscript related terminals should have the same plot size or if they
should preserve their old size.

The same plot size is more consistent and makes it easier to change
between the different versions while different sizes preserve
compatibility to old gnuplot versions.

What do you think is better?

Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

macros with parameters

[Petr M. <mi...@ph...>]

Currently, the following code with a macro for generating labels works:

F(x)=sprintf("set label 1000+%i 'result %i' at %g,%g", x,x,x,x)
	A=F(1)
	@A
	A=F(-1)
	@A
	plot x

Would it be possible to execute C-like macros:
	@(F(1))
? I would like this.

---
PM

Re: bug in splot and datafile with 4 columns

[Ethan A M. <merritt@u.washington.edu>]

On Friday 15 October 2004 06:12 am, Petr Mikulik wrote:
> Having a datafile with at least 4 columns, for example:
> then
> 	splot 'a.dat'
> reports
> gnuplot> splot 'a3d.dat'
>                ^
>          Wrong number of columns in input data - line 1

Rather than gripe again about how gnuplot assumes too much 
from the number of columns present, I have now re-organized 
the code in plot3d.c (get_3ddata) so that it is less sensitive to
plot style and number of columns.

I suppose the 2D code should be similarly cleaned up, but
that will be more work because there are more 2D plot styles.

-- 
Ethan A Merritt
Department of Biochemistry & Biomolecular Structure Center
University of Washington, Seattle

Re: Request for comments: string variable patchset 2

[Juergen W. <wie...@fr...>]

Petr Mikulik wrote:
> I though that instead of using
> 	a=`runme`
> there would be an alternative with macro expansion:
> 	a=command('runme')

Yes, yes, I'd love that.  The variable "a" contains a string
afterwards, doesn't it?


Currently, I'm trying to extract some information from comments in
datafiles.  The crucial thing is that information is to be passes
from gnuplot to the script and vice versa.  I need something like

  gawkcall = sprintf("gawk -f getname %i %s", this_index, filename)
  name = execute(gawkcall)


For numerical values, you can already do this with

  getvalcall = sprintf("getval %i %s", this_index, filename)
  value = `@getvalcall`

but something like

  gawkcall = sprintf("gawk -f getval %i %s", this_index, filename)
  value = atof(execute(gawkcall))

or

  value = 0 + execute(gawkcall)

is cleaner, I think.


Juergen

Re: Request for comments: string variable patchset 2

[Petr M. <mi...@ph...>]

> back-tics.  When called to expand the argument to a particular function, in
> this case system() or execute(), then it *would* expand in backtics.

I though that instead of using
	a=`runme`
there would be an alternative with macro expansion:
	a=command('runme')



> > >>   gnuplot> print sprintf("%i", 5.)
> > >>   0
> > >This example doesn't work in C either.
> >
> > But it works in Octave and awk; I use it there to print an integer part of
> > the value. I would rather prefer an inteligent version that returns in the
> > above example 5.
>
> If Octave does that, I'd say it's a bug, or at least an unreliable behaviour.
> Auto-conversion of an ambiguous variable type is one thing, but
> refusing to do what the user asks for is quite another.

I think that all numbers in Octave are double, so it's not unexpected.
Awk knows how to convert numbers and strings, according to user
"expectation".

The result of the above being "5" is more expected than "0".

---
PM

Re: Request for comments: string variable patchset 2

[Ethan M. <merritt@u.washington.edu>]

On Friday 15 October 2004 12:01 am, Petr Mikulik wrote:
> I would propose to ignore macro expansion in `blabla1` and
> !blabla2
> 
> but allow them in
> system('blabla2')
> and in
> value = execute('blabla1');
> 
> Where the execute() is a new command. The user could use what he wants.

I think that would be possible.
The string expansion routine would be called in two places.
When called to process the entire command line it would not expand inside
back-tics.  When called to expand the argument to a particular function, in
this case system() or execute(), then it *would* expand in backtics.

Anyone else have an opinion on that point?

Another alternative is to provide a run-time option
	set macro$expansion {none|all|nobacktics}


> >>   gnuplot> print sprintf("%i", 5.)
> >>   0
> >This example doesn't work in C either.
> 
> But it works in Octave and awk; I use it there to print an integer part of
> the value. I would rather prefer an inteligent version that returns in the
> above example 5.

If Octave does that, I'd say it's a bug, or at least an unreliable behaviour.
Auto-conversion of an ambiguous variable type is one thing, but
refusing to do what the user asks for is quite another.
You have explicitly given a floating point number, and explicitly
given an integer format.  That is user error.  Is it "intelligent"
for a program to over-ride what the user has explicitly asked for?

> > FOO = floor(FOO)
> > "see man page for sprintf"
> 
> Well, "man floor" says that result of floor() and ceil() is also a double
> value, so it does not help. Just in gnuplot it returns an integer.

I was not justifying gnuplot's use of floor; I was just responding
to the request for a way to insure that a gnuplot variable was an
integer.  That command happens to work already.
I have no objection to adding a built-in function  int(x).

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

bug in splot and datafile with 4 columns

[Petr M. <mi...@ph...>]

I have found a bug:

Having a datafile with at least 4 columns, for example:

0 0 0 5
0 1 1 5
0 2 2 5

1 0 1 5
1 1 2 5
1 2 4 5

then
	splot 'a.dat'

reports

gnuplot> splot 'a3d.dat'
               ^
         Wrong number of columns in input data - line 1

You have to say explicitly:
	splot 'a3d.dat' u 1:2:3


Can somebody find out wherefrom this bugs comes?

---
PM