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

Re: Idea: env-mapping for dataplot over pipes

[Tino W. <ti...@wi...>]

Ethan A Merritt wrote:
...
> Right. That you can do, for instance by passing the values as
> script parameters:
> 
>   command1 = sprintf("< scriptname  %g %g",GPVAL_X_MIN,GPVAL_X_MAX)
>   plot command1 with lines

Well, this works with the current checkout, but not in a way to
fix the problem ;) After the sprintf of course the values
are fixed in the string and are not recalculated when you
select another area to zoom with the mouse.
So a mapping to the environment would be the most flexible
way to make all this possible I guess...

Regards
Tino

Re: Fwd: [ gnuplot-Bugs-1517932 ] epslatex terminal spews useless output

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

>>   LT0
>>   3775 3671 M
>>   stroke
>> have no effect.
>
>    if (PS_linetype_last == linetype) return;
>
> This comment is almost certainly out of date, as predates version 3.5.
> The code has changed radically since then!
>
> "make check" and all.dem seem to work properly if the redundancy test is
> restored, and I am agreeable to doing so. This reduces the size of the
> all.dem postscript output by 3%.

then please commit it


> Related issue
> =============
>
> More annoying to me are all the output lines
>  Blacktext { gsave 0 setgray } if
>  <something>
>  Blacktext { grestore } if
> At the least, perhaps we should define shorthand forms in the prolog:
>  /BTon { Blacktext { gsave 0 setgray } if } def
>  /Btoff { Blacktext { grestore } if } def

I think the following is the correct solution:

/Rshow {Blacktext { gsave 0 setgray } if
     currentpoint stroke M dup stringwidth pop neg vshift R show
     Blacktext { grestore } if} def

and same for Cshow and Lshow.


>> Further 2.eps shows that gnuplot core is generating many sequent numbers
>> like:
>>
>> .4891 g .4673 g .4462 g .4259 g .4068 g .3893 g .3735 g .3599 g .3485 g
>> .3397 g ...
>>
>> I think that these two excessivenesses should be eliminated by (hidden3d?)
>> code, because they don't appear normally, and it could be easier to fix
>> there than in all terminal drivers.
>
> This only affects drivers which create an output stream
> for later execution.  The pixel-based drivers don't care.
>
> In fact, I'm not certain it affects any drivers other than post and svg.
> The other candidates would be emf and pdf, but emf doesn't support
> that color mode, and I think the pdf library already optimizes this out.
> Can you think of any others?

I think it "affects" all, if term->set_color() has to do something ... e.g. 
pm.trm send the info through pipe to gnupmdrv.exe, win.trm saves all these 
"new color" commmands into its drawing buffer...

I think that the "producer" of these ".4068 g" should eliminate to call 
term->set_color() if it is not needed for any drawing. Is it some "hidden3d" 
code?

---
PM

Re: Build problem

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

On Saturday 08 July 2006 02:02 pm, Hans-Bernhard Br=C3=B6ker wrote:
>=20
> So, summing it up: initializing, even to the wrong value, is never worse=
=20
> than not initializing at all, and it does get rid of the warning.

Never worse with regard to code correctness, but it can make later
debugging harder. =20

Suppose there really is a yet unrecognized error. Eventually it bites us.
If the compiler warning is still there, pointing a finger of blame at a=20
suspiciously relevant variable, then you have a big hint at where to start
debugging.  If the compiler is silent (because of the spurious
initialization), then your error is no worse but you no longer have that
debugging hint.

The usual counter-argument is that real errors flagged in the compiler
output may go unnoticed if they are buried in a flood of spurious warnings.
=46ortunately, we are not in that position.

The same concerns pertain to the other two warnings in the current build:
color.c:516: warning: pointer targets in passing argument 2 of =E2=80=98map=
3d_position_r=E2=80=99 differ in signedness
color.c:516: warning: pointer targets in passing argument 3 of =E2=80=98map=
3d_position_r=E2=80=99 differ in signedness
set.c:2309: warning: pointer targets in passing argument 2 of =E2=80=98map_=
position=E2=80=99 differ in signedness
set.c:2309: warning: pointer targets in passing argument 3 of =E2=80=98map_=
position=E2=80=99 differ in signedness

The warning is correct, and points to an inconsistency in the 2D and 3D cod=
e.
We code hide the warning by casting the variable to singed or unsigned, but=
 then
we would no longer have a reminder to deal someday with the real inconsiste=
ncy.


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

Re: Fwd: [ gnuplot-Bugs-1517932 ] epslatex terminal spews useless output

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

