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

Re: grouping available terminals together

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

> Back to the topic of allowing color in LaTeX plots.  It seems perfectly
> reasonable to me.  Just as with the post, emf, pbm terminals there would
> be a choice of {monochrome|color} when you select the terminal.  If you
> don't want color in your TeX document, then don't select it.

Exactly. The options for the latex terminal can be "rotate" and "color". I=
=20
remember times I was using latex terminal and I had to put those \rotate=20
commands for the y-axis myself.

> I am inclined to agree with Timoth=C3=A9e and Mojca. We should either upd=
ate
> the latex driver to the extent possible or deprecate it altogether.

Nowaday, latex terminal is useful for simple drawings. It's easier than=20
learning diagram latex packages.

---
PM

Re: grouping available terminals together

[<tim...@en...>]

Ethan A Merritt wrote:
> On Sunday 11 February 2007 03:16, Timothée Lecomte wrote:
>   
>> But do we want gnuplot to stay at what was the least-common denominator 
>> 20 years ago ? How many people use gnuplot right now for pen plotters ?
>> And since we provide rgb colors, why not doing the same with other kind 
>> of "modern" features ?
>>     
>
> I have been working for some time now to add exactly this capability for
> RGB color, explicit fonts,  choice of symbols for plotting, and so on.
> And you know what?  In version 4.2 we are already about 90% of the way
> to exactly what you want.
>   
and that's very good to see. Congrats to you for that. I just don't 
understand why there seems to be some sort of opposition for the same 
thing with dash patterns...

Best regards,

Timothée

Re: "set scale" as opposed to "set size" or something else

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

> So if I may re-phrase your suggestion.  We should add a command
> 	set scale <multiplier>
> that is passed to each terminal.  Terminals capable of uniform scaling
> would apply this multiplier to relevant plot elements, including
> 	font size
> 	point size
> 	line width
> 	dash length

That would be cool for subfigures.

---
PM

Re:

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

> > It could be changed to:
> >  ... Please see "help dgrid3d".
> 
> That would be exactly contrary to what I was getting at.
> 
> That's why I recommend strongly to point to "help grid_data" instead of
> dgrid3d.

That help topic speaks about both functions and data, starting with 
isosamples ... that's very (IMHO) confusing for contouring a datafile.

On the other hand, "help dgrid3d" is clear from its 1st sentence. There it 
would be useful to add a link to "grid_data" either from this sentence, or 
from an added 2nd sentence.

---
PM

Re: grouping available terminals together

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

On Sunday 11 February 2007 03:16, Timoth=E9e Lecomte wrote:
>=20
> But do we want gnuplot to stay at what was the least-common denominator=20
> 20 years ago ? How many people use gnuplot right now for pen plotters ?
> And since we provide rgb colors, why not doing the same with other kind=20
> of "modern" features ?

I have been working for some time now to add exactly this capability for
RGB color, explicit fonts,  choice of symbols for plotting, and so on.
And you know what?  In version 4.2 we are already about 90% of the way
to exactly what you want.

In particular, if you have not already done so, please take time out to
investigate the new mechanism for replacing the fixed set of line "types"
with an arbitrary set of line "styles".  This allows you to choose any
sequence of colors, line widths, point types, etc, and have those used
in preference to the default set.  Furthermore, it is implemented in=20
such a way that old command scripts "just work", even thought they are
unaware of the new set of line properties being used. =20

The operative command is

	set style increment user

I must admit that I hate that syntax.  Suggestions for a more obvious
command are welcome.


Back to the topic of allowing color in LaTeX plots.  It seems perfectly
reasonable to me.  Just as with the post, emf, pbm terminals there would
be a choice of {monochrome|color} when you select the terminal.  If you
don't want color in your TeX document, then don't select it.

I am inclined to agree with Timoth=E9e and Mojca. We should either update
the latex driver to the extent possible or deprecate it altogether.

> Hans-Bernhard Br=F6ker wrote:
> > The moment "set term latex" produces dvi files with \special in them,
> > it becomes pointless to have it.

Could you elaborate, please?  Are you suggesting that only
PostScript-based specials (pstricks, metapost, [e]pslatex, pstex) have
any merit? Why would it be "pointless" to allow color in other LaTeX
output via color.sty?

