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

about windows binaries

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

Hello

http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/


1. After long struggle, the wxt terminal works on 64 bit platform.
Using MinGW-w64 complier, the build of wxWidgets failed cc1plus hangs during 'make'
using Msys+MinGW64 toolchain.

Therefore I have build wxWidgets-3.0.0 using mingw32-make at 
wxWidgets-3.0.0\build\msw by the following command 

mingw32-make -f makefile.gcc BUILD=release SHARED=1 UNICODE=1 USE_ODBC=1

This build does not give a wx-config script. So I have to modify mingw/Makefile manually.

The using this wxWidgets, the latest cairo (cairo-1.12.16) seems not to work (no plot appear in wxt terminal window).
I carefully searched working combination of version of the glib, cairo and pango.
The resulted combination is : 
glib-2.31.22, cairo-1.10.2, and pango-1.30.1.

The pango-1.30.1 is configured --with-dynamic-modules=yes.

I do know whether the above is the best or not solution but works.


2.  For libcaca build, local patches for MinGW-w64(32 and 64 bit) to string.c and figfont.c.
I have modified the local patches. Now the 32 bit binaries work on XP again.

3. I have found that qt terminal does not work when loading gnuplot_qt.exe when my binary installed into PC in which qt binary is not installed. The error dialogs are
http://www.geocities.jp/tmgpltwin/Files/Files.html#0060

20140610_qtlog.png, 20140610_qtlog2.png


The binary packages include  Qt5Core.dll, Qt5Gui.dll, Qt5Network.dll, Qt5PrintSupport.dll, Qt5Svg.dll, and Qt5Widgets.dll as dynamic link files.  I have checked the dependency dll files for gnuplot_qt.exe using the dependency walker. However, the described dll files seem to be enough from the dependency walker analysis. 
If someone knows additional dll files for Qt terminal to work on windows PC in which Qt binary is not installed, please let me know. 

Regards

Tatsuro

OT: Employee Contracts/ NDAs and OSS contribution

[Tom L. <tl...@cp...>]

Hi-

first, sorry for an OT post in the middle of the 5.0RC phase, but…:

My company is about to impose a new Non-disclosure/ Non-compete/ Other Stuff… agreement. It’s the usual draconian nonsense, but the bit that really concerns me is the absence of explicit permission to contribute to, or found, Open Source projects. (This can of course lead to contamination of OSS projects with code which the author did not have the right to contribute…  q.v. SCO/IBM/Linux )

Happily, my company is prepared to add a clause to cover OSS development, but, much googling later, I’ve failed to turn up good legalese boilerplate to work with…

I wonder if any gnuplot devs on this list are employed by commercial companies*, are contributing to gnuplot (or other OSS) on company time (which, under some contracts, is 24/7…), and have wording in their contracts to make this OK, that we might be able to borrow…?

We’re located in Colorado, USA, but I’d be interested in wording from anywhere in the world where this might be an issue.

TIA if anyone can help, and apologies for the bandwidth…

Tom Lawton

(*US Government agencies are rather different, since they cannot copyright, and their code- unless security forbids- has to be available to the public domain; Academia may or may not fall into a similar position…)

Re: Gnuplot version 5 release candidate

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

On Friday, 06 June, 2014 11:39:53 Pieter-Tjerk de Boer wrote:
> Hello,
> 
> I've given the 5.0-rc1 release candidate a try, and a few minor things
> caught my attention:
> 
> * The .tgz source tarball doesn't seem to contain the release notes.

Yeah, the packaging script failed to include it.
I've fixed the script so that subsequent packages will include the release notes.

> * The section in the release notes on potentially backward-incompatible
>   changes does not mention the change of the default colorsequence on
>   many terminals.
>   This change doesn't stop old scripts from working, but the output
>   produced is different, which can be an issue in case of non-interactive
>   use (e.g., automatic plots on a website, with surrounding text referring
>   to colours in the plot).

FYI the old behavior is available via "set colors classic".

