gnuplot-beta

Re: Build problem

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

On Tuesday 27 June 2006 12:59 pm, you wrote:
>
> Are you sure you had the *-devel rpm installed when you first tried ?

It's not done by the *-devel rpms.  The pkgconfig hooks are in the
library rpms themselves (I just checked).

> > But what about if you're not using pkg-config?  It seems really
> > odd to me to require a particular package manager.  If you've got
> > the libraries themselves, that should be sufficient.
>
> It seems to me that it helps a lot when compiler flags are concerned.
> For example , 'pkg-config pango --cflags' gives :
>
>     -I/usr/include/pango-1.0 -I/usr/include/glib-2.0
> -I/usr/lib/glib-2.0/include
>
> Or 'pkg-config pango --libs' :
>
>     -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0

But that information is not required by ./configure, so what's
the point?
You don't need all those extra -lXXX flags; they will be pulled in
by the main shared library anyhow.

[2] ldd /usr/lib/libpango-1.0.so
        linux-gate.so.1 =>  (0xffffe000)
        libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb7f3b000)
        libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb7f38000)
        libdl.so.2 => /lib/libdl.so.2 (0xb7f34000)
        libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb7eae000)
        libm.so.6 => /lib/tls/libm.so.6 (0xb7e89000)
        libc.so.6 => /lib/tls/libc.so.6 (0xb7d5b000)
        /lib/ld-linux.so.2 (0x80000000)

As I already said, the configure process works fine without this.


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

Re: Build problem

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

Ethan Merritt wrote:
> On Tuesday 27 June 2006 12:59 pm, you wrote:
>  =20
>> It seems to me that it helps a lot when compiler flags are concerned.
>> For example , 'pkg-config pango --cflags' gives :
>>
>>     -I/usr/include/pango-1.0 -I/usr/include/glib-2.0
>> -I/usr/lib/glib-2.0/include
>>
>> Or 'pkg-config pango --libs' :
>>
>>     -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0
>>    =20
>
> But that information is not required by ./configure, so what's
> the point?
> You don't need all those extra -lXXX flags; they will be pulled in
> by the main shared library anyhow.
> (...)
>
> As I already said, the configure process works fine without this.
>  =20
That succeeds because of a "chain reaction" : wxGTK (wxWidgets based on=20
gtk) links against gtk, and consequently against pango and cairo. But it=20
is not guaranteed that you'll be using the gtk port of wxWidgets. What=20
if in the future somebody tries to make it work with wxX11 (wxWidgets=20
based on the Xlib without gtk), wxOS/2 or wxMAC ? Then (in addition to=20
the little work needed in wxt_gui.cpp) we won't have the magic link=20
against cairo and pango, and the compilation would fail.

Timoth=C3=A9e

Re: Build problem

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

On Tuesday 27 June 2006 01:48 pm, Timoth=C3=A9e Lecomte wrote:
> Ethan Merritt wrote:
> >
> > As I already said, the configure process works fine without this.
>
> That succeeds because of a "chain reaction" : wxGTK (wxWidgets based
> on gtk) links against gtk, and consequently against pango and cairo.
> But it is not guaranteed that you'll be using the gtk port of
> wxWidgets. What if in the future somebody tries to make it work with
> wxX11 (wxWidgets based on the Xlib without gtk), wxOS/2 or wxMAC ?
> Then (in addition to the little work needed in wxt_gui.cpp) we won't
> have the magic link against cairo and pango, and the compilation
> would fail.

Maybe it would; I'd have to try it to see for sure.
In fact, I'd like to try it :-)
Can you point me to a wxWidgets variant based directly on Xlib?

But I'm not sure you have addressed what I see as the main issue.
The use of pkg-config in the configure script is itself problematic.
What about people who aren't trying to build wxt?  They should not be=20
required to install pkg-config just because hypothetically it would
have been required in other circumstances.

Do you now have it set up so the one can configure and install
gnuplot in the total absence of pkg-config?

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

Re: Build problem

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

