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

Re: cannot find entry symbol mainCRTStartup; defaulting to 00401000 (gnuplot_qt)

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

On 05/28/2014 10:30 PM, 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>

Sorry Tatsuro, I could have been clearer.  In the Makefile for is a 
specification that the entry point should be mainCRTStartup:

gnuplot_qt.exe: ui_QtGnuplotSettings.h $(GNUPLOTQTOBJS)
	$(LD) /entry:mainCRTStartup /subsystem:windows $(LDFLAGS) 
/map:gnuplot_qt.map /out:$@ $(GNUPLOTQTOBJS) $(QTLIBS) shell32.lib

The linker is not finding that for some reason and defaults to the 
main(){} function, which is most likely offset 00401000 if one were to 
look at the linker map.

I'm not real familiar with the way Windows launches a program, but here 
is a summary:

http://stackoverflow.com/questions/22934206/what-is-the-difference-between-main-and-maincrtstartup


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

I'm sure.  We looked at this one for quite a while thinking we could 
find a solution, but then realized there wasn't a good one if a font 
library takes so long to load.  But who knows?  Perhaps you've found the 
source of the very slow fonts.  (It would be nice, but I'm not counting 
on it.)  Maybe (repeat "maybe") by going directly to main() and 
bypassing the run-time library setup routines at the launch the system 
fonts hash/tree/whatever isn't setup properly and the system has to 
search for a long time to find the fonts rather than jumping right to them.

If you can figure out how to link your system to get rid of the warning 
message, and if that solves the slow font problem, it could lead somewhere.

Dan

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

Regards

Tatsuro

Re: cannot find entry symbol mainCRTStartup; defaulting to 00401000 (gnuplot_qt)

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

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

 

Re: cannot find entry symbol mainCRTStartup; defaulting to 00401000 (gnuplot_qt)

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

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.


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

Dan

cannot find entry symbol mainCRTStartup; defaulting to 00401000 (gnuplot_qt)

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

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.

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.

Regards

Tatsuro

Re: win7: erratic console behaviour after first plot on wxt terminal

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

This is forwarded message.
--- Karl Ratzsch wrote:
> From: Karl Ratzsch 
> Subject: Re: win7: erratic console behaviour after first plot on wxt terminal
> To: "Tatsuro MATSUOKA" 
> Date: Mon, 26 May 2014 10:35:51 +0900
> 
> On 26.05.2014 02:40, Tatsuro MATSUOKA wrote:
> > I have updated the binary on my website.
> > 
> > Karl Ratzsch.
> > Please confirm whether the fix by Bastian are fix your problem or not.
> > 
> 
> Problem definitely sems fixed, scripts run much faster now. Thanks!
> 
> The test script i attached last week was the wrong one, of course,
> the original one timed some commands with time(). Sorry.
> 
> Best,
>   Karl
> 
> -- 
> Karl-Friedrich Ratzsch (Dipl. Chem.)
> Freiburger Materialforschungszentrum, Universität Freiburg
> Stefan-Meier-Straße 21, 79104 Freiburg i. Br.
> Tel.: 0761/203-4748 Fax: -4701
> 

Re: qt terminal for windows binary

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

--- On Mon, 2014/5/26, Bastian Märkisch <bma...@we...> wrote:

> Am 24.05.2014 22:48, schrieb Tatsuro MATSUOKA:
> > Hello
> >
> > Prof. Kakuto prepared gnuplot binary for windows with qt terminal using msvc complier
> > http://ctan.ijs.si/mirror/w32tex/w32/
> > gnuplot-50plrc1w32.zip
> >
> > An example snapshot are
> > http://www.geocities.jp/tmgpltwin/Files/Files.html#0057
> > qtTerminalSin.png
> >
> > I execute all.dem, the speed is faster than that of wxt terminal.
> > (On Ununtu, I found qt terminal is faster than wxt terminal.)
> >
> > BTW, in the gnuplot/config/msvc/Makefile, I found the description:
> >
> > # Build qt terminal? WARNING: the qt terminal should build, but does not work correctly.
> > # Only enable it if you want to work on fixing qt terminal on windows.
> > # (Basic problem: qt_waitforinput() uses select() to wait on stdin and a named
> > # pipe simultaneously. On Windows, this fails, because select() on Windows can
> > # only be used on network sockets)
> >
> > I asked Prof. Kakuto what is done in response to the above description.
> > He replied that no work around is done to the problem described the above.
> >
> > Does anyone fixed the problem for qt terminal for windows?
> 
> That comment is indeed out-of-date. The qt terminal is supported on 
> Windows using MSVC since 2014-02-14 (plus subsequent patches).
> 
>    Bastian
Reading the code of qt_term.cpp, the procedures that are windows specific are described
Thank you for your reply.  The comment in the msvc/Makefile should be deleted.