> * The fit command in some cases interprets one column as errors, for
>   compatibility with pre-5.0 versions, according to `help fit`.
>   Perhaps it's an idea to change this, making 'noerror' the default,
>   since 5.0 isn't supposed to be fully compatible anyway?
>   That seems more systematic: then the error column is only there when
>   explicitly indicated, and it makes the 'using' specification in case
>   of 2 independent variables similar to what the user expects from splot.

I find myself somewhat by the new keywords also.
The v5 docs appear contradictory. 
First it says:

   If specified using the `errors` or `zerrors` keyword, the last column `s` is
   interpreted as the standard deviation of the corresponding z value and is
   used to compute a weight for the datum, 1/s**2.  Otherwise, all data points
   are weighted equally, with a weight of one. 

That appears to say that "noerror" is the default.  
But then later it says

    [...] this means that you always have to supply z-errors s in a fit with two
    independent variables x, y if you do not specify the `{no}error`  keyword. 

which appears to say that "noerror" is _not_ the default, at least for the 3D 
case.  Hence my confusion.  Do the keywords mean different things in 
the 2D, 3D, and ND cases?

For me the most useful statement in the v5 docs was that the "yerror"
keyword made fit work analogously to "plot with yerrorbars".
Perhaps either the documentation or the keywords themselves could
be made to match better with "plot/splot" commands?

> Regards,
>   Pieter-Tjerk

Thanks for the feedback.

	Ethan

Re: Gnuplot version 5 release candidate

[Pieter-Tjerk de B. <p.t...@ut...>]

Hello,

I've given the 5.0-rc1 release candidate a try, and a few minor things
caught my attention:

* The .tgz source tarball doesn't seem to contain the release notes.

* The section in the release notes on potentially backward-incompatible
  changes does not mention the change of the default colorsequence on
  many terminals.
  This change doesn't stop old scripts from working, but the output
  produced is different, which can be an issue in case of non-interactive
  use (e.g., automatic plots on a website, with surrounding text referring
  to colours in the plot).

* The fit command in some cases interprets one column as errors, for
  compatibility with pre-5.0 versions, according to `help fit`.
  Perhaps it's an idea to change this, making 'noerror' the default,
  since 5.0 isn't supposed to be fully compatible anyway?
  That seems more systematic: then the error column is only there when
  explicitly indicated, and it makes the 'using' specification in case
  of 2 independent variables similar to what the user expects from splot.

Regards,
  Pieter-Tjerk

Re: qt terminal is now default for windows binary

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

----- Original Message -----
> From: Mojca Miklavec 
> To: Tatsuro MATSUOKA 
> Cc: 
> Date: 2014/6/3, Tue 21:28
> Subject: Re: qt terminal is now default for windows binary
> 
> On Tue, Jun 3, 2014 at 6:37 AM, Tatsuro MATSUOKA wrote:
>>  Hello
>> 
>>  I have built qt 5.3.0 by myself for both 32bit and 64bit and they are now 
> used for gnuplot build. Slowness issue is solved.
> 
> How exactly did you solve it?
> 
> Thank you,
>     Mojca


Nothing. I just change qt version from 4.8 to 5.3.

Bastian toled me Qt5 did not have problem:

http://gnuplot.10905.n7.nabble.com/cannot-find-entry-symbol-mainCRTStartup-defaulting-to-00401000-gnuplot-qt-td18461.html#a18472

On native windows (except cygwin), qt4 seems to have performance problem for gnuplot build.

Regards

Tatsuro 

Re: Should 'dashlength' affect only builtin or also custom dash patterns?

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

