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

Re: What's left for a 4.2 release?

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

>
> This attempts to be a complete list of unresolved issues that I see
> as release-critical.   It's a very short list.

I've run through things on OS X and realized that aqua is missing the  
following vital part, although Ethan pointed it out previously:

> The term->set_font() routines have all been standardized to
> accept the form   "FontFace,FontSize"   i.e. the face and
> the size are comma-separated in a single string.  I have
> been gradually updating the various "set term <foo> font
> <baz>" routines to accept the same form, but in all cases
> have left the previous syntax active for backwards
> compatibility.

I'll fix it ASAP, hopefully today.

/Per

Re: Build problem

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

Daniel J Sebald wrote:
> Ethan A Merritt wrote:
>>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.
> 
> 
> That's the warning?  Just yank out that function.

Oh, that's what you did ostensibly.  Sorry.  Looks good.

Dan

Re: Build problem

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

Timoth=E9e Lecomte wrote:

> The warnings about wxt.trm and gp_cairo.c are false alarms, but I will=20
> initialize the variables to avoid the warnings.

I've had to do this too... when I remember the -Wall, that is.  I'm going=
 to give this annoying warning some credit though, because I think it has=
 caught one or two things for me.

Dan

Re: Build problem

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

Ethan A Merritt wrote:
> 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.

That's the warning?  Just yank out that function.  Trying to revert is a lot of effort.  Keep the test that verifies the number of input arguments at interpretation time.

What we could have done for the parse-time test was to change it from int_error() to int_warn().  In some sense that is a good warning... and if the user intended to redefine a function, he or she can say back to the screen "I know that, gnuplot!"

Dan

Re: What's left for a 4.2 release?

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

Ethan Merritt wrote:
> Patches
> =3D=3D=3D=3D=3D=3D=3D=3D
>
> #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.
>
> 	On the other hand, maybe this isn't really release critical.
> 	If it can be fixed by providing a Windows installer bundle,
> 	then we could freeze and release now, and add a bundled=20
> 	installer on the "Files" page afterwards.
>  =20
The Windows-specific code is in my patch.

If you are sure that other platforms are ok with GNUPLOT_PS_DIR (I doubt=20
OS/2 is), then just take my patch without the "#ifndef GNUPLOT_PS_DIR",=20
without the *.h and without the script.

Timoth=E9e

What's left for a 4.2 release?

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

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.


Patches
========

#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.

	On the other hand, maybe this isn't really release critical.
	If it can be fixed by providing a Windows installer bundle,
	then we could freeze and release now, and add a bundled 
	installer on the "Files" page afterwards.

#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.


Documentation
=============

#######	 Nothing in particular. Just a thorough check to make sure
	we are properly describing the new version.


Feature Requests
================

#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.

#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?


			Ethan


The relevant #defines in config.h are

/* Define to enable parsing of deprecated syntax */
#define BACKWARDS_COMPATIBLE 1

/* Define if you want to support files in binary format. */
#define BINARY_DATA_FILE 1

/* Define to allow reading strings from datafiles */
#define EAM_DATASTRINGS 1

/* Define to enable histograms plot style. */
#define EAM_HISTOGRAMS 1

/* Define to allow placement of rectangles and other objects */
#define EAM_OBJECTS 1

/* Define to allow 'fit' to create parameter error variables. */
#define GP_FIT_ERRVARS 1

/* Define to allow command line macros. EXPERIMENTAL */
#define GP_MACROS 1

/* Define to allow string variables. */
#define GP_STRING_VARS 2

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

/* Define to enable handling point size in hidden3d code. */
#define HIDDEN3D_VAR_PTSIZE 1

/* Define if you want to have image plotting support. */
#define WITH_IMAGE 1



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

Re: Build problem

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

On Monday 10 July 2006 03:09 pm, Timoth=C3=A9e Lecomte wrote:
> Hmm. You must have missed a part of the changelog a month ago :

So sorry.  You're right, I completely missed that.
Great, so the demo works on both x11 and wxt.
And one more item can be crossed off my TODO list for 4.2

> ! A little remark : when hitting ESC to quit the demo, the command
> prompt 'gnuplot>' does not come back, I have to hit ctrl-c (both wxt
> and x11).

