Menu
▾
▴
gnuplot-beta
|
From: Tatsuro M. <tma...@ya...> - 2010-02-01 05:38:08
|
Hello --- Ethan Merritt wrote: > On linux it is always safe to hit "ctrl-c" in order to return to > the command prompt. As I understand it, this solution does not work > on windows (see other thread). I understand the situation. BTW, I found the my fix for 'pause mouse' shows different results whether gnuplot is built with wxt or without wxt. I will fix it. After that I will try to CTRL+C problem using win32 api of SetConsoleCtrlHandler. in the below http://msdn.microsoft.com/en-us/library/ms685049(VS.85).aspx I do not know fix will be successful and fix itself apparently goes well but it break the pipe communication that is mentioned by Benjamin. http://old.nabble.com/Re:-towards-4.4-p27395529.html For wgnuplot, perhaps the ConsoleCtrlHandler can not be used I cannot find the way to do at the moment. My knowledge is not enough for win32 programing so that it will take a time and Febrar At the moment, I vote to Benajmin's opinion and please go ahead to the 4.4-rc2. Regards Tatsuro -------------------------------------- Get the new Internet Explorer 8 optimized for Yahoo! JAPAN http://pr.mail.yahoo.co.jp/ie8/ |
|
From: Allin C. <cot...@wf...> - 2010-02-01 02:00:08
|
On Sun, 31 Jan 2010, Ethan Merritt wrote: > - If an x11 plot window is killed, then a subsequent 'pause mouse' > command should be rejected. The only way I have managed to set this up > so far is to have event_reset() set term_initialised = FALSE, > and have pause_command() test for it. This seems to work for x11, but > I have no idea what havoc it might trigger on os2 or whatever else. os2?! I love gnuplot, but when I try to delve into the code base I'm struck by the opacity induced by trying to support Dinosaur OSes. I think some have been cleaned out lately (?) but if os2 has not, then time to go? Allin Cottrell |
|
From: Petr M. <mi...@ph...> - 2010-02-01 07:06:44
|
> > - If an x11 plot window is killed, then a subsequent 'pause mouse' > > command should be rejected. The only way I have managed to set this up > > so far is to have event_reset() set term_initialised = FALSE, > > and have pause_command() test for it. This seems to work for x11, but > > I have no idea what havoc it might trigger on os2 or whatever else. > > os2?! I love gnuplot, but when I try to delve into the code base > I'm struck by the opacity induced by trying to support Dinosaur > OSes. I think some have been cleaned out lately (?) but if os2 > has not, then time to go? Nowadays you can buy modern OS/2 under the name eComStation, see http://www.ecomstation.com where you can even try a DemoCD. The OS/2 community is quite active, see web pages such as http://hobbes.nmsu.edu/h-browse.php?dir=/pub/new&sort=date There is absolutely no reason to remove the OS/2 support. And neither DOS support - the latest gnuplot compiled by DJGPP runs well in DOS. You find such machines in labs running various experimental tools. Greetings, Petr |
|
From: Tatsuro M. <tma...@ya...> - 2010-01-28 05:11:30
|
Hello
--- Petr Mikulik wrote:
> If WX is the current terminal under windows, then the pausing code with
> waitforinput() has to be used instead. Will the (untested) enclosed patch
> work?
>
Hello
I have applied your patch to cvs trees.
In the patch, a small fix is needed
+ if (!strcmp(term->title, "wx")) {
should be
+ if (!strcmp(term->name, "wxt")) {
# ***** results for gnuplot.exe *****
The patch for pause mouse for windows and wxt terminals works well except a side effect.
The patch gives s gui 'gnuplot pause' window when the command 'pause -1' is executed when terminal is
set to 'windows'.
When WGP_CONSOLE is true. the code should be modified.
I have encountered this problem and I have considered to treat the side effect.
I will show it afterwards.
# ***** results for wgnuplot{_pipes}.exe *****
The patch does not correct the 'pause mouse' issue of wxt term.
Clicking mouse button does not break 'pause mouse' while pressing a key breaks it.
Of course, the pause mouse for windows terminals works correct.
I have tried the similar treatment but that also did not work.
There is no gnuplot executable for all other platformes which has a original GUI based console except
for wgnuplot. I suspect that wxt_waitforinput() does not work correct on wgnuplot.exe.
However it is no more than speculation at present.
Regards
Tatsuro
--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/
|
|
From: Benjamin L. <lin...@gm...> - 2010-01-26 16:45:40
|
> BTW, gnuplot.exe is used in Octave nowadays ... does ginput work on Windows > correctly? There has been a Bug report against this in octave, and IIRC there was an issue with "set multiplot". But I'm not currently up-to-date on whether this has been fixed already. It's not mentioned in the thread http://old.nabble.com/Ginput-doesn%27t-work-in-3.2.3-tp26470943p26470943.html benjamin |
|
From: Petr M. <mi...@ph...> - 2010-01-26 19:47:51
|
> > BTW, gnuplot.exe is used in Octave nowadays ... does ginput work on Windows > > correctly? > > There has been a Bug report against this in octave, and IIRC there was an > issue with "set multiplot". > But I'm not currently up-to-date on whether this has been fixed already. > It's not mentioned in the thread > http://old.nabble.com/Ginput-doesn%27t-work-in-3.2.3-tp26470943p26470943.html This occured on all OSes; it was due to missing "unset multiplot". It has been fixed. --- PM |
|
From: Tatsuro M. <tma...@ya...> - 2010-01-28 23:33:58
|
Hello I have remembered that Benjamin have posted concerning issue of ctrl+c on gnuplot.exe for windows. http://old.nabble.com/MSWin-issues-holding-up-4.4.rc1-td25793940.html#a26015183 **************** --- gnuplot-4.3.0-2009-07-08-orig/src/plot.c 2009-09-20 20:16:47 +0200 +++ gnuplot-4.3.0-2009-07-08/src/plot.c 2009-10-18 13:06:08 +0200 @@ -684,7 +684,11 @@ setmatherr(purec_matherr); #endif +#if defined(WGP_CONSOLE) + (void) signal(SIGINT, SIG_IGN); +#else (void) signal(SIGINT, (sigfunc) inter); +#endif #ifdef SIGPIPE /* ignore pipe errors, this might happen with set output "|head" */ ****************** The above seems not to be applied yet. Regards Tatsuro -------------------------------------- Get the new Internet Explorer 8 optimized for Yahoo! JAPAN http://pr.mail.yahoo.co.jp/ie8/ |
|
From: Ethan M. <merritt@u.washington.edu> - 2010-01-29 01:12:20
|
On Thursday 28 January 2010 15:33:48 Tatsuro MATSUOKA wrote: > Hello > > I have remembered that Benjamin have posted concerning issue of ctrl+c on gnuplot.exe for windows. > > http://old.nabble.com/MSWin-issues-holding-up-4.4.rc1-td25793940.html#a26015183 > > **************** > --- gnuplot-4.3.0-2009-07-08-orig/src/plot.c 2009-09-20 20:16:47 +0200 > +++ gnuplot-4.3.0-2009-07-08/src/plot.c 2009-10-18 13:06:08 +0200 > @@ -684,7 +684,11 @@ > setmatherr(purec_matherr); > #endif > > +#if defined(WGP_CONSOLE) > + (void) signal(SIGINT, SIG_IGN); > +#else > (void) signal(SIGINT, (sigfunc) inter); > +#endif > > #ifdef SIGPIPE > /* ignore pipe errors, this might happen with set output "|head" */ > ****************** > > The above seems not to be applied yet. That would cause the program to ignore ctrl-c. It would be better to fix the signal-handling routine so that it responds to ctrl-c correctly. Does someone know the history of this problem? Did ctrl-c work on Windows in older versions of gnuplot? If so, when did it break? -- Ethan A Merritt |
|
From: Tatsuro M. <tma...@ya...> - 2010-01-29 06:54:08
|
Hello
I have found web page in written Japanese.
It was written that SIGINT is not easy to handle in console applications.
However, there shows a way to use SetConsoleCtrlHandler function.
#***************
#include <windows.h>
#include <wincon.h>
#include <iostream>
//handler function
BOOL handler(DWORD ctrlChar){
if(CTRL_C_EVENT == ctrlChar){
std::cout<< "Ctrl+C pressed"<< std::endl;
return FALSE;
}
int main(void){
::SetConsoleCtrlHandler(handler, TRUE);
while(true)
::Sleep(100);
return 0;
}
#*********
prototype of handler
BOOL WINAPI HandlerRoutine(DWORD dwCtrlType);
#***************
dwCtrlType
CTRL_C_EVENT Receives Cntl+C
CTRL_BREAK_EVENT Receives Cntl+BREAK
CTRL_CLOSE_EVENT Console is closed by a user
CTRL_LOGOFF_EVENT Receives a signal which is sent from the system
to all console processes because user tries to log off
CTRL_SHUTDOWN_EVENT Receives a signal which is sent from the system
to all console processes because user tries to shut down
#**************
MSDN page in English
http://msdn.microsoft.com/en-us/library/ms686016(VS.85).aspx
Are the above helpful?
Regards
Tatsuro
--- Ethan Merritt <merritt@u.washington.edu> wrote:
> On Thursday 28 January 2010 15:33:48 Tatsuro MATSUOKA wrote:
> > Hello
> >
> > I have remembered that Benjamin have posted concerning issue of ctrl+c on gnuplot.exe for
> windows.
> >
> > http://old.nabble.com/MSWin-issues-holding-up-4.4.rc1-td25793940.html#a26015183
> >
> > ****************
> > --- gnuplot-4.3.0-2009-07-08-orig/src/plot.c 2009-09-20 20:16:47 +0200
> > +++ gnuplot-4.3.0-2009-07-08/src/plot.c 2009-10-18 13:06:08 +0200
> > @@ -684,7 +684,11 @@
> > setmatherr(purec_matherr);
> > #endif
> >
> > +#if defined(WGP_CONSOLE)
> > + (void) signal(SIGINT, SIG_IGN);
> > +#else
> > (void) signal(SIGINT, (sigfunc) inter);
> > +#endif
> >
> > #ifdef SIGPIPE
> > /* ignore pipe errors, this might happen with set output "|head" */
> > ******************
> >
> > The above seems not to be applied yet.
>
> That would cause the program to ignore ctrl-c.
> It would be better to fix the signal-handling routine so that it
> responds to ctrl-c correctly.
>
> Does someone know the history of this problem?
> Did ctrl-c work on Windows in older versions of gnuplot?
> If so, when did it break?
>
> --
> Ethan A Merritt
>
--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/
|
|
From: Hans-Bernhard B. <HBB...@t-...> - 2010-01-29 19:40:54
|
Ethan Merritt wrote: > Does someone know the history of this problem? > Did ctrl-c work on Windows in older versions of gnuplot? To the best of my recollection, no. |
|
From: Benjamin L. <lin...@gm...> - 2010-01-31 19:07:09
|
Ethan Merritt wrote: > On Thursday 28 January 2010 15:33:48 Tatsuro MATSUOKA wrote: >> Hello >> >> I have remembered that Benjamin have posted concerning issue of ctrl+c on gnuplot.exe for windows. >> >> http://old.nabble.com/MSWin-issues-holding-up-4.4.rc1-td25793940.html#a26015183 >> >> **************** >> --- gnuplot-4.3.0-2009-07-08-orig/src/plot.c 2009-09-20 20:16:47 +0200 >> +++ gnuplot-4.3.0-2009-07-08/src/plot.c 2009-10-18 13:06:08 +0200 >> @@ -684,7 +684,11 @@ >> setmatherr(purec_matherr); >> #endif >> >> +#if defined(WGP_CONSOLE) >> + (void) signal(SIGINT, SIG_IGN); >> +#else >> (void) signal(SIGINT, (sigfunc) inter); >> +#endif >> >> #ifdef SIGPIPE >> /* ignore pipe errors, this might happen with set output "|head" */ >> ****************** >> >> The above seems not to be applied yet. > > That would cause the program to ignore ctrl-c. That's what the windows GUI version does... > It would be better to fix the signal-handling routine so that it > responds to ctrl-c correctly. True, but at the current stage pressing ctrl+c segfaults gnuplot and personally I'd prefer it to simply ignore it than to segfault. If you execute gnuplot as piped child process as e.g. octave does, then there is no interactive stdin so ignoring ctrl+c is a quick and simple though maybe not elegant solution of the problem. Besides the signal-handling responds correctly, but the longjmp in bail_to_command_line() fails. > Does someone know the history of this problem? > Did ctrl-c work on Windows in older versions of gnuplot? With older versions you mean the gui version? These ignored ctrl+c to my knowledge. benjamin |
|
From: Tatsuro M. <tma...@ya...> - 2010-02-10 08:38:50
|
Hello
I have traced this issue.
--- Ethan Merritt wrote:
> > ****************
> > --- gnuplot-4.3.0-2009-07-08-orig/src/plot.c 2009-09-20 20:16:47 +0200
> > +++ gnuplot-4.3.0-2009-07-08/src/plot.c 2009-10-18 13:06:08 +0200
> > @@ -684,7 +684,11 @@
> > setmatherr(purec_matherr);
> > #endif
> >
> > +#if defined(WGP_CONSOLE)
> > + (void) signal(SIGINT, SIG_IGN);
> > +#else
> > (void) signal(SIGINT, (sigfunc) inter);
> > +#endif
> >
> > #ifdef SIGPIPE
> > /* ignore pipe errors, this might happen with set output "|head" */
> > ******************
I have completely misunderstood the situation. The (void) signal(SIGINT, (sigfunc) inter); works on
gnuplot.exe. Pressing CTRL+C, inter(int anint) was surely called.
In the function 'inter', the below exist
term_reset();
(void) putc('\n', stderr);
bail_to_command_line(); /* return to prompt */
#####
The upper two
term_reset();
(void) putc('\n', stderr);
was executed correctly and fails at bail_to_command_line();.
bail_to_command_line() is described as
void
bail_to_command_line()
{
#ifdef _Windows
call_kill_pending_Pause_dialog();
#endif
LONGJMP(command_line_env, TRUE);
}
call_kill_pending_Pause_dialog(); exist in commnand.c, and it just call the function
kill_pending_Pause_dialog(); in the following in winmain.c
***
void
kill_pending_Pause_dialog ()
{
if (pausewin.bPause == FALSE) /* no Pause dialog displayed */
return;
/* Pause dialog displayed, thus kill it */
DestroyWindow(pausewin.hWndPause);
#ifndef WIN32
#ifndef __DLL__
FreeProcInstance((FARPROC)pausewin.lpfnPauseButtonProc);
#endif
#endif
pausewin.bPause = FALSE;
}
Obviously, kill_pending_Pause_dialog() has no meaning for gnuplot.exe.
I have quickly tried to modify bail_to_command_line() and ,
bail_to_command_line()
{
#if defined(_Windows) && !defined(WGP_CONSOLE)
call_kill_pending_Pause_dialog();
#endif
LONGJMP(command_line_env, TRUE);
}
However, gnuplot.exe still hangs up.
LONGJMP(command_line_env, TRUE);
seems not work for windows console mode.
Perhaps, the above things have known but I have noticed this time.
Any suggestions?
Regards
Tatsuro
--------------------------------------
VANCOUVER 2010 Olympic News [Yahoo! Sports/sportsnavi]
http://pr.mail.yahoo.co.jp/olympic/
|
|
From: Tatsuro M. <tma...@ya...> - 2010-02-10 08:55:50
|
Hello
Sorry I have still misled.
term_reset();
(void) putc('\n', stderr);
bail_to_command_line(); /* return to prompt */
If, for example, I modify
(void) putc('\n', stderr);
char buf[256];
fgets(buf, strlen(buf), stdin);
bail_to_command_line(); /* return to prompt */
fgets(buf, strlen(buf), stdin);
is ignored. That is a problem.
I have tried term->waitforinput(), the result was the same.
Regards
Tatsuro
--- Tatsuro MATSUOKA wrote:
> Hello
>
> I have traced this issue.
> --- Ethan Merritt wrote:
> > > ****************
> > > --- gnuplot-4.3.0-2009-07-08-orig/src/plot.c 2009-09-20 20:16:47 +0200
> > > +++ gnuplot-4.3.0-2009-07-08/src/plot.c 2009-10-18 13:06:08 +0200
> > > @@ -684,7 +684,11 @@
> > > setmatherr(purec_matherr);
> > > #endif
> > >
> > > +#if defined(WGP_CONSOLE)
> > > + (void) signal(SIGINT, SIG_IGN);
> > > +#else
> > > (void) signal(SIGINT, (sigfunc) inter);
> > > +#endif
> > >
> > > #ifdef SIGPIPE
> > > /* ignore pipe errors, this might happen with set output "|head" */
> > > ******************
>
> I have completely misunderstood the situation. The (void) signal(SIGINT, (sigfunc) inter);
> works on
> gnuplot.exe. Pressing CTRL+C, inter(int anint) was surely called.
>
> In the function 'inter', the below exist
>
> term_reset();
> (void) putc('\n', stderr);
> bail_to_command_line(); /* return to prompt */
>
> #####
> The upper two
> term_reset();
> (void) putc('\n', stderr);
>
> was executed correctly and fails at bail_to_command_line();.
>
> bail_to_command_line() is described as
>
> void
> bail_to_command_line()
> {
> #ifdef _Windows
> call_kill_pending_Pause_dialog();
> #endif
> LONGJMP(command_line_env, TRUE);
> }
>
> call_kill_pending_Pause_dialog(); exist in commnand.c, and it just call the function
> kill_pending_Pause_dialog(); in the following in winmain.c
>
> ***
> void
> kill_pending_Pause_dialog ()
> {
> if (pausewin.bPause == FALSE) /* no Pause dialog displayed */
> return;
> /* Pause dialog displayed, thus kill it */
> DestroyWindow(pausewin.hWndPause);
> #ifndef WIN32
> #ifndef __DLL__
> FreeProcInstance((FARPROC)pausewin.lpfnPauseButtonProc);
> #endif
> #endif
> pausewin.bPause = FALSE;
> }
>
>
> Obviously, kill_pending_Pause_dialog() has no meaning for gnuplot.exe.
>
> I have quickly tried to modify bail_to_command_line() and ,
>
> bail_to_command_line()
> {
> #if defined(_Windows) && !defined(WGP_CONSOLE)
> call_kill_pending_Pause_dialog();
> #endif
> LONGJMP(command_line_env, TRUE);
> }
>
> However, gnuplot.exe still hangs up.
>
> LONGJMP(command_line_env, TRUE);
>
> seems not work for windows console mode.
>
> Perhaps, the above things have known but I have noticed this time.
>
> Any suggestions?
>
> Regards
>
> Tatsuro
>
>
>
>
> --------------------------------------
> VANCOUVER 2010 Olympic News [Yahoo! Sports/sportsnavi]
> http://pr.mail.yahoo.co.jp/olympic/
>
> ------------------------------------------------------------------------------
> SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
> Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
> http://p.sf.net/sfu/solaris-dev2dev
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>
--------------------------------------
VANCOUVER 2010 Olympic News [Yahoo! Sports/sportsnavi]
http://pr.mail.yahoo.co.jp/olympic/
|
|
From: Benjamin L. <lin...@gm...> - 2010-01-26 16:51:05
|
> > Other Windows issues: > - Shall be the default terminal wx instead of windows? I would vote for > this change. If you build gnuplot with wxt terminal then it is already the default. I personally prefer the native windows terminal, it is *much* faster, and it exhibits the expected behaviour of redrawing when moved/resized. So I'd actually prefer to have the windows terminal the default. There is still one issue open I believe: - Copying to clipboard as metafile is broken. This I'd love to see fixed, but I don't really see where the problem lurks. benjamin |
|
From: Hans-Bernhard B. <HBB...@t-...> - 2010-01-26 22:52:03
|
Benjamin Lindner wrote: [about wgnuplot 4.4 candidate:] > There is still one issue open I believe: > - Copying to clipboard as metafile is broken. Broken how, exactly? |
|
From: Benjamin L. <lin...@gm...> - 2010-02-01 21:56:34
Attachments:
termwindow.png
paste.png
|
Hans-Bernhard Bröker wrote: > Benjamin Lindner wrote: > > [about wgnuplot 4.4 candidate:] >> There is still one issue open I believe: >> - Copying to clipboard as metafile is broken. > > Broken how, exactly? > in the way that the command plot sin(x) with linespoints, cos(x) with linespoints produces the attached term window, but when doing Options->Copy to Clipboard and then pasting as Metafile in openoffice the result looks like the second attachment. benjamin |
|
From: Ethan M. <merritt@u.washington.edu> - 2010-02-02 17:25:18
|
On Monday 01 February 2010 13:37:04 Benjamin Lindner wrote: > Hans-Bernhard Bröker wrote: > > Benjamin Lindner wrote: > > > > [about wgnuplot 4.4 candidate:] > >> There is still one issue open I believe: > >> - Copying to clipboard as metafile is broken. > > > > Broken how, exactly? > > > > in the way that the command > > plot sin(x) with linespoints, cos(x) with linespoints > > produces the attached term window, but when doing Options->Copy to Clipboard > and then pasting as Metafile in openoffice the result looks like the > second attachment. > > benjamin I am totally unfamiliar with the mechanisms for loading or dumping the MSWin clipboard. But that doesn't stop me from looking at the code :-) Two thoughts: In wgraph.c (CopyClip) line 1434: hdc = CreateMetaFile((LPSTR)NULL); According to the on-line docs at msdn.microsoft.com, since 2000 it is better to use CreateEnhMetaFile(), and if necessary convert this afterwards to a backwards compatible [unenhanced] metafile. Can the clipboard not handle an enhanced metafile? I also notice the following in the current code, and I wonder if it explains the lack of text output in your clipboard screenshots: wgraph.c line 849: /* HBB 20010218: the GDI status query functions don't work on Metafile * handles, so can't know whether the screen is actually showing * color or not, if drawgraph() is being called from CopyClip(). * Solve by defaulting isColor to 1 if hdc is a metafile. */ isColor = (((GetDeviceCaps(hdc, PLANES) * GetDeviceCaps(hdc,BITSPIXEL))>2) || (GetDeviceCaps(hdc, TECHNOLOGY) == DT_METAFILE)); The comment indicates that GetDeviceCaps() can fail if the context is creation of a metafile, as it is when loading the clipboard. But then elsewhere in the code.... wgraph.c (MakeFonts) line 661: lpgw->lf.lfHeight = -MulDiv(lpgw->fontsize, GetDeviceCaps(hdc, LOGPIXELSY), 72); line 689: /* CMW: Base tick size on character size */ lpgw->htic = lpgw->hchar / 2; cy = MulDiv(cx/20, GetDeviceCaps(hdc, LOGPIXELSY), GetDeviceCaps(hdc, LOGPIXELSX)); lpgw->vtic = MulDiv(cy,lpgw->ymax,lprect->bottom - lprect->top); /* find out if we can rotate text 90deg */ SelectObject(hdc, lpgw->hfontv); result = GetDeviceCaps(hdc, TEXTCAPS); If the comment is correct, then maybe other places where there is a call to GetDeviceCaps() must be modified to do something else during metafile creation. I.e., maybe the font size is being set to 0 because GetDeviceCaps() returns something other than a useful screen resolution. Finally, if the clipboard wants an enhanced metafile, is it possible that an alternative approach is to replace CopyClip() with an equivalent to tmpgc = CreateEnhMetaFile(...) set term push set term emf [some new option to attach the output to tmpgc] replot set term pop -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Allin C. <cot...@wf...> - 2010-02-03 04:04:20
|
On Tue, 2 Feb 2010, Ethan Merritt wrote: > I am totally unfamiliar with the mechanisms for loading or dumping the > MSWin clipboard. But that doesn't stop me from looking at the code :-) > > Two thoughts: > > In wgraph.c (CopyClip) line 1434: > hdc = CreateMetaFile((LPSTR)NULL); > > According to the on-line docs at msdn.microsoft.com, since 2000 > it is better to use CreateEnhMetaFile(), and if necessary > convert this afterwards to a backwards compatible [unenhanced] > metafile. Can the clipboard not handle an enhanced metafile? Yes, the Windows clipboard can handle enhanced metafiles, and since we have a good driver for that format in emf.trm it would be a good idea to make use of it. (I suspect -- though I admit I'm winging it here -- that Windows could downgrade it to WMF if needed for an archaic paste target that can't handle EMF.) One observation on gnuplot 4.4: this list has been much taken up with somewhat arcane problems on Windows. My 2 cents is that it would be good to have 4.4 out as soon as possible just so long as there are no substantial regressions relative to 4.2 (given how much good stuff 4.4 contains). I fear that waiting for perfection on "pause mouse" and company could be a recipe for indefinite postponement. Allin Cottrell |
|
From: Ethan M. <merritt@u.washington.edu> - 2010-02-03 04:40:09
|
On Tuesday 02 February 2010, Allin Cottrell wrote: > > One observation on gnuplot 4.4: this list has been much taken up > with somewhat arcane problems on Windows. That's 'cos Windows is in the worst shape. > My 2 cents is that it > would be good to have 4.4 out as soon as possible just so long as > there are no substantial regressions relative to 4.2 (given how > much good stuff 4.4 contains). I fear that waiting for perfection > on "pause mouse" and company could be a recipe for indefinite > postponement. To be fair, people have been sending reports and patches to fix build problems on other platforms as well. But I've been kind of busy, and haven't yet caught up with all of them. The target release date all along has been March (6 months after 4.2.6). I think we can hit that target, though I am not sure we will have a fully automated recipe for building from source under OSX. Ethan |
|
From: Tatsuro M. <tma...@ya...> - 2010-02-03 06:22:50
|
Hello --- Allin Cottrell wrote: > One observation on gnuplot 4.4: this list has been much taken up > with somewhat arcane problems on Windows. My 2 cents is that it > would be good to have 4.4 out as soon as possible just so long as > there are no substantial regressions relative to 4.2 (given how > much good stuff 4.4 contains). I fear that waiting for perfection > on "pause mouse" and company could be a recipe for indefinite > postponement. For 'pause mouse' problem for without the graph window is not serious for the windows terminal. One can breaks 'pause mouse' without the graph window by pressing enter for windows terminal. For wxt terminal, one cannot break it by the Enter key. The problem is related to the CTRL+C problem for windows. If it will be fixed, the wxt terminal problem will not be serious. However, if it cannot be fixed, it is better to go forward noting that 'pause mouse' problem for without the graph window on wxt terminal for windows is known problem. In practical sense, the situation of the graph window is disappeared is not caused in the ordinary use, I think. Regards Tatsuro Regards Tatsuro -------------------------------------- VANCOUVER 2010 Olympic News [Yahoo! Sports/sportsnavi] http://pr.mail.yahoo.co.jp/olympic/ |