Thanks! 

Tatsuro 

Re: qt terminal for windows binary

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

Am 24.05.2014 22:48, schrieb Tatsuro MATSUOKA:
> Hello
>
> Prof. Kakuto prepared gnuplot binary for windows with qt terminal using msvc complier
> http://ctan.ijs.si/mirror/w32tex/w32/
> gnuplot-50plrc1w32.zip
>
> An example snapshot are
> http://www.geocities.jp/tmgpltwin/Files/Files.html#0057
> qtTerminalSin.png
>
> I execute all.dem, the speed is faster than that of wxt terminal.
> (On Ununtu, I found qt terminal is faster than wxt terminal.)
>
> BTW, in the gnuplot/config/msvc/Makefile, I found the description:
>
> # Build qt terminal? WARNING: the qt terminal should build, but does not work correctly.
> # Only enable it if you want to work on fixing qt terminal on windows.
> # (Basic problem: qt_waitforinput() uses select() to wait on stdin and a named
> # pipe simultaneously. On Windows, this fails, because select() on Windows can
> # only be used on network sockets)
>
> I asked Prof. Kakuto what is done in response to the above description.
> He replied that no work around is done to the problem described the above.
>
> Does anyone fixed the problem for qt terminal for windows?

That comment is indeed out-of-date. The qt terminal is supported on 
Windows using MSVC since 2014-02-14 (plus subsequent patches).

   Bastian

>
> As a note, Prof. Kakuto uses qt-5.3.0 for qt terminal building.
>
> I am now trying to revise gnuplot/config/mingw/Makefile and support the qt terminal on mingw platform.
>
> Regards
>
> Tatsuro
>

Re: Gnuplot version 5 release candidate

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

--- On Thu, 2014/5/22, Tatsuro MATSUOKA wrote:
> --- On Wed, 2014/5/21, Tatsuro MATSUOKA  wrote:
> > --- 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:...
> > 
> > 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.
> > 

Tait

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.

Tatsuro

Re: win7: erratic console behaviour after first plot on wxt terminal

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

--- On Sat, 2014/5/24, Tatsuro MATSUOKA  wrote:
> --- On Sat, 2014/5/24, Bastian Märkischwrote:
> > Got it. wxt_waitforinput() was waiting for an event even when called 
> > with TERM_ONLY_CHECK_MOUSING. Now fixed in CVS.
> > 
> >    Bastian
> I have confirmed the fix. Thanks!
> I will update my binary distribution on Monday.
> 

I have updated the binary on my website.

Karl Ratzsch.
Please confirm whether the fix by Bastian are fix your problem or not.

Tatsuro  

Re: win7: erratic console behaviour after first plot on wxt terminal

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

--- On Sat, 2014/5/24, Bastian Märkisch wrote:

> Got it. wxt_waitforinput() was waiting for an event even when called 
> with TERM_ONLY_CHECK_MOUSING. Now fixed in CVS.
> 
>    Bastian
> 
> 
> Am 23.05.2014 06:47, schrieb Bastian Märkisch:
> > This seems to be an effect of the event handling: gnuplot seems to wait
> > for an event and blocks. Just moving the mouse inside plot window
> > terminates the  "waiting" e.g. I will see if I can find the time to
> > track this down over the weekend. IMHO this bug is release critical.
> >
> >     Bastian
> >
> >
> > Am 22.05.2014 23:33, schrieb Karl Ratzsch:
> >> Hi,
> >>
> >> this happens on win7 with the 5.0 binaries both from Tatsuro and the
> >> older one from Bastian (so both with wxgtk2.8 and 3.0): After the
> >> first plot on a wxt terminal, any command that is loaded from a file
> >> can take several seconds. Function declarations, plots, whatever.
> >> This only goes away when another terminal ist set, and resumes when
> >> a new plot is done on wxt.
> >>
> >> The exact times are only reproducible with the exact same script,
> >> and plots sometimes even get stuck and the script only resumes after
> >> changing the focus back to the gp console window. Several commands
> >> in one line (separated with ";") don´t seem to take longer that one.
> >>
> >> I´ve attached the script i used to probe this on three win7 machines.
> >>
> >> And this also works when a command including a linefeed is
> >> copypasted into the console.
> >>
> >> It does not depend on uses privileges like the exit problem
> >> https://sourceforge.net/p/gnuplot/bugs/1384/
> >>
> >> Best,
> >>      Karl
> >>
> 
Hello  Karl

Prof. Kakuto prepared a new snapshot gnuplot-5.0rc1 on
http://ctan.ijs.si/mirror/w32tex/w32/
gnuplot-50plrc1w32.zip 

Note that the default terminal on his binary is windows terminal.
You can use wxt or qt terminal explicitly set

set term wxt
or
set term qt

Please confirm whether your problem is solved in the new snapshot binary.

Tatsuro

qt terminal for windows binary

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

Hello

Prof. Kakuto prepared gnuplot binary for windows with qt terminal using msvc complier
http://ctan.ijs.si/mirror/w32tex/w32/
gnuplot-50plrc1w32.zip

An example snapshot are
http://www.geocities.jp/tmgpltwin/Files/Files.html#0057
qtTerminalSin.png

I execute all.dem, the speed is faster than that of wxt terminal.
(On Ununtu, I found qt terminal is faster than wxt terminal.)

BTW, in the gnuplot/config/msvc/Makefile, I found the description:

# Build qt terminal? WARNING: the qt terminal should build, but does not work correctly.
# Only enable it if you want to work on fixing qt terminal on windows.
# (Basic problem: qt_waitforinput() uses select() to wait on stdin and a named
# pipe simultaneously. On Windows, this fails, because select() on Windows can
# only be used on network sockets)

I asked Prof. Kakuto what is done in response to the above description.
He replied that no work around is done to the problem described the above.

Does anyone fixed the problem for qt terminal for windows?

As a note, Prof. Kakuto uses qt-5.3.0 for qt terminal building.

I am now trying to revise gnuplot/config/mingw/Makefile and support the qt terminal on mingw platform. 

Regards

Tatsuro

Re: win7: erratic console behaviour after first plot on wxt terminal

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

--- On Sat, 2014/5/24, Bastian Märkischwrote:
> Got it. wxt_waitforinput() was waiting for an event even when called 
> with TERM_ONLY_CHECK_MOUSING. Now fixed in CVS.
> 
>    Bastian
> 
> 
> Am 23.05.2014 06:47, schrieb Bastian Märkisch:
> > This seems to be an effect of the event handling: gnuplot seems to wait
> > for an event and blocks. Just moving the mouse inside plot window
> > terminates the  "waiting" e.g. I will see if I can find the time to
> > track this down over the weekend. IMHO this bug is release critical.
> >
> >     Bastian
> >
> >
> > Am 22.05.2014 23:33, schrieb Karl Ratzsch:
> >> Hi,
> >>
> >> this happens on win7 with the 5.0 binaries both from Tatsuro and the
> >> older one from Bastian (so both with wxgtk2.8 and 3.0): After the
> >> first plot on a wxt terminal, any command that is loaded from a file
> >> can take several seconds. Function declarations, plots, whatever.
> >> This only goes away when another terminal ist set, and resumes when
> >> a new plot is done on wxt.
> >>
> >> The exact times are only reproducible with the exact same script,
> >> and plots sometimes even get stuck and the script only resumes after
> >> changing the focus back to the gp console window. Several commands
> >> in one line (separated with ";") don´t seem to take longer that one.
> >>
> >> I´ve attached the script i used to probe this on three win7 machines.
> >>
> >> And this also works when a command including a linefeed is
> >> copypasted into the console.
> >>
> >> It does not depend on uses privileges like the exit problem
> >> https://sourceforge.net/p/gnuplot/bugs/1384/
> >>
> >> Best,
> >>      Karl
> >>
> 
> 