Hmm. You're right about the prompt.=20
But I don't have to hit ctrl-c;   a simple <cr> is sufficient.
This is an old, old problem when mixing terminal input and
mouse-channel input.  I have never found a general solution,
although it may be possible to provide an explicit reset command
of some sort that could be called from a script like this one
when it is known in advance that the problem will be triggered.



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

Re: Build problem

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

Ethan Merritt wrote:
> Wxt still needs a mechanism to disable the trapping of "q" and
> "space" as special cases, right?  I've been holding off on adding
> an interactive label-placement demo because it fails on wxt.
> But I'll go ahead and add it in the hope that it makes clear why
> such a feature is needed.
>
> mouselabels.dem  (now in cvs)
>
> Give it a try under x11, and then see how unusable it is under wxt
> because of the 'q' and '<space>' trapping.
>  =20
Hmm. You must have missed a part of the changelog a month ago :

2006-06-17  Timothee Lecomte  <tim...@en...>

    (...)
    (wxtPanel::OnKeyEvent):
    (wxt_init):
    (wxtConfigDialog):
    New variable wxt_ctrl to handle 'q' and <space>.
    (...)

    * term/wxt.trm (wxt_options): New terminal option '{no}ctrl'.
    (TERM_HELP): Updated.

I have just tried and it.... is great ! How powerful these demos are !
A little remark : when hitting ESC to quit the demo, the command prompt=20
'gnuplot>' does not come back, I have to hit ctrl-c (both wxt and x11).

Best regards,

Timoth=C3=A9e

Re: Build problem

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

On Monday 10 July 2006 01:53 pm, Timoth=C3=A9e Lecomte wrote:
> > Just curious: Will there be a smoother integration of the mousing
> > features into the GUI?
>
> Well, if you have a precise idea, I'm all ears. For 4.2 it will
> definitely stay like that, i.e. the same mouse behaviour as other
> terminals plus the few icons in the toolbar. But if we can make it
> better, we should try !

Wxt still needs a mechanism to disable the trapping of "q" and
"space" as special cases, right?  I've been holding off on adding
an interactive label-placement demo because it fails on wxt.
But I'll go ahead and add it in the hope that it makes clear why
such a feature is needed.

mouselabels.dem  (now in cvs)

Give it a try under x11, and then see how unusable it is under wxt
because of the 'q' and '<space>' trapping.


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

Re: Build problem

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

Juergen Wieferink wrote:
> On Monday 10 July 2006 22:53 Timoth=C3=A9e Lecomte wrote:
>  =20
>> Juergen Wieferink wrote:
>>    =20
>>> Just curious: Will there be a smoother integration of the mousing
>>> features into the GUI?
>>>      =20
>> Well, if you have a precise idea, I'm all ears. For 4.2 it will
>> definitely stay like that, i.e. the same mouse behaviour as other
>> terminals plus the few icons in the toolbar. But if we can make it
>> better, we should try !
>>    =20
>
> Hmm....  The problem I have is that I cannot remember all the keys.
> If the message, which is displayed with 'h' would also show up
> directly in the help dialog, I would already be helped.=20
Agreed. It needs too much work for 4.2, because this help message is=20
entangled with the 'bind' system, but it seems worthwile.
> I feel quite uncomfortable with the output to the terminal while mousin=
g
> because I generally keep terminal windows at 80x25.
I don't understand what you mean here.
> And I'd like the 'verbose' message to show up also in the status bar...
>  =20
Again, it  needs too much work for 4.2, but makes sense.
I will write that in my to-do list !

Best regards,

Timoth=C3=A9e

Re: Build problem

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

On Monday 10 July 2006 22:53 Timoth=C3=A9e Lecomte wrote:
> Juergen Wieferink wrote:
> > Just curious: Will there be a smoother integration of the mousing
> > features into the GUI?
>
> Well, if you have a precise idea, I'm all ears. For 4.2 it will
> definitely stay like that, i.e. the same mouse behaviour as other
> terminals plus the few icons in the toolbar. But if we can make it
> better, we should try !

Hmm....  The problem I have is that I cannot remember all the keys.
If the message, which is displayed with 'h' would also show up
directly in the help dialog, I would already be helped.  I feel
quite uncomfortable with the output to the terminal while mousing
because I generally keep terminal windows at 80x25.  And I'd like
the 'verbose' message to show up also in the status bar...

Just my few cents.

Thanks again,
Juergen