Mind you, I myself do not see much point in using the current latex
terminal at all.  The curve-drawing is terrible, the list of features is
minimal, and I am unaware of any practical benefit that comes from=20
avoiding the more feature-complete epslatex pathway.  But I may be=20
ignorant of some major category of use.

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

"set scale" as opposed to "set size" or something else

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

On Sunday 11 February 2007 00:22, Daniel J Sebald wrote:
> set term png size 1280,960
>=20
> the result is a 1280 x 960 PNG image with the same resolution as the=20
> previous 640 x 480 PNG image.  That is, depending on one's viewpoint,=20
> it's as though every plot item has become 1/2 the size relative to=20
> the plot coordinate system.  =20
> I could increase resolution by making the pointsize twice=20
> as big, line thickness twice as big, etc.

I believe that this was the original intent of the "set size" command.
It later got co-opted to implement multiplot mode instead.
The original terminal entry point  term->scale() is still there, however.

It is interesting that Timoth=E9e recently submitted a patchset (#1616945)
to remove this terminal entry, and now you are arguing in effect that
we whould intead resurrect it for its original purpose. =20

So if I may re-phrase your suggestion.  We should add a command
	set scale <multiplier>
that is passed to each terminal.  Terminals capable of uniform scaling
would apply this multiplier to relevant plot elements, including
	font size
	point size
	line width
	dash length

This is not strictly necessary, as all of these can be set separately
for terminals that support them.  But it would add some degree of=20
convenience.

	Ethan


[nit-picking follows]

> Say there were a "resolution #" option that would internally scale line=20
thickness, pointsize, and fonts (have to have a mapping to medium, large,=20
giant... unfortunately the largest font doesn't have very high=20
resolution).

What is this "medium, large, giant" business? =20
Surely you are not still using the old 1999 PNG driver!
We've had support for scalable fonts for about 6 years now.
You can scale up to posterboard size if you want.

See for example the label "Kuen's Surface" in the transparent solids demo
   http://gnuplot.sourceforge.net/demo_4.3/transparent_solids.html
That is an intricate script font scaled up about 3x from the typical
font size used for PNG plots, and it scales beautifully.


=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: [gnuplot - Help] Error compiling CVS HEAD with VC6 on Windows

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

On Sunday 11 February 2007 03:06, Timoth=E9e Lecomte wrote:
> > Is there a gcc flag that will cause it to emit warnings for this,
> > without flooding the output with more useless warnings?
> >
> -pedantic will warn about that, among other things ;)

Yes. It was exactly the "among other things" that I wanted to avoid.

I've added -Wdeclaration-after-statement to the CFLAGS in my normal
test-build script, so this particular issue should be caught more
quickly in the future.


=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re:

[<HBB...@t-...>]

Petr Mikulik wrote:
> It could be changed to:
> 	... Please see "help dgrid3d".

That would be exactly contrary to what I was getting at.

dgrid3d is *not* automatically the right thing to use here.  Pointing to 
only it but nothing else would make matters worse than they are now. 
Before, the error message was precisely that: an error message.  It 
pointed out the error.  A message that points out the wrong solution 
would be worse than a message that leaves it for the user to find a 
solution.

The key problem is that a shockingly large number of users encounter 
this error and have no idea whatsoever what "gridded data" means, so 
they don't understand why contouring of non-gridded data might fail. 
The right thing to do is to point them to an explanation of "gridded data".

That's why I recommend strongly to point to "help grid_data" instead of 
dgrid3d.

Re: Windows pause behaviour

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

> > Modified files:
> > 	./: ChangeLog 
> > 	gnuplot/src/: command.c 
> > 
> > Log message:
> > 	On Windows, wait for Enter in console instead for a mouse click in a special
> > 	window if the graph window is not (yet) present.
> 
> Ahem --- are you aware that the console window itself wouldn't be 
> displayed at all, in a non-interactive session?  What good can a  "Press 
> Enter" prompt in an invisible window do us?

Good point! I've fixed this.

---
PM

Re:

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