Ethan Merritt wrote:
> On Tuesday 27 June 2006 01:48 pm, Timoth=C3=A9e Lecomte wrote:
>  =20
>> Ethan Merritt wrote:
>>    =20
>>> As I already said, the configure process works fine without this.
>>>      =20
>> That succeeds because of a "chain reaction" : wxGTK (wxWidgets based
>> on gtk) links against gtk, and consequently against pango and cairo.
>> But it is not guaranteed that you'll be using the gtk port of
>> wxWidgets. What if in the future somebody tries to make it work with
>> wxX11 (wxWidgets based on the Xlib without gtk), wxOS/2 or wxMAC ?
>> Then (in addition to the little work needed in wxt_gui.cpp) we won't
>> have the magic link against cairo and pango, and the compilation
>> would fail.
>>    =20
>
> Maybe it would; I'd have to try it to see for sure.
> In fact, I'd like to try it :-)
> Can you point me to a wxWidgets variant based directly on Xlib?
>  =20
Sure, take a look here :

http://sourceforge.net/project/showfiles.php?group_id=3D9863

and choose either wxX11 or wxMotif (for example).
Then you'll have to slightly modify wxt_gui.h and wxt_gui.cpp so that=20
those behave as wxGTK, i.e. replace

    #ifdef __WXGTK__
    ...
    #elif defined(__WXMSW__)
    ...
    #else
    # error "No implementation"
    #endif

by

    #if defined(__WXGTK__)||defined(__WXX11__)
    ...
    #elif defined(__WXMSW__)
    ...
    #else
    # error "No implementation"
    #endif

assuming you try with wxX11 (these conditional parts are there because=20
gnuplot on Windows already has its own main loop.

And finally you may have to comment the code related to the clipboard if=20
the compiler complains, as wxMotif or wxX11 are not supposed to support=20
it entirely according to http://wxwidgets.org/docs/supported.htm

Then, have fun !

> But I'm not sure you have addressed what I see as the main issue.
> The use of pkg-config in the configure script is itself problematic.
> What about people who aren't trying to build wxt?  They should not be=20
> required to install pkg-config just because hypothetically it would
> have been required in other circumstances.
>  =20

> Do you now have it set up so the one can configure and install
> gnuplot in the total absence of pkg-config?
>  =20
Yes, this case is handled now. The macros PKG_CHECK_MODULES (provided by=20
pkg.m4 which is in gnuplot tree) check for the presence of pkg-config=20
and the configure script will just disable wxt if this program can't be=20
found. You can try. Just rename pkg-config temporarely and see.

Best regards,

Timoth=C3=A9e

Re: Build problem

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

Ethan Merritt wrote:
>
>>> As I previously described, in order to get wxWidgets up and running
>>> I first had to find and install pkgconfig. But that wasn't
>>> sufficient; I then had to go back and re-install earlier packages.
>>> What a pain.
>>>      =20
>> I think that's the fault of your distribution.
>>    =20
>
> We'll have to agree to disagree on this point.
> I think that the fewer packages I have to install, the better.
> Installing pkgconfig was unnecessary before wxt entered the
> picture, so there was no reason to install it.
>  =20
As were pango, cairo, glib, gtk ... I acknowledge that, I just thought=20
pkg-config was a very small and natural dependency compared to the=20
formers. And it is still unneeded if you don't want wxt.

>  =20
>> Checking for libraries' versions at run-time? Unless I have
>> cairo>0.9, the necessary functions are not even defined in the
>> headers. That's a compile-time requirement.
>>    =20
>
> The existence of particular entry points in a library is what the=20
> AC_CHECK_LIB macro is for. That's what we use elsewhere
> in configure.in.  Can't we use it here also?
>  =20
Oh yes, we could, you are right.
> If you link against shared libraries, the version must also be
> checked at run-time.  However, this is conflating possible problems
> at very different stages, so let's not worry about anything past
> the configuration stage.
>  =20
Ok, I see what you mean. I don't really know how to handle that.
>  =20
>> Relying on the magic of wxWidgets compile and linking flags ? What if
>> I want to write a static terminal based on cairo and independant of
>> wxWidgets then ?
>>    =20
>
> Sorry, I'm not following you there.  What's a "static terminal"?
>  =20
A terminal that would output to a file :

gnuplot> set term cairopng
gnuplot> set output 'plot.png'
gnuplot> plot x
gnuplot> set output

> I'm pretty sure that aquaterm uses cairo, but does not use wxWidgets.
> Does that count?
>  =20
I don't think it does. aquaterm is based on the native MacOS X vector=20
drawing library ("Cocoa"), not on cairo.
> Anyhow, I don't want to flog a dead horse.
> I appreciate your work, and you are clearly more comfortable with
> all the auto-build tools and accoutrements than I am.
> If it's all working now - great. I'm happy.
>  =20
I hope it is ;-)
I would really like to let configure.in as it is now.