Re: Build problem

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

Juergen Wieferink wrote:
> On Sunday 09 July 2006 22:11 Timoth=C3=A9e Lecomte wrote:
>  =20
>> Juergen Wieferink wrote:
>>    =20
>>> Terminal type set to 'wxt'
>>> gnuplot> plot sin(x)
>>> Error reading Pango modules file
>>>
>>> (<unknown>:17660): Pango-WARNING **: No builtin or dynamically loaded
>>> modules were found. Pango will not work correctly. This probably mean=
s
>>> there was an error in the creation of:
>>>   '/usr/local/etc/pango/pango.modules'
>>> You may be able to recreate this file by running pango-querymodules.
>>>      =20
>
>  =20
>> Have you tried to run 'pango-querymodules' ? It may tell you why it di=
d
>> not find the so-called modules.
>> Attached is my file to let you know what you are expecting.
>>    =20
>
> Well, I tried somehow...  I typed "pango-q" and hit tab twice and
> was getting nothing because it was not yet in the hash, probably.  I
> thought that this was because missing priveleges and got root.  And
> also root did not know pango-querymodules.  Because /usr/local/bin
> is not in the path of root.  Maybe this is the reason
> /usr/local/etc/pango/pango.modules was empty.
>
> Finally, I piped the output of pango-querymodules into
> /usr/local/etc/pango/pango.modules and there you are, it works!
> Really cool look and feel, congrats!!!  And thanks for your efforts
> to get it to work on machines like mine. ;-)
>  =20
You're welcome. I am glad you've succeeded, and your reports really made=20
me fix problems that may have annoyed others. And the howto you wrote is=20
just a good idea (and I am happy it is not longer ;-) ). Thank you !
> Just curious: Will there be a smoother integration of the mousing
> features into the GUI?
>  =20
Well, if you have a precise idea, I'm all ears. For 4.2 it will=20
definitely stay like that, i.e. the same mouse behaviour as other=20
terminals plus the few icons in the toolbar. But if we can make it=20
better, we should try !

Best regards,

Timoth=C3=A9e

Re: Build problem

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

On Sunday 09 July 2006 22:11 Timoth=C3=A9e Lecomte wrote:
> Juergen Wieferink wrote:
> > Terminal type set to 'wxt'
> > gnuplot> plot sin(x)
> > Error reading Pango modules file
> >
> > (<unknown>:17660): Pango-WARNING **: No builtin or dynamically loaded
> > modules were found. Pango will not work correctly. This probably means
> > there was an error in the creation of:
> >   '/usr/local/etc/pango/pango.modules'
> > You may be able to recreate this file by running pango-querymodules.

> Have you tried to run 'pango-querymodules' ? It may tell you why it did
> not find the so-called modules.
> Attached is my file to let you know what you are expecting.

Well, I tried somehow...  I typed "pango-q" and hit tab twice and
was getting nothing because it was not yet in the hash, probably.  I
thought that this was because missing priveleges and got root.  And
also root did not know pango-querymodules.  Because /usr/local/bin
is not in the path of root.  Maybe this is the reason
/usr/local/etc/pango/pango.modules was empty.

=46inally, I piped the output of pango-querymodules into
/usr/local/etc/pango/pango.modules and there you are, it works!
Really cool look and feel, congrats!!!  And thanks for your efforts
to get it to work on machines like mine. ;-)

Just curious: Will there be a smoother integration of the mousing
features into the GUI?




JFTR:

*Howto* get the wxWidgets terminal of gnuplot working on SuSE
9.3 (the problem are missing libraries):

* install the *-devel rpms of the glib and of gtk2
* build and install cairo-1.2=20
* build and pango-1.10=20
    the latest version will not work because of the glib dependence