On Saturday 08 July 2006 02:21 am, Petr Mikulik wrote:
> I'm enclosing eg7.zip, with 1.tex+1.eps as generated by eg7.gp script, and 
> the same output into ps terminal 2.eps, wherefrom I've removed the color 
> surface part (see "@@@ Petr" in 2.eps) to demonstrate those many
>   LT0
>   3775 3671 M
>   stroke
> have no effect.

As Dan Sebald pointed out, these are caused by the following section
in post.trm|

  #if 0
    /*  In order to make 'PS_linewidth' work properly, I need to comment
     *  this line out.  Especially in combination with the line width
     *  extension of the `set arrow` command this is necessary.
     *  Can we live with that drawback?  (JFi)
     */
    if (PS_linetype_last == linetype) return;
  #endif

This comment is almost certainly out of date, as predates version 3.5. 
The code has changed radically since then!

"make check" and all.dem seem to work properly if the redundancy test is
restored, and I am agreeable to doing so. This reduces the size of the 
all.dem postscript output by 3%.


Related issue
=============

More annoying to me are all the output lines
  Blacktext { gsave 0 setgray } if
  <something>
  Blacktext { grestore } if
These amount to 4.6% of the output file size from all.dem, and their only
utility is to allow users to toggle the "blacktext" option in the output
file rather than as a 'set term' option.  Is this worth the cost?

At the least, perhaps we should define shorthand forms in the prolog:
  /BTon { Blacktext { gsave 0 setgray } if } def
  /Btoff { Blacktext { grestore } if } def


> Further 2.eps shows that gnuplot core is generating many sequent numbers 
> like:
> 
> .4891 g .4673 g .4462 g .4259 g .4068 g .3893 g .3735 g .3599 g .3485 g 
> .3397 g ...
> 
> I think that these two excessivenesses should be eliminated by (hidden3d?) 
> code, because they don't appear normally, and it could be easier to fix 
> there than in all terminal drivers.

This only affects drivers which create an output stream 
for later execution.  The pixel-based drivers don't care.

In fact, I'm not certain it affects any drivers other than post and svg.
The other candidates would be emf and pdf, but emf doesn't support
that color mode, and I think the pdf library already optimizes this out.
Can you think of any others?

	Ethan

> 
> Petr
> 
> 
> > Do you have a sample script that demonstrates this problem?
> >
> > 	Ethan
> >
> >
> >> Comment By: Petr Mikulik (mikulik)
> >> Date: 2006-07-07 12:21
> >>
> >> I have found that these lines
> >>
> >> LT0
> >> 3775 3671 M
> >> stroke
> >> LT0
> >> 4124 2937 M
> >> stroke
> >>
> >> are written by the command
> >>
> >> set hidden3d offset 1 trianglepattern 3 undefined 1
> >> altdiagonal bentover
> >>
> >> and they appear even for "set term postscript"

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

Re: Build problem

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

Ethan A Merritt wrote:
> On Saturday 08 July 2006 12:22 pm, Hans-Bernhard Br=F6ker <broeker@=
physik.rwth-aachen.de> wrote:
>> [gcc -Wuninitialized warnings]

>>> I don't know of any way to make gcc more accurate in such cases.
>> Well, just initialize them!  Worst that can happen is that the cod=
e=20
>> gratuitously grows by 3 'load value into variable' operations.  *I=
f*=20
>> they're actually false alarms, that is.
>=20
> Not quite.  The worst thing that can happen is that by initializing
> to some spurious value, you trigger run-time errors that are no lon=
ger
> accompanied by a relevant compiler warning. =20

You've just demonstrated the reason why I wrote: "*If*" they're actua=
lly=20
false alarms".  A -Wuniniatilized can be a false alarm _only_ if all=
=20
code paths leading to  the place of the warning actually come by a wr=
ite=20
to the variable in question, but the compiler didn't understand the c=
ode=20
well enough to notice that.  If there's any way the dummy initializer=
=20
can survive to the place warned about, the alarm is not false.

> But if somehow the pair of if conditions are not truly
> equivalent, then you have a problem regardless of the fact
> that baz has been initialized. =20

If that happens, there was no false alarm to begin with.

There can really be only two cases.

1) False alarm.  Adding an initializer silences the warning, slightly=
=20
increases code size and burns some useless CPU cycles.  Nothing gaine=
d=20
except the warning is silenced, but no considerable harm done either.

2) Justified alarm.  This is a bug that needs to be fixed, and the fi=
x=20
will be to initialize that variable.  The only tricky question remain=
s=20
is what the initial value should be.