I have confirmed the fix. Thanks!
I will update my binary distribution on Monday.

Tatsuro

Re: win7: erratic console behaviour after first plot on wxt terminal

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

Got it. wxt_waitforinput() was waiting for an event even when called 
with TERM_ONLY_CHECK_MOUSING. Now fixed in CVS.

   Bastian


Am 23.05.2014 06:47, schrieb Bastian Märkisch:
> This seems to be an effect of the event handling: gnuplot seems to wait
> for an event and blocks. Just moving the mouse inside plot window
> terminates the  "waiting" e.g. I will see if I can find the time to
> track this down over the weekend. IMHO this bug is release critical.
>
>     Bastian
>
>
> Am 22.05.2014 23:33, schrieb Karl Ratzsch:
>> Hi,
>>
>> this happens on win7 with the 5.0 binaries both from Tatsuro and the
>> older one from Bastian (so both with wxgtk2.8 and 3.0): After the
>> first plot on a wxt terminal, any command that is loaded from a file
>> can take several seconds. Function declarations, plots, whatever.
>> This only goes away when another terminal ist set, and resumes when
>> a new plot is done on wxt.
>>
>> The exact times are only reproducible with the exact same script,
>> and plots sometimes even get stuck and the script only resumes after
>> changing the focus back to the gp console window. Several commands
>> in one line (separated with ";") don´t seem to take longer that one.
>>
>> I´ve attached the script i used to probe this on three win7 machines.
>>
>> And this also works when a command including a linefeed is
>> copypasted into the console.
>>
>> It does not depend on uses privileges like the exit problem
>> https://sourceforge.net/p/gnuplot/bugs/1384/
>>
>> Best,
>>      Karl
>>

Re: win7: erratic console behaviour after first plot on wxt terminal

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

This seems to be an effect of the event handling: gnuplot seems to wait 
for an event and blocks. Just moving the mouse inside plot window 
terminates the  "waiting" e.g. I will see if I can find the time to 
track this down over the weekend. IMHO this bug is release critical.

   Bastian


Am 22.05.2014 23:33, schrieb Karl Ratzsch:
> Hi,
>
> this happens on win7 with the 5.0 binaries both from Tatsuro and the
> older one from Bastian (so both with wxgtk2.8 and 3.0): After the
> first plot on a wxt terminal, any command that is loaded from a file
> can take several seconds. Function declarations, plots, whatever.
> This only goes away when another terminal ist set, and resumes when
> a new plot is done on wxt.
>
> The exact times are only reproducible with the exact same script,
> and plots sometimes even get stuck and the script only resumes after
> changing the focus back to the gp console window. Several commands
> in one line (separated with ";") don´t seem to take longer that one.
>
> I´ve attached the script i used to probe this on three win7 machines.
>
> And this also works when a command including a linefeed is
> copypasted into the console.
>
> It does not depend on uses privileges like the exit problem
> https://sourceforge.net/p/gnuplot/bugs/1384/
>
> Best,
>     Karl
>

Re: win7: erratic console behaviour after first plot on wxt terminal

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