On Mon, Jun 2, 2014 at 5:39 PM, sfeam wrote:
> On Monday, 02 June 2014 11:18:08 AM Christoph Bersch wrote:
>>
>> Zitat von sfeam <sf...@us...>:
>>
>> > On Sunday, 01 June 2014 07:34:53 PM Christoph Bersch wrote:
>> >
>> >> I've seen, that different terminals handle the `dashlength` option
>> >> differently:
>> >>
>> >> set termoption dashlength 1
>> >> plot x dt 2, 2*x dt '.-'
>> >> pause -1
>> >>
>> >> set termoption dashlength 3
>> >> replot
>> >>
>> >> `qt`: dashlength affects only the custom dash pattern
>> >> `wxt`: both patterns are stretched
>> >> `post`: only the builtin patterns are affected
>> >>
>> >> This behaviour should be equal for all terminals.
>> >
>> > Good point.
>>
>> I've had a quick look at the Qt-documentation, but I couldn't find an
>> option to change the dash length for the builtin patterns.
>
> Correct.
>
>> Another thing I've seen is, that for some terminals the dash pattern
>> length depends on the linewidth, e.g. for the `qt` terminal. For
>> others, like the `wxt` terminal it doesn't.
>
> Qt docs:  "the dash pattern is specified in units of the pens width"
>
>> [...] we should try to have similar
>> behavior across the terminals, or at least try to.
>
> For output devices that really do provide their own dash types
> we can't do much other than use them as provided.

But wxt isn't a black box that simply draws dashed lines with "please
give me dash type 3" and could probably be fixed. I'm attaching an
example of a patch that fixes at least some cases (please note that
I'm not familiar with wxt code, I haven't verified or tested the patch
extensively, it's just a quick hack and it's possible that I made
mistakes; use it only as a proof-of-principle for now).

> But we can aim for consistent behavior of the new "custom"
> dashtypes.  I kind of like the Qt approach of scaling the
> dashlength with the line width.  I'm not certain that would
> work for all terminal types but it's something to think about.

I agree. Scaling the dash length with the pen width certainly makes
sense. In all terminals where this can be supported.

Mojca

qt terminal is now default for windows binary

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

Hello

I have built qt 5.3.0 by myself for both 32bit and 64bit and they are now used for gnuplot build. Slowness issue is solved. Therefore, for binaries from today (2014-06-03), the qt terminal is default.

http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/

If you found some trouble, please let me now through the gnuplot-beta list.
https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Enjoy!

Tatsuro

Re: Should 'dashlength' affect only builtin or also custom dash patterns?

[sfeam <sf...@us...>]

On Monday, 02 June 2014 11:18:08 AM Christoph Bersch wrote:
> 
> Zitat von sfeam <sf...@us...>:
> 
> > On Sunday, 01 June 2014 07:34:53 PM Christoph Bersch wrote:
> >
> >> I've seen, that different terminals handle the `dashlength` option
> >> differently:
> >>
> >> set termoption dashlength 1
> >> plot x dt 2, 2*x dt '.-'
> >> pause -1
> >>
> >> set termoption dashlength 3
> >> replot
> >>
> >> `qt`: dashlength affects only the custom dash pattern
> >> `wxt`: both patterns are stretched
> >> `post`: only the builtin patterns are affected
> >>
> >> This behaviour should be equal for all terminals.
> >
> > Good point.
> 
> I've had a quick look at the Qt-documentation, but I couldn't find an  
> option to change the dash length for the builtin patterns.

Correct.

> Another thing I've seen is, that for some terminals the dash pattern  
> length depends on the linewidth, e.g. for the `qt` terminal. For  
> others, like the `wxt` terminal it doesn't.

Qt docs:  "the dash pattern is specified in units of the pens width"

> [...] we should try to have similar  
> behavior across the terminals, or at least try to.

For output devices that really do provide their own dash types
we can't do much other than use them as provided.  
But we can aim for consistent behavior of the new "custom"
dashtypes.  I kind of like the Qt approach of scaling the
dashlength with the line width.  I'm not certain that would
work for all terminal types but it's something to think about.

	Ethan

Re: Should 'dashlength' affect only builtin or also custom dash patterns?

[Christoph B. <us...@be...>]

Zitat von sfeam <sf...@us...>:

> On Sunday, 01 June 2014 07:34:53 PM Christoph Bersch wrote:
>
>> I've seen, that different terminals handle the `dashlength` option
>> differently:
>>
>> set termoption dashlength 1
>> plot x dt 2, 2*x dt '.-'
>> pause -1
>>
>> set termoption dashlength 3
>> replot
>>
>> `qt`: dashlength affects only the custom dash pattern
>> `wxt`: both patterns are stretched
>> `post`: only the builtin patterns are affected
>>
>> This behaviour should be equal for all terminals.
>
> Good point.