So, summing it up: initializing, even to the wrong value, is never wo=
rse=20
than not initializing at all, and it does get rid of the warning.

Re: Build problem

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

On Saturday 08 July 2006 12:22 pm, Hans-Bernhard Br=F6ker <broeker@physik.r=
wth-aachen.de> wrote:
>=20
> [gcc -Wuninitialized warnings]
>=20
> > I don't know of any way to make gcc more accurate in such cases.
>=20
> Well, just initialize them!  Worst that can happen is that the code=20
> gratuitously grows by 3 'load value into variable' operations.  *If*=20
> they're actually false alarms, that is.

Not quite.  The worst thing that can happen is that by initializing
to some spurious value, you trigger run-time errors that are no longer
accompanied by a relevant compiler warning.  Hiding a possible
problem is worse than leaving the possibly spurious error message.

The problematic constuct is code like the following:

  if (foo) {
    ...
    baz =3D something_calculated;
  }
  [lots of code]
  if (foo) {
    do_something_with(baz);
  }

gcc recognizes that baz is set only inside an if () statement,
but fails to notice that it is only dereferenced inside a=20
matching if () statment.

Yes, you could initialize at the head of the program:
  static double baz =3D 0.0;

But if somehow the pair of if conditions are not truly
equivalent, then you have a problem regardless of the fact
that baz has been initialized.  It is true that in many
cases an incorrect value of 0 is less likely to cause a
segfault than an incorrect value of NaN.  But it's incorrect
either way, and I see no particular virtue in silencing the
compiler's attempt to point out the source of a possible problem.
 =20

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

Re: Build problem

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

Ethan A Merritt wrote:

> The patch was not correct. Instead the changes of 2006-06-11 should
> have been reverted entirely.  Unfortunately, I don't know how to issue
> a "revert to verion xxx" command in cvs.  Is that even possible?

Not directly.  But see the -j <rev|date> option of 'cvs update'.  That 
one allows you to check get a version with all changes between to given 
ones applied to it.  So

	cvs update -j 1.25 -j 1.23 file.ext

will revert all the changes from revision 1.23 to revision 1.25 of that 
file.  As an alternative, you can check out a given old revision,
remove the sticky revision state, and check it back in as new.

[gcc -Wuninitialized warnings]

> I've been getting all 3 of those for a long time now.
> They are all false alarms, and highly dependent on the precise gcc version
> being used.  I don't know of any way to make gcc more accurate in such cases.

Well, just initialize them!  Worst that can happen is that the code 
gratuitously grows by 3 'load value into variable' operations.  *If* 
they're actually false alarms, that is.

Re: Build problem

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

On Saturday 08 July 2006 08:33 am, Juergen Wieferink wrote:
> 
> parse.c:846: warning: `is_ud_function' defined but not used

That is a result of a patch yesterday from Dan Sebald.
The patch was not correct. Instead the changes of 2006-06-11 should
have been reverted entirely.  Unfortunately, I don't know how to issue
a "revert to verion xxx" command in cvs.  Is that even possible?
I guess I'll have to manually extract the earlier version and re-submit
it as if it were new.

> plot3d.c:1159: warning: `specs' might be used uninitialized in this function
> ../term/wxt.trm:112: warning: `font_setting' might be used uninitialized in 
> this function
> wxterminal/gp_cairo.c:1029: warning: `overprinted_width' might be used 
> uninitialized in this function
> 
> The first one is recently introduced, the second one seems to be
> false alarm.  Of the third one I've heard similar diagnose on the
> list.

I've been getting all 3 of those for a long time now.
They are all false alarms, and highly dependent on the precise gcc version
being used.  I don't know of any way to make gcc more accurate in such cases.



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

Re: Build problem

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

On Friday 07 July 2006 02:10 Timoth=E9e Lecomte wrote:
> This turned out to be an interesting information. I was obviously relying
> on an undocumented behaviour so that Init(wxWindowDC*) was working,
> whereas it is absent from the wxWidgets manual, even from 2.6.x
>
> I solved that problem in the CVS, so if you want you can try again and
> report other interesting bits like those ones ;-)

Well, probably not that interesting.  Though I found some things.
=46irst the warnings:

parse.c:846: warning: `is_ud_function' defined but not used
plot3d.c:1159: warning: `specs' might be used uninitialized in this function
=2E./term/wxt.trm:112: warning: `font_setting' might be used uninitialized =
in=20
this function
wxterminal/gp_cairo.c:1029: warning: `overprinted_width' might be used=20
uninitialized in this function

