gnuplot development

There seems to be no further discussion, and the code is already in CVS, so
I am closing this tracker item.

In preparation for eventual release of gnuplot version 4.4, existing bugs
and patchsets are being re-prioritized.

I have chosen to use the following categories

9 - should be included in 4.4.rc1 if possible
7 - looks reasonable to me, but not high priority for 4.4.rc1
5 - default priority for newly submitted patches
2 - not under active consideration


These are my personal ratings. If you want to argue for a different
priority on one or more patches - go right ahead.

Ethan Merritt (sfeam)

In preparation for eventual release of gnuplot version 4.4, existing bugs
and patchsets are being re-prioritized.

I have chosen to use the following categories

9 - should be included in 4.4.rc1 if possible
7 - looks reasonable to me, but not high priority for 4.4.rc1
5 - default priority for newly submitted patches
2 - not under active consideration


These are my personal ratings. If you want to argue for a different
priority on one or more patches - go right ahead.

Ethan Merritt (sfeam)

I'd like to propose a small addition to the windows console patch:

diff -urN gnuplot-4.3.0-2008-11-21-orig/src/win/winmain.c
gnuplot-4.3.0-2008-11-21/src/win/winmain.c
--- gnuplot-4.3.0-2008-11-21-orig/src/win/winmain.c 2008-11-07 12:01:31
+0000
+++ gnuplot-4.3.0-2008-11-21/src/win/winmain.c 2008-12-03 14:36:34 +0000
@@ -269,7 +269,7 @@
#ifdef WGP_CONSOLE
# define _argv argv
# define _argc argc
- HINSTANCE hInstance = NULL, hPrevInstance = NULL;
+ HINSTANCE hInstance = GetModuleHandle(NULL), hPrevInstance = NULL;
int nCmdShow = 0;
#else
#ifdef __MSC__ /* MSC doesn't give us _argc and _argv[] so ... */


This enables to load the correct .ico symbol for the plotting window
within win.trm
( LoadIcon(graphwin.hInstance, "GRPICON") fails if graphwin.hInstance
equals NULL )

benjamin

Should the patch below
Date: 2008-11-07 22:17
Sender: tlecomte
be applied or not?

It does check for console input, when paused_for_mouse is false.

I don't remember why the code is different in win and
wxt terminal. All scenarios have probably to be checked
for correct behavior (regarding paused_for_mouse). It
might be that calling ConsoleGetch() is enough as well.

Regarding the following patch against the wxt terminal, I don't understand
how this achieve the desired effect of _waitforinput(), since it doesn't
check for console input at all. Shouldn't it be simply identical to
WIN_waitforinput() which just calls ConsoleGetch() ?


*** wxt_gui.cpp 13 Oct 2008 19:45:17 -0000 1.69
--- wxt_gui.cpp 7 Nov 2008 11:55:46 -0000 1.70
***************
*** 3128,3132 ****
int wxt_waitforinput()
{
! return getch();
}
#endif /* WXT_MONOTHREADED || WXT_MULTITHREADED */
--- 3128,3150 ----
int wxt_waitforinput()
{
! #ifdef WGP_CONSOLE
! if (paused_for_mouse) {
! MSG msg;
! BOOL ret;
!
! while ((ret = GetMessage(&msg, NULL, 0, 0)) != 0) {
! if (ret == -1)
! break;
! TranslateMessage(&msg);
! DispatchMessage(&msg);
!
! if (!paused_for_mouse)
! break;
! }
! return '\0';
! }
! else
! #endif /* WGP_CONSOLE */
! return getch();
}
#endif /* WXT_MONOTHREADED || WXT_MULTITHREADED */

Committed to cvs. Thanks for the patch!

It would be very welcome if somebody updated the raising capability also
for the console mode of gnuplot for Windows, see the previous comment.

New patch with updated makefile.mgw.
File Added: wgnuplot_console-Oct18.diff

I have updated the patch. I have added CONSOLE target in makefile.mgw. I
have renamed CONSOLE to WGP_CONSOLE to avoid potential name clash. I have
#ifndef WGP_CONSOLE around many routines named Text*().

What does not work are raise commands in both directions. I.e., the graph
window is not raised when the graph is plotted and the text window is not
raised when <space> is hit. Can somebody fix it?

Patch added: wgnuplot_console-Oct17.diff

File Added: wgnuplot_console-Oct17.diff

