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

Re: Qt terminal on Mac & Icon

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

On Fri, Mar 9, 2012 at 06:14, sfeam (Ethan Merritt) wrote:
> On Sunday, 04 March 2012, Mojca Miklavec wrote:
>>
>> Also, is there any chance to use some high resolution icon? I have
>> created some PDF and SVG examples based on the original 16x16 image.
>> I'm attaching a SVG (it has a tiny flaw though
>
> How does one "use" the icon?  Do you just mean we would include it
> in the distribution, for distro packages to copy into their preferred
> icon directory during installation?

No, at the moment Qt terminal uses
    setWindowIcon(QIcon(":/images/gnuplot"));
which takes the icon
    src/qtterminal/images/icon32x32.xpm
based on information
    <file alias="images/gnuplot">images/icon32x32.xpm</file>
from
    src/qtterminal/QtGnuplotResource.qrc

I think that simply replacing xpm file with svg file either in
QtGnuplotResource.qrc or in source code should work (but I'm currently
unable to compile Qt terminal to be able to test). Assuming that you
are happy with the SVG image of course.

>> : its vertical and
>> horizontal line widths are slightly distorted, but I can create an
>> image that is not if that "defect" is visible). The SVG could be used
>> for icon in Qt. Of course one could try to create a better/nicer/3D
>> icon, but at the moment having one high resolution (in this cane a
>> vector image) would already be much better than having 32x32 pixels. I
>> guess that this is not visible on Linux, but you can see how it
>> compares with other programs on
>>     http://sourceforge.net/tracker/download.php?group_id=2055&atid=352055&file_id=432231&aid=3469808

Mojca

Re: Tarball for 4.6.0 release is available on SourceForge

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

On Fri, Mar 9, 2012 at 05:50, sfeam (Ethan Merritt) wrote:
> I have uploaded a tarball for the 4.6.0 release to SourceForge,

Thank you very much for that.

> You are welcome to test it now, and let me know if you encounter
> any problems.

None of the following reports is critical (they are all just
warnings), but I wanted to report what I found out when testing with
MacPorts with clang compiler:


:info:build color.c:518:14: warning: implicit conversion from
enumeration type 'enum JUSTIFY' to different enumeration type
'VERT_JUSTIFY' (aka 'enum VERT_JUSTIFY') [-Wconversion]
:info:build                             just, CENTRE, hrotate,
:info:build                                   ^~~~~~
:info:build color.c:529:14: warning: implicit conversion from
enumeration type 'enum JUSTIFY' to different enumeration type
'VERT_JUSTIFY' (aka 'enum VERT_JUSTIFY') [-Wconversion]
:info:build                             just, CENTRE, 0.0,
:info:build                                   ^~~~~~

:info:build graphics.c:1737:4: warning: implicit conversion from
enumeration type 'enum VERT_JUSTIFY' to different enumeration type
'JUSTIFY' (aka 'enum JUSTIFY') [-Wconversion]
:info:build                         JUST_CENTRE, JUST_TOP, 0,
:info:build                         ^~~~~~~~~~~

:info:build plot2d.c:2123:29: warning: implicit conversion from
enumeration type 'enum VERT_JUSTIFY' to different enumeration type
'enum JUSTIFY' [-Wconversion]
:info:build                         this_plot->labels->pos = JUST_CENTRE;
:info:build                                                ~ ^~~~~~~~~~~
:info:build plot2d.c:2312:32: warning: implicit conversion from
enumeration type 'enum VERT_JUSTIFY' to different enumeration type
'enum JUSTIFY' [-Wconversion]
:info:build                     this_plot->labels->pos = JUST_CENTRE;
:info:build                                            ~ ^~~~~~~~~~~

:info:build plot3d.c:1558:29: warning: implicit conversion from
enumeration type 'enum VERT_JUSTIFY' to different enumeration type
'enum JUSTIFY' [-Wconversion]
:info:build                         this_plot->labels->pos = JUST_CENTRE;
:info:build                                                ~ ^~~~~~~~~~~

(I think that compiler would like to see an explicit cast here.)

:info:build In file included from term.c:1394:
:info:build In file included from ./term.h:240:
:info:build ../term/x11.trm:620:55: warning: data argument not used by
format string [-Wformat-extra-args]
:info:build             fprintf(X11_ipc, (set_number ? "C%d\n" :
"C\n"), new_term_number);
:info:build                                                      ~~~~~   ^

(This can probably only be rewritten as
    if(set number) fprintf(X11_ipc, "C%d\n", new_term_number); else
fprintf(X11_ipc, "C\n");
to make compiler happy.)

:info:build In file included from term.c:1394:
:info:build In file included from ./term.h:426:
:info:build ../term/lua.trm:875:39: warning: if statement has empty
body [-Wempty-body]
:info:build   if (ftruncate(fileno(gpoutfile), 0));
:info:build                                       ^
:info:build util.c:509:10: warning: 'sprintf' macro redefined
:info:build # define sprintf(str,fmt,arg) \
:info:build          ^
:info:build /usr/include/secure/_stdio.h:49:9: note: previous definition is here
:info:build #define sprintf(str, ...) \
:info:build         ^

:info:build gplt_x11.c:2900:20: warning: format string is not a string
literal (potentially insecure) [-Wformat-security]
:info:build                         fprintf(stderr, display_error_text_after);
:info:build                                         ^~~~~~~~~~~~~~~~~~~~~~~~
:info:build gplt_x11.c:2905:20: warning: format string is not a string
literal (potentially insecure) [-Wformat-security]
:info:build                         fprintf(stderr, display_error_text_after);
:info:build                                         ^~~~~~~~~~~~~~~~~~~~~~~~
:info:build gplt_x11.c:2910:20: warning: format string is not a string
literal (potentially insecure) [-Wformat-security]
:info:build                         fprintf(stderr, display_error_text_after);
:info:build                                         ^~~~~~~~~~~~~~~~~~~~~~~~
:info:build gplt_x11.c:2915:20: warning: format string is not a string
literal (potentially insecure) [-Wformat-security]
:info:build                         fprintf(stderr, display_error_text_after);
:info:build                                         ^~~~~~~~~~~~~~~~~~~~~~~~
:info:build gplt_x11.c:4562:11: warning: 'XKeycodeToKeysym' is
deprecated [-Wdeprecated-declarations]
:info:build         keysym = XKeycodeToKeysym(dpy, event->xkey.keycode, 0);
:info:build                  ^