The first one is recently introduced, the second one seems to be
false alarm.  Of the third one I've heard similar diagnose on the
list.


Linking fails with:

g++  -g -O2 -I/usr/lib/wx/include/gtk2-unicode-release-2.5=20
=2DI/usr/include/wx-2.5 -DGTK_NO_CHECK_CASTS -D__WXGTK__ -D_FILE_OFFSET_BIT=
S=3D64=20
=2DD_LARGE_FILES   -I/usr/local/include/cairo -I/usr/X11R6/include=20
=2DI/usr/include/libpng12 -I/usr/include/freetype2  =20
=2DI/usr/local/include/pango-1.0 -I/opt/gnome/include/glib-2.0=20
=2DI/opt/gnome/lib/glib-2.0/include   -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE=
_API=20
=2DI/usr/local/include/pango-1.0 -I/usr/X11R6/include -I/usr/include/freety=
pe2=20
=2DI/usr/include/freetype2/config -I/opt/gnome/include/gtk-2.0=20
=2DI/opt/gnome/lib/gtk-2.0/include -I/opt/gnome/include/atk-1.0=20
=2DI/opt/gnome/include/glib-2.0 -I/opt/gnome/lib/glib-2.0/include    -L/usr=
/lib=20
=2DWl,-rpath,/usr/lib -L/usr/X11R6/lib -o gnuplot  alloc.o axis.o breaders.=
o=20
bitmap.o color.o command.o contour.o datafile.o dynarray.o eval.o fit.o=20
gadgets.o getcolor.o graph3d.o graphics.o help.o hidden3d.o history.o=20
internal.o interpol.o matrix.o misc.o mouse.o parse.o plot.o plot2d.o=20
plot3d.o pm3d.o readline.o save.o scanner.o set.o show.o specfun.o standard=
=2Eo=20
stdfn.o tables.o term.o time.o unset.o util.o util3d.o variable.o version.o=
 =20
gp_cairo.o wxt_gui.o -lreadline  -lncurses  -lz -lgd -lXpm -lX11 -ljpeg=20
=2Dlfontconfig -lfreetype -lpng12 -lz -lm  -pthread   -L/usr/X11R6/lib =20
=2Dlwx_gtk2u_xrc-2.5 -lwx_gtk2u_html-2.5 -lwx_gtk2u_adv-2.5 -lwx_gtk2u_core=
=2D2.5=20
=2Dlwx_baseu_xml-2.5 -lwx_baseu_net-2.5 -lwx_baseu-2.5  -L/usr/local/lib=20
=2DL/usr/X11R6/lib -lcairo -lXrender -lX11 -lXext -lpng12 -lz -lm -lfreetyp=
e=20
=2Dlfontconfig   -L/usr/local/lib -L/opt/gnome/lib -lpango-1.0 -lgobject-2.=
0=20
=2Dlgmodule-2.0 -ldl -lglib-2.0   -L/usr/local/lib -L/opt/gnome/lib=20
=2Dlgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangoxft-1.0=
=20
=2Dlpangox-1.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl=
=20
=2Dlglib-2.0   -lm=20
wxterminal/gp_cairo.c:1592: undefined reference to `pango_cairo_create_layo=
ut'
gp_cairo.o(.text+0x18a3): In function `gp_cairo_enhanced_flush':
wxterminal/gp_cairo.c:1202: undefined reference to `pango_cairo_create_layo=
ut'
gp_cairo.o(.text+0x19a5):wxterminal/gp_cairo.c:1167: undefined reference to=
=20
`pango_cairo_create_layout'
gp_cairo.o(.text+0x19f0):wxterminal/gp_cairo.c:1175: undefined reference to=
=20
`pango_cairo_create_layout'
gp_cairo.o(.text+0x1bf1):wxterminal/gp_cairo.c:1101: undefined reference to=
=20
`pango_cairo_create_layout'
gp_cairo.o(.text+0x1dc7):wxterminal/gp_cairo.c:1124: more undefined referen=
ces=20
to `pango_cairo_create_layout' follow
gp_cairo.o(.text+0x2ec6): In function `gp_cairo_draw_enhanced_text':
wxterminal/gp_cairo.c:1391: undefined reference to `pango_cairo_update_layo=
ut'
gp_cairo.o(.text+0x2ed5):wxterminal/gp_cairo.c:1392: undefined reference to=
=20
`pango_cairo_show_layout'
gp_cairo.o(.text+0x3c9a): In function `gp_cairo_draw_text':
wxterminal/gp_cairo.c:637: undefined reference to `pango_cairo_create_layou=
t'
gp_cairo.o(.text+0x3e6a):wxterminal/gp_cairo.c:690: undefined reference to=
=20
`pango_cairo_update_layout'
gp_cairo.o(.text+0x3e79):wxterminal/gp_cairo.c:691: undefined reference to=
=20
`pango_cairo_show_layout'
collect2: ld returned 1 exit status
make[1]: *** [gnuplot] Fehler 1