--- On Fri, 2014/5/23, Tatsuro MATSUOKA wrote:
> --- On Fri, 2014/5/23, Karl Ratzsch wrote:
> > this happens on win7 with the 5.0 binaries both from Tatsuro and the
> > older one from Bastian (so both with wxgtk2.8 and 3.0): After the
> > first plot on a wxt terminal, any command that is loaded from a file
> > can take several seconds. Function declarations, plots, whatever.
> > This only goes away when another terminal ist set, and resumes when
> > a new plot is done on wxt.
> > 
> > The exact times are only reproducible with the exact same script,
> > and plots sometimes even get stuck and the script only resumes after
> > changing the focus back to the gp console window. Several commands
> > in one line (separated with ";") don´t seem to take longer that one.
> > 
> > I´ve attached the script i used to probe this on three win7 machines.
> > 
> > And this also works when a command including a linefeed is
> > copypasted into the console.
> > 
> > It does not depend on uses privileges like the exit problem
> > https://sourceforge.net/p/gnuplot/bugs/1384/
> > 
> > Best,
> >    Karl
> 
> Hello
> 
> Thank you for the feed back. The origin of problem that you pointed out is the same that was pointed out by Tait.
> 
> http://gnuplot.10905.n7.nabble.com/Gnuplot-version-5-release-candidate-td18424.html#a18437
> 
> I have quickly downgrade the cvs source before the change 2014-01-04 but the change there seemed not to be the origin of the problem.
> 
> We have to go back and search which change is the origin of the problem.
> 
> Your bug report might be useful for searching the origin.


Mmmm. The issue that you pointed out is different from that I have met.

The all.dem script work correctly on 4.6.5 binary build by Bastian.

Perhaps two different issues exist for wxt terminal on gnuplot for windows.

Tatsuro

Re: win7: erratic console behaviour after first plot on wxt terminal

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

--- On Fri, 2014/5/23, Karl Ratzsch wrote:
> I´ve attached the script i used to probe this on three win7 machines.
> 
> And this also works when a command including a linefeed is
> copypasted into the console.

The contests of the 'test.plt' is :

tand(gp,gpp) = (gp<0?1/0:gpp<0?1/0:abs(log10(gp/gpp)) > 2 ? 1/0 : gpp/gp)

This is an only function. No plot command I can see.

Tatsuro

Re: win7: erratic console behaviour after first plot on wxt terminal

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

--- On Fri, 2014/5/23, Karl Ratzsch wrote:
> this happens on win7 with the 5.0 binaries both from Tatsuro and the
> older one from Bastian (so both with wxgtk2.8 and 3.0): After the
> first plot on a wxt terminal, any command that is loaded from a file
> can take several seconds. Function declarations, plots, whatever.
> This only goes away when another terminal ist set, and resumes when
> a new plot is done on wxt.
> 
> The exact times are only reproducible with the exact same script,
> and plots sometimes even get stuck and the script only resumes after
> changing the focus back to the gp console window. Several commands
> in one line (separated with ";") don´t seem to take longer that one.
> 
> I´ve attached the script i used to probe this on three win7 machines.
> 
> And this also works when a command including a linefeed is
> copypasted into the console.
> 
> It does not depend on uses privileges like the exit problem
> https://sourceforge.net/p/gnuplot/bugs/1384/
> 
> Best,
>    Karl

Hello

Thank you for the feed back. The origin of problem that you pointed out is the same that was pointed out by Tait.

http://gnuplot.10905.n7.nabble.com/Gnuplot-version-5-release-candidate-td18424.html#a18437

I have quickly downgrade the cvs source before the change 2014-01-04 but the change there seemed not to be the origin of the problem.

We have to go back and search which change is the origin of the problem.

Your bug report might be useful for searching the origin.

Regards

Tatsuro
 
 

win7: erratic console behaviour after first plot on wxt terminal

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

Hi,

this happens on win7 with the 5.0 binaries both from Tatsuro and the
older one from Bastian (so both with wxgtk2.8 and 3.0): After the
first plot on a wxt terminal, any command that is loaded from a file
can take several seconds. Function declarations, plots, whatever.
This only goes away when another terminal ist set, and resumes when
a new plot is done on wxt.

The exact times are only reproducible with the exact same script,
and plots sometimes even get stuck and the script only resumes after
changing the focus back to the gp console window. Several commands
in one line (separated with ";") don´t seem to take longer that one.

I´ve attached the script i used to probe this on three win7 machines.

And this also works when a command including a linefeed is
copypasted into the console.

It does not depend on uses privileges like the exit problem
https://sourceforge.net/p/gnuplot/bugs/1384/

Best,
   Karl

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

Re: Gnuplot version 5 release candidate

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

