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

Re: Keep compilable with --disable-string-variables

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

On Thursday 13 July 2006 17:14 Ethan A Merritt wrote:
> On Thursday 13 July 2006 12:43 am, Juergen Wieferink wrote:
> > While in it, the snippet:
> >
> >     v = add_udv_by_name("GPVAL_TERM");
> >     if (v) {
> > 	v->udv_undef = FALSE;
> > 	Gstring(&v->udv_value,(char*)term->name); /* this can be pointer */
> >     }
> >
> > looks dangerous to me.  The string a variable points to may be freed
> > if the variable is reset.
>
> I take it that you are worried some other bit of code might call
> gpfree_string(add_udv_by_name("GPVAL_TERM")), thus triggering
> an error when it tries to free the static allocation of term->name?
>
> The GPVAL_* variables cannot be over-written by the user,
> and this one bit of code is the only place that gnuplot itself
> sets this variable. So it is safe.

I don't like code like that nevertheless.  But it's not within my
responsibility.

> > Would an additional function Gstring_copy() be useful, which could be
> > called in places like this?
>
> I don't think that is necessary. You can already do this easily:
>
>   Gstring(&v->udv_value, gp_strdup(term->name));

Good point!

> Then you would have to modify the snippet of code above to deal with the
> opposite problem, that unless the previous name is explicitly freed there
> will be a memory leak.

Well, it could be done like the others:

    fill_gpval_string("GPVAL_TERM", term->name);

Never mind.



I do see another problem in fill_gpval_string():


fill_gpval_string(char *var, char *value)
{
#ifdef GP_STRING_VARS
    struct udvt_entry *v = add_udv_by_name(var);
    if (!v)
	return;
    if (v->udv_undef == FALSE && !strcmp((char*)&v->udv_value, value))
	return;
    v->udv_undef = FALSE; 
    gpfree_string(&v->udv_value);
    Gstring(&v->udv_value, gp_strdup(value));
    /* fprintf(stderr, "now it is: |%s|\n", &v->udv_value.v.string_val); */
#endif
}

When this function is invoked with a new variable, *v is newly
allocated and v->udv_value is not initialized.  It may happen to be
(v->udv_value->type == STRING && v->udv_value->string_val != NULL),
in which (quite improbable) case one would trigger a hardly
reproducible segfault.

I'd suggest something like:

Index: eval.c
===================================================================
--- eval.c	(Revision 279)
+++ eval.c	(Arbeitskopie)
@@ -733,8 +733,10 @@
 	return;
     if (v->udv_undef == FALSE && !strcmp((char*)&v->udv_value, value))
 	return;
-    v->udv_undef = FALSE; 
-    gpfree_string(&v->udv_value);
+    if (v->udv_undef)
+        v->udv_undef = FALSE;
+    else
+        gpfree_string(&v->udv_value);
     Gstring(&v->udv_value, gp_strdup(value));
     /* fprintf(stderr, "now it is: |%s|\n", &v->udv_value.v.string_val); */
 #endif



Juergen

Re: Bug in logarithmic minitics + suggested fix

[Aapo L. <aap...@gm...>]

On Wed, 2006-07-12 at 23:34 +0200, Hans-Bernhard Bröker wrote:
> though that's only 9 minitic intervals per decade.  What it should mean 
> in case the  major tics are more than one decade apart is anyone's 
> guess.  Your patch would place them at arithmetic intervals (1, 10, 20, 
> 30, 40, 50, 60, 70, 80, 90, 100), the existing code *wants* to place 
> them at geometric intervals (i.e. graphically equidistant, but at 
> numerically funny places, integer powers of 100^0.1), but fails.

Yes, it is difficult to say what should be done, when the user wants,
say 12 minitic intervals on a logarithmic plot with tic interval 100.
Actually, the automatic system "set mytics default" appears to work in a
rather sensible fashion, but unfortunately the user requested minitics
are not honoured.  Also, I think that for the user requested minitics
the arithmetic intervals would be better, because the user requested
minitics probably aren't in "nice" places (otherwise "auto" and
"default" would be used) and for awkward positions the arithmetic
intervals are by far easier to read and understand.  Compare e.g.
100^(x/6) and x/6*100 as tic positions.  Moreover, if the tics are at
arithmetic intervals, you can immediately see that the plot has a
logarithmic axis without looking at the numbers.
 