Is this a problem with the installation of the libs?


Juergen

Re: bivariat.dem fails when run from all.dem

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

On Friday 07 July 2006 12:44 am, Daniel J Sebald wrote:
>>
>> Then running bivariat.dem:
>>
>> gnuplot> int1a(x,d) = (x<=d*.1) ? 0 :
>> (int1a(x-d,d)+(f(x-d)+4*f(x-d*.5)+f(x))*d/6.) ^
>>          "bivariat.dem", line 24: requires 3 variables
>>
>> It is later that bivariat.dem redefines f() to be a two variable
>> function.
>>
>> So, the question is, is the above error message the desired behavior?
>>  Or should gnuplot wait until evaluation time *only* to complain?

>Comment By: Hans-Bernhard Broeker (broeker)
> Date: 2006-07-07 23:52

> No.  It represents excess strictness.

I agree.

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

Re: 4.2pre-whatever builds OK on VMS

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

Ethan Merritt wrote:
> On Friday 07 July 2006 01:08 am, Daniel J Sebald wrote:
> 
>>Ethan A Merritt wrote:
>>
>>>2) The column-stacked histogram demo has some missing boxes.
>>>I vaguely recall encountering that once before, but I can't
>>>remember what it turned out to be.  Maybe some browsing through
>>>ChangeLog.
>>
>>This one is not VMS related.  I see the missing boxes in both X11 and
>>PostScript.  I don't recall seeing this except only recently.
> 
> 
> Sigh.
> 
> So it's something that broke very recently.
> That's the danger of this mad dash to close out all bug reports
> before a release.  The fixes can have unintended side effects
> that are worse than the original problem.

Yes.  But I think the process is going very well.  We've been discovering and fixing a lot of things that would have been problematic to the release.

> 
> I wonder if it's somehow related to NaN / DF_MISSING...

That is exactly what I was thinking.  So maybe that is a good place to start.  Attached are the two problematic plots.

Dan

Re: 4.2pre-whatever builds OK on VMS

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

On Friday 07 July 2006 01:08 am, Daniel J Sebald wrote:
> Ethan A Merritt wrote:
> > 2) The column-stacked histogram demo has some missing boxes.
> > I vaguely recall encountering that once before, but I can't
> > remember what it turned out to be.  Maybe some browsing through
> > ChangeLog.
>
> This one is not VMS related.  I see the missing boxes in both X11 and
> PostScript.  I don't recall seeing this except only recently.

Sigh.

So it's something that broke very recently.
That's the danger of this mad dash to close out all bug reports
before a release.  The fixes can have unintended side effects
that are worse than the original problem.

I wonder if it's somehow related to NaN / DF_MISSING...

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

Re: Something overlooked in multimesh.dem?

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

Daniel J Sebald wrote:

> I was paging through PostScript versions of all.dem and noticed one
> of the whale plots uses points.  I'm OK with that, if that is what
> was intended.  Looks slightly odd and inconsistent with the rest of
> the demo, so I'm just wondering if
> 
> splot "whale.dat" index 12 with points
> 
> is what the programmer originally intended.

Yes.  He actually spelled out 'with points', so that's what he wanted.

And if he didn't, then he's kept remarkably quiet about it for about a 
decade...

Re: 4.2pre-whatever builds OK on VMS

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

Ethan A Merritt wrote:
> I've just built and tested the current cvs version on VMS.
> I can't test x11 because it's a remote machine with no X connection
> available, but 'all.dem' run through 'set term post color solid'
> looks almost perfect.  
> 
> Only two glitches:

> 2) The column-stacked histogram demo has some missing boxes.
> I vaguely recall encountering that once before, but I can't
> remember what it turned out to be.  Maybe some browsing through
> ChangeLog.

This one is not VMS related.  I see the missing boxes in both X11 and PostScript.  I don't recall seeing this except only recently.

Dan

Something overlooked in multimesh.dem?

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

I was paging through PostScript versions of all.dem and noticed one of the whale plots uses points.  I'm OK with that, if that is what was intended.  Looks slightly odd and inconsistent with the rest of the demo, so I'm just wondering if