:info:build wxterminal/wxt_gui.cpp:2638:11: warning: enumeration value
'command_enhanced_put_text' not handled in switch [-Wswitch-enum]
:info:build         switch ( command.command ) {
:info:build                  ^

Also, the wxt terminal won't even compile with clang++ compiler, but
that's a report for elsewhere. I'm not yet sure what exactly is the
problem, but the linker doesn't find functions, it simply breaks with

 Undefined symbols for architecture x86_64:
   "wxNavigationEnabled<wxNonOwnedWindow>::SetFocus()", referenced from:
       vtable for wxtFrame in wxt_gui.o
       vtable for wxtConfigDialog in wxt_gui.o
       vtable for wxMDIParentFrameBase in wxt_gui.o
   "wxNavigationEnabled<wxNonOwnedWindow>::AcceptsFocus() const",
referenced from:
       vtable for wxtFrame in wxt_gui.o
       vtable for wxtConfigDialog in wxt_gui.o
       vtable for wxMDIParentFrameBase in wxt_gui.o

But again, this is most probably not gnuplot's problem.

Mojca

[patch v2] libedit problems with 8-bit input due to initialize-before-locale-was-set

[Yuriy K. <yu...@ma...>]

Hello!
libedit initialize its allowed character map (over 7bit ascii range) based on
locale/LC_CTYPE (and consider 8bit characters Meta-<7bit-char> otherwise); as
using_history() calls rl_initialize() before gnuplot set process locale, it
results with problems with non-ascii character input. Either init_locale() call
should be moved up, or using_history() moved down, or libedit should be
re-initialized after locale set. Patch for latter below.

(BTW, I noticed that `setlocale(LC_CTYPE,"")` is also called in
set.c/set_encoding/"locale"); is not this redundant after -r1.41? maybe it
should be replaced with `setlocale(LC_CTYPE, NULL)`?)