--- On Wed, 2014/5/21, Tatsuro MATSUOKA  wrote:

> --- 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:...
> 
> 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.
> 
> The change below perhaps related to the phenomena that you have met.
> *************************************************************************
> 2014-01-04  Bastian Maerkisch  <bma...@we...>
> 
>     * src/win/wcommon.h src/win/wgdiplus.cpp|h src/win/wgnuplib.h
>     src/win/wgraph.c src/win/resourc.h term/win.trm:  New (optional)
>     variant of the windows terminal backend which draws using the GDI+ API
>     whenever possible. This is much faster in some cases than the old
>     backend which switches between GDI and GDI+ to support antialiasing
>     and RGBA colors. Images are drawn using GDI since GDI+ always uses some
>     sort of interpolation when scaling images. Enhanced text is currently
>     still drawn using GDI. Adjacent polygons of the same color are merged
>     in order to avoid "seams" between them caused by antialiasing. See also
>     Bug #1096.
> 
>     * src/term_api.h src/graphics (plot_image_or_update_axes):  Wrap
>     the fallback image output with term->layer() commands using
>     TERM_LAYER_BEGIN_IMAGE and TERM_LAYER_END_IMAGE. This can be
>     used by terminals to optimize output.
> 
>     * src/win/wgraph.c (drawgraph):  Move GDI image drawing code from
>     drawgraph() to a new routine draw_image().
> 
>     * src/command.c src/fit.c|h src/plot.c|h src/term.c src/win/wgraph.c 
>     src/win/winmain.c src/win/wtext.c term/win.trm:  Handle Ctrl-C
>     asynchronously on Windows (GUI and console mode). This is done by
>     setting ctrlc_flag and testing it in check_for_mouse_event(). Thus,
>     scripts etc. can now finally be interrupted by pressing Ctrl-C in
>     console mode gnuplot or Ctrl-Break in wgnuplot.
> 
>     * src/win/winmain.c (ConsoleGetch):  Remap Shift-Tab key-code in
>     console mode, too.
> 
> ***********************************************************************
> The above change solves the CTRL+C issue on gnuplot on windows for a long term.
> The change seems to be well on windows terminal but not be well on wxt terminal.
> 
> To confirm my assumption, I have to downgrade the cvs source but I have not tried yet.  
> 
> Please give me a little bit time to confirm that the change above is an origin of the fault on the wxt terminal.

My assumption is wrong.  Using the cvs source dated 2014-01-02, the same phenomena occur on the wxt terminal for windows.

Perhaps it will take time which change is the origin this fault.

Tatsuro

Re: I cannot build wgnuplot.exe.

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

Hello

I delete the macro -D__STRICT_ANSI__

The build of wgnuplot.exe was successful.
Sorry for the noise.

Tatsuro

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