splot "whale.dat" index 12 with points

is what the programmer originally intended.

Dan

bivariat.dem fails when run from all.dem

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

(from sourceforge)

When bivariat.dem is run from all.dem there is a failure.  The reason is a previous definition of f() from stat.inc which does not have the same number of inputs as f() used in the definitions in bivariat.dem.

At the point of calling bivariat.dem f() is defined as:

f(x,d1,d2)=d1<=0||!isint(d1)||d2<=0||!isint(d2)?1/0:  Binv(0.5*d1,0.5*d2)*(real(d1)/d2)**(0.5*d1)*x**(0.5*d1-1.0)/(1.0+(real(d1)/d2)*x)**(0.5*(d1+d2))

Then running bivariat.dem:

gnuplot> int1a(x,d) = (x<=d*.1) ? 0 : (int1a(x-d,d)+(f(x-d)+4*f(x-d*.5)+f(x))*d/6.)
                                                          ^
         "bivariat.dem", line 24: requires 3 variables

It is later that bivariat.dem redefines f() to be a two variable function.



So, the question is, is the above error message the desired behavior?  Or should gnuplot wait until evaluation time *only* to complain?



If the list decides it is only at evaluation time, not also parse time, that number of variables should be checked then the attached patch will fix the problem.

I've verified that gnuplot still catches inconsistent input arguments if the problem exists.  It looks as follows:

gnuplot> load 'bivariat.dem
         "bivariat.dem", line 42: function f requires 3 variables

Dan

Re: Build problem

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

>> > wiefer@localhost:~> rpm -qa |grep -i wx
>> > wxGTK-2.5.3.1-5
>> > wxGTK-gl-2.5.3.1-5
>> > wxGTK-compat-2.5.3.1-5
>> > wxGTK-devel-2.5.3.1-5
>>
>> Well, these are outdated (and by the way 2.5.x are development version=
s)
>> but they may be enough for the wxWidgets terminal.
>
> I just tried.  The ./configure script went fine.  But during
> compile, I got:
>
> wxterminal/wxt_gui.cpp: In member function `void
>    wxtPanel::DrawToDC(wxWindowDC&, wxRegion&)':
> wxterminal/wxt_gui.cpp:588: error: no matching function for call to `
>    wxBufferedDC::Init(wxWindowDC*)'
> /usr/include/wx-2.5/wx/dcbuffer.h:60: error: candidates are: void
>    wxBufferedDC::Init(wxDC*, const wxBitmap&)
> /usr/include/wx-2.5/wx/dcbuffer.h:69: error:                 void
>    wxBufferedDC::Init(wxDC*, const wxSize&)

Hi Juergen,

This turned out to be an interesting information. I was obviously relying
on an undocumented behaviour so that Init(wxWindowDC*) was working,
whereas it is absent from the wxWidgets manual, even from 2.6.x

I solved that problem in the CVS, so if you want you can try again and
report other interesting bits like those ones ;-)

Regards,

Timoth=E9e

Re: calling all computers, 4.2 odds and ends

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

On Thursday 06 July 2006 01:59 pm, Daniel J Sebald wrote:
> James R. Van Zandt wrote:
> >>  3) Please ask Jim Van Zandt if his 'bivariat.dem' patch is ready.
> >>     There are currently some quite inaccurate plots in the CVS
> >>     version of that demo.
> >
> > As far as I'm concerned, the version I just posted can go in.
>
> Should I post this to SourceForge patches?

This is the one posted to the list on 21 June 2006?
I've got that one, and can put it in CVS.
There's a minor glitch ('set key' syntax), but I can fix that.

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

Re: calling all computers, 4.2 odds and ends

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

James R. Van Zandt wrote:
>>  3) Please ask Jim Van Zandt if his 'bivariat.dem' patch is ready.
>>     There are currently some quite inaccurate plots in the CVS
>>     version of that demo.
> 
> 
> As far as I'm concerned, the version I just posted can go in.

Should I post this to SourceForge patches?

Dan

Re: pslatex.trm: useless \colorgray into tex file

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

Ethan A Merritt wrote:
> On Wednesday 05 July 2006 10:59 pm, Daniel J Sebald wrote:
> 
>>>>There seems to be a bug: EPSLATEX_set_color() produces many many 
>>>>\colorgray{} commands into output .tex file, which are completely useless, 
>>>>because color for filled rectangles is set directly in .eps file.
>>
>>Note my email from a couple days ago.  
>>Perhaps begin by looking at this strange defined-out line of code: 
> 
> 
> Wrong driver. We're talking about the *.tex output from pslatex.trm