> > I propose to change the message
> >  Notice: cannot contour non grid data!
> > into
> >  Notice: Cannot contour non grid data. Please use "set dgrid3d".
> > Any objections?
> 
> Yes.  "set dgrid3d" is far from being the single, obvious solution to the
> problem.  A good portion of people having this problem simply don't know about
> grid-structured data files.  For them dgrid3d would be the wrong thing to do.
> 
> If you want to put a recommendation, make it a reference to (a to-be written
> node of) the manual.

It could be changed to:
	... Please see "help dgrid3d".
however, the user will do so if he doesn't know about "set dgrid3d", so
I let the former message.

---
PM

Re: grouping available terminals together

[<tim...@en...>]

Hans-Bernhard Bröker wrote:
> Ethan A Merritt wrote:
>   
>> On Thursday 08 February 2007 23:53, Timothée Lecomte wrote:
>>     
>>> Maybe we should change the terminal API to:
>>> * rgb colors
>>> * dash patterns
>>>
>>> and the default linetypes would be handled by the core.
>>> On a screen terminal:
>>> -lt 1 would be red
>>> -lt 2 would be blue
>>> ...
>>> On a print-oriented terminal:
>>> -lt 1 would be red/solid
>>> -lt 2 would be blue/dash
>>>       
>> Isn't that exactly what we have now?
>>
>> I am speculating, since the decision must date back to 
>> the origins of gnuplot. 
>>     
>
> Absolutely.  In a nutshell, since no two terminals agree 100% on what 
> kinds of line they can draw, our founders decided on the sanest possible 
> approach: the least common denominator.  Which is that on any remotely 
> suitable output medium, there will be some way to draw at least a couple 
> different types of lines, and that's *all* that can be said about them.
And it was the right decision at that time.

But do we want gnuplot to stay at what was the least-common denominator 
20 years ago ? How many people use gnuplot right now for pen plotters ?
And since we provide rgb colors, why not doing the same with other kind 
of "modern" features ?

>  
>   We can't generally prescribe they must differ in colour, width, 
> pattern or whatever.  All we know is that the set of possible choice 
> will be countable, so count them is what we do.  Which brought us the 
> concept of a linetype number.
>   
Note that the concept of linetype number looks very useful to me to 
provide sensible default styles.

Timothée

Re: [gnuplot - Help] Error compiling CVS HEAD with VC6 on Windows

[<tim...@en...>]

Ethan A Merritt wrote:
> On Saturday 10 February 2007 09:51, Hans-Bernhard Bröker wrote:
>   
>> SourceForge.net wrote:
>>
>>     
>>> ..\\term\cgm.trm(475) : error C2143: Syntaxfehler : Fehlendes ';' vor 'type'
>>> ..\\term\cgm.trm(477) : error C2065: 'new_font_data' : nichtdeklarierter
>>> Bezeichner
>>>       
>> Guys, can we _please_ restrict ourselves to normal C for the time being?
>>
>> I.e. no C++ style variable declarations in the middle of code blocks.
>>     
>
> Hmm. Yes. Not sure how that happened.
>
> Is there a gcc flag that will cause it to emit warnings for this,
> without flooding the output with more useless warnings?
>
>
>   
-pedantic will warn about that, among other things ;)

Timothée

Re: symbol/color/line consistency in terminals

[<HBB...@t-...>]

Daniel J Sebald wrote:

> Not sure on that one.  I've turned on -warnspecials in xdvi and it gives 
> plenty of warnings like:

> But I don't seen any warnings for rotated text.  It could be that xdvi 
> simply hasn't gotten around to supporting rotated text.  Any idea?

The reason xdvi doesn't warn about this is because xdvi does have some 
support for PostScript specials, implemented by passing the work off to 
ghostscript or other tools (--> man xdvi).

Re: symbol/color/line consistency in terminals

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

Ethan A Merritt wrote:
> On Saturday 10 February 2007 11:28, Daniel J Sebald wrote:
> 
>>Hans-Bernhard Bröker wrote:
>>
>>>That's because GD, last I looked, didn't support linewidths on patterned 
>>>lines.  Which made it rather pointless to try and implement dashing for 
>>>the first three.
>>
>>I'm not real familiar with GD, but the header file has:
>>
>>gdImageSetStyle ();
>>gdImageSetThickness ();
> 
> 
> Take my word for it, the gd routines for dashed lines and for
> linewidth are useless for our purposes.