> Getting back to the main concern: what's needed for a 4.2 release...
> Do you know what, if anything, needs to be added to the config and
> makefiles for the various gnuplot platforms that don't use the main
> configure script?=20
>  =20
Currently, the wxWidgets terminal is only available when compiled with=20
the configure script or with makefile.mgw. The others makefiles will=20
hopefully just compile gnuplot without it. I don't think I have enough=20
experience to modify those.

As far as the other features are concerned, I can only see the=20
GNUPLOT_PS_DIR stuff as a show-stopper. And the config/config.* files=20
may be updated to enable the features that have been introduced since=20
they have been generated.

Best regards,

Timoth=C3=A9e

Re: Build problem

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

Juergen Wieferink wrote:
> On Tuesday 27 June 2006 21:34 Timoth=E9e Lecomte wrote:
>  =20
>> Nevermind, this patch does not solve anything. I uninstalled pkg-confi=
g,
>> and can reproduce exactly your problem (AC_MSG_WARN undefined and
>> PKG_CHECK_MODULES with wrong syntax).
>>
>> However, I think I have found the right solution. As explained in
>> http://programming.linux.com/programming/05/08/11/1923248.shtml?tid=3D=
22
>> ("Best Practices with autotools"), we should always distribute the
>> macros we are using, because the user may have an old and buggy macro =
or
>> he may not have it at all.
>>
>> So the solution is to put 'pkg.m4' taken from the pkg-config package i=
n
>> <gnuplot source directory>/m4
>>
>> I have commited the file to the CVS.
>> Hardy and Juergen, can you try with the current CVS ?
>>    =20
>
> Yepp.  Works.  Great work, thanks!
>
> FWIW: If I understand correctly, you say that this problem occurs if
> there is no pkgconfig.  But actually, I have pkgconfig installed.
>  =20
Then, the pkg.m4 file that pkgconfig is supposed to install cannot be=20
found by autoconf. It should be in /usr/share/aclocal/pkg.m4 or=20
something like that depending on your distribution.

By the way, you can also look at the following line when executing=20
./configure saying :
    checking for pkg-config... /usr/bin/pkg-config

If it does not find the pkg-config program in your PATH, then your=20
pkg-config install has definitely a problem.

> OTOH the distribution (SuSE 9.3) is rather outdated:
>
> wiefer@localhost:~> rpm -qa |grep -i pkgconfig
> pkgconfig-0.15.0-201
>  =20
I checked in the pkg-config changelog, and this version should have=20
everything we need.
> 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
>  =20
Well, these are outdated (and by the way 2.5.x are development versions)=20
but they may be enough for the wxWidgets terminal.
> wiefer@localhost:~> rpm -qa |grep -i cairo
>  =20
That will be the main issue (once you solved your pkg-config problem) to=20
compile the wxWidgets terminal. If you really want to try it, you will=20
have to compile cairo from source (it has no dependency - at least none=20
of them is required for the wxWidgets terminal), and probably pango too,=20
unless you upgrade to suse 10.
> Thanks,
> Juergen
>  =20
Best regards,

Timoth=E9e

Re: Build problem

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

On Thursday 29 June 2006 00:29 Timoth=E9e Lecomte wrote:
> > wiefer@localhost:~> rpm -qa |grep -i cairo
>
> That will be the main issue (once you solved your pkg-config problem) to
> compile the wxWidgets terminal. If you really want to try it, you will
> have to compile cairo from source (it has no dependency - at least none
> of them is required for the wxWidgets terminal), and probably pango too,
> unless you upgrade to suse 10.

I have compiled and installed cairo-1.2.0 and pango-1.10.4.  The
newest version of pange needs a more recent version of glib.

> > 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 versions)
> 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&)

This is just for your information.  I think I can live without the
wxterminal until the next operating system update.  Though it really
sounds to be a cool feature. :-)

Juergen

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

[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: 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

[<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: 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

[<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 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:
> 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 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: 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: 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

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

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

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

[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