I have found the problem. If the CONSOLE is defined, you don't call some
functions of the text GUI terminal, like TextInit(); that's why some
variables are not initialized. However, TextClose() is still called, that's
why gnuplot should crash because of many zero pointers. Maybe MSVC has some
layer which protects against zero pointers and such a test is not part of
the Win API. (Well, this just hides the true problem in a buggy program.)

Therefore wgnuplib.h needs:

/* ================================== */
/* wtext.c - Text Window */
#ifndef CONSOLE
void WDPROC TextMessage(void);
int WDPROC TextInit(LPTW lptw);
void WDPROC TextClose(LPTW lptw);
void WDPROC TextToCursor(LPTW lptw);
int WDPROC TextKBHit(LPTW);
int WDPROC TextGetCh(LPTW);
int WDPROC TextGetChE(LPTW);
LPSTR WDPROC TextGetS(LPTW lptw, LPSTR str, unsigned int size);
int WDPROC TextPutCh(LPTW, BYTE);
int WDPROC TextPutS(LPTW lptw, LPSTR str);
void WDPROC TextGotoXY(LPTW lptw, int x, int y);
int WDPROC TextWhereX(LPTW lptw);
int WDPROC TextWhereY(LPTW lptw);
void WDPROC TextCursorHeight(LPTW lptw, int height);
void WDPROC TextClearEOL(LPTW lptw);
void WDPROC TextClearEOS(LPTW lptw);
void WDPROC TextInsertLine(LPTW lptw);
void WDPROC TextDeleteLine(LPTW lptw);
void WDPROC TextScrollReverse(LPTW lptw);
void WDPROC TextAttr(LPTW lptw, BYTE attr);
#endif
void WDPROC AboutBox(HWND hwnd, LPSTR str);

and all the respective calls (mainly TextMessage() and TextAttr()) should
be #ifndef'ed in the respective places. I've tried it and gnuplot-console
works without crash.

I would prepare a patch later if you cannot do it for the constrains we
have told us.

However, the infinite-loop under wine remains unexplained.

To be honest, I won't be able to help you for the
coming weeks. Starting from tomorrow, I'll be in the
process of moving abroad, without web access (and
probably without any time to spend on anything else
than taking care of the moving).

But what you can easily test (and this does not involve
Windows programming) is to add and if-test to check the
value of the GlobalHandle argument, before using it. This
should avoid the crash you get.

I don't know about Windows programming. The most helpful for us would be if
you could install MingW compiler and try to compile gnuplot with your
patch. MingW is freely available and very easy to install, see
http://www.mingw.org
https://sourceforge.net/projects/mingw/
http://csjava.occ.cccd.edu/~gilberts/mingw/

Into makefile.mgw you just add -DCONSOLE into CFLAGS, and remove the
-mwindows as you suggested previously.
Can you please do and test it? Thanks.

I don't know why it crashes for you and not for me.
Maybe MSVC is doing something special, or it might be
related to the fact that MSVC does not use the same
C runtime library as MinGW. No idea. But I guess you
can avoid the problem by adding some extra checks in
TextClose.

Yes, it runs OK until exit.
Then in TextClose is a line
hglobal = (HGLOBAL)GlobalHandle( SELECTOROF(lptw->ScreenBuffer) );
where gnuplot crashes.
I can see that the point lptw is non-NULL, but lptw->ScreenBuffer is
0000000, and the same for SELECTOROF(lptw->ScreenBuffer).

Do you have an idea?

I can't comment for the Wine situation as the problem might
come from the emulation itself. For the Windows situation,
do you get it running correctly, until you exit? (which is
when TextClose is called). What is the argument value of
GlobalHandle when it crashes: in my case, it's 0 and it does
not crash. I don't use gdb or valgrind, I'm not sure it would
work fine with MSVC compiled stuff.

I have used temporarily the output name wgnuplot.exe in order to make
minimal changes to the Makefile. The idea is to get console instead of
graphical executable.

I added ZeroMemory() into winmain.c.

I have removed -mwindows. Now, in wine, gnuplot start-ups, but it freezes
after hitting <Enter>.

Under Windows, I can run it through gdb. Then I can find that in wtext.c,
routine TextClose(), all calls to GlobalHandle() crash.

I use mingw gcc 3.4.4.

Is all right when you run your executable through gdb or through valgrind?
No problems?
Do you have any further idea? It may help if you also try mingw
compilation.

There's something I don't understand in the way you compile
gnuplot: the CONSOLE mode is intended to be used in non
windows mode, so you shouldn't compile into wgnuplot.exe and
you shouldn't use the -mwindows flag at link stage.