Some way of specifying a resolution for PNG-like terminals might be nice.  Am I overlooking something?

If I say

set term png size 1280,960
set output 'test.png'
text
set output

the result is a 1280 x 960 PNG image with the same resolution as the previous 640 x 480 PNG image.  That is, depending on one's viewpoint, it's as though every plot item has become 1/2 the size relative to the plot coordinate system.

The PNG documentation says something about "set size", but that doesn't achieve the concept of increasing resolution, just changes the portion of the PNG array used.

Now, I guess I could increase resolution by making the pointsize twice as big, line thickness twice as big, etc.  In fact, this setting

set term png giant size 1280,960
set pointsize 2.5

makes the symbol samples in "test" about the same as other plots (30 to 35 examples in the column) and the symbols are pretty good resolution.  But that doesn't exactly give the desired overall effect.  Adjusting so much becomes inconvenient.

So, it seems to me that with PNG one is inherently restricted to low resolution plots.  One could argue it is for network graphics, but still 1000x1000 in a compact format like PNG doesn't seem excessive.

Say there were a "resolution #" option that would internally scale line thickness, pointsize, and fonts (have to have a mapping to medium, large, giant... unfortunately the largest font doesn't have very high resolution).

Dan

Re: symbol/color/line consistency in terminals

[Mojca M. <moj...@gm...>]

> Similarly, there is now rotated text, for which we can use the LaTeX rotate package.  This one I don't think needs a special "set term latex rotate".  That would be confusing and there is no need for a "rotate" command if the user doesn't specify some piece of rotated text.


"ylabel" is rotated by 90 degrees by default, so yes - if supported, I
guess that you really need to provide a special keyword for it.

I would think (but I don't have LaTeX at hand on this computer) that
rotation and color should be supported by both dvips & pdfTeX, but
default options should not use any specials.

Having color in LaTeX terminal would nevertheless be very nice. The
old scripts won't break if you have to add the option color
explicitely, esp. since color is most probably supported by all most
important devices. It's not 100% clean and portable, but users would
probably prefer to have color than 100% portability, esp. if they
deliberately choose so (by selecting "color rotate").

(I missed the color very much when I was still using the LaTeX
terminal, and I didn't like eepic - it had worse defaults, even if
only the default linewidth and tic length was different than in LaTeX)

Mojca

Re: grouping available terminals together

[Mojca M. <moj...@gm...>]

On 2/10/07, Ethan A Merritt wrote:
>
> The logical next step would be to create an actual gnuplot package
> for TeX so that the user would do \usepackage{gnuplot}

Sure, but there has to be a good reason first (ie. enough
functionality provided). Solely for the reason of defining the
thirteen points types, it's not worth the problems. (Keep in mind that
the only reasonble way of having the solution work out-of-the-box is
to have the package on CTAN, not shipped with gnuplot, since shipping
the file with gnuplot needs an extra "installation" first - and you
might end up with the same question that you once asked me: what if
one has older gnuplot and newer TeX distribution or newer gnuplot and
older TeX)

But I still support having a gnuplot.sty if one can think of enough
ideas to implement in that package,  so that it will be "worth the
problems".


There is already a package "gnuplottex". With it one can do

\begin{gnuplot}
plot sin(x)
\end{gnuplot}

and it will run gnuplot automatically (with terminal "latex") and
include the resulting file (one needs write18 enabled and gnuplot in
PATH). Also, TikZ has an interesting module which passes a function to
gnuplot and runs it, but only to get the values of the function back:
it draws the result on it's own then.


Perhaps extentions to gnuplottex might make sense, again, if one has
ideas what to do. The package is rather new.

Mojca

Re: grouping available terminals together

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

On Saturday 10 February 2007 08:04, Mojca Miklavec wrote:
> 
> At the very bottom of
> http://sourceforge.net/tracker/download.php?group_id=2055&atid=302055&file_id=215003&aid=1654807
> you can see which symbols I used for ConTeXt

> {\scale[scale=800]{$+$}},
> {\scale[scale=800]{$\times$}},
> $\ast$,
> {\scale[scale=700]{$\square$}},
> {\scale[scale=700]{$\blacksquare$}},
> $\circ$,
> $\bullet$,
> {\scale[scale=900]{$\triangleup$}},
> {\scale[scale=900]{$\blacktriangle$}},
> {\scale[scale=900]{$\triangledown$}},
> {\scale[scale=900]{$\blacktriangledown$}},
> {\scale[scale=800]{$\lozenge$}},
> {\scale[scale=800]{$\blacklozenge$}}%,

Yes, thanks.  I found these in a grand compendium of LaTeX symbols
after my earlier post.  We ended up with the same choices, except for
\square (which comes out a different size than \blacksquare).
 
> I would suggest to put something like
> 
> \def\GnuplotSymbol#1{\ifcase#1 \GpSymI \or \GpSymII \or \GpSymIV \or
> \GpSymV \or \GpSymVI \or \GpSymVII ... \fi }
> 
> and then
> 
> \def\GpSymI{$+$} % perhaps including the scale somewhere
> \def\GpSymII{$\times$}
> \def\GpSymIII{$\ast$}
> ... etc.