In any case, the current behaviour is inconsistent with the
documentation, AND completely chaotic.  See, for example, the following
plots:

set logscale y
set ytics 10
set mytics 10
plot [0:200] [1e-3:1e8] x**3   # that's good, mtics at 10, 20, 30, ...
set mytics 6
plot [0:200] [1e-3:1e8] x**3   # good, 5 mtics at arithmetic intervals
set ytics 100                  # "set ytics auto" has the same effect
plot [0:200] [1e-3:1e8] x**3   # but now there are 2 equidistant mtics!
# also, notice that minitics above 0.1 and 1 are missing!
# (without changing mytics, somehow mytics went from 6 to 3?!)
set mytics 2
plot [0:200] [1e-3:1e8] x**3   # no mtics ...
set mytics 3
plot [0:200] [1e-3:1e8] x**3   # now it's getting weird
set mytics 4
plot [0:200] [1e-3:1e8] x**3   # now we only have 1 tic ...
# ... but it is actually in a sensible place, no?

Of course, if you put ytics interval at something big&weird (i.e. not a
power of 10), the situation only gets worse.  See:

set ytics 313
set mytics 13
plot [0:200] [1e-3:1e8] x**3   # tic-tic-notic-tic-skip-tic-halfskip-...

or even (fortunately nobody needs these crazy intervals in practice!)

set ytics 313.345637
set mytics 13.3
plot [0:200] [1e-3:1e8] x**3   # hmm


> In a nutshell, I concede there's a bug, but I think you've found the 
> wrong fix.

True.  You got me thinking that maybe Gnuplot should simply discard the
logarithmic minitics asked, if the logarithmic interval is not "close
enough" to 1..10, as is done now.  As you said, it's not clear how the
minitics should be placed, arithmetically or equidistantly.  However,
the documentation should be modified to reflect the current behaviour;
and also, the current behaviour should be fixed.  The documentation
simply states that you get as many mtics intervals you ask, expect that
you should get one less if you ask for ten for obvious reasons (that's
what you want, anyway).  But it doesn't tell you that you get arithmetic
mtic intervals if [xyzc]tics <= 10*sqrt(10) =~ 31.6 and equidistant
otherwise.  In fact, it doesn't say anything about the mtics being
either arithemtic or equidistant.  And, it's not possible to choose
between the two modes.


> I would guess that was just because the existing code knows it would 
> fail in that case, and thus doesn't try to continue.

Perhaps.  But at least some of the bugs highlighted above may be caused
by the 1.5 limit.

In conclusion, it might be worthwile to add command "set m[xyzc]tics
arithmetic/equidistant/auto" for logarithmic axis.  For linear axis it
would work all right, as arithemtic and equidistant would be the same
for a linear axis.  Anyway, something (tm) should be done, at minimum
for the documentation.

Best Regards,
Aapo Lankinen

Re: Keep compilable with --disable-string-variables

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

On Thursday 13 July 2006 12:43 am, Juergen Wieferink wrote:
> 
> While in it, the snippet:
> 
>     v = add_udv_by_name("GPVAL_TERM");
>     if (v) {
> 	v->udv_undef = FALSE;
> 	Gstring(&v->udv_value,(char*)term->name); /* this can be pointer */
>     }
> 
> looks dangerous to me.  The string a variable points to may be freed
> if the variable is reset.

I take it that you are worried some other bit of code might call
gpfree_string(add_udv_by_name("GPVAL_TERM")), thus triggering
an error when it tries to free the static allocation of term->name?

The GPVAL_* variables cannot be over-written by the user,
and this one bit of code is the only place that gnuplot itself
sets this variable. So it is safe.  