Index: gnuplot_4.6.0~20120302/src/variable.c
===================================================================
--- gnuplot_4.6.0~20120302.orig/src/variable.c
+++ gnuplot_4.6.0~20120302/src/variable.c
@@ -45,6 +45,7 @@ static char *RCSid() { return RCSid("$Id
 #include "plot.h"
 #include "util.h"
 #include "term_api.h"
+#include "readline.h"

 #define PATHSEP_TO_NUL(arg)			\
 do {						\
@@ -571,6 +572,11 @@ locale_handler(int action, char *newloca
 #ifdef HAVE_LOCALE_H
 	setlocale(LC_TIME, "");
 	setlocale(LC_CTYPE, "");
+#if defined(HAVE_LIBREADLINE) || defined(HAVE_LIBEDITLINE)
+	/* we must (re-)initialize readline after locale set */
+	if (interactive)
+	    rl_initialize();
+#endif
 	current_locale = gp_strdup(setlocale(LC_TIME,NULL));
 #else
 	current_locale = gp_strdup(INITIAL_LOCALE);

Re: Qt terminal on Mac & Icon

[sfeam (E. Merritt) <eam...@gm...>]

On Sunday, 04 March 2012, Mojca Miklavec wrote:
> 
> Also, is there any chance to use some high resolution icon? I have
> created some PDF and SVG examples based on the original 16x16 image.
> I'm attaching a SVG (it has a tiny flaw though

How does one "use" the icon?  Do you just mean we would include it
in the distribution, for distro packages to copy into their preferred
icon directory during installation?


	Ethan




> : its vertical and
> horizontal line widths are slightly distorted, but I can create an
> image that is not if that "defect" is visible). The SVG could be used
> for icon in Qt. Of course one could try to create a better/nicer/3D
> icon, but at the moment having one high resolution (in this cane a
> vector image) would already be much better than having 32x32 pixels. I
> guess that this is not visible on Linux, but you can see how it
> compares with other programs on
>     http://sourceforge.net/tracker/download.php?group_id=2055&atid=352055&file_id=432231&aid=3469808
> 
> Thank you,
>     Mojca
> 

Tarball for 4.6.0 release is available on SourceForge

[sfeam (E. Merritt) <eam...@gm...>]

I have uploaded a tarball for the 4.6.0 release to SourceForge, 
along with the planned release announcement and a PDF copy of the 
User Manual.  These should propagate to mirrors by tomorrow.

You are welcome to test it now, and let me know if you encounter
any problems.  If there are no unexpected glitches, the plan is to
publicize the release by sending out announcments next Monday.

Thanks to everyone who provided feedback on the -rc1 
release candidate!

	happy gnuplotting,

		Ethan

Qt terminal on Mac & Icon

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

Dear Gnuplot developers,

The Qt terminal was almost ready for Mac (it works on my computer),
however it has not been polished in the main CVS source (there are
still some minor issues). Would it be possible to take a look and make
it work before the official release of 4.6?

Also, is there any chance to use some high resolution icon? I have
created some PDF and SVG examples based on the original 16x16 image.
I'm attaching a SVG (it has a tiny flaw though: its vertical and
horizontal line widths are slightly distorted, but I can create an
image that is not if that "defect" is visible). The SVG could be used
for icon in Qt. Of course one could try to create a better/nicer/3D
icon, but at the moment having one high resolution (in this cane a
vector image) would already be much better than having 32x32 pixels. I
guess that this is not visible on Linux, but you can see how it
compares with other programs on
    http://sourceforge.net/tracker/download.php?group_id=2055&atid=352055&file_id=432231&aid=3469808

Thank you,
    Mojca

download section on the home page

[Juhász P. <pet...@gm...>]

I see that the gnuplot.info home page has been revamped, it's very nice!

However, the page accessible from the "Download" link is out of date: it
advertises obsolete versions. Some of the links are broken.

Péter Juhász

Re: doc2ipf and int_error

[Ethan A M. <sf...@us...>]

On Friday, March 02, 2012 02:50:03 pm Petr Mikulik wrote:
> Compiling of doc2ipf is broken:
> 
> $ make doc2ipf
> doc2ipf.o: In function `process_line':
> /home/mikulik/work/Software/gnuplot/gnuplot/docs/doc2ipf.c:406: undefined 
> reference to `int_error'
> 
> It's strange because process_line() does not call directly int_error().
> Any idea how to fix this?
> (doc2ipf is required to generate the hypertext documentation for OS/2.)

#undef assert

Or just remove the line containing assert() altogether.

Or replace it with an error message + exit.

diff -urp gnuplot/docs/doc2ipf.c gnuplot-cvs/docs/doc2ipf.c
--- gnuplot/docs/doc2ipf.c      2008-02-25 01:05:16.000000000 -0800
+++ gnuplot-cvs/docs/doc2ipf.c  2012-03-02 15:05:38.000000000 -0800
@@ -401,7 +401,10 @@ process_line(char *line, FILE *b)
                    if (*pt != NUL) {   /* ignore null columns */
                        char *tagend, *tagstart;
                        /* this fails on format line */
-                       assert(j < MAX_COL);
+                       if (j >= MAX_COL) {
+                               fprintf(stderr,"j >= MAX_COL\n");
+                               exit(-1);
+                       }
                        while (*pt==' ') pt++; /* strip spaces */
                        strcpy(tableins->col[j], " ");
                        strcat(tableins->col[j], pt);

doc2ipf and int_error

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

Compiling of doc2ipf is broken:

$ make doc2ipf
doc2ipf.o: In function `process_line':
/home/mikulik/work/Software/gnuplot/gnuplot/docs/doc2ipf.c:406: undefined 
reference to `int_error'

It's strange because process_line() does not call directly int_error().
Any idea how to fix this?
(doc2ipf is required to generate the hypertext documentation for OS/2.)

---
PM

Re: Observations on the 4.6rc1 windows package

[Tatsuro M. <tma...@ya...>]

--- On Tue, 2012/2/28, Ethan A Merritt  wrote:
> On Monday, February 27, 2012 02:44:22 am Peter Juhasz wrote:
> > 2012/2/27 Bastian M�rkisch <bma...@we...>:
> > >>>> I've fired up that virtual machine that produced that 5 minute delay
> > >>>> earlier. Some observations on several different builds:
> > >>>>
> > >>>> gp46rc1-win32-setup.exe from http://gnuplot.info/development/binaries/
> > >>>> (25-Feb-2012 07:19): a small (1-2 s) delay on startup.
> > >>>>
> > >>>> gp450win32-small-setup.zip from
> > >>>> http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/ (2012-02-23, md5sum
> > >>>> feebe279501075f8806a04a4029f899c): No delay at all!
> > >>>>
> > >>>> gp450win32-setup.zip from the same location (2012-02-23, md5sum
> > >>>> 728918c93811f1644711c05fecaebd8f): several minutes of delay.
> > >>>>
> > >>>> I thought that if the delay is related to the initialization of the wxt
> > >>>> terminal, then setting the GNUTERM variable to "windows" may alleviate
> > >>>> the problem, but it didn't.
> > >>>>
> > >>>> P�ter Juh�sz
> > >>>>
> > >>> One of the possibility is that the version of wxwidgets. �Now I am using
> > >>> wxwidgets-2.9.3.
> > >>> To be clear I have to rebuiild wxwidigts 2.8 and re-provide the binary.
> > >>> Now my condition is not so good, I cannot commit further at the moment.
> > >>>
> > >>> Sorry for inconvenience.
> > >>>
> > >>> Tatsuro
> > >>>
> > >>
> > >> Hello
> > >>
> > >> I have downgraded wxWidgets from version 2.9.3 to 2.8.12 and built the
> > >> recent cvs source.
> > >> http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/
> > >> gp450win32-setup.zip
> > >>
> > >> Please test this binary shows slow startup or not.
> > >>
> > >> Regards
> > >>
> > >> Tatsuro
> > >>
> > >
> > > Thanks for providing a new build so quickly! On my Vista machine your (old)
> > > build with wxWidgets 2.9.3 takes ~6s to start up, whereas the build with
> > > wxWidgets 2.8.12 takes only 0.7s. This is exactly the same time it takes for
> > > my own build to start up (wxWidgets 2.8.11).
> > > For the moment, I would thus suggest to stay with 2.8 for a 4.6 release
> > > build.
> > >
> > > �Bastian
> > 
> > I confirm the speedup with this new build: on this pathological Vista
> > virtual machine I have the delay on startup has shrunk down to 8
> > seconds. On a real XP box the delay is less than 1 s.
> > 
> > Perhaps it would be illuminating to look at the changelogs of
> > wxWidgets to see what could possibly cause this effect, and also test
> > whether it appears on non-Windows platforms.
> > 
> > P�ter Juh�sz
> 
> This tracker:
>   http://openeuphoria.org/forum/117422.wc
> suggests that it can take 15 seconds to load the 2.9 wxWidgets *.dll if it is
> built as a monolithic library. Splitting it into smaller pieces may help.
> 
> And this one:
>   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
> gives work-arounds for horrible problems when compiling wxWidgets with certain 
> versions of Mingw and gcc
> 
> I gather from the wxWiki pages that the package can be built in either
> "debug" or "release" mode.  The latter can be much faster.  Several debug levels
> are possible.   Apparently the defaults changed between 2.8 and 2.9, so maybe
> this is part of the problem? 
> 
> 
>     Ethan

Hello

> This tracker:
>   http://openeuphoria.org/forum/117422.wc
> suggests that it can take 15 seconds to load the 2.9 wxWidgets *.dll if it is
> built as a monolithic library. Splitting it into smaller pieces may help.

Perhaps I made smaller pieces dll libraries. 

>   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
> gives work-arounds for horrible problems when compiling wxWidgets with certain 
> versions of Mingw and gcc

I have noticed this one. I have attached the patch when building wxWidgets 2.8 in order to avoid increase in size of the dll files.

Anyway thank you for your pointer.

Regards

Tatsuro

Re: Observations on the 4.6rc1 windows package

[Ethan A M. <sf...@us...>]

On Monday, February 27, 2012 02:44:22 am Peter Juhasz wrote:
> 2012/2/27 Bastian M�rkisch <bma...@we...>:
> >>>> I've fired up that virtual machine that produced that 5 minute delay
> >>>> earlier. Some observations on several different builds:
> >>>>
> >>>> gp46rc1-win32-setup.exe from http://gnuplot.info/development/binaries/
> >>>> (25-Feb-2012 07:19): a small (1-2 s) delay on startup.
> >>>>
> >>>> gp450win32-small-setup.zip from
> >>>> http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/ (2012-02-23, md5sum
> >>>> feebe279501075f8806a04a4029f899c): No delay at all!
> >>>>
> >>>> gp450win32-setup.zip from the same location (2012-02-23, md5sum
> >>>> 728918c93811f1644711c05fecaebd8f): several minutes of delay.
> >>>>
> >>>> I thought that if the delay is related to the initialization of the wxt
> >>>> terminal, then setting the GNUTERM variable to "windows" may alleviate
> >>>> the problem, but it didn't.
> >>>>
> >>>> P�ter Juh�sz
> >>>>
> >>> One of the possibility is that the version of wxwidgets. �Now I am using
> >>> wxwidgets-2.9.3.
> >>> To be clear I have to rebuiild wxwidigts 2.8 and re-provide the binary.
> >>> Now my condition is not so good, I cannot commit further at the moment.
> >>>
> >>> Sorry for inconvenience.
> >>>
> >>> Tatsuro
> >>>
> >>
> >> Hello
> >>
> >> I have downgraded wxWidgets from version 2.9.3 to 2.8.12 and built the
> >> recent cvs source.
> >> http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/
> >> gp450win32-setup.zip
> >>
> >> Please test this binary shows slow startup or not.
> >>
> >> Regards
> >>
> >> Tatsuro
> >>
> >
> > Thanks for providing a new build so quickly! On my Vista machine your (old)
> > build with wxWidgets 2.9.3 takes ~6s to start up, whereas the build with
> > wxWidgets 2.8.12 takes only 0.7s. This is exactly the same time it takes for
> > my own build to start up (wxWidgets 2.8.11).
> > For the moment, I would thus suggest to stay with 2.8 for a 4.6 release
> > build.
> >
> > �Bastian
> 
> I confirm the speedup with this new build: on this pathological Vista
> virtual machine I have the delay on startup has shrunk down to 8
> seconds. On a real XP box the delay is less than 1 s.
> 
> Perhaps it would be illuminating to look at the changelogs of
> wxWidgets to see what could possibly cause this effect, and also test
> whether it appears on non-Windows platforms.
> 
> P�ter Juh�sz

This tracker:
  http://openeuphoria.org/forum/117422.wc
suggests that it can take 15 seconds to load the 2.9 wxWidgets *.dll if it is
built as a monolithic library. Splitting it into smaller pieces may help.

And this one:
  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
gives work-arounds for horrible problems when compiling wxWidgets with certain 
versions of Mingw and gcc

I gather from the wxWiki pages that the package can be built in either
"debug" or "release" mode.  The latter can be much faster.  Several debug levels
are possible.   Apparently the defaults changed between 2.8 and 2.9, so maybe
this is part of the problem? 


	Ethan

Re: Observations on the 4.6rc1 windows package

[Juhász P. <pet...@gm...>]

On Mon, 2012-02-27 at 20:53 +0100, Bastian Märkisch wrote:
> 
> Am 27.02.2012 20:35, schrieb Mojca Miklavec:
> > On Mon, Feb 27, 2012 at 12:22, Ethan A Merritt wrote:
> >>
> >> Mojca Miklavec reported earlier that wxWidgets 2.9 has problems on OSX.
> >
> > However it works now - after some patches have been applied to gnuplot
> > (or maybe I should double check that the patches are indeed in sources
> > and not just on my computer).
> >
> >
> > Before claiming differences in startup speed, please double check
> > something that definitely has a huge influence. I think that wxWidgets
> > use fc-config and when one first starts the program, it will always
> > take a considerable amount of time to build font caches (it has to
> > scan all fonts in C:\Windows\Fonts and possibly some others). So it
> > might be that whenever one tested the new build with wxt 2.9, it was
> > only rebuilding caches and the second run would be faster, while the
> > caches for gnuplot with wxt 2.8 were already present and thus gnuplot
> > start was faster. This problem should not occur on linux and mac and
> > you cannot get rid of it on windows unless you rewrite some code from
> > wxt or configure fontconfig in a different way (but then users might
> > just as well start complaining that the new fonts don't work in
> > gnuplot).
> >
> > Mojca
> 
> Tests have been run several times of course. Please note that the 
> cairo/pango terminals (including wxt) no longer use the fontconfig 
> mechanism.
> 
>    Bastian
> 

I remember that there used to be delays related to font caching but this
issue seems to be something else. For one, that delay used to manifest
itself the first time I used the wxt terminal, and only then. This delay
shows up every time I start the program, even in non-interactive mode.
And as Bastian says, the fontconfig mechanism is not used anymore.

Péter Juhász

Re: Observations on the 4.6rc1 windows package

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

Am 27.02.2012 20:35, schrieb Mojca Miklavec:
> On Mon, Feb 27, 2012 at 12:22, Ethan A Merritt wrote:
>>
>> Mojca Miklavec reported earlier that wxWidgets 2.9 has problems on OSX.
>
> However it works now - after some patches have been applied to gnuplot
> (or maybe I should double check that the patches are indeed in sources
> and not just on my computer).
>
>
> Before claiming differences in startup speed, please double check
> something that definitely has a huge influence. I think that wxWidgets
> use fc-config and when one first starts the program, it will always
> take a considerable amount of time to build font caches (it has to
> scan all fonts in C:\Windows\Fonts and possibly some others). So it
> might be that whenever one tested the new build with wxt 2.9, it was
> only rebuilding caches and the second run would be faster, while the
> caches for gnuplot with wxt 2.8 were already present and thus gnuplot
> start was faster. This problem should not occur on linux and mac and
> you cannot get rid of it on windows unless you rewrite some code from
> wxt or configure fontconfig in a different way (but then users might
> just as well start complaining that the new fonts don't work in
> gnuplot).
>
> Mojca

Tests have been run several times of course. Please note that the 
cairo/pango terminals (including wxt) no longer use the fontconfig 
mechanism.

   Bastian

Re: Observations on the 4.6rc1 windows package

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

On Mon, Feb 27, 2012 at 12:22, Ethan A Merritt wrote:
>
> Mojca Miklavec reported earlier that wxWidgets 2.9 has problems on OSX.

However it works now - after some patches have been applied to gnuplot
(or maybe I should double check that the patches are indeed in sources
and not just on my computer).


Before claiming differences in startup speed, please double check
something that definitely has a huge influence. I think that wxWidgets
use fc-config and when one first starts the program, it will always
take a considerable amount of time to build font caches (it has to
scan all fonts in C:\Windows\Fonts and possibly some others). So it
might be that whenever one tested the new build with wxt 2.9, it was
only rebuilding caches and the second run would be faster, while the
caches for gnuplot with wxt 2.8 were already present and thus gnuplot
start was faster. This problem should not occur on linux and mac and
you cannot get rid of it on windows unless you rewrite some code from
wxt or configure fontconfig in a different way (but then users might
just as well start complaining that the new fonts don't work in
gnuplot).

Mojca

Re: Observations on the 4.6rc1 windows package

[Ethan A M. <sf...@us...>]

On Monday, February 27, 2012 09:00:37 am pl...@pi... wrote:
> On 02/27/12 16:43, Peter Juhasz wrote:
> > On Mon, Feb 27, 2012 at 1:31 PM,<pl...@pi...>  wrote:
> >> On 02/27/12 11:44, Peter Juhasz wrote:
> >>> Perhaps it would be illuminating to look at the changelogs of
> >>> wxWidgets to see what could possibly cause this effect, and also test
> >>> whether it appears on non-Windows platforms.
> >>
> >> using recent CVS and wxGTK-2.8.12.1 , not unusual slowness.
> >>
> >
> > Same for me, but it'd be interesting to upgrade wx* to 2.9.3 and
> > retry, as the problems on windows appeared with that version.
> >
> > P�ter Juh�sz
> >
> 
> sorry , not paying attention.
> 
> Gentoo throws this msg if I try to force that version.
> 
> # Ryan Hill <dir...@ge...> (22 Jan 2011)
> # Mask development versions due to unstable API
> # as requested by leio
> =x11-libs/wxGTK-2.9.1.1
> 
> I don't have much interest in screwing half my system and not getting 
> other things done while trying to patch it up again.
> 
> I already run "testing" profile, if this is not even in testing I guess 
> they know it really is still buggy still.
> 
> Peter.

Mojca Miklavec reported earlier that wxWidgets 2.9 has problems on OSX.

> from: Mojca Miklavec 01-Aug-2011
> > Anyhow, I take it the bottom line is that wxWidgets 2.8 does work,
> > but 2.9 does not?
> 
> True. I'm not sure what is wrong with 2.9, but it might also be a bug
> in their code, not just the need to rewrite the program. It would make
> a lot of sense to resolve such bugs before 3.0 is released, but I
> don't know how to create a minimal example to submit a bug report (if
> there is one).

The wxWidgets project documentation warns that 2.9 and 2.8 are not
100% compatible, although the only specific relevant examples that I
see there have to do with unicode characters and with wxString objects
in general.

Re: Observations on the 4.6rc1 windows package

[<pl...@pi...>]

On 02/27/12 16:43, Peter Juhasz wrote:
> On Mon, Feb 27, 2012 at 1:31 PM,<pl...@pi...>  wrote:
>> On 02/27/12 11:44, Peter Juhasz wrote:
>>> Perhaps it would be illuminating to look at the changelogs of
>>> wxWidgets to see what could possibly cause this effect, and also test
>>> whether it appears on non-Windows platforms.
>>
>> using recent CVS and wxGTK-2.8.12.1 , not unusual slowness.
>>
>
> Same for me, but it'd be interesting to upgrade wx* to 2.9.3 and
> retry, as the problems on windows appeared with that version.
>
> Péter Juhász
>

sorry , not paying attention.

Gentoo throws this msg if I try to force that version.

# Ryan Hill <dir...@ge...> (22 Jan 2011)
# Mask development versions due to unstable API
# as requested by leio
=x11-libs/wxGTK-2.9.1.1

I don't have much interest in screwing half my system and not getting 
other things done while trying to patch it up again.

I already run "testing" profile, if this is not even in testing I guess 
they know it really is still buggy still.

Peter.

Re: Observations on the 4.6rc1 windows package

[Peter J. <pet...@gm...>]

On Mon, Feb 27, 2012 at 1:31 PM,  <pl...@pi...> wrote:
> On 02/27/12 11:44, Peter Juhasz wrote:
>> Perhaps it would be illuminating to look at the changelogs of
>> wxWidgets to see what could possibly cause this effect, and also test
>> whether it appears on non-Windows platforms.
>
> using recent CVS and wxGTK-2.8.12.1 , not unusual slowness.
>

Same for me, but it'd be interesting to upgrade wx* to 2.9.3 and
retry, as the problems on windows appeared with that version.

Péter Juhász

Re: Observations on the 4.6rc1 windows package

[<pl...@pi...>]

On 02/27/12 11:44, Peter Juhasz wrote:
> Perhaps it would be illuminating to look at the changelogs of
> wxWidgets to see what could possibly cause this effect, and also test
> whether it appears on non-Windows platforms.

using recent CVS and wxGTK-2.8.12.1 , not unusual slowness.

Re: Observations on the 4.6rc1 windows package

[Peter J. <pet...@gm...>]

2012/2/27 Bastian Märkisch <bma...@we...>:
>>>> I've fired up that virtual machine that produced that 5 minute delay
>>>> earlier. Some observations on several different builds:
>>>>
>>>> gp46rc1-win32-setup.exe from http://gnuplot.info/development/binaries/
>>>> (25-Feb-2012 07:19): a small (1-2 s) delay on startup.
>>>>
>>>> gp450win32-small-setup.zip from
>>>> http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/ (2012-02-23, md5sum
>>>> feebe279501075f8806a04a4029f899c): No delay at all!
>>>>
>>>> gp450win32-setup.zip from the same location (2012-02-23, md5sum
>>>> 728918c93811f1644711c05fecaebd8f): several minutes of delay.
>>>>
>>>> I thought that if the delay is related to the initialization of the wxt
>>>> terminal, then setting the GNUTERM variable to "windows" may alleviate
>>>> the problem, but it didn't.
>>>>
>>>> Péter Juhász
>>>>
>>> One of the possibility is that the version of wxwidgets.  Now I am using
>>> wxwidgets-2.9.3.
>>> To be clear I have to rebuiild wxwidigts 2.8 and re-provide the binary.
>>> Now my condition is not so good, I cannot commit further at the moment.
>>>
>>> Sorry for inconvenience.
>>>
>>> Tatsuro
>>>
>>
>> Hello
>>
>> I have downgraded wxWidgets from version 2.9.3 to 2.8.12 and built the
>> recent cvs source.
>> http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/
>> gp450win32-setup.zip
>>
>> Please test this binary shows slow startup or not.
>>
>> Regards
>>
>> Tatsuro
>>
>
> Thanks for providing a new build so quickly! On my Vista machine your (old)
> build with wxWidgets 2.9.3 takes ~6s to start up, whereas the build with
> wxWidgets 2.8.12 takes only 0.7s. This is exactly the same time it takes for
> my own build to start up (wxWidgets 2.8.11).
> For the moment, I would thus suggest to stay with 2.8 for a 4.6 release
> build.
>
>  Bastian

I confirm the speedup with this new build: on this pathological Vista
virtual machine I have the delay on startup has shrunk down to 8
seconds. On a real XP box the delay is less than 1 s.

Perhaps it would be illuminating to look at the changelogs of
wxWidgets to see what could possibly cause this effect, and also test
whether it appears on non-Windows platforms.

Péter Juhász

Re: Observations on the 4.6rc1 windows package

[Tatsuro M. <tma...@ya...>]

--- On Mon, 2012/2/27, Bastian Märkisch wrote:
> >>> I've fired up that virtual machine that produced that 5 minute delay
> >>> earlier. Some observations on several different builds:
> >>>
> >>> gp46rc1-win32-setup.exe from http://gnuplot.info/development/binaries/
> >>> (25-Feb-2012 07:19): a small (1-2 s) delay on startup.
> >>>
> >>> gp450win32-small-setup.zip from
> >>> http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/ (2012-02-23, md5sum
> >>> feebe279501075f8806a04a4029f899c): No delay at all!
> >>>
> >>> gp450win32-setup.zip from the same location (2012-02-23, md5sum
> >>> 728918c93811f1644711c05fecaebd8f): several minutes of delay.
> >>>
> >>> I thought that if the delay is related to the initialization of the wxt
> >>> terminal, then setting the GNUTERM variable to "windows" may alleviate
> >>> the problem, but it didn't.
> >>>
> >>> Péter Juhász
> >>>
> >> One of the possibility is that the version of wxwidgets.  Now I am using wxwidgets-2.9.3.
> >> To be clear I have to rebuiild wxwidigts 2.8 and re-provide the binary.
> >> Now my condition is not so good, I cannot commit further at the moment.
> >>
> >> Sorry for inconvenience.
> >>
> >> Tatsuro
> >>
> >
> > Hello
> >
> > I have downgraded wxWidgets from version 2.9.3 to 2.8.12 and built the recent cvs source.
> > http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/
> > gp450win32-setup.zip
> >
> > Please test this binary shows slow startup or not.
> >
> > Regards
> >
> > Tatsuro
> >
> 
> Thanks for providing a new build so quickly! On my Vista machine your 
> (old) build with wxWidgets 2.9.3 takes ~6s to start up, whereas the 
> build with wxWidgets 2.8.12 takes only 0.7s. This is exactly the same 
> time it takes for my own build to start up (wxWidgets 2.8.11).
> For the moment, I would thus suggest to stay with 2.8 for a 4.6 release 
> build.
> 
>    Bastian

Hello

Thank you for immediate test.  I will use wxWidgets 2.8.12 for the moment.

Thank you for all who found and commit the slowness issue. 

Regards

Tatsuro
 

Re: Observations on the 4.6rc1 windows package

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

>>> I've fired up that virtual machine that produced that 5 minute delay
>>> earlier. Some observations on several different builds:
>>>
>>> gp46rc1-win32-setup.exe from http://gnuplot.info/development/binaries/
>>> (25-Feb-2012 07:19): a small (1-2 s) delay on startup.
>>>
>>> gp450win32-small-setup.zip from
>>> http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/ (2012-02-23, md5sum
>>> feebe279501075f8806a04a4029f899c): No delay at all!
>>>
>>> gp450win32-setup.zip from the same location (2012-02-23, md5sum
>>> 728918c93811f1644711c05fecaebd8f): several minutes of delay.
>>>
>>> I thought that if the delay is related to the initialization of the wxt
>>> terminal, then setting the GNUTERM variable to "windows" may alleviate
>>> the problem, but it didn't.
>>>
>>> Péter Juhász
>>>
>> One of the possibility is that the version of wxwidgets.  Now I am using wxwidgets-2.9.3.
>> To be clear I have to rebuiild wxwidigts 2.8 and re-provide the binary.
>> Now my condition is not so good, I cannot commit further at the moment.
>>
>> Sorry for inconvenience.
>>
>> Tatsuro
>>
>
> Hello
>
> I have downgraded wxWidgets from version 2.9.3 to 2.8.12 and built the recent cvs source.
> http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/
> gp450win32-setup.zip
>
> Please test this binary shows slow startup or not.
>
> Regards
>
> Tatsuro
>

Thanks for providing a new build so quickly! On my Vista machine your 
(old) build with wxWidgets 2.9.3 takes ~6s to start up, whereas the 
build with wxWidgets 2.8.12 takes only 0.7s. This is exactly the same 
time it takes for my own build to start up (wxWidgets 2.8.11).
For the moment, I would thus suggest to stay with 2.8 for a 4.6 release 
build.

   Bastian

Re: Observations on the 4.6rc1 windows package

[Tatsuro M. <tma...@ya...>]

--- On Mon, 2012/2/27, Tatsuro MATSUOKA  wrote:
> --- On Sat, 2012/2/25, Juhász Péter wrote:
> 
> > On Sat, 2012-02-25 at 09:04 +0100, Bastian Märkisch wrote:
> > > Am 17.02.2012 19:16, schrieb Juhász Péter:
> > > > On Fri, 2012-02-17 at 18:56 +0100, Bastian Märkisch wrote:
> > > >>
> > > >> Am 17.02.2012 18:46, schrieb Ethan A Merritt:
> > > >>> On Friday, February 17, 2012 09:35:20 am Juhász Péter wrote:
> > > >>>>
> > > >>>> - On one of my machines, startup appeared to be extremely slow, taking
> > > >>>> about 5 minutes (!). This is true for both the console and GUI versions.
> > > >>>> For the first few tries I've actually killed the process, because I
> > > >>>> didn't have the patience to wait it out. Once it started, it appeared to
> > > >>>> work normally, there were no delays and plotting was instantaneous as
> > > >>>> well. (Older versions had a long delay at the first plot because of
> > > >>>> fontconfig or whatever.)
> > > >>>> This happened in both interactive and non-interactive mode, however,
> > > >>>> only on a virtual machine running Vista. On a real computer running
> > > >>>> Windows 7, startup was instantaneous.
> > > >>>
> > > >>> I seem to recall this was discussed a couple of years ago.
> > > >>> The issue then was that if the program did not find a certain set of fonts,
> > > >>> it triggered creation of a bitmap font set from the underlying font
> > > >>> descriptions.  This was painfully slow but only  happened the first time,
> > > >>> since subsequent runs would find the  now-created font set.
> > > >>> However, I wonder if you run under a virtual machine whether every time
> > > >>> is a "first" time?  Anyhow, my best guess is that this is a font issue
> > > >>> rather than anything to do with gnuplot per se.
> > > >>>
> > > >>>     Ethan
> > > >>>
> > > >>
> > > >> The cairo terminals no longer use the fontconfig mechanism of Windows,
> > > >> so this particular issue should have been solved.
> > > >> On the other hand I vaguely remember a similar report a while ago, but I
> > > >> couldn't reproduce on various XP, Vista and 7 machines.
> > > >>
> > > >
> > > > On further testing I've noticed that there *is* a slight delay on
> > > > startup even on the Win7 machine (4-5 seconds). This means that even
> > > > something like 'gnuplot -e "print 1"' takes this much time.
> > > >
> > > > Péter Juhász
> > > >
> > > 
> > > Finally, I have been able to reproduce this delay on a Vista machine 
> > > using Tatsuro Matsuoka's 4.5 and 4.6rc1 builds. Note that the "small" 
> > > 4.5 build which does not include cairo and wxt terminals does not show 
> > > the delay on start-up.
> > > Also, I do not see any notable delay using my own build (including wxt 
> > > and cairo), see
> > > http://gnuplot.info/development/binaries/
> > > Is anybody able to reproduce this observation?
> > > 
> > >    Bastian
> > 
> > 
> > I've fired up that virtual machine that produced that 5 minute delay
> > earlier. Some observations on several different builds:
> > 
> > gp46rc1-win32-setup.exe from http://gnuplot.info/development/binaries/
> > (25-Feb-2012 07:19): a small (1-2 s) delay on startup.
> > 
> > gp450win32-small-setup.zip from
> > http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/ (2012-02-23, md5sum
> > feebe279501075f8806a04a4029f899c): No delay at all!
> > 
> > gp450win32-setup.zip from the same location (2012-02-23, md5sum
> > 728918c93811f1644711c05fecaebd8f): several minutes of delay.
> > 
> > I thought that if the delay is related to the initialization of the wxt
> > terminal, then setting the GNUTERM variable to "windows" may alleviate
> > the problem, but it didn't.
> > 
> > Péter Juhász
> > 
> One of the possibility is that the version of wxwidgets.  Now I am using wxwidgets-2.9.3.
> To be clear I have to rebuiild wxwidigts 2.8 and re-provide the binary.
> Now my condition is not so good, I cannot commit further at the moment.
> 
> Sorry for inconvenience.
> 
> Tatsuro
> 

Hello

I have downgraded wxWidgets from version 2.9.3 to 2.8.12 and built the recent cvs source.
http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/
gp450win32-setup.zip

Please test this binary shows slow startup or not.

Regards

Tatsuro

Re: Observations on the 4.6rc1 windows package

[Tatsuro M. <tma...@ya...>]

--- On Sat, 2012/2/25, Juhász Péter wrote:

> On Sat, 2012-02-25 at 09:04 +0100, Bastian Märkisch wrote:
> > Am 17.02.2012 19:16, schrieb Juhász Péter:
> > > On Fri, 2012-02-17 at 18:56 +0100, Bastian Märkisch wrote:
> > >>
> > >> Am 17.02.2012 18:46, schrieb Ethan A Merritt:
> > >>> On Friday, February 17, 2012 09:35:20 am Juhász Péter wrote:
> > >>>>
> > >>>> - On one of my machines, startup appeared to be extremely slow, taking
> > >>>> about 5 minutes (!). This is true for both the console and GUI versions.
> > >>>> For the first few tries I've actually killed the process, because I
> > >>>> didn't have the patience to wait it out. Once it started, it appeared to
> > >>>> work normally, there were no delays and plotting was instantaneous as
> > >>>> well. (Older versions had a long delay at the first plot because of
> > >>>> fontconfig or whatever.)
> > >>>> This happened in both interactive and non-interactive mode, however,
> > >>>> only on a virtual machine running Vista. On a real computer running
> > >>>> Windows 7, startup was instantaneous.
> > >>>
> > >>> I seem to recall this was discussed a couple of years ago.
> > >>> The issue then was that if the program did not find a certain set of fonts,
> > >>> it triggered creation of a bitmap font set from the underlying font
> > >>> descriptions.  This was painfully slow but only  happened the first time,
> > >>> since subsequent runs would find the  now-created font set.
> > >>> However, I wonder if you run under a virtual machine whether every time
> > >>> is a "first" time?  Anyhow, my best guess is that this is a font issue
> > >>> rather than anything to do with gnuplot per se.
> > >>>
> > >>>     Ethan
> > >>>
> > >>
> > >> The cairo terminals no longer use the fontconfig mechanism of Windows,
> > >> so this particular issue should have been solved.
> > >> On the other hand I vaguely remember a similar report a while ago, but I
> > >> couldn't reproduce on various XP, Vista and 7 machines.
> > >>
> > >
> > > On further testing I've noticed that there *is* a slight delay on
> > > startup even on the Win7 machine (4-5 seconds). This means that even
> > > something like 'gnuplot -e "print 1"' takes this much time.
> > >
> > > Péter Juhász
> > >
> > 
> > Finally, I have been able to reproduce this delay on a Vista machine 
> > using Tatsuro Matsuoka's 4.5 and 4.6rc1 builds. Note that the "small" 
> > 4.5 build which does not include cairo and wxt terminals does not show 
> > the delay on start-up.
> > Also, I do not see any notable delay using my own build (including wxt 
> > and cairo), see
> > http://gnuplot.info/development/binaries/
> > Is anybody able to reproduce this observation?
> > 
> >    Bastian
> 
> 
> I've fired up that virtual machine that produced that 5 minute delay
> earlier. Some observations on several different builds:
> 
> gp46rc1-win32-setup.exe from http://gnuplot.info/development/binaries/
> (25-Feb-2012 07:19): a small (1-2 s) delay on startup.
> 
> gp450win32-small-setup.zip from
> http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/ (2012-02-23, md5sum
> feebe279501075f8806a04a4029f899c): No delay at all!
> 
> gp450win32-setup.zip from the same location (2012-02-23, md5sum
> 728918c93811f1644711c05fecaebd8f): several minutes of delay.
> 
> I thought that if the delay is related to the initialization of the wxt
> terminal, then setting the GNUTERM variable to "windows" may alleviate
> the problem, but it didn't.
> 
> Péter Juhász
> 
One of the possibility is that the version of wxwidgets.  Now I am using wxwidgets-2.9.3.
To be clear I have to rebuiild wxwidigts 2.8 and re-provide the binary.
Now my condition is not so good, I cannot commit further at the moment.

Sorry for inconvenience.

Tatsuro

Re: Observations on the 4.6rc1 windows package

[Juhász P. <pet...@gm...>]

On Sat, 2012-02-25 at 09:04 +0100, Bastian Märkisch wrote:
> Am 17.02.2012 19:16, schrieb Juhász Péter:
> > On Fri, 2012-02-17 at 18:56 +0100, Bastian Märkisch wrote:
> >>
> >> Am 17.02.2012 18:46, schrieb Ethan A Merritt:
> >>> On Friday, February 17, 2012 09:35:20 am Juhász Péter wrote:
> >>>>
> >>>> - On one of my machines, startup appeared to be extremely slow, taking
> >>>> about 5 minutes (!). This is true for both the console and GUI versions.
> >>>> For the first few tries I've actually killed the process, because I
> >>>> didn't have the patience to wait it out. Once it started, it appeared to
> >>>> work normally, there were no delays and plotting was instantaneous as
> >>>> well. (Older versions had a long delay at the first plot because of
> >>>> fontconfig or whatever.)
> >>>> This happened in both interactive and non-interactive mode, however,
> >>>> only on a virtual machine running Vista. On a real computer running
> >>>> Windows 7, startup was instantaneous.
> >>>
> >>> I seem to recall this was discussed a couple of years ago.
> >>> The issue then was that if the program did not find a certain set of fonts,
> >>> it triggered creation of a bitmap font set from the underlying font
> >>> descriptions.  This was painfully slow but only  happened the first time,
> >>> since subsequent runs would find the  now-created font set.
> >>> However, I wonder if you run under a virtual machine whether every time
> >>> is a "first" time?  Anyhow, my best guess is that this is a font issue
> >>> rather than anything to do with gnuplot per se.
> >>>
> >>> 	Ethan
> >>>
> >>
> >> The cairo terminals no longer use the fontconfig mechanism of Windows,
> >> so this particular issue should have been solved.
> >> On the other hand I vaguely remember a similar report a while ago, but I
> >> couldn't reproduce on various XP, Vista and 7 machines.
> >>
> >
> > On further testing I've noticed that there *is* a slight delay on
> > startup even on the Win7 machine (4-5 seconds). This means that even
> > something like 'gnuplot -e "print 1"' takes this much time.
> >
> > Péter Juhász
> >
> 
> Finally, I have been able to reproduce this delay on a Vista machine 
> using Tatsuro Matsuoka's 4.5 and 4.6rc1 builds. Note that the "small" 
> 4.5 build which does not include cairo and wxt terminals does not show 
> the delay on start-up.
> Also, I do not see any notable delay using my own build (including wxt 
> and cairo), see
> http://gnuplot.info/development/binaries/
> Is anybody able to reproduce this observation?
> 
>    Bastian


I've fired up that virtual machine that produced that 5 minute delay
earlier. Some observations on several different builds:

gp46rc1-win32-setup.exe from http://gnuplot.info/development/binaries/
(25-Feb-2012 07:19): a small (1-2 s) delay on startup.

gp450win32-small-setup.zip from
http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/ (2012-02-23, md5sum
feebe279501075f8806a04a4029f899c): No delay at all!

gp450win32-setup.zip from the same location (2012-02-23, md5sum
728918c93811f1644711c05fecaebd8f): several minutes of delay.

I thought that if the delay is related to the initialization of the wxt
terminal, then setting the GNUTERM variable to "windows" may alleviate
the problem, but it didn't.

Péter Juhász

Re: Observations on the 4.6rc1 windows package

[Juhász P. <pet...@gm...>]

On Sat, 2012-02-25 at 09:04 +0100, Bastian Märkisch wrote:
> Am 17.02.2012 19:16, schrieb Juhász Péter:
> > On Fri, 2012-02-17 at 18:56 +0100, Bastian Märkisch wrote:
> >>
> >> Am 17.02.2012 18:46, schrieb Ethan A Merritt:
> >>> On Friday, February 17, 2012 09:35:20 am Juhász Péter wrote:
> >>>>
> >>>> - On one of my machines, startup appeared to be extremely slow, taking
> >>>> about 5 minutes (!). This is true for both the console and GUI versions.
> >>>> For the first few tries I've actually killed the process, because I
> >>>> didn't have the patience to wait it out. Once it started, it appeared to
> >>>> work normally, there were no delays and plotting was instantaneous as
> >>>> well. (Older versions had a long delay at the first plot because of
> >>>> fontconfig or whatever.)
> >>>> This happened in both interactive and non-interactive mode, however,
> >>>> only on a virtual machine running Vista. On a real computer running
> >>>> Windows 7, startup was instantaneous.
> >>>
> >>> I seem to recall this was discussed a couple of years ago.
> >>> The issue then was that if the program did not find a certain set of fonts,
> >>> it triggered creation of a bitmap font set from the underlying font
> >>> descriptions.  This was painfully slow but only  happened the first time,
> >>> since subsequent runs would find the  now-created font set.
> >>> However, I wonder if you run under a virtual machine whether every time
> >>> is a "first" time?  Anyhow, my best guess is that this is a font issue
> >>> rather than anything to do with gnuplot per se.
> >>>
> >>> 	Ethan
> >>>
> >>
> >> The cairo terminals no longer use the fontconfig mechanism of Windows,
> >> so this particular issue should have been solved.
> >> On the other hand I vaguely remember a similar report a while ago, but I
> >> couldn't reproduce on various XP, Vista and 7 machines.
> >>
> >
> > On further testing I've noticed that there *is* a slight delay on
> > startup even on the Win7 machine (4-5 seconds). This means that even
> > something like 'gnuplot -e "print 1"' takes this much time.
> >
> > Péter Juhász
> >
> 
> Finally, I have been able to reproduce this delay on a Vista machine 
> using Tatsuro Matsuoka's 4.5 and 4.6rc1 builds. Note that the "small" 
> 4.5 build which does not include cairo and wxt terminals does not show 
> the delay on start-up.
> Also, I do not see any notable delay using my own build (including wxt 
> and cairo), see
> http://gnuplot.info/development/binaries/
> Is anybody able to reproduce this observation?
> 
>    Bastian


Thanks for the followup. 

I did use Tatsuro Matsuoka's "full" win32 package. With that, I observed
a startup delay of a few seconds on all (real) windows machines I've
tried.
I haven't tried other builds yet, but I'll try them today.

Péter Juhász