Similar to the PostScript prologue. Yes, that is not a bad idea.
The logical next step would be to create an actual gnuplot package
for TeX so that the user would do \usepackage{gnuplot} 


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: symbol/color/line consistency in terminals

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

Daniel J Sebald wrote:

> How about an option "set term latex specials"?

I'll answer my own question and save you some work...  That's what "pslatex" is for.

Dan

Re: symbol/color/line consistency in terminals

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

Hans-Bernhard Bröker wrote:
> Daniel J Sebald wrote:
> 
>> Hans-Bernhard Bröker wrote:
> 
> 
>>> That would gravely endanger any usefulness of this driver.  The only 
>>> real virtue of "latex" compared to other Tex-family drivers (emtex, 
>>> eepic, and PostScript+LaTeX ones) is that its output is pure, 
>>> unextended, driver-independent LaTeX.  Pulling in terminal-specific 
>>> packages like "colour" would break that.
> 
> 
>> Not sure I follow.  The LaTeX driver already uses the symbol package(s).  
> 
> 
> Using packages as such is not the problem.  Using packages that only 
> work with a certain subset of DVI drivers, is.

Oh, yeah I see.  You mean such as when some xdvi output places labels out in space when rotating a block of text.  Guess so.  Ultimately comes out correctly in PostScript so it never bothered me too much.

> 
>> monochrome but also have no color commands.  Similarly, there is now 
>> rotated text, for which we can use the LaTeX rotate package. 
> 
> 
> ... which used dvips specials last I looked, so causes the same kind of 
> problem.

Not sure on that one.  I've turned on -warnspecials in xdvi and it gives plenty of warnings like:

xdvi.bin:  special "color push rgb 0 0 0" not implemented

But I don't seen any warnings for rotated text.  It could be that xdvi simply hasn't gotten around to supporting rotated text.  Any idea?

> 
> The moment "set term latex" produces dvi files with \special in them, it 
> becomes pointless to have it.

How about an option "set term latex specials"?

Dan

Re: symbol/color/line consistency in terminals

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

On Saturday 10 February 2007 11:28, Daniel J Sebald wrote:
> Hans-Bernhard Br=F6ker wrote:
> >=20
> > That's because GD, last I looked, didn't support linewidths on patterne=
d=20
> > lines.  Which made it rather pointless to try and implement dashing for=
=20
> > the first three.
>=20
> I'm not real familiar with GD, but the header file has:
>=20
> gdImageSetStyle ();
> gdImageSetThickness ();

Take my word for it, the gd routines for dashed lines and for
linewidth are useless for our purposes.

We work around the latter by defining a finites size 'brush' for drawing,
but there is no easy work-around for dashed lines.  And given that
PNG output is normally for screen display, and thus color is far
more useful than dashes, there is little incentive to code up a hack.

Anyhow, if it's to be new code, it makes more sense to add that new code
to the gd library than to gnuplot.

You could ask Pierre Joye, who is now directing libgd development,
if he would be interested in accepting a patchset for libgd that
implements more useful support for linewidth+dashed lines. If libgd
provided such support, it would make sense for gnuplot to use it.

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: symbol/color/line consistency in terminals

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