> Would an additional function Gstring_copy() be useful, which could be called
> in places like this?

I don't think that is necessary. You can already do this easily:

  Gstring(&v->udv_value, gp_strdup(term->name));

Then you would have to modify the snippet of code above to deal with the
opposite problem, that unless the previous name is explicitly freed there
will be a memory leak.

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

Re: Keep compilable with --disable-string-variables

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

> the attached patch contains the minimal changes to reenable
> compiling and linking with --disable-stringvars.

Had another look into it.  This would also disable the 'defined'
function within gnuplot.  AFAICS, the solution is to give it any
pointer, including NULL, instead of f_exists.  But I'm not really
comfortable with the defined-code.


Juergen

Keep compilable with --disable-string-variables

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

Hi,

the attached patch contains the minimal changes to reenable
compiling and linking with --disable-stringvars.  I think this
switch should be dropped somewhen.

While in it, the snippet:

    v = add_udv_by_name("GPVAL_TERM");
    if (v) {
	v->udv_undef = FALSE;
	Gstring(&v->udv_value,(char*)term->name); /* this can be pointer */
    }

looks dangerous to me.  The string a variable points to may be freed
if the variable is reset.  Even if it might be save in this special
case (I don't know), it is bad style in my opinion.  Would an
additional function Gstring_copy() be useful, which could be called
in places like this?

Juergen

Re: What's left for a 4.2 release?

[Bastian M. <bma...@we...>]

Lucas Hart wrote:
=2E..
> I don't recall having seen any mention of incorporating patch=20
>  1445064  Gnuplot fitting improvements  2006-03-07
> submitted by Thomas Mattison after a number of exchanges on the
> mail list between he and HBB.
>=20
> The discussions re that patch brought out the point that currently=20
> the documentation and the fit output label are consistent, but those=20
> are inconsistent with the values output by the fit routine, i.e.,=20
> the documentation and fit output explicitly refer to parameter=20
> errors as "asymptotic standard error", i.e., as calculated from the=20
> variance-covariance matrix, with the intent that notation might cause
> the less experienced fitter to consult the documentation and become=20
> aware of the limitations in using those values to determine confidence =

> levels.
>=20
> However, fit.c has the comment
>  * HBB (br...@ph...) : fit didn't calculate the error=
s
>  * in the 'physically correct' (:-) way, if a third data column
>  * containing the errors (or 'uncertainties') of the input data was giv=
en.
>=20
> and the code
> 	/* scale parameter errors based on chisq */
> 		chisq =3D sqrt(chisq / (num_data - num_params));
> 			for (i =3D 0; i < num_params; i++)
> 				    dpar[i] *=3D chisq;
>=20
> Somehow, that discrepency was overlooked in earlier releases.
>=20
> I would present the asymptotic standard error and leave it to the user
> to determine any relationship between parameter errors as determined by=
=20
> the curvature of the chisquare hypersurface in the region of the minimu=
m=20
> and confidence limits for those parameters rather than apply an
> arbitrary scaling to the asymptotic standard errors.
>=20
Seconded. This scaling has been a major source of irritation to
to students in our lab courses.
But the scaling is not arbitrary. Effectively the errors of the
datapoints are scaled such that  reduced chi^2 =3D=3D 1.
That's very sensible if no data errors are supplied.

Btw. other widely used data analysis packages (including ROOT and
Origin) do not scale errors by default.

> That may be a point of contention - IIRC, the patch has a control
> variable which allows the user to select unscaled errors, as documented=
,
> or scaled errors, if such are desired, or for consistency with earlier
> gnuplot versions.

Personally, I would prefer new options to `set fit` instead of numerous n=
ew
FIT_xxx control variables. This would be much more consistent with the re=
st
of gnuplot.

--=20
Bastian M=E4rkisch
Physikalisches Institut, Universit=E4t Heidelberg

Re: What's left for a 4.2 release?

[<ha...@on...>]

On Wed, Jul 12, 2006 at 11:12:07PM +0200, Hans-Bernhard Broeker wrote:
> Ethan Merritt wrote:
> 
> > 	FIT_CONVERGED - 1 if the fit has converged, 0 otherwise
> > 	FIT_NDF  - number of degrees of freedom (#obs - #param)
> > 	FIT_RMS  - RMS fit of model to data;
> > 	           a.k.a. "std fit"
> >                    a.k.a. sqrt(sum_of_squares/ndf)
> > 	FIT_CHI2 - variance (reduced chi-squared residual) after fit;
> > 	           a.k.a. (sum_of_squares/ndf)
> > 
> > 	Hans-Bernhard has objected to these names, but no one has
> > 	suggested anything better. Please speak up.
> 
> Oh well, since I don't have the time to put my money where my mouth is 
> --- go ahead and check it in as-is.
> 

I agree with Hans-Bernhard's point in Feature Request 1117724
that it is preferable to be consistent and use the same variable 
names as occur in the printout and documentation rather than
introduce additional notation for the same quantities.

Thus FIT_STDFIT instead of the above FIT_RMS, to indicate that the
denominator is ndf not #obs-1.  While STDFIT may not be familiar, 
it is documented.

However, gnuplot.doc could be clearer wrt rms of the residuals, i.e, 
when estimating the mean value of the residuals, one would use #obs-1, 
and refer to standard deviation of the residuals.  For standard 
deviation of the fit, one uses #obs-#param.  Thus 'variance of residuals' 
and 'rms of residuals' in gnuplot.doc are generic descriptions for the 
lack of an alternative characterization of WSSR/ndf and sqrt(WSSR/ndf).)

By analogy to STDFIT, I would suggest FIT_VARFIT for variance of 
the fit rather than some other notation for WSSR/ndf.

It is not clear in the request why one wants both FIT_STDFIT and 
FIT_VARFIT, each readily computed from the other.

BTW It is difficult to find posts relevant to a particular item when 
all have the same subject so I may have missed some mention of the fit
discussions related to a 4.2 release.  Any suggestions for a subject 
for any fit follow-up? 

I don't recall having seen any mention of incorporating patch 
 1445064  Gnuplot fitting improvements  2006-03-07
submitted by Thomas Mattison after a number of exchanges on the
mail list between he and HBB.

The discussions re that patch brought out the point that currently 
the documentation and the fit output label are consistent, but those 
are inconsistent with the values output by the fit routine, i.e., 
the documentation and fit output explicitly refer to parameter 
errors as "asymptotic standard error", i.e., as calculated from the 
variance-covariance matrix, with the intent that notation might cause
the less experienced fitter to consult the documentation and become 
aware of the limitations in using those values to determine confidence 
levels.

However, fit.c has the comment
 * HBB (br...@ph...) : fit didn't calculate the errors
 * in the 'physically correct' (:-) way, if a third data column
 * containing the errors (or 'uncertainties') of the input data was given.

and the code
	/* scale parameter errors based on chisq */
		chisq = sqrt(chisq / (num_data - num_params));
			for (i = 0; i < num_params; i++)
				    dpar[i] *= chisq;

Somehow, that discrepency was overlooked in earlier releases.

I would present the asymptotic standard error and leave it to the user
to determine any relationship between parameter errors as determined by 
the curvature of the chisquare hypersurface in the region of the minimum 
and confidence limits for those parameters rather than apply an
arbitrary scaling to the asymptotic standard errors.

That may be a point of contention - IIRC, the patch has a control
variable which allows the user to select unscaled errors, as documented,
or scaled errors, if such are desired, or for consistency with earlier
gnuplot versions.

- Lucas Hart

Re: Bug in logarithmic minitics + suggested fix

[<br...@ph...>]

Aapo Lankinen wrote:
> The first plot has the minitics on the logarithmic y-axis as it should;
> but the second plot with ytics having a longer step doesn't show any
> minitics at all.  I think the 10 minitics should be there as ordered,
> no?  

Not really.  '10 minitics' on a log-10 axis has generally been 
interpreted to mean the same as the default minitic placement, even 
though that's only 9 minitic intervals per decade.  What it should mean 
in case the  major tics are more than one decade apart is anyone's 
guess.  Your patch would place them at arithmetic intervals (1, 10, 20, 
30, 40, 50, 60, 70, 80, 90, 100), the existing code *wants* to place 
them at geometric intervals (i.e. graphically equidistant, but at 
numerically funny places, integer powers of 100^0.1), but fails.

In a nutshell, I concede there's a bug, but I think you've found the 
wrong fix.

> I'm not sure why there was a (step <= 1.5) condition - I needed to
> remove it to allow larger ytics steps than 1.5 (the example has step =
> 2.0).  

I would guess that was just because the existing code knows it would 
fail in that case, and thus doesn't try to continue.

Re: What's left for a 4.2 release?

[<br...@ph...>]

Ethan Merritt wrote:
> This attempts to be a complete list of unresolved issues that I see
> as release-critical.   It's a very short list.
> 
> Bugs
> ========
> 
> #1512210  buffer overflow using pgnuplot
> 		
> 	Sounds serious, but no one has confirmed the bug.
> 	We never heard back from the original reporter.

Let's put this on the back-burner.  Whatever it is, I'm reasonably sure 
it's been exactly like that since pgnuplot was first written.  There's 
no hurry fixing it now.

> #1510816  Postscript prologues files
> 
> 	Works fine under linux/DU4/irix/etc, and OK though not
> 	perfectly on VMS.  The sticking point is Windows.
> 	Is this workable under Windows, or do we have to provide a
> 	compile-time option to include all of the PostScript
> 	boilerplate in the driver itself?  I'd hate to take what
> 	I consider to be a step backwards, but if we must - we must.

I'll try to have a look at this, but: my time is severely limited.  New 
job, new town, you get the drift.

> #1505261  wgnuplot: open file-open-dialog in current dir
> 
> 	I don't care whether this goes in, or gets vetoed,
> 	but we need a decision one way or the other.

I vote for keeping it as-is.  The potential benefit is too small to 
warrant the risk of a last-minute fix.

IMHO, if there's any Windows-specific issue that *really* needs to be 
addressed, it's the #1 FAQ issue about wgnuplot: font in the text window 
is unreadably small for first-time users.  Has to be fixed once and the 
fix solidified by writing a wgnuplot.ini.  Unfortunately, this broke by 
outside interference, i.e. we changed nothing, but Redmond did, and 
poof, the original code that worked since wgnuplot 3.5 on Windows 3.1, 
suddenly fails.  Windows seems to have forgotten what "just give me the 
default font" means.

> 	FIT_CONVERGED - 1 if the fit has converged, 0 otherwise
> 	FIT_NDF  - number of degrees of freedom (#obs - #param)
> 	FIT_RMS  - RMS fit of model to data;
> 	           a.k.a. "std fit"
>                    a.k.a. sqrt(sum_of_squares/ndf)
> 	FIT_CHI2 - variance (reduced chi-squared residual) after fit;
> 	           a.k.a. (sum_of_squares/ndf)
> 
> 	Hans-Bernhard has objected to these names, but no one has
> 	suggested anything better. Please speak up.

Oh well, since I don't have the time to put my money where my mouth is 
--- go ahead and check it in as-is.

Re: What's left for a 4.2 release?

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

On Wednesday 12 July 2006 01:46 pm, Hans-Bernhard Br=F6ker wrote:
> >> /* Define to enable quadtree optimization in hidden3d code. */
> >> #define HIDDEN3D_QUADTREE 1
> >
> > It's nowhere written whether it is useful.
> > If it is, then let us have it on.
>
> It's useful.  The only reason I didn't enable it by default for 4.0
> was that it had seen very little testing by anybody but myself, since
> I implemented it.  I think it should be made the ./configure default
> for 4.2

I agree. All testing that I have done for the last 6 months or more
has had this option enabled.

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

Re: What's left for a 4.2 release?

[<br...@ph...>]

Petr Mikulik wrote:
>> Bugs
>> ========
>>
>> #1512210  buffer overflow using pgnuplot
>>
>> 	Sounds serious, but no one has confirmed the bug.
>> 	We never heard back from the original reporter.
> 
> Thus it should be closed.

No.  It should be left alone.  Just because we're in a hurry doesn't 
mean we can ignore all bug reports that can't handle that speed.

>> #1117724  [fit] access to resulting chisquare

>> 	Hans-Bernhard has objected to these names, but no one has
>> 	suggested anything better. Please speak up.
> 
> I prefer the proposed names FIT_*

My objection was not to the FIT_* part, but to what comes after it.

>> /* Define to enable quadtree optimization in hidden3d code. */
>> #define HIDDEN3D_QUADTREE 1

> But this is not default in ./configure.
> I never tried this option. It's nowhere written whether it is useful. If it 
> is, then let us have it on.

It's useful.  The only reason I didn't enable it by default for 4.0 was 
that it had seen very little testing by anybody but myself, since I 
implemented it.  I think it should be made the ./configure default for 4.2

history, post 4.2

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

How about being able to recall from the history via number:

gnuplot> history 5
  162  myval = 123
  163  show vars
  164  show variables
  165  plot x + myval
  166  history 5
gnuplot> history !165
                  ^
         not in history

which would be useful if the history gets quite long and the user wants to recall a long ago command that is very similar to one more recent?

Dan

Re: 'make distcheck' has problems with the wxt files

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

Daniel J Sebald wrote:
> Here are the differences in directory contents before and after all.dem=
:
> (...)
> There are three files with the .dat extension.  "temp.dat" is the only =
one that causes problems?  I'm OK with renaming that to anything, really.=
  "normal.dat", "normal.tmp", "gauss.dat", "gauss.tmp", "foo.foo", "fi.fi=
"...  "normal.tmp" probably.
>
> Dan
>  =20
Lars Hecking wrote:
>  Everything .dat is automatically included with "make dist".
>  The alternative is to list all distributed .dat files, all
>  29 of them, individually in Makefile.am.in under the Makefile.am
>  creation rule.
I changed the three temporary *.dat files to *.tmp files.

Timoth=E9e

Re: 'make distcheck' has problems with the wxt files

[Lars H. <lhe...@us...>]

> I don't quite follow why the name makes a difference, but I'm
 
 Everything .dat is automatically included with "make dist".
 The alternative is to list all distributed .dat files, all
 29 of them, individually in Makefile.am.in under the Makefile.am
 creation rule.

Re: 'make distcheck' has problems with the wxt files

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

On Wednesday 12 July 2006 09:44 am, Lars Hecking wrote:
> > >  This is a real bummer - by default, make dist includes *.dat,
> > > there are really too many to list individually. Can whoever added
> > > this (Ethan?) rename temp.dat so it doesn't have a .dat
> > > extension? tempdat.tmp maybe?

Not me.

The only place I see temp.dat mentioned is in random.dem
I don't quite follow why the name makes a difference, but I'm
sure the demo itself doesn't depend on any particular name.

> > Ethan solved the problem by adding temp.dat to CLEANFILES in
> > docs/Makefile.am.in
>
>  This did not solve it because recreating Makefile.am from
> Makefile.am.in adds temp.dat to EXTRA_DIST, so temp.dat gets included
> with make dist.

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

Re: 'make distcheck' has problems with the wxt files

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

Lars Hecking wrote:
>  Nobody replied to this section:
> 
> Timoth?e Lecomte writes:
> 
>>Ethan Merritt wrote:
> 
> [...] 
> 
>>Now 'make distcheck' seems to go almost to its completion, but ends up 
>>like that :
>>
>>make[2]: quittant le r?pertoire ? 
>>/home/tipote/gnuplot-cvs2/gnuplot-4.1.0/_build ?
>>rm -f config.status config.cache config.log configure.lineno 
>>configure.status.lineno
>>rm -f Makefile
>>ERROR: files left in build directory after distclean:
>>./demo/temp.dat
> 
> [...]
> 
>  This is a real bummer - by default, make dist includes *.dat, there are
>  really too many to list individually. Can whoever added this (Ethan?)
>  rename temp.dat so it doesn't have a .dat extension? tempdat.tmp maybe?

Here are the differences in directory contents before and after all.dem:

12a13,15
> binary1
> binary2
> binary3
33a37,38
> equipo2.dat
> field2xy.dat
39a45
> fit.log
96a103
> soundfit.par
106a114
> stringvar.tmp
109a118
> temp.dat

There are three files with the .dat extension.  "temp.dat" is the only one that causes problems?  I'm OK with renaming that to anything, really.  "normal.dat", "normal.tmp", "gauss.dat", "gauss.tmp", "foo.foo", "fi.fi"...  "normal.tmp" probably.

Dan

Re: 'make distcheck' has problems with the wxt files

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

Lars Hecking wrote:
>>>  This is a real bummer - by default, make dist includes *.dat, there =
are
>>>  really too many to list individually. Can whoever added this (Ethan?=
)
>>>  rename temp.dat so it doesn't have a .dat extension? tempdat.tmp may=
be?
>>>
>>>  Thanks.
>>>  =20
>>>      =20
>> Ethan solved the problem by adding temp.dat to CLEANFILES in=20
>> docs/Makefile.am.in
>>    =20
> =20
>  This did not solve it because recreating Makefile.am from Makefile.am.=
in
>  adds temp.dat to EXTRA_DIST, so temp.dat gets included with make dist.
Ok, I get the point. If you will, I can correct that.

Timoth=E9e

Re: 'make distcheck' has problems with the wxt files

[Lars H. <lhe...@us...>]

> >  This is a real bummer - by default, make dist includes *.dat, there are
> >  really too many to list individually. Can whoever added this (Ethan?)
> >  rename temp.dat so it doesn't have a .dat extension? tempdat.tmp maybe?
> >
> >  Thanks.
> >   
> Ethan solved the problem by adding temp.dat to CLEANFILES in 
> docs/Makefile.am.in
 
 This did not solve it because recreating Makefile.am from Makefile.am.in
 adds temp.dat to EXTRA_DIST, so temp.dat gets included with make dist.

Re: 'make distcheck' has problems with the wxt files

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

Lars Hecking wrote:
>  Nobody replied to this section:
>
> Timoth?e Lecomte writes:
>  =20
>> Ethan Merritt wrote:
>>    =20
> [...]=20
>  =20
>> Now 'make distcheck' seems to go almost to its completion, but ends up=
=20
>> like that :
>>
>> make[2]: quittant le r?pertoire ?=20
>> /home/tipote/gnuplot-cvs2/gnuplot-4.1.0/_build ?
>> rm -f config.status config.cache config.log configure.lineno=20
>> configure.status.lineno
>> rm -f Makefile
>> ERROR: files left in build directory after distclean:
>> ./demo/temp.dat
>>    =20
> [...]
>
>  This is a real bummer - by default, make dist includes *.dat, there ar=
e
>  really too many to list individually. Can whoever added this (Ethan?)
>  rename temp.dat so it doesn't have a .dat extension? tempdat.tmp maybe=
?
>
>  Thanks.
>  =20
Ethan solved the problem by adding temp.dat to CLEANFILES in=20
docs/Makefile.am.in

Timoth=E9e

Re: 'make distcheck' has problems with the wxt files

[Lars H. <lhe...@us...>]

 Nobody replied to this section:

Timoth?e Lecomte writes:
> Ethan Merritt wrote:
[...] 
> Now 'make distcheck' seems to go almost to its completion, but ends up 
> like that :
> 
> make[2]: quittant le r?pertoire ? 
> /home/tipote/gnuplot-cvs2/gnuplot-4.1.0/_build ?
> rm -f config.status config.cache config.log configure.lineno 
> configure.status.lineno
> rm -f Makefile
> ERROR: files left in build directory after distclean:
> ./demo/temp.dat
[...]

 This is a real bummer - by default, make dist includes *.dat, there are
 really too many to list individually. Can whoever added this (Ethan?)
 rename temp.dat so it doesn't have a .dat extension? tempdat.tmp maybe?

 Thanks.

Re: What's left for a 4.2 release?

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

> I still think #1488168 should be addressed before 4.2.
>
> set xyplane at 0
> splot x+y
>
> The line going down beyond the used range is a clear bug and restricts any 
> users from manually adjusting things.

I like the patch and propose it for committing now.

---
PM

line from ruler to current mouse position if polar distance

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

Can you please test this patch:
https://sourceforge.net/tracker/?func=detail&atid=302055&aid=1520821&group_id=2055

The patch completes the functionality of the ruler-cursor visualizatin in 
"polar distance" (=distance, angle, slope) mode.


Patch description:
This patch draws a line from ruler to current mouse
cursor when ruler is visible (hotkey 'r') and polar
distance is displayed in the status bar (hotkey '5').

This implements calls set_cursor(flag,...) for flag=-3
and -4. Currently implemented for x11 and windows
terminals; implementation for wxt and pm is welcome.

---
PM

Re: What's left for a 4.2 release?

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

Ethan Merritt wrote:
> This attempts to be a complete list of unresolved issues that I see
> as release-critical.   It's a very short list.
> 
> Bugs
> ========
> 
> #1512210  buffer overflow using pgnuplot
> 		
> 	Sounds serious, but no one has confirmed the bug.
> 	We never heard back from the original reporter.

I still think #1488168 should be addressed before 4.2.

set xyplane at 0
splot x+y

The line going down beyond the used range is a clear bug and restricts any users from manually adjusting things.

Dan

Re: What's left for a 4.2 release?

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

On Tuesday 11 July 2006 01:27 pm, Petr Mikulik wrote:
>
> I've confirmed it for config.{os2, mgw, cyg, nt}

Great.

> > /* Define to enable quadtree optimization in hidden3d code. */
> > #define HIDDEN3D_QUADTREE 1
>
> But this is not default in ./configure.
> I never tried this option. It's nowhere written whether it is useful.
> If it is, then let us have it on.

Sorry for the confusion.
I've had this option selected in my test-build script for
so long that I forgot is was not the default.

So far as I know, the only reason to turn it off is so that you
can try HIDDEN3D_GRIDBOX instead.  The two options are mutually
incompatible.

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

Re: What's left for a 4.2 release?

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

> Bugs
> ========
>
> #1512210  buffer overflow using pgnuplot
>
> 	Sounds serious, but no one has confirmed the bug.
> 	We never heard back from the original reporter.

Thus it should be closed.

> #1117724  [fit] access to resulting chisquare
>
> 	I proposed exporting user-visible variables named
>
> 	FIT_CONVERGED - 1 if the fit has converged, 0 otherwise
> 	FIT_NDF  - number of degrees of freedom (#obs - #param)
> 	FIT_RMS  - RMS fit of model to data;
> 	           a.k.a. "std fit"
>                   a.k.a. sqrt(sum_of_squares/ndf)
> 	FIT_CHI2 - variance (reduced chi-squared residual) after fit;
> 	           a.k.a. (sum_of_squares/ndf)
>
> 	Hans-Bernhard has objected to these names, but no one has
> 	suggested anything better. Please speak up.

I prefer the proposed names FIT_*

> #1513118  Standardize all config and Makefiles for 4.2
>
> 	We have set the ./configure script to select most of the
> 	new features by default.  But the makefiles for platforms
> 	not using the configure script do not match this (see below).
> 	Should they?

Yes, at least those maintained.

I've confirmed it for config.{os2, mgw, cyg, nt}

> /* Define to enable quadtree optimization in hidden3d code. */
> #define HIDDEN3D_QUADTREE 1

But this is not default in ./configure.
I never tried this option. It's nowhere written whether it is useful. If it 
is, then let us have it on.

---
PM