> Hello
> 
> By accident, I have erased my local patch for mingw build.
> I am now struggling.
> 
> The problem happened in building wgnuplot.exe (link stage). 
> 
> g++ -L/c/Programs/gplibs32/lib -Wl,--enable-auto-import -Wl,--enable-runtime-pseudo-reloc-v2 -Wl,--allow-multiple-definition -s -mwindows -Wl,--enable-auto-import -LC:/PROGRA~2/HELPWO~1/lib -o wgnuplot.exe alloc.o axis.o binary.o bitmap.o boundary.o breaders.o color.o command.o contour.o datablock.o datafile.o dynarray.o eval.o external.o fit.o gadgets.o getcolor.o graph3d.o graphics.o help.o hidden3d.o history.o internal.o interpol.o libcerf.o matrix.o misc.o mouse.o multiplot.o parse.o plot.o plot2d.o plot3d.o pm3d.o readline.o save.o scanner.o set.o show.o specfun.o standard.o stats.o stdfn.o tables.o tabulate.o term.o time.o unset.o util.o util3d.o variable.o version.o gpexecute.o wxt_gui.o gp_cairo.o gp_cairo_helpers.o winmain.o wgnuplib.o wgraph.o wprinter.o wpause.o wgdiplus.o wtext.o screenbuf.o wmenu.o wredirect.o wgplt_res.o -lkernel32 -lgdi32 -lwinspool -lcomdlg32 -lcomctl32 -ladvapi32 -lshell32 -lmsimg32 -lgdiplus -lhtmlhelp\
>          -lgd -lgd -ljpeg -lz -LC:/Programs/gplibs32/lib -lpng16 -L/c/Programs/gplibs32/lib -lfreetype -LC:/Programs/gplibs32/lib -lfontconfig -lfontconfig -liconv -llua -lcaca -liconv -lcerf -lm -L/c/Programs/gplibs32/lib   -Wl,--enable-auto-import -L/c/Programs/gplibs32/lib -L/c/Programs/expat/lib   -lwx_mswu_xrc-3.0 -lwx_mswu_webview-3.0 -lwx_mswu_html-3.0 -lwx_mswu_qa-3.0 -lwx_mswu_adv-3.0 -lwx_mswu_core-3.0 -lwx_baseu_xml-3.0 -lwx_baseu_net-3.0 -lwx_baseu-3.0  -LC:/Programs/gplibs32/lib -L/c/Programs/gplibs32/lib -LC:/Programs/gplibs32/lib -lpangocairo-1.0 -lpangoft2-1.0 -lfreetype -lfontconfig -lpangowin32-1.0 -lgdi32 -lpango-1.0 -lm -lgobject-2.0 -lglib-2.0 -lintl -lcairo
> Warning: .drectve `-defaultlib:uuid.lib ' unrecognized
> Warning: corrupt .drectve at end of def file
> winmain.o:winmain.c:(.text+0xf86): undefined reference to `va_copy'
> collect2.exe: error: ld returned 1 exit status
> make[1]: *** [wgnuplot.exe] Error 1
> make[1]: Leaving directory `/e/usr/Tatsu/mingw32work/gnuplot/gnuplotcvs/gnuplot/config/mingw'
> make: *** [windows] Error 2
> 
> winmain.o:winmain.c:(.text+0xf86): undefined reference to `va_copy'
> 
> I backed to the cvs source 2014-05-16, the result was the same.
> 
> Any suggestions?
> 
> Tatsuro
> 
> Building gnuplot.exe without problem.
> 
> 
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

I cannot build wgnuplot.exe.

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

Hello

By accident, I have erased my local patch for mingw build.
I am now struggling.

The problem happened in building wgnuplot.exe (link stage). 

g++ -L/c/Programs/gplibs32/lib -Wl,--enable-auto-import -Wl,--enable-runtime-pseudo-reloc-v2 -Wl,--allow-multiple-definition -s -mwindows -Wl,--enable-auto-import -LC:/PROGRA~2/HELPWO~1/lib -o wgnuplot.exe alloc.o axis.o binary.o bitmap.o boundary.o breaders.o color.o command.o contour.o datablock.o datafile.o dynarray.o eval.o external.o fit.o gadgets.o getcolor.o graph3d.o graphics.o help.o hidden3d.o history.o internal.o interpol.o libcerf.o matrix.o misc.o mouse.o multiplot.o parse.o plot.o plot2d.o plot3d.o pm3d.o readline.o save.o scanner.o set.o show.o specfun.o standard.o stats.o stdfn.o tables.o tabulate.o term.o time.o unset.o util.o util3d.o variable.o version.o gpexecute.o wxt_gui.o gp_cairo.o gp_cairo_helpers.o winmain.o wgnuplib.o wgraph.o wprinter.o wpause.o wgdiplus.o wtext.o screenbuf.o wmenu.o wredirect.o wgplt_res.o -lkernel32 -lgdi32 -lwinspool -lcomdlg32 -lcomctl32 -ladvapi32 -lshell32 -lmsimg32 -lgdiplus -lhtmlhelp\
         -lgd -lgd -ljpeg -lz -LC:/Programs/gplibs32/lib -lpng16 -L/c/Programs/gplibs32/lib -lfreetype -LC:/Programs/gplibs32/lib -lfontconfig -lfontconfig -liconv -llua -lcaca -liconv -lcerf -lm -L/c/Programs/gplibs32/lib   -Wl,--enable-auto-import -L/c/Programs/gplibs32/lib -L/c/Programs/expat/lib   -lwx_mswu_xrc-3.0 -lwx_mswu_webview-3.0 -lwx_mswu_html-3.0 -lwx_mswu_qa-3.0 -lwx_mswu_adv-3.0 -lwx_mswu_core-3.0 -lwx_baseu_xml-3.0 -lwx_baseu_net-3.0 -lwx_baseu-3.0  -LC:/Programs/gplibs32/lib -L/c/Programs/gplibs32/lib -LC:/Programs/gplibs32/lib -lpangocairo-1.0 -lpangoft2-1.0 -lfreetype -lfontconfig -lpangowin32-1.0 -lgdi32 -lpango-1.0 -lm -lgobject-2.0 -lglib-2.0 -lintl -lcairo