Next, the crash occurs in the exit routine, this means that
the program does not run at all and exits immediately, right?

Finally, the crash seems to be related to uninitialized
data in textwin structure. Under VC++, the structure is
initialized to 0 automatically, so the TextClose function
does not crash. Would the following statement help in
your case?

ZeroMemory(&textwin, sizeof(textwin));

Michael.

I have committed the wxt and ps-prolog patches into cvs.

Ad console patch: it crashes.
- Under Wine, it starts the gnuplot command line, and either exits when
you enter any line or it goes into an infinite loop.
The place I have found yesterday.
- Under Windows, it just crashes after startup. gdb says it crashes in
wtext.c:283 which was called from winmain.c:165.
The former line is this:
hglobal = (HGLOBAL)GlobalHandle( SELECTOROF(lptw->ScreenBuffer) );


I have compiled gnuplot with the CONSOLE patch by means of makefile.mgw
with -DCONSOLE, so that "make" was writing this:

gcc -c -g -I.. -I. -D_Windows -DHAVE_CONFIG_H -DCONSOLE \
-DUSE_MOUSE=1 -DWIN_IPC alloc.c
...
gcc -c -g -I.. -I. -D_Windows -DHAVE_CONFIG_H -DCONSOLE \
-DUSE_MOUSE=1 -DWIN_IPC win/wmenu.c

g++ -g -mwindows -o wgnuplot.exe alloc.o axis.o binary.o bitmap.o
breaders.o
color.o command.o contour.o datafile.o dynarray.o eval.o fit.o gadgets.o
getcolor.o graph3d.o graphics.o help.o hidden3d.o history.o internal.o
interpol.o matrix.o misc.o mouse.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 stdfn.o
tables.o
tabulate.o term.o time.o unset.o util.o util3d.o variable.o version.o
gpexecute.o winmain.o wgnuplib.o wgraph.o wprinter.o wtext.o wpause.o
wmenu.o
wgplt_res.o -lkernel32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32
-ladvapi32

Do you have same options under your compiler?

> - gnuplot-console.diff
> -- I propose to rename #define CONSOLE to WIN_CONSOLE or
> WGNUPLOT_CONSOLE to clearly distinguish it is Windows-specific
> -- I have compiled by means of MingW. I've just added CFLAGS +=
-DCONSOLE
> into makefile.mgw.
> When I run the executable, then there is an infinite loop instead of
input
> from the command line; it is inside:
> winmain.c:ConsoleGetch()
> which is called from
> win.trm:WIN_waitforinput()
> How to fix it?

By debugging...? It would help to know why you enter
an infinite loop. Do you run pgnuplot from a windows
command shell?

I know that Benjamin Lindner (who provides octave
compiled with MinGW) provides a CVS version of gnuplot
including my console patch (but without wxt terminal).
You might consider asking him about the problem.

ChangeLog for gnuplot-relocatable-ps-prolog.diff:

* src/win/winmain.c: Declare szPackageDir.
(WinMain): Compute szPackageDir from szModuleName,
stripping possible "\bin\" at the end.
* src/win/winmain.h: Declate szPackageDir.
* term/post.trm (PS_open_prologue_file): Use szPackageDir
instead of szModuleName.

The difference between szModuleName and szPackageDir
is that any ending "\bin" directory is removed. I use a
directory layout where all executables (.exe and .dll) are
in a \bin subdirectory, a little bit like UNIX systems.

ChangeLog for gnuplot-wxt.diff

* src/wxterminal/gp_cairo.c (gp_cairo_draw_text):
Define rint for MSVC. Make code C compliant.

* src/wxterminal/wxt_gui.cpp (wxtFrame::wxtFrame):
Do not force toolbar item size. Force resize event at
the end of frame creation.
(wxt_init): Declare wxSetInstance.

I have tried all the three patches. My comments:

- gnuplot-wxt.diff
What should be written to ChangeLog?

- gnuplot-relocatable-ps-prolog.diff
What should be written to ChangeLog?
What is the difference between szModuleName and szPackageDir?

- gnuplot-console.diff
-- I propose to rename #define CONSOLE to WIN_CONSOLE or
WGNUPLOT_CONSOLE to clearly distinguish it is Windows-specific
-- I have compiled by means of MingW. I've just added CFLAGS += -DCONSOLE
into makefile.mgw.
When I run the executable, then there is an infinite loop instead of
input
from the command line; it is inside:
winmain.c:ConsoleGetch()
which is called from
win.trm:WIN_waitforinput()
How to fix it?