Hans-Bernhard Bröker wrote:

>> - "jpeg", "png", "gif" and "tkcanvas" have no line patterns.
> 
> 
> That's because GD, last I looked, didn't support linewidths on patterned 
> lines.  Which made it rather pointless to try and implement dashing for 
> the first three.

I'm not real familiar with GD, but the header file has:

gdImageSetStyle ();
gdImageSetThickness ();

Dan

Re: symbol/color/line consistency in terminals

[<HBB...@t-...>]

Daniel J Sebald wrote:
> Hans-Bernhard Bröker wrote:

>> That would gravely endanger any usefulness of this driver.  The only 
>> real virtue of "latex" compared to other Tex-family drivers (emtex, 
>> eepic, and PostScript+LaTeX ones) is that its output is pure, 
>> unextended, driver-independent LaTeX.  Pulling in terminal-specific 
>> packages like "colour" would break that.

> Not sure I follow.  The LaTeX driver already uses the symbol 
> package(s).  

Using packages as such is not the problem.  Using packages that only 
work with a certain subset of DVI drivers, is.

> monochrome but also have no color commands.  Similarly, there is now 
> rotated text, for which we can use the LaTeX rotate package. 

... which used dvips specials last I looked, so causes the same kind of 
problem.

The moment "set term latex" produces dvi files with \special in them, it 
becomes pointless to have it.

Re: symbol/color/line consistency in terminals

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

Hans-Bernhard Bröker wrote:
> Daniel J Sebald wrote:
> 
>> - "latex" doesn't support color, but we could upgrade that to use color
>>   package.  (Just LaTeX is still very useful for basic figures.)
> 
> 
> That would gravely endanger any usefulness of this driver.  The only 
> real virtue of "latex" compared to other Tex-family drivers (emtex, 
> eepic, and PostScript+LaTeX ones) is that its output is pure, 
> unextended, driver-independent LaTeX.  Pulling in terminal-specific 
> packages like "colour" would break that.

Not sure I follow.  The LaTeX driver already uses the symbol package(s).  What I am thinking is having an option "set term latex color", that will allow placing the appropriate LaTeX color package \color[rgb]{#,#,#} commands.  Without that option the figure will be monochrome but also have no color commands.  Similarly, there is now rotated text, for which we can use the LaTeX rotate package.  This one I don't think needs a special "set term latex rotate".  That would be confusing and there is no need for a "rotate" command if the user doesn't specify some piece of rotated text.

> 
>> - "jpeg", "png", "gif" and "tkcanvas" have no line patterns.
> 
> 
> That's because GD, last I looked, didn't support linewidths on patterned 
> lines.  Which made it rather pointless to try and implement dashing for 
> the first three.
> 
> I have no idea what tk can, or can not do.

No desire to add features to tk, just make things a bit more consistent.

Dan

Re: [gnuplot - Help] Error compiling CVS HEAD with VC6 on Windows

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

On Saturday 10 February 2007 09:51, Hans-Bernhard Br=F6ker wrote:
> SourceForge.net wrote:
>=20
> > ..\\term\cgm.trm(475) : error C2143: Syntaxfehler : Fehlendes ';' vor '=
type'
> > ..\\term\cgm.trm(477) : error C2065: 'new_font_data' : nichtdeklarierter
> > Bezeichner
>=20
> Guys, can we _please_ restrict ourselves to normal C for the time being?
>=20
> I.e. no C++ style variable declarations in the middle of code blocks.

Hmm. Yes. Not sure how that happened.

Is there a gcc flag that will cause it to emit warnings for this,
without flooding the output with more useless warnings?


=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: [gnuplot - Help] Error compiling CVS HEAD with VC6 on Windows

[<HBB...@t-...>]

SourceForge.net wrote:

> ..\\term\cgm.trm(475) : error C2143: Syntaxfehler : Fehlendes ';' vor 'type'
> ..\\term\cgm.trm(477) : error C2065: 'new_font_data' : nichtdeklarierter
> Bezeichner

Guys, can we _please_ restrict ourselves to normal C for the time being?

I.e. no C++ style variable declarations in the middle of code blocks.