* make sure that /usr/local/etc/pango/pango.modules is valid
  run `pango-querymodules' and pipe the output into the above file
  if neccessary.
* configure, build and install gnuplot
* have fun!


Thanks again for a great piece of work,
Juergen

Re: Build problem

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

On Monday 10 July 2006 12:43 am, Timoth=C3=A9e Lecomte wrote:
> Ethan A Merritt wrote:
> > Furthermore, to the extent that these various character sets are
> > all implemented via UTF-8,  why would one need separate modules
> > anyhow?
>
> Then, Pango and text rendering in general is not only about drawing
> individual characters. It is about glyphs, layout, typography and I
> should maybe add calligraphy. And this goes very language-specific.
> Arab for example needs the glyphs to be joint together, and the same
> character at the end or in the middle of a word would be drawn as a
> different glyph.

That make sense.  I am not familiar with the orthography of all the
modules in that list, but it does seem likely that some
languages would require extra rules for placement and connection
of adjacent letters.  Of course, even English othography does that to=20
some extent via font kerning.

> Maybe Chinese and Japanese don't need those special
> modules, because the typography is closer to occidental languages
> (one character in utf8=3D one glyph in the output, always the same ?).

Some fonts vary by a factor of 2 in character width, but I doubt that
simple test would require a specialized module.  On the other hand,
x11 gets it wrong without external help, so maybe it's trickier than
it would seem.


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

Bug in logarithmic minitics + suggested fix

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

Hello everyone!

I found a bug in Gnuplot CVS logarithmic axis minitics in certain
user-controlled minitic settings when I was plotting a logarithmic graph
with rather long range today.  The following short script highlights the
problem:

set logscale y
set ytics 10
set mytics 10
plot [0:1e3] [1:1e10] x**3
pause -1
set ytics 100
set mytics 10
plot [0:1e3] [1:1e10] x**3
pause -1

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?  So, I hurried through the Gnuplot CVS source and found a solution
(patch attached).  However, I'm not sure whether or not there are any
problems that I might have overlooked, so could someone who understands
the axis system check the problem and the patch, please?  Particularly,
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).  As a bonus, the patch fixes a typo in comment, "but" should
probably be "bug".  :-)

Best Regards, and thanks for the good plotting program
Aapo Lankinen



--- src/axis.c  2006-07-10 19:32:44.000000000 +0300
+++ src/axis.c  2006-07-10 19:35:19.000000000 +0300
@@ -976,9 +976,9 @@
                    minitics = 0;       /* not much else we can do */
                else if (axis_array[axis].log) {
                    /* Sep 2005 - This case has been commented out since v3.7 */
-                   /* but in fact it seems correct, and fixes but #1223149 */
-                   ministart = ministep = step / minifreq * axis_array[axis].base;
-                   miniend = step * axis_array[axis].base;
+                   /* but in fact it seems correct, and fixes bug #1223149 */
+                   ministart = ministep = AXIS_UNDO_LOG(axis,step) / minifreq;
+                   miniend = AXIS_UNDO_LOG(axis,step);
                } else {
                    ministart = ministep = step / minifreq;
                    miniend = step;
@@ -1137,7 +1137,7 @@
                                             internal + mplace);
                    else
                        mtic = internal
-                           + (axis_array[axis].log && step <= 1.5
+                           + (axis_array[axis].log
                               ? AXIS_DO_LOG(axis,mplace)
                               : mplace);
                    if (inrange(mtic, internal_min, internal_max)

Re: Build problem

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

Ethan A Merritt wrote:
> On Sunday 09 July 2006 01:11 pm, Timoth=C3=A9e Lecomte wrote:
>  =20
>>> The file /usr/local/etc/pango/pango.modules actually exists, but is
>>> empty apart from comments.
>>>      =20
>> Have you tried to run 'pango-querymodules' ? It may tell you why it di=
d=20
>> not find the so-called modules.
>>    =20
>
> So now I'm curious.=20
> What, exactly, is this modules list supposed to tell us?
>
> The list on my machine looks very much like the one on yours.
> The curious thing is that Japanese/Chinese character support is
> listed nowhere in it. Why is this curious? Because my machine is in fac=
t
> configured for Japanese, and the Chinese characters are rendered nicely
> in wxWidgets.  So at the least it seems the module list is an
> incomplete description of the actual capabilities.
>  =20
> Furthermore, to the extent that these various character sets are all
> implemented via UTF-8,  why would one need separate modules anyhow?
>  =20
First, it can be either in modules or builtin (which *may* explain why=20
Juergen has an empty file). And it is probably possible to configure=20
that when you compile Pango, for example by removing this modules for an=20
embedded platform.

Then, Pango and text rendering in general is not only about drawing=20
individual characters. It is about glyphs, layout, typography and I=20
should maybe add calligraphy. And this goes very language-specific. Arab=20
for example needs the glyphs to be joint together, and the same=20
character at the end or in the middle of a word would be drawn as a=20
different glyph. I guess Pango uses modules to handle these=20
particularities. Maybe Chinese and Japanese don't need those special=20
modules, because the typography is closer to occidental languages (one=20
character in utf8=3D one glyph in the output, always the same ?).

Best regards,

Timoth=C3=A9e

Re: Build problem

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

On Sunday 09 July 2006 01:11 pm, Timoth=C3=A9e Lecomte wrote:
> > The file /usr/local/etc/pango/pango.modules actually exists, but is
> > empty apart from comments.
> Have you tried to run 'pango-querymodules' ? It may tell you why it did=20
> not find the so-called modules.

So now I'm curious.=20
What, exactly, is this modules list supposed to tell us?

The list on my machine looks very much like the one on yours.
The curious thing is that Japanese/Chinese character support is
listed nowhere in it. Why is this curious? Because my machine is in fact
configured for Japanese, and the Chinese characters are rendered nicely
in wxWidgets.  So at the least it seems the module list is an
incomplete description of the actual capabilities.

=46urthermore, to the extent that these various character sets are all
implemented via UTF-8,  why would one need separate modules anyhow?

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

Re: Build problem

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

Juergen Wieferink wrote:
> Hi Timoth=E9e,
>
>  =20
>> I guess you have gtk+ 2.6, not 2.8 or later. That's fine in terms of
>>    =20
>
> wiefer@localhost:~> rpm -qa |grep -i gtk2
> gtk2-devel-2.6.4-6.3
> gtk2-2.6.4-6.3
>
>  =20
>> what we need for the wxWidgets terminal. However, gtk+ 2.8 is dependan=
t
>> on cairo, and was magically adding the '-lpangocairo' flag. gtk+ 2.6
>> does not depend on cairo, hence the missing flag. I've fixed that in
>> CVS. Please try to see if the problem is fixed.
>>    =20
>
> Yes, compiles and links fine.
>  =20
Good !
>  =20
>> Well, so far your experience and your reports have been really fruitfu=
l,
>> thank you very much, and please go on ;-)
>>    =20
>
> Thanks.  But now to the next riddle:
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D8<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> (...)
>
> Terminal type set to 'wxt'
> gnuplot> plot sin(x)
> Error reading Pango modules file
>
> (<unknown>:17660): Pango-WARNING **: No builtin or dynamically loaded m=
odules
> were found. Pango will not work correctly. This probably means
> there was an error in the creation of:
>   '/usr/local/etc/pango/pango.modules'
> You may be able to recreate this file by running pango-querymodules.
>
> (...)
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>8=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> The file /usr/local/etc/pango/pango.modules actually exists, but is
> empty apart from comments.
Have you tried to run 'pango-querymodules' ? It may tell you why it did=20
not find the so-called modules.
Attached is my file to let you know what you are expecting.

Best regards,

Timoth=E9e

Re: Build problem

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

Hi Timoth=E9e,

> I guess you have gtk+ 2.6, not 2.8 or later. That's fine in terms of

wiefer@localhost:~> rpm -qa |grep -i gtk2
gtk2-devel-2.6.4-6.3
gtk2-2.6.4-6.3

> what we need for the wxWidgets terminal. However, gtk+ 2.8 is dependant
> on cairo, and was magically adding the '-lpangocairo' flag. gtk+ 2.6
> does not depend on cairo, hence the missing flag. I've fixed that in
> CVS. Please try to see if the problem is fixed.

Yes, compiles and links fine.

> Well, so far your experience and your reports have been really fruitful,
> thank you very much, and please go on ;-)

Thanks.  But now to the next riddle:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D8<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


        G N U P L O T
        Version 4.1 patchlevel 0
        last modified July 2006
        System: Linux 2.6.11.4-21.12-default

        Copyright (C) 1986 - 1993, 1998, 2004
        Thomas Williams, Colin Kelley and many others

        Type `help` to access the on-line reference manual.
        The gnuplot FAQ is available from
                http://www.gnuplot.info/faq/

        Send comments and help requests to =20
<gnu...@li...>
        Send bug reports and suggestions to=20
<gnu...@li...>


Terminal type set to 'wxt'
gnuplot> plot sin(x)
Error reading Pango modules file

(<unknown>:17660): Pango-WARNING **: No builtin or dynamically loaded modul=
es
were found. Pango will not work correctly. This probably means
there was an error in the creation of:
  '/usr/local/etc/pango/pango.modules'
You may be able to recreate this file by running pango-querymodules.

(<unknown>:17660): Pango-CRITICAL **: _pango_engine_shape_shape: assertion=
=20
`PANGO_IS_FONT (font)' failed