True.  However, I've a feeling that post.trm and pslatex.trm behave in a similar fashion, and if pslatex.trm goes down the path post.trm appears to have gone, it could end up a similarly tangled web.



> 
>>#if 0
>>    /*  In order to make 'PS_linewidth' work properly, I need to comment
>>     *  this line out.  Especially in combination with the line width
>>     *  extension of the `set arrow` command this is necessary.
>>     *  Can we live with that drawback?  (JFi)
>>     */
>>    if (PS_linetype_last == linetype) return;
>>#endif
> 
> 
> But I agree that this comment is probably obsolete.
> I tested re-enabling this test quite a while back, and found no problems.
> But also it didn't produce any substantial saving in the output file size,
> so I left it alone.  We can look at it again later.

It's noticable.  Not huge, say 15-20% in that eg7.plt example.  But the bottom line is that there seems to be a lot of unnecessary repetition in PostScript output instructions and pslatex instructions.

Seeing this in a few places makes me worry.

    PS_linewidth_last = PS_linetype_last =  -1; /* force next linetype change */

It isn't the fact that there are some "state variables", it is where they are placed, e.g., after doing _point() or _fillbox().

I wonder if it is some property of PostScript interpretation that is driving that, or someone has used this as an inappropriate solution to a problem.

...

Thinking of what you and I looked at the other week, Ethan, (that issue with needing the palette at the start of every page otherwise jumping around nonlinearly in "gv" produces incorrect results) I wonder if there are similar problems with LT0, etc... That is, if it isn't the case that LT? were not written every time before line draw.

It seems to me that the PostScript like drivers should have a whole group of "state variables" to account for the fact that we don't want to put commands on a PS page unless needed.  Say for example, if the page doesn't need a palette, then we don't want a palette command at the start of that page.  So, let's say we have

   bool page_palette_specified;
   bool page_linetype_specified;
   bool page_linewidth_specified;
   etc.

Whenever, PS_graphic() is called, it sets

   page_palette_specified = 0;
   page_linetype_specified = 0;
   page_linewidth_specified = 0;
   etc.

Then, at the start of every terminal routine there is a call to some routine, say

   require_property(PALETTE | LINETYPE);

and require_property will check if those have been specified yet, if not call the appropriate routines with the previous contents.

Without going into too much more detail, I hope I've gotten my point across, which is the idea of having an organized set of state variables.

Right now, it seems the concept is to count on the core routine having called the necessary property beforehand and creatively using  PS_linewidth_last = PS_linetype_last =  -1; and such.  I think state variables would be much more effective.  In some sense, that is what PS_linewidth_last, etc. are, state variables, but it approaching things from an unusual way.


>>Also, could this bug have something to do with bug report: 
>>[ 1512210 ] buffer overflow using pgnuplot
> 
> 
> Nope.

I'm not so sure...  I don't have a good feeling about this one.

Dan

Re: Idea: env-mapping for dataplot over pipes

[Tino W. <ti...@wi...>]

Ethan A Merritt schrieb:
> On Wednesday 05 July 2006 03:54 am, Tino Wildenhain wrote:
> 
>>Petr Mikulik schrieb:
>>
>>>Since very recently, you can
>>>    print GPVAL_X_MIN, GPVAL_X_MAX, GPVAL_Y_MIN, GPVAL_Y_MAX
>>>and let your driving application to read it. See also 'help set print' 
>>>and "bidirectional" examples on gnuplot web page.
>>
>>But this looks as if my application would have to
>>run gnuplot in popen() and not vice versa?
> 
> 
> No, you have that backwards.
> It is only possible to set environmental variables for
> your current process, or for a child process. Not for a parent.

well it wasnt me who got this backwards ;) I know I can
only set vars for current process (and therefore childs)
> 
>>Currently I run a number of scripts in plot
>>where each script delivers data for a part graph.
>>
>>It would be nice to be able to access these values
>>from the script which runs inside
>>
>>plot "<script"
> 
> 
> Right. That you can do, for instance by passing the values as
> script parameters:
> 
>   command1 = sprintf("< scriptname  %g %g",GPVAL_X_MIN,GPVAL_X_MAX)
>   plot command1 with lines

Ah, now thats interesting! I guess I fetch the current
sources and try again.

Regards
Tino

Re: pslatex.trm: useless \colorgray into tex file

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