Warning: .drectve `-defaultlib:uuid.lib ' unrecognized
Warning: corrupt .drectve at end of def file
winmain.o:winmain.c:(.text+0xf86): undefined reference to `va_copy'
collect2.exe: error: ld returned 1 exit status
make[1]: *** [wgnuplot.exe] Error 1
make[1]: Leaving directory `/e/usr/Tatsu/mingw32work/gnuplot/gnuplotcvs/gnuplot/config/mingw'
make: *** [windows] Error 2

winmain.o:winmain.c:(.text+0xf86): undefined reference to `va_copy'

I backed to the cvs source 2014-05-16, the result was the same.

Any suggestions?

Tatsuro

Building gnuplot.exe without problem.

Re: cvs update -D -d 'xxxx-xx-xx' does not work

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

--- On Thu, 2014/5/22, sfeam  wrote:

> On Thursday, 22 May 2014 09:21:51 AM Tatsuro MATSUOKA wrote:
> > Hello
> > 
> > To specify the issue discussed on the beta-list
> > http://gnuplot.10905.n7.nabble.com/Gnuplot-version-5-release-candidate-td18424.html#a18437
> > 
> > http://gnuplot.10905.n7.nabble.com/Gnuplot-version-5-release-candidate-td18424.html#a18439
> > 
> > I tried to downgrade the cvs source by
> > 
> > $ cd gnuplot; cvs update -D -d '2014-01-04'
> > 
> > However, no response appear and files does not change at all.
> > Am I wrong?
> 
> I think you do not need the "-d" part.
> Use  
>     cvs update -D -d '2014-01-04'date -D -d '2014-01-04'
> 
> However the trouble may instead be explained by a message
> I received today from SourceForge.  See below.
> 

cvs update -D went well '2014-01-04'

Thanks!
Tatsuro

cvs update -D -d 'xxxx-xx-xx' does not work

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

Hello

To specify the issue discussed on the beta-list
http://gnuplot.10905.n7.nabble.com/Gnuplot-version-5-release-candidate-td18424.html#a18437

http://gnuplot.10905.n7.nabble.com/Gnuplot-version-5-release-candidate-td18424.html#a18439

I tried to downgrade the cvs source by

$ cd gnuplot; cvs update -D -d '2014-01-04'

However, no response appear and files does not change at all.
Am I wrong?

Thank you in advance for your kind consideration.

Tatsuro
 

Re: Gnuplot version 5 release candidate

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

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

> On Tuesday, 20 May 2014 10:47:50 AM Christoph Bersch wrote:
>> How was the HTML
>> documentation of version 4.2 created, which is still online?
>
> It was generated with an external tool called latex2html.
> But that tool ceased to be developed or supported, so far as I
> can tell, and no longer works with current LaTeX installations.
> Furthermore it didn't handle figures, or at least the commands
> in gnuplot's Makefile didn't handle figures.
>
> I have tried several possible replacements. The most promising
> seems to be htlatex.  Supposedly it should do what we want, but
> the default mode is not very satisfactory.

I've written a Python script doc2html.py which does the conversion  
directly from the gnuplot.doc file. It is working already, but needs  
some more tweaking. I'll upload a patch next week to sourceforge, so  
we can discuss about the formatting details.

Christoph