Pango-ERROR **: file shape.c: line 75 (pango_shape): assertion failed:=20
(glyphs->num_glyphs > 0)
aborting...
Abgebrochen
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>8=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The file /usr/local/etc/pango/pango.modules actually exists, but is
empty apart from comments.


Juergen

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

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

Petr Mikulik wrote:

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

I'm afraid you think quite wrongly here.  The problem is that there's no 
way the core can know whether that call is needed to get a correct 
drawing or not.  The API call's name is "set color", not "change color", 
so it should be obvious that the core is perfectly allowed to set the 
color to the same value as often as it likes.  If a driver has a problem 
with that, it should take care of it itself.  If there are many such 
drivers, let them delegate the work to a shared lower-level function or 
let term.c offer an intermediate layer (along the lines of 
term.c:term_suspend, the only caller of term->suspend).

We almost have such an intermediate function already:  there are rather 
few functions of the core that actually call term->set_color:

color.c:set_color()
color.c:set_rgbcolor()
gadgets.c: apply_pm3dcolor()

 > Is it some "hidden3d" code?

I must say I'm rather negatively surprised by you asking this question 
at this time.  How come that you have to ask, days after you rather 
openly blamed hidden3d for this?

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

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

On Saturday 08 July 2006 02:57 pm, Petr Mikulik wrote:
> 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?