On Wednesday 05 July 2006 10:59 pm, Daniel J Sebald wrote:
> >>There seems to be a bug: EPSLATEX_set_color() produces many many 
> >>\colorgray{} commands into output .tex file, which are completely useless, 
> >>because color for filled rectangles is set directly in .eps file.
> 
> Note my email from a couple days ago.  
> Perhaps begin by looking at this strange defined-out line of code: 

Wrong driver. We're talking about the *.tex output from pslatex.trm
 
> #if 0
>     /*  In order to make 'PS_linewidth' work properly, I need to comment
>      *  this line out.  Especially in combination with the line width
>      *  extension of the `set arrow` command this is necessary.
>      *  Can we live with that drawback?  (JFi)
>      */
>     if (PS_linetype_last == linetype) return;
> #endif

But I agree that this comment is probably obsolete.
I tested re-enabling this test quite a while back, and found no problems.
But also it didn't produce any substantial saving in the output file size,
so I left it alone.  We can look at it again later.
 
> Also, could this bug have something to do with bug report: 
> [ 1512210 ] buffer overflow using pgnuplot

Nope.

> crashes if gnuplotfile.gnuplot
> contains a lot of postscript plots from datafiles

Again - not the same driver.

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

Re: pslatex.trm: useless \colorgray into tex file

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

Ethan A Merritt wrote:
> On Tuesday 04 July 2006 01:20 pm, Petr Mikulik wrote:
> 
>>Currently, "make tutorial" fails due to "TeX capacity exceeded".
>>
>>Reason: try
>> 	gnuplot eg7.plt
>>
>>There seems to be a bug: EPSLATEX_set_color() produces many many 
>>\colorgray{} commands into output .tex file, which are completely useless, 
>>because color for filled rectangles is set directly in .eps file.
> 
> 
> Ugh.
> It's worse than that.

Note my email from a couple days ago.  Perhaps begin by looking at this strange defined-out line of code:

#if 0
    /*  In order to make 'PS_linewidth' work properly, I need to comment
     *  this line out.  Especially in combination with the line width
     *  extension of the `set arrow` command this is necessary.
     *  Can we live with that drawback?  (JFi)
     */
    if (PS_linetype_last == linetype) return;
#endif

Again, we probably shouldn't be getting _linetype() called so often, but I don't know if that can be addressed before 4.2.

Also, could this bug have something to do with bug report:

[ 1512210 ] buffer overflow using pgnuplot

?  This says:

pgnuplot < gnuplotfile.gnuplot
crashes if gnuplotfile.gnuplot
contains a lot of postscript plots from datafiles
(in my case 20 were enough)

which sounds like the person means they are attempting to create some PostScript plot.  Maybe the system is trying to create bloated PostScript plots and is running out of buffered memory.

Dan

Re: pslatex.trm: useless \colorgray into tex file

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

On Tuesday 04 July 2006 01:20 pm, Petr Mikulik wrote:
> Currently, "make tutorial" fails due to "TeX capacity exceeded".
> 
> Reason: try
>  	gnuplot eg7.plt
> 
> There seems to be a bug: EPSLATEX_set_color() produces many many 
> \colorgray{} commands into output .tex file, which are completely useless, 
> because color for filled rectangles is set directly in .eps file.

Ugh.
It's worse than that.

The *.tex file is full of these useless color commands that belong to
the postscript half.

Similarly the *.eps file is full of thousands of useless triplets:
  LT0
  2715 2933 M
  stroke
  LT0
  2719 2865 M
  stroke
  [ repeat 6000 times ]

Net result: nothing.
OK, this goes to the top of the must-fix list.

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

Re: Idea: env-mapping for dataplot over pipes

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

On Wednesday 05 July 2006 03:54 am, Tino Wildenhain wrote:
> Petr Mikulik schrieb:
> > 
> > Since very recently, you can
> >     print GPVAL_X_MIN, GPVAL_X_MAX, GPVAL_Y_MIN, GPVAL_Y_MAX
> > and let your driving application to read it. See also 'help set print' 
> > and "bidirectional" examples on gnuplot web page.
> 
> But this looks as if my application would have to
> run gnuplot in popen() and not vice versa?

No, you have that backwards.
It is only possible to set environmental variables for
your current process, or for a child process. Not for a parent.
 
> Currently I run a number of scripts in plot
> where each script delivers data for a part graph.
> 
> It would be nice to be able to access these values
> from the script which runs inside
> 
> plot "<script"

Right. That you can do, for instance by passing the values as
script parameters:

  command1 = sprintf("< scriptname  %g %g",GPVAL_X_MIN,GPVAL_X_MAX)
  plot command1 with lines


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