File Added: gnuplot-wxt.diff

File Added: gnuplot-relocatable-ps-prolog.diff

File Added: gnuplot-console.diff

Hello Michael, can you please update the patch?
I think you maintain it elsewhere. Putting the patch here will
allow more people to have a look in order to submit the patch
into cvs after a testing.

I updated the patch to version 4.2rc4. I also made several changes to
makefile.nt in order to be able to compile gnuplot with NMAKE/MSVC in
console and normal windows mode (+ support for wxt terminal).

In the code, you'll see a few '#ifdef OCTAVE_BUILD': I added those to
easily compile a gnuplot version that works slightly better with octave, by
changing some default values (font set to courier, enhanced mode, no
toolbar). you might not want to include these changes.
File Added: gp-win-console-4.2.diff

Patch update: strips carriage return '\r' from input lines.

File Added: gp-win32-console.diff

Not using WM_CHAR messages. WM_CHAR is the easiest solution because it
does not require any modification in the original code of wgnuplot. To send
whole lines, you could rely on WM_COPYDATA messages, but this requires
modifying the code for text window.

The patch is not MSVC specific, it uses the CONSOLE preprocessor symbol.
If you want to use it from MinGW, it should be enough to define CONSOLE in
the associated makefile.

Cannot pgnuplot send strings with whole lines (i.e. until \n)?

BTW, please make the patch compiles also with MingW.

I tried first to fix pgnuplot, by checking the result of PostMessage and
using Sleep() to wait a little bit. But the pgnuplot approach (decomposing
every single char into a separate message) is rather inefficient. Using
Sleep() for a few hundreds of milliseconds will make it worse. Moreover,
even when using Sleep(), I still suffered data loss.

Using real pipes makes the communication with gnuplot much faster. And
eventually, I don't want the text window to appear (in the context of
octave).

Is a properly working pgnuplot.c patch available? There was a patch sent
to gnuplot-beta. If this patch is important for Windows users, please act
quickly so that it could be put into gnuplot 4.2-rc3.

Thanks for the explanation, I now remember what I used to know...

Isn't it possible to fix pgnuplot.c to check for the full event queue ?

Interestingly, I do see in pgnuplot.c, line 193:
PostMessage(hwnd, WM_CHAR, (unsigned char) *pc, 1L);
/* CRS: should add a check of return code on PostMessage. If 0, the
message que was full and the message wasn't posted. */

So, there's room for improvement here.

Anyway, I guess part of your problem is that there's no feedback from
wgnuplot to pgnuplot in that case, i.e. messages get printed in the
"undesired additional text window", right ?

Indeed, it might be possible to hack MyFGetC and friends, I can give
it a try. However, the only actually needed function is
MyFGetCh()/getch(),
all others would simply end up calling the C equivalent.

Note however that you can't mix non-console and console version into a
single executable and use a command-line switch, because both uses
different
entry points (WinMain/main): either you use WinMain, but then
stdin/stdout/stderr
are not defined and you can't pipe (that's the reason of pgnuplot); or you
use
main, but you will have a console window popping up (which you don't want
in
plain windows mode; that's what wgnuplot_pipes.exe probably does).

In console mode, the text window is never shown, it's even not created as
you
don't need it. Messages are printed in the windows console: gnuplot then
acts
really as under UNIX when started from a terminal.

Hi Michael,

I like your initiative, and I have a few questions and remarks.

First, I would suggest to do the change conditionnally to a command-line
option, or automatically, if it's possible to detect that stdin comes from
a pipe (hmm, I see it's already done using isatty(), and it is also done
like that in the current code in src/win/winmain.c).
Then, I wonder if it's the best choice to do the work in src/readline.c by
changing special_getc(). Why don't you modify MyFGetC and friends in
src/win/winmain.c instead ?
By the way, you didn't modify MyPutCh or MyFPutC in that file, so I assume
the text window will still popup if gnuplot has any message to display,
right ? Or, are they just never showing at all ?

I also remember reading that pgnuplot was introduced because Windows
applications do not have piped io unless they are working from a Windows
console. Is that true ? Otherwise, it would be interesting to see if it's
possible to move the current gnuplot pseudo-console to an external
application (which is somewhat related to what is discussed in
https://sourceforge.net/tracker/?func=detail&atid=302055&aid=1620225&group_id=2055
).

Anyway, thanks for your work on octave and now on gnuplot. No doubt
improving them for Windows in a good thing.

Patch update: do not hang the GUI when switching to another terminal type.
File Added: gp-win-console.diff.bz2