It's not so easy as you make it sound.
The logic of the higher level code is 
 1) determine color of rectangle (or other object)
 2) set color
 3) draw the object

But the object is drawn by invoking a hierarchy of lower level
routines, and at those levels hidden3d, or clipping, or various other
filters, may cause the object not to be passed through to the driver
after all. By that time the set_color command has already been sent.

Have a look at the second patch to pslatex.trm that I posted on
SourceForge for this bug.  The amount of code added to pslatex.trm
to filter out unnecessary set_color commands is relatively small.
A similar thing could be done, I think, for the small number of other
drivers that need it.  But each one will have to be considered on its own.  

To do this in the core code would be much, much messier.
In fact, it would be impossible to do correctly for epslatex.
epslatex has two output streams, and the commands are properly sent to
one but not the other. How would you have the core code deal with that?
I think that specific micro-optimization is too driver-dependent
to be done at a higher level.

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

Re: Build problem

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

Hi Juergen,

Juergen Wieferink wrote:
> Though I found some things.
> First the warnings:
>
> parse.c:846: warning: `is_ud_function' defined but not used
> plot3d.c:1159: warning: `specs' might be used uninitialized in this fun=
ction
> ../term/wxt.trm:112: warning: `font_setting' might be used uninitialize=
d 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.
>  =20
The warnings about wxt.trm and gp_cairo.c are false alarms, but I will=20
initialize the variables to avoid the warnings.
> Linking fails with:
>
> g++  -g -O2 -I/usr/lib/wx/include/gtk2-unicode-release-2.5=20
> -I/usr/include/wx-2.5 -DGTK_NO_CHECK_CASTS -D__WXGTK__ -D_FILE_OFFSET_B=
ITS=3D64=20
> -D_LARGE_FILES   -I/usr/local/include/cairo -I/usr/X11R6/include=20
> -I/usr/include/libpng12 -I/usr/include/freetype2  =20
> -I/usr/local/include/pango-1.0 -I/opt/gnome/include/glib-2.0=20
> -I/opt/gnome/lib/glib-2.0/include   -DXTHREADS -D_REENTRANT -DXUSE_MTSA=
FE_API=20
> -I/usr/local/include/pango-1.0 -I/usr/X11R6/include -I/usr/include/free=
type2=20
> -I/usr/include/freetype2/config -I/opt/gnome/include/gtk-2.0=20
> -I/opt/gnome/lib/gtk-2.0/include -I/opt/gnome/include/atk-1.0=20
> -I/opt/gnome/include/glib-2.0 -I/opt/gnome/lib/glib-2.0/include    -L/u=
sr/lib=20
> -Wl,-rpath,/usr/lib -L/usr/X11R6/lib -o gnuplot  alloc.o axis.o breader=
s.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 stan=
dard.o=20
> stdfn.o tables.o term.o time.o unset.o util.o util3d.o variable.o versi=
on.o =20
> gp_cairo.o wxt_gui.o -lreadline  -lncurses  -lz -lgd -lXpm -lX11 -ljpeg=
=20
> -lfontconfig -lfreetype -lpng12 -lz -lm  -pthread   -L/usr/X11R6/lib =20
> -lwx_gtk2u_xrc-2.5 -lwx_gtk2u_html-2.5 -lwx_gtk2u_adv-2.5 -lwx_gtk2u_co=
re-2.5=20
> -lwx_baseu_xml-2.5 -lwx_baseu_net-2.5 -lwx_baseu-2.5  -L/usr/local/lib=20
> -L/usr/X11R6/lib -lcairo -lXrender -lX11 -lXext -lpng12 -lz -lm -lfreet=
ype=20
> -lfontconfig   -L/usr/local/lib -L/opt/gnome/lib -lpango-1.0 -lgobject-=
2.0=20
> -lgmodule-2.0 -ldl -lglib-2.0   -L/usr/local/lib -L/opt/gnome/lib=20
> -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangoxft-1=
.0=20
> -lpangox-1.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ld=
l=20
> -lglib-2.0   -lm=20
> wxterminal/gp_cairo.c:1592: undefined reference to `pango_cairo_create_=
layout'
> gp_cairo.o(.text+0x18a3): In function `gp_cairo_enhanced_flush':
> wxterminal/gp_cairo.c:1202: undefined reference to `pango_cairo_create_=
layout'
> gp_cairo.o(.text+0x19a5):wxterminal/gp_cairo.c:1167: undefined referenc=
e to=20
> `pango_cairo_create_layout'
> gp_cairo.o(.text+0x19f0):wxterminal/gp_cairo.c:1175: undefined referenc=
e to=20
> `pango_cairo_create_layout'
> gp_cairo.o(.text+0x1bf1):wxterminal/gp_cairo.c:1101: undefined referenc=
e to=20
> `pango_cairo_create_layout'
> gp_cairo.o(.text+0x1dc7):wxterminal/gp_cairo.c:1124: more undefined ref=
erences=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_=
layout'
> gp_cairo.o(.text+0x2ed5):wxterminal/gp_cairo.c:1392: undefined referenc=
e 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_l=
ayout'
> 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?
>  =20
I don't think so.

You are missing the linking flag '-lpangocairo'.

I guess you have gtk+ 2.6, not 2.8 or later. That's fine in terms of=20
what we need for the wxWidgets terminal. However, gtk+ 2.8 is dependant=20
on cairo, and was magically adding the '-lpangocairo' flag. gtk+ 2.6=20
does not depend on cairo, hence the missing flag. I've fixed that in=20
CVS. Please try to see if the problem is fixed.

Well, so far your experience and your reports have been really fruitful,=20
thank you very much, and please go on ;-)

Timoth=E9e

Re: Idea: env-mapping for dataplot over pipes

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

Ethan A Merritt wrote:
> On Saturday 08 July 2006 03:03 pm, Tino Wildenhain wrote:
>> 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 put it in the plot command directly.
> That way it will get re-evaluated every time:

uh. can I? How?

>> So a mapping to the environment would be the most flexible
>> way to make all this possible I guess...
> 
> That would suffer the same problem.  You would have to
> re-export the environmental variable prior to doing each
> replot.

Just before popen() would make most sense, right? -
or alternatively with every change to a variable
(a bit more code work, but probably not - since
there seems to be a central mapping and interface
for setting/reading vars)

Regards
Tino

Re: Idea: env-mapping for dataplot over pipes

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

On Saturday 08 July 2006 03:03 pm, Tino Wildenhain wrote:
> 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 put it in the plot command directly.
That way it will get re-evaluated every time:

> So a mapping to the environment would be the most flexible
> way to make all this possible I guess...

That would suffer the same problem.  You would have to
re-export the environmental variable prior to doing each
replot.


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

Re: Idea: env-mapping for dataplot over pipes

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

>> 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.

The values GPVAL_X_MIN etc are changed after the zoom! Thus:

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

---
PM