I've had a quick look at the Qt-documentation, but I couldn't find an  
option to change the dash length for the builtin patterns.

Another thing I've seen is, that for some terminals the dash pattern  
length depends on the linewidth, e.g. for the `qt` terminal. For  
others, like the `wxt` terminal it doesn't.

This gives the following problem with the `wxt` terminal:

With the default setting of the line cap (square, see  
http://cairographics.org/samples/set_line_cap/), a thick, dashed line  
becomes solid:

plot x dt 2 lw 10

This gives a solid line for me. Using `set termoption butt` resolves  
this, but the dashes look strange, being more dots than dashes. So  
this would be another point, where we should try to have similar  
behavior across the terminals, or at least try to.


> I am also wondering whether the dashtype or linetype itself should
> include a dashlength attribute, independent of the terminal setting.
> Thus you could say:
>
>    set dashtype 1 ".-.-" dashlength 0.5
>
> or
>
>    set linetype 1 dashtype "._._" dashlength 0.5

Yes, that looks like a reasonable option.

Christoph

win64 binaries are uploaded (without wxt)

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

Although the wxt terminal has not been implemented yet, I uploaded 64bit binaries of gnuplot for windows.

http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/

Reason of lack of wxt terminal is that I have not been able to build the wxWidgets because the  MinGW-w64 compiler hangs in compiling some c++ codes in the wxWidgets.

If someone succeeded in building the wxWidgets using MinGW-w64 compiler, please let me know.

Tatsuro

a few small mingw inconsistencies

[Karl R. <ra...@un...>]

Hi,

i´ve noticed a few small inconsistencies around the mingw Makefile :

- "make wgnuplot.mnu" throws an error about a "circular dependency" and
does nothing, only "make install" (which does not call "wgnuplot.mnu")
directly copies the file to the installation directory

- making the japanese help file stops if iconv is not available.
Attached patch adds a JA_HELP option in the upper part of the makefile,
and tells the user that iconv is needed. (On my system the mingw
iconv.exe misses libintl-8.dll, which only comes with the gtk+ bundle.
There´s something wrong in mingw here, i guess.)

- making wgnuplot.exe stops at wpause.c if MOUSE=1 is not defined

- "make docs" should depend on NEWGD or BGD or CAIROTERMS or PDF

- Weren´t those "-mpentium" optimization flags removed from gcc ~ ten
years ago?

I´m on win7/MinGW4.8.2, but i think this should apply for all mingw systems.

Best regards,
   Karl



-- 
Karl-Friedrich Ratzsch (Dipl. Chem.)
Freiburger Materialforschungszentrum / Universität Freiburg
Stefan-Meier-Straße 21, 79104 Freiburg im Breisgau
Tel. 0761/203-4748 Fax:-4701
ra...@un...

Re: Should 'dashlength' affect only builtin or also custom dash patterns?

[sfeam <sf...@us...>]

On Sunday, 01 June 2014 07:34:53 PM Christoph Bersch wrote:

> I've seen, that different terminals handle the `dashlength` option  
> differently:
> 
> set termoption dashlength 1
> plot x dt 2, 2*x dt '.-'
> pause -1
> 
> set termoption dashlength 3
> replot 
> 
> `qt`: dashlength affects only the custom dash pattern
> `wxt`: both patterns are stretched
> `post`: only the builtin patterns are affected
> 
> This behaviour should be equal for all terminals.

Good point.

I am also wondering whether the dashtype or linetype itself should
include a dashlength attribute, independent of the terminal setting.
Thus you could say:

   set dashtype 1 ".-.-" dashlength 0.5

or

   set linetype 1 dashtype "._._" dashlength 0.5

The first option would add a new field to struct t_dashtype.
The second would instead add a new field to struct lp_style_type.
I have not tried implementing either of these options.
It may turn out that one option is easier/better than the other.

Either way this factor would be multiplied by the terminal's own
dashlength setting.

	Ethan

> My suggestion is to have the dashlength option apply to all dash  
> patterns. Especially for patterns of the kind `dt '.-'` it is very  
> helpful to have the ability to change the basic unit of the patterns.
> 
> I wanted to discuss this before I submit any patches to sf.
> 
> Best regards,
> Christoph

Should 'dashlength' affect only builtin or also custom dash patterns?

[Christoph B. <us...@be...>]

Hi,

I've seen, that different terminals handle the `dashlength` option  
differently:

set termoption dashlength 1
plot x dt 2, 2*x dt '.-'
pause -1

set termoption dashlength 3
replot


`qt`: dashlength affects only the custom dash pattern
`wxt`: both patterns are stretched
`post`: only the builtin patterns are affected

This behaviour should be equal for all terminals.

My suggestion is to have the dashlength option apply to all dash  
patterns. Especially for patterns of the kind `dt '.-'` it is very  
helpful to have the ability to change the basic unit of the patterns.

I wanted to discuss this before I submit any patches to sf.

Best regards,
Christoph

Re: I cannot inculde gnuplot_qt.exe into installer file.

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

--- On Fri, 2014/5/30, Tatsuro MATSUOKA wrote:
> I cannot include gnuplot_qt.exe into the  installer file.
> 
> I made a patch the below
> https://sourceforge.net/p/gnuplot/patches/689/
> 
> But I also could not.

I have slightly modified the patch and it seems to work.
https://sourceforge.net/p/gnuplot/patches/689/

Re: incorrect plot on qt terminal on windows (MinGW) (was Re: cannot find entry symbol mainCRTStartup; defaulting to 00401000 (gnuplot_qt))

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

--- On Fri, 2014/5/30, Tatsuro MATSUOKA wrote:
> --- On Fri, 2014/5/30, Bastian Märkisch  wrote:
> 
> > I cannot reproduce your problems here using MSVC 2012 and pre-built Qt 
> > 5.1.2 (MSVC) on Windows 8. Also MinGW with pre-built Qt 5.1.2 (MinGW64) 
> > works as expected. That is actually somewhat surprising since this mixes 
> > MinGW's libs with MinGW64's ...
> > 
> > Have you tried using the provided binary Qt versions for MinGW64?
> > 
> 
> The MinGW64 projrcts provides both 64 bit and 32 bit compliers.  
> Which one do you indicate by MinGW64.
> 
> First try I have tried pre-built Qt 5.3.0 on MinGW 4.8.2 32bit.
> But the compliler is posix threads version.
> I have built my all dependencies using win32 threads.
> 
> Therefore I build Qt 4.8.6 on MinGW w62-32 dawarf2 win32 thread and used.

Although MinGW binary for Qt 5.3 is created by MinGW 4.8.2 with posix thread I heve tried again building gnuplot binary. As you told, the mouse operation can be done without problem.  At the moment I will use Qt 5.3 pre-build binary and will y be replaced  by self build one using MinGW with win32 thread.

Thank you for your advise.

Tatsuro

I cannot inculde gnuplot_qt.exe into installer file.

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

Hello

I cannot include gnuplot_qt.exe into the  installer file.

I made a patch the below
https://sourceforge.net/p/gnuplot/patches/689/

But I also could not.

Any suggestions?

Tatsuro

a typo in ChangeLog

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

2014-05-29  Akira Kakuto <ka...@fu...>

	* term/caca/trm:  Modify nominal codepage to accommodate CJK Windows.

"term/caca/trm" should be "term/caca.trm" 

Tatsuro

Re: incorrect plot on qt terminal on windows (MinGW) (was Re: cannot find entry symbol mainCRTStartup; defaulting to 00401000 (gnuplot_qt))

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

--- On Fri, 2014/5/30, Bastian Märkisch  wrote:

> I cannot reproduce your problems here using MSVC 2012 and pre-built Qt 
> 5.1.2 (MSVC) on Windows 8. Also MinGW with pre-built Qt 5.1.2 (MinGW64) 
> works as expected. That is actually somewhat surprising since this mixes 
> MinGW's libs with MinGW64's ...
> 
> Have you tried using the provided binary Qt versions for MinGW64?
> 

The MinGW64 projrcts provides both 64 bit and 32 bit compliers.  
Which one do you indicate by MinGW64.

First try I have tried pre-built Qt 5.3.0 on MinGW 4.8.2 32bit.
But the compliler is posix threads version.
I have built my all dependencies using win32 threads.

Therefore I build Qt 4.8.6 on MinGW w62-32 dawarf2 win32 thread and used.

Regards

Tatsuro
 

Re: incorrect plot on qt terminal on windows (MinGW) (was Re: cannot find entry symbol mainCRTStartup; defaulting to 00401000 (gnuplot_qt))

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

I cannot reproduce your problems here using MSVC 2012 and pre-built Qt 
5.1.2 (MSVC) on Windows 8. Also MinGW with pre-built Qt 5.1.2 (MinGW64) 
works as expected. That is actually somewhat surprising since this mixes 
MinGW's libs with MinGW64's ...

Have you tried using the provided binary Qt versions for MinGW64?

Bastian


Am 29.05.2014 07:32, schrieb Tatsuro MATSUOKA:
> --- On Thu, 2014/5/29, Tatsuro MATSUOKA wrote:
>
>> You are right.  I restart gnuplot qt terminal begin works correctly but mousing and zooming seems not to work.
>>
>> Tatsuro
>
> Mousing and zoom works but slow.
> Translation does not work.
> Tatsuro
>

qt translation on windows platform

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

Hello

I have submitted a patch for qt translation on windows platform to the patch ticket.

https://sourceforge.net/p/gnuplot/patches/687/

This is a work by Akira Kakuto on msvc and I received it and tested it on MinGW.

Tatsuro

Re: Gnuplot version 5 release candidate

[Tait <gnu...@t4...>]

I tried the 20140528 binaries and they do not exhibit the same
symptoms anymore. The plot window appears immediately, even without
moving the mouse. Thanks


Tatsuro MATSUOKA <tma...@ya...> said (on 2014/05/26):
> Bastian made a fix 
> *************************************************************
> 2014-05-24  Bastian Maerkisch  <bma...@we...>
> 
> 	* src/wxterminal/wxt_gui.cpp (wxt_waitforinput):  Do not wait for an
> 	event when only checking for mouse events.
> 	Bugfix
> *************************************************************
> and I rebuilt Windows binaries.
> 
> Please test the fixed binaries solve your problem.
> 
> --- On Thu, 2014/5/22, Tatsuro MATSUOKA wrote:
> > --- On Wed, 2014/5/21, Tatsuro MATSUOKA  wrote:
> > > Tait. Please confirm whether your operation works well on windows terminal.
> > > 
> > > I suspect that the change on 2014-01-04 is related to that you pointed out.
> > > I have aware the phenomenon that all .dem on wxt terminal on windows does not work correctly. Shigeharu Takeno also pointed out that point in the private mail to me.
> > > 
> > > --- On Wed, 2014/5/21, Tait wrote:
> > > > I don't see the windows binaries on SourceForge, but I did pull them
> > > > from Tatsuro's site, and the default wxt terminal behaves oddly, now.
> > > > When I load a script containing "set contour" and a plot or splot, the
> > > > plot window does not appear until after I move the mouse. Without the
> > > > "set contour", without the (s)plot, or when not from within a script,
> > > > the plot displays immediately.
> > > > 
> > > > To try it out, create a script:
> > > >     reset
> > > >     set contour
> > > >     plot x
> > > > 
> > > > then 'load "thatscript.gps"' from within gnuplot, without touching the
> > > > mouse. No plot or plot window is displayed. As soon as the mouse
> > > > moves, the window appears, with the plot as expected. The behavior is
> > > > repeatable, for me. Does anybody else see this as well?
> > > > 
> > > > Ethan A Merritt <sf...@us...> said (on 2014/05/19):
> > > > > A source tarball for the version 5.0-rc1 release candidate 
> > > > > is now publically accessible on SourceForge:...

Re: incorrect plot on qt terminal on windows (MinGW) (was Re: cannot find entry symbol mainCRTStartup; defaulting to 00401000 (gnuplot_qt))

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

--- On Thu, 2014/5/29, Tatsuro MATSUOKA wrote:

> You are right.  I restart gnuplot qt terminal begin works correctly but mousing and zooming seems not to work.
> 
> Tatsuro

Mousing and zoom works but slow.
Translation does not work.
Tatsuro

Re: incorrect plot on qt terminal on windows (MinGW) (was Re: cannot find entry symbol mainCRTStartup; defaulting to 00401000 (gnuplot_qt))

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

> > 
> > See: 
> > http://www.geocities.jp/tmgpltwin/Files/Files.html#0058
> > 20140529qt_mgw.png
> > 
> > On the command line I found the message:
> > 
> > gnuplot> plot sin(x)
> > 
> > Warning: slow font initializationqt_processTermEvent received a GE_fontprops eve
> > nt. This should not have happened.
> > 
> > Any suggestions?
> 
--- On Thu, 2014/5/29, sfeam wrote:
> Is the process gnuplot_qt running at this point, or has it died?
> 
> If gnuplot_qt is running then I think the problem really is due to the font
> server, not gnuplot.   The one time I saw this on linux, it was with a 
> newly installed Windows font.  The first plot command in gnuplot produced 
> that error message and failed to obtain the font.  However by the second
> plot command the font had finished initializing and the message never appeared
> again.
> 
>     Ethan
Ethan.

You are right.  I restart gnuplot qt terminal begin works correctly but mousing and zooming seems not to work.

Tatsuro

Re: incorrect plot on qt terminal on windows (MinGW) (was Re: cannot find entry symbol mainCRTStartup; defaulting to 00401000 (gnuplot_qt))

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

--- On Thu, 2014/5/29, Tatsuro MATSUOKA wrote:
> --- On Thu, 2014/5/29, Tatsuro MATSUOKA wrote:
> > --- On Thu, 2014/5/29, Daniel J Sebald wrote:
> > > On 05/28/2014 09:03 PM, Tatsuro MATSUOKA wrote:
> > > > Hello
> > > >
> > > > I am trying to build gnuplot for windows with qt terminal on MinGW platform.
> > > >
> > > > In linking gnuplot_qt.exe, the following warnig appear:
> > > >   warning: cannot find entry symbol mainCRTStartup; defaulting to 00401000
> > > >
> > > > Perhaps this is related to failure in executing qt terminal.
> > > 
> > > Maybe, but I don't think so because the program runs.  That warning is 
> > > indicating that the linker can't find main(){} for some reason and is 
> > > making a good guess at it.
> > 
> > Thank you for your reply.
> > gnuplot_qt.cpp has apparently a main() function.
> > 
> > <snip>
> > #include "QtGnuplotApplication.h"
> > #include <QtCore>
> > #include <signal.h>
> > 
> > int main(int argc, char* argv[])
> > <snip>
> > 
> > 
> > 
> > > 
> > > 
> > > > Terminal type set to 'qt'
> > > > gnuplot>  plot sin(x)
> > > > Could not connect to gnuplot_qt "qtgnuplot4832" . Starting a new one
> > > >
> > > > Warning: slow font initializationgnuplot>
> > > >
> > > > I'm now using Qt-4.8.6 build myself using the same gcc (4.8.2 MinGW-w64 win32) to build
> > > > gnuplot and dependencies.
> > > 
> > > This sounds like the issue that came up not too long ago about TrueType 
> > > fonts taking much longer than they should to load.  There were two 
> > > TrueType fonts in particular found to be the problem, but I forget which.
> > 
> > Mmmm. Does anyone remember the issue?
> > 
> > Anyway thanks for your pointer.
> > 
> > Tatsuro  
> > 
> 
> I have referred msvc/Makefile.  From the description "$(LD) /entry:mainCRTStartup" in it, I have used  -Wl,-emainCRTStartup flag.  I deleted this flag and I can see qt terminal plot but it is insufficient.
> 
> See: 
> http://www.geocities.jp/tmgpltwin/Files/Files.html#0058
> 20140529qt_mgw.png
> 
> On the command line I found the message:
> 
> gnuplot> plot sin(x)
> 
> Warning: slow font initializationqt_processTermEvent received a GE_fontprops eve
> nt. This should not have happened.
> 
> Any suggestions?

I closed gnuplot and restart it and then 

Terminal type set to 'qt'
gnuplot> plot sin(x)
gnuplot>

No meassage appeared and plot is appeared as:
http://www.geocities.jp/tmgpltwin/Files/Files.html#0059
20140529qt_mgw2.png

However, mouse zoom and grid buttom does not work. Other features (like save as) will be tested later.

Regards

Tatsuro

Re: incorrect plot on qt terminal on windows (MinGW) (was Re: cannot find entry symbol mainCRTStartup; defaulting to 00401000 (gnuplot_qt))

[sfeam <sf...@us...>]

On Thursday, 29 May 2014 01:17:20 PM Tatsuro MATSUOKA wrote:
> --- On Thu, 2014/5/29, Tatsuro MATSUOKA wrote:
> > --- On Thu, 2014/5/29, Daniel J Sebald wrote:
> > > On 05/28/2014 09:03 PM, Tatsuro MATSUOKA wrote:
> > > > Hello
> > > >
> > > > I am trying to build gnuplot for windows with qt terminal on MinGW platform.
> > > >
> > > > In linking gnuplot_qt.exe, the following warnig appear:
> > > >   warning: cannot find entry symbol mainCRTStartup; defaulting to 00401000
> > > >
> > > > Perhaps this is related to failure in executing qt terminal.
> > > 
> > > Maybe, but I don't think so because the program runs.  That warning is 
> > > indicating that the linker can't find main(){} for some reason and is 
> > > making a good guess at it.
> > 
> > Thank you for your reply.
> > gnuplot_qt.cpp has apparently a main() function.
> > 
> > <snip>
> > #include "QtGnuplotApplication.h"
> > #include <QtCore>
> > #include <signal.h>
> > 
> > int main(int argc, char* argv[])
> > <snip>
> > 
> > 
> > 
> > > 
> > > 
> > > > Terminal type set to 'qt'
> > > > gnuplot>  plot sin(x)
> > > > Could not connect to gnuplot_qt "qtgnuplot4832" . Starting a new one
> > > >
> > > > Warning: slow font initializationgnuplot>
> > > >
> > > > I'm now using Qt-4.8.6 build myself using the same gcc (4.8.2 MinGW-w64 win32) to build
> > > > gnuplot and dependencies.
> > > 
> > > This sounds like the issue that came up not too long ago about TrueType 
> > > fonts taking much longer than they should to load.  There were two 
> > > TrueType fonts in particular found to be the problem, but I forget which.
> > 
> > Mmmm. Does anyone remember the issue?
> > 
> > Anyway thanks for your pointer.
> > 
> > Tatsuro  
> > 
> 
> I have referred msvc/Makefile.  From the description "$(LD) /entry:mainCRTStartup" in it, I have used  -Wl,-emainCRTStartup flag.  I deleted this flag and I can see qt terminal plot but it is insufficient.
> 
> See: 
> http://www.geocities.jp/tmgpltwin/Files/Files.html#0058
> 20140529qt_mgw.png
> 
> On the command line I found the message:
> 
> gnuplot> plot sin(x)
> 
> Warning: slow font initializationqt_processTermEvent received a GE_fontprops eve
> nt. This should not have happened.
> 
> Any suggestions?


Is the process gnuplot_qt running at this point, or has it died?

If gnuplot_qt is running then I think the problem really is due to the font
server, not gnuplot.   The one time I saw this on linux, it was with a 
newly installed Windows font.  The first plot command in gnuplot produced 
that error message and failed to obtain the font.  However by the second
plot command the font had finished initializing and the message never appeared
again.

	Ethan


> 
> Regards
> 
> Tatsuro
> 
> 
> ------------------------------------------------------------------------------
> Time is money. Stop wasting it! Get your web API in 5 minutes.
> www.restlet.com/download
> http://p.sf.net/sfu/restlet
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta