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

Re: Reworked qt terminal is much faster – and fails to work on Mac

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

On Monday, 03 March 2014 01:41:06 AM Mojca Miklavec wrote:
> On Sun, Mar 2, 2014 at 11:28 PM, Daniel J Sebald wrote:
> >
> > I wrote a clean patch which I placed here
> >
> > https://sourceforge.net/p/gnuplot/patches/653/
> 
> I first faced problems with "plugin"
> 
> Making all in plugin
> /bin/sh: line 0: cd: plugin: No such file or directory

That's a totally separate problem.
The new .../demo/plugin directory is not being handled properly
by autoconf/automake.  I don't know how to fix it, but the answer 
for now is to use
 ./configure --disable-plugins

> but after manually patching the Makefile (there is a fair chance that
> my setup is semi-broken in that respect, so I don't blame the sources
> until I do a few more tests from a totally clean CVS checkout), here
> are the initial problems again:
> 
> gnuplot> plot sin(x)
> qt_sendFont: Not receiving font properties
> qt_sendFont: "QLocalSocket: Socket operation timed out"
> gnuplot> qt_processTermEvent received a GE_fontprops event. This
> should not have happened
> 
> The plot finally appears after 15 seconds, without any labels, wrong
> window size (that's also a problem in trunk/HEAD). Gnuplot then never
> properly recovered (I never got any text labels).
> 
> The second gnuplot run works.
> 
> These are exactly the symptoms that Ethan fixed recently.

Yeah. I put my comments on the patch tracker, but in short the patch
removes exactly the fixes I put in to handle the slow OSX font response.
So I don't think this patch is going in the right direction for event
handling.

The initial fork+and wait of the external process may be cleaner in
Dan's patch than it was before.  But I think we should leave the event
handling the way it is now.

	Ethan

Re: Reworked qt terminal is much faster – and fails to work on Mac

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

On 03/02/2014 06:41 PM, Mojca Miklavec wrote:
> On Sun, Mar 2, 2014 at 11:28 PM, Daniel J Sebald wrote:
>>
>> I wrote a clean patch which I placed here
>>
>> https://sourceforge.net/p/gnuplot/patches/653/
>
> I first faced problems with "plugin"
>
> Making all in plugin
> /bin/sh: line 0: cd: plugin: No such file or directory

Not sure what that is, as I don't see any instance of "plugin" in the 
patch.  I am, however, disabling plugins when I build so maybe that is 
finding its way into the patch file somehow.


> here
> are the initial problems again:
>
> gnuplot>  plot sin(x)
> qt_sendFont: Not receiving font properties
> qt_sendFont: "QLocalSocket: Socket operation timed out"
> gnuplot>  qt_processTermEvent received a GE_fontprops event. This
> should not have happened

Probably the flush isn't complete before waiting on the GE_fontprops 
event.  Could you please search for this line in the code

#if 0  // 2014mar02 NOT SURE THIS IS NEEDED

and change 0 to 1?

Thanks,

Dan

Re: Repository conversion

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

On 02/24/2014 04:42 PM, Clark Gaylord wrote:
> I would certainly agree that git is apparently more prevalent than hg but both have reasonable critical mass. I wouldn't be concerned about the vitality of either. I would suggest those who are interested do a real comparison relative to how you want the project to work, and do so with an open mind relative to your preferred default.
>
> For example one thing git does well is manage changes that do not respect file structure, whereas hg considers the file to be the artifact that is managed. I think in gnuplot the latter is consistent with how we think of the code base, but git's perspective is interesting.

 From my understanding, the reason that git is more flexible in terms of 
modifying past comments as pointed out by Mojca is fact that the 
underlying manner in which files are stored in git is as complete files, 
albeit hash files.  On the other hand, hg uses a series of diffs.  Thus 
hg is in more sense "immutable".

There is a bit of philosophy with this, however.  Going back through 
local changesets and making modifications to comments, etc. is one 
thing, but once the canonical version of the repository is modified it 
is best to leave that be--the reason being that there are possibly 
hundreds of other developers who have clones of that repository and 
modifying the base of the canonical version risks upsetting the apple 
cart for a lot of people.  So, once a push is done and considered 
public, it is best to be immutable.

Locally, I'm often deconstructing some sequence of two or three 
changesets and correcting things in mercurial.  From the sound of it, it 
is probably easier to do such a thing in git, but it isn't that 
difficult in hg either so long as the canonical repository is still not 
updated as a reference point to get back to.  Changesets can be 
exported/copied from one clone to another so long as their bases are the 
same.  Mercurial makes a little noise doing such a thing now and then, 
but often diffs can be imported without too much fuss.

I recently read a blog post by Steve Losh that made a good point about 
the big difference between the two systems: the look and feel.  I pretty 
much agree with that.  For me, the two differences that stood out when I 
compared git and mercurial years ago (git I have limited exposure with 
since):

1) I found hg's syntax more understandable and less cumbersome.  I 
didn't like the staging area concept of Git because it felt repetitive, 
although I'm sure there might be some simple ways of circumventing this 
staging area because git does provide so many options/configurations. 
So please point out if that is still true and a big difference between 
the two systems.

2) Mercurial has a built in html server that I really like.  Does git 
have that now?  I really like being able to go to some project's 
repository online and there is that similar, nice interface for finding 
info about recent changesets, browsing code, viewing file history, etc. 
  That really is an important part of source control.  (One of the 
nicest VCS's in terms of visual navigation is a commercial product, but 
isn't a distributed VCS but more along the lines of cvs.)

Recently I've discovered tortoisehg which is a very nice interface for 
Windows users especially.  I assume there is a tourtoisegit as well. 
So, for Windows developers, hg and git look-and-feel differences might 
hardly matter.  Also, a good merge tool is worth considering, but I 
think that might independent of the git/hg question.

Dan

Re: Reworked qt terminal is much faster – and fails to work on Mac

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

On Sun, Mar 2, 2014 at 11:28 PM, Daniel J Sebald wrote:
>
> I wrote a clean patch which I placed here
>
> https://sourceforge.net/p/gnuplot/patches/653/

I first faced problems with "plugin"

Making all in plugin
/bin/sh: line 0: cd: plugin: No such file or directory

but after manually patching the Makefile (there is a fair chance that
my setup is semi-broken in that respect, so I don't blame the sources
until I do a few more tests from a totally clean CVS checkout), here
are the initial problems again:

gnuplot> plot sin(x)
qt_sendFont: Not receiving font properties
qt_sendFont: "QLocalSocket: Socket operation timed out"
gnuplot> qt_processTermEvent received a GE_fontprops event. This
should not have happened

The plot finally appears after 15 seconds, without any labels, wrong
window size (that's also a problem in trunk/HEAD). Gnuplot then never
properly recovered (I never got any text labels).

The second gnuplot run works.

These are exactly the symptoms that Ethan fixed recently.

Mojca

Re: Qt terminal has a long wait at the end of running 'all.dem'

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

On 03/02/2014 04:47 PM, sfeam wrote:
> On Sunday, 02 March 2014 04:36:04 PM Daniel J Sebald wrote:
>> When I ran 'all.dem' interactively to test the patch I referred to in a
>> previous post, at the very end there was about a five to ten second
>> delay before gnuplot came back to the command line.  If I ran the last
>> demo inside 'all.dem' on its own there was no delay.
>>
>> Does anyone have a guess at what might be the issue with that?
>
>    That would be because the last line executed by all.dem is "pause 5"
>    It gives the user something pretty to look at.
>    Otherwise on a fast machine the whole thing is blink-and-it's-gone.

Oh...

Good point about blink-and-gone.  I usually just use 'all.dem' for 
testing purposes and if I want to know about features I look to the 
individual demo files.

That makes me wonder if maybe gnuplot should have an internal pause 
setting that is inherent after every plot.  E.g.,

set pause 0.5 plot
load 'all.dem'

which would pause a half second after every plot no matter if there are 
queued carriage returns or a NULL input.  Something like that.

Dan

Qt terminal speedup by placing socket within separate thread?

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

OK, here's a follow-up post on what I've learned from reworking the 
waiting constructs of the qt_term.cpp file.

Oh, first I forgot to say in the previous post that the patch did not 
address the issue of Qt terminal dimensions persistence.  We can do that 
after patch #653 is stable.  Basically, gnuplot_qt needs a command that 
will send back position information just as it does with the font 
information.  Should be easy once things are stable.

After patch #653 is stable, I'd like to revisit the idea of using a 
separate thread to, in this case, improve the efficiency of data 
transfer.  Here is what I think is the biggest ramification of not 
having an event loop to work in.  The stream of data intended for 
gnuplot_qt is first sent into an intermediate output buffer and then 
later written to the server socket with a continual flush.  That is 
repetitive and, I think, can be avoided with an event loop in a second 
thread.

This routine is the core of the issue:

void qt_flushOutBuffer()
{
	if (!qt || !qt->socket.isValid())
		return;

	// Write the block size at the beginning of the block
	QDataStream sizeStream(&qt->socket);
	sizeStream << (quint32)(qt->outBuffer.size());
	// Write the block to the QLocalSocket
	qt->socket.write(qt->outBuffer);
	// Reset the buffer
	qt->out.device()->seek(0);
	qt->outBuffer.clear();

	while (qt->socket.bytesToWrite() > 0)
	{
		// Write as much data at once as the operating system will allow
		// for the socket.
		qt->socket.flush();

#if 0  // 2014mar02 NOT SURE THIS IS NEEDED
		// Avoid dead-locking when no more data is available
		if (qt->socket.bytesToWrite() > 0)
		{
			if (!(qt->socket.waitForBytesWritten(DEFAULT_TIMEOUT)))
			{
				qDebug() << "qt_flushOutBuffer: Bytes not being written to socket";
				qDebug() << "qt_flushOutBuffer:" << qt->socket.errorString();
				break;
			}
		}
#endif
	}
}


Because there is no event loop, the use of "socket.flush()" is 
mandatory.  If the socket were in a separate thread with an event loop, 
all that would be needed is a write to that socket.  The even loop would 
then manage data flow out to the peripheral gnuplot_qt.  See this reference:

http://qt-project.org/doc/qt-4.8/qlocalsocket.html#flush

    "In most cases, you do not need to call this function, because 
QLocalSocket will start sending data automatically once control goes 
back to the event loop. In the absence of an event loop, call 
waitForBytesWritten() instead."

So, what I'm wondering is if we start a thread and then move the socket 
over to that thread that might obviate the need for flushing anywhere. 
If that is the case, then perhaps instead of sending all the terminal 
API commands to an intermediate qt->outBuffer.  If that is the case, it 
might make qt_term/gnuplot_qt data transfer a little faster.

Do you think that will improve things Jérôme?  Maybe next weekend I'll 
give that a try if it makes sense.

Dan

Re: Qt terminal has a long wait at the end of running 'all.dem'

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

On Sunday, 02 March 2014 04:36:04 PM Daniel J Sebald wrote:
> When I ran 'all.dem' interactively to test the patch I referred to in a 
> previous post, at the very end there was about a five to ten second 
> delay before gnuplot came back to the command line.  If I ran the last 
> demo inside 'all.dem' on its own there was no delay.
> 
> Does anyone have a guess at what might be the issue with that?

  That would be because the last line executed by all.dem is "pause 5"
  It gives the user something pretty to look at. 
  Otherwise on a fast machine the whole thing is blink-and-it's-gone.

	Ethan

Qt terminal has a long wait at the end of running 'all.dem'

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

When I ran 'all.dem' interactively to test the patch I referred to in a 
previous post, at the very end there was about a five to ten second 
delay before gnuplot came back to the command line.  If I ran the last 
demo inside 'all.dem' on its own there was no delay.

Does anyone have a guess at what might be the issue with that?

Thanks,

Dan

Re: Reworked qt terminal is much faster – and fails to work on Mac

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

 From thread:

Re: enhanced_recursion()  and do_event(), can they be redesigned?

On 02/25/2014 11:39 PM, Daniel J Sebald wrote:
> On 02/24/2014 09:59 AM, Jérôme Lodewyck wrote:
[snip]
>> Concerning the code you propose: apart from the synchronization problems
>> between the Qt event loop and the main thread that you mention, I am
>> worried about the performances. As far as I can see, the communication
>> between the main thread and the thread running the Qt event loop relies
>> on the signal/slot mechanism, which I think can be significantly slower
>> that direct function calls. From rough testing, plotting a graph with a
>> million points takes about 3x more time with the code you posted.
[snip]
> So, how about as a first step this weekend I take just the QProcess
> startup code and make a nice diff/patch for you to try out and tweak how
> you see fit. We'll see if that much gets us to a functioning OSX Qt
> terminal. Simplifying that should clear things up so that if OSX Qt term
> still doesn't function we might find the source of the problem.

I wrote a clean patch which I placed here

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

for cleaning up the linking and waiting for gnuplot_qt socket.  This has 
no thread-related code.  It is simply what I think is improved use of 
existing Qt class member functions for waiting.  The basic summary is 
that the while loops which "poll" for input or response are removed.  To 
me, polling means whenever a loop just circulates as fast as possible 
when waiting on something.  So, while there are some while loops still 
left in the code after this patch, they are of the variety that has a 
proper Qt wait mechanism which handles all that detail for us.

As far as Mac OSX, I think there is nothing within qt_term.cpp anymore 
that is specific to OSX.

A larger summary of changes is below, but please give the patch a try 
and let me know how things work.

After this post I will write a follow-up post about threading and the 
possibility of speeding up qt_term transfer.

Dan


* I changed the QProcess to be a conventional one rather than a 
disconnected one.  That way there is still some access to the process so 
that the constructed server name can be retrieved from the process 
itself rather than having to duplicate the construction of the name in 
multiple places.  We can then use the Qt waiting mechanisms and get rid 
of the custom while loop that waits for an external server to appear.

* Note:  In qt_flushOutBuffer() the flush() is necessary because there 
is no event loop.  If there were an event loop, just socket.write() 
would be enough.

* I commented out

	// Avoid dead-locking when no more data is available
	if (qt->socket.bytesToWrite() > 0)
		qt->socket.waitForBytesWritten(-1);

because I don't think it is necessary.  I left it there just in case it 
is needed on some systems.  I doubt it, though.

* I added

     qt->socket.disconnectFromServer();

to the end of qt_atexit().  That routine waits for all pending data to 
be sent before returning and complains if one attempts to wait on 
disconnect.  So, an additional wait-on-disconnect doesn't seem necessary.

* I altered the way that qt_term waits on gnuplot_qt when it wants font 
property info.  (We are going to need to add a similar routine in order 
to get the true terminal size back from gnuplot_qt term in to fix the 
issue Ethan noted.)  I make use of the proper timeout mechanism for Qt 
rather than introducing "micro sleep" and timeouts of 0 or -1.  If one 
reviews that hunk of code they'll realize it is pretty conventional, 
i.e., keep reading bytes until enough are read to fill 
sizeof(gp_event_t).  It turns out that one read typically get all of the 
bytes necessary.

* Even after this change, I don't like the fact that qt_sendFont() 
discards events.  It is usually carriage returns from holding the Enter 
key down and an event slips in before gnuplot_qt receives 
GEFontMetricRequest.  However, I'm not sure what to do without some kind 
of queueing mechanism.

* Similar to the waiting on font info, I changed this while loop:

   while (qt->socket.bytesAvailable() >= (int)sizeof(gp_event_t)) {
   }

because, as with Yuriy Kaminskiy, that construct doesn't sit well with 
me.  Beyond seeming like it could get stuck in certain situations (maybe 
not), I don't like that it is whirling away waiting for the number of 
bytes to be sufficient.  We should be using the Qt mechanism to do any 
type of waiting rather than doing polling.

* I changed that construct for Windows as well.  It looks like almost an 
exact copy so I suspect it shouldn't break Windows Qt term.  But if it 
breaks something, we'll have to do another rev.

* The only thing I worry about (and I've left a note in the code) is 
that when waiting for responses from gnuplot_qt (such as font props) if 
there was a preceeding plot that has a huge amount of data.  If the plot 
doesn't complete in the timeout, then there could be an error.  The 
proper thing would be to dynamically adjust the wait time.  But let's 
hold off on that scheme.  I defined DEFAULT_TIMEOUT at the top of 
qt_term.cpp and we can lengthen that if need be.

* There may be a chance that Windows persist works correctly now.  I 
changed the qt_atexit() function slightly to use Qt routines

	// This Qt function waits until pending data to write is complete.
	qt->socket.disconnectFromServer();

Before that change it seemed like qt_atexit() might be wrapping things 
up too briskly, not giving enough time for proper interchange and 
disconnect.  Perhaps Windows automatically deletes the gnuplot_qt 
process without proper disconnect, or more likely the persist command 
wasn't making its way to gnuplot_qt.

Re: Inconsistent type magic

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

On Sunday, 02 March 2014 01:47:57 AM pl...@pi... wrote:
> Hi,
> 
> I'm trying to get a status result back from a system call but am getting 
> inconsistent behaviour from the automatic typecasting magic.
> 
> bash$ test=OK;echo $test; echo $?
> OK
> 0
> 
> gnuplot
>    Version 4.7 patchlevel 0    last modified 2012-10-16
> ....
> 
> gnuplot>   cmd="test=OK;echo $test; echo $?;"
> gnuplot>  res=0;print system (cmd);print res
> OK
> 0
> 0
> 
> gnuplot>  res=0;  res= system (cmd);print res
> OK
> 0
> 
> gnuplot> res=0; if (res==0) {print "test OK"}
> test OK
> 
> gnuplot>  res=0;  res=res+ system (cmd);print res
>           Non-numeric string found where a numeric expression was expected
> 
> gnuplot>  res=0;  res=res || system (cmd);print res
>           non-integer passed to boolean operator
> 
> 
> Now I know automatic typing is _supposed_ to be inconsistent ( it's a 
> feature not a bug). but this seems nonsensical.
> 
> The first and second invocations are as expected and prints integer zero 
> (the status result returned by the shell). So what the heck is it 
> complaining about when I try to add integer zero to integer zero?

gnuplot> help system
  `system "command"` executes "command" using the standard shell. See `shell`.
 If called as a function, `system("command")` returns the resulting character
 stream from stdout as a string.

Your printout above shows exactly this. 
After setting res = system(...) it is a string
containing "OK\n0"

> How is it that it manages to print the zero result directly but when I 
> try to add it , it suddenly becomes a "non numeric" expression? Then a 
> "non integer".

It doesn't print 0.  It prints "OK\n0"

> Is this really what it's supposed to be doing?

Yes.

	Ethan

Inconsistent type magic

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

Hi,

I'm trying to get a status result back from a system call but am getting 
inconsistent behaviour from the automatic typecasting magic.

bash$ test=OK;echo $test; echo $?
OK
0

gnuplot
   Version 4.7 patchlevel 0    last modified 2012-10-16
....

gnuplot>   cmd="test=OK;echo $test; echo $?;"
gnuplot>  res=0;print system (cmd);print res
OK
0
0

gnuplot>  res=0;  res= system (cmd);print res
OK
0

gnuplot> res=0; if (res==0) {print "test OK"}
test OK

gnuplot>  res=0;  res=res+ system (cmd);print res
          Non-numeric string found where a numeric expression was expected

gnuplot>  res=0;  res=res || system (cmd);print res
          non-integer passed to boolean operator


Now I know automatic typing is _supposed_ to be inconsistent ( it's a 
feature not a bug). but this seems nonsensical.

The first and second invocations are as expected and prints integer zero 
(the status result returned by the shell). So what the heck is it 
complaining about when I try to add integer zero to integer zero?

How is it that it manages to print the zero result directly but when I 
try to add it , it suddenly becomes a "non numeric" expression? Then a 
"non integer".


Is this really what it's supposed to be doing?

Best regards. Peter.

demo/plugin Makefile is not derivative of configure

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

I've tried to build gnuplot in a directory other than the "src" 
directory but it failed because the demo/plugin/Makefile is missing from 
the "build" directory.  The reason is that demo/plugin/Makefile is in 
the repository and not generated from the ./prepare and ./configure 
build process.  If I use

../gnuplot/configure --with-qt --disable-plugins

gnuplot builds without problem.

Should I try fixing that?  Or is the change to a Makefile.in or 
Makefile.am.in obvious to someone else?

Thanks,

Dan

fit now segfaults

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

Unfortunately, since yesterday's change to fit.c I get a segfault
from the fit demo:

gnuplot> load 'fit.dem'
Some examples how data fitting using nonlinear least squares fit can be done.

We fit a straight line to the data -- only as a demo without physical meaning.
  fit function:l(x) = y0 + m*x
  initial parameters: y0 = 0, m = 0
  fit command: fit l(x) 'lcdemo.dat' via y0, m

Now start fitting...  (-> return)
fit: Deprecated syntax. Consider using the 'noerror' option, see `help fit`.

Program received signal SIGSEGV, Segmentation fault.
0x0000000000449672 in fit_command () at fit.c:1924
1924                err_data[num_data] = 1; /* constant weight */

(gdb) print num_data
$1 = 0
(gdb) print err_data
$2 = (double *) 0x0
((gdb) print max_data
$2 = 2048
(gdb) print num_errors
$4 = 0

So err_data is being allocated as length 0 because num_errors = 0.
But then it is accessed anyway.
What's the fix?

	Ethan

Re: enhanced_recursion() and do_event(), can they be redesigned?

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

On Thu, Feb 27, 2014 at 6:31 PM, Jérôme Lodewyck wrote:
>
>> Alternatively, would it be possible to write the mouse coordinates into a widget
>> contained in the toolbar rather than into the status bar?   That would also
>> conserve vertical space.  And it might have the side-effect of working around
>> the current OSX glitch of not properly allocating space for the status bar.
>
> I have precisely tested this idea recently but didn't find the result
> visually appealing. I can submit a patch tough.

Another option would be to write the coordinates on a semi-transparent
frame somewhere in the bottom left corner when mouse is in the
plotting area. And make it disappear when the mouse goes away or is
inactive long enough (to allow to clearly see the whole plot).

Something similar to the way that play/pause/stop buttons work in
media players or in YouTube. When mouse is active, they are shown,
after certain actions they are removed to allow to clearly see the
video.

Mojca

Re: enhanced_recursion() and do_event(), can they be redesigned?

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

On Thursday, 27 February, 2014 09:17:33 Ethan A Merritt wrote:
 
> By the way, is there a some way to toggle the toolbar itself on and off?  
> I'd like to conserve vertical screen space.

Answering my own question...
I find that if you right-click in the blank area of the toolbar there is an unlabeled
check-box which, if clicked, makes the toolbar vanish. 

	Ethan

Re: enhanced_recursion() and do_event(), can they be redesigned?

[Jérôme L. <lod...@us...>]

Le 27/02/2014 18:17, Ethan A Merritt a écrit :
> I must amend my previous statement.
> "set term qt size" seems to have started working at some point (recently?).
> It used to be ignored entirely, and I did not recheck.

Actually, I think I broke it accidentally, but restored the correct 
behaviour shortly afterwards. But it still has some rough edges as 
reported by Daniel and Mojca

> By the way, is there a some way to toggle the toolbar itself on and off?

Adding such an option is possible, but the question is how to restore it 
if no other widget is visible and the mouse & key events are captures by 
gnuplot.

> I'd like to conserve vertical screen space.

It is still possible to have it clutter your horizontal screen space 
instead by moving it to the left edge of the window.

> Alternatively, would it be possible to write the mouse coordinates into a widget
> contained in the toolbar rather than into the status bar?   That would also
> conserve vertical space.  And it might have the side-effect of working around
> the current OSX glitch of not properly allocating space for the status bar.

I have precisely tested this idea recently but didn't find the result 
visually appealing. I can submit a patch tough.

Jérôme

Re: enhanced_recursion() and do_event(), can they be redesigned?

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

On Thursday, 27 February, 2014 07:55:33 Jérôme Lodewyck wrote:
> Le mercredi 26 février 2014 22:02:13 sfeam a écrit :
> > The one bit that I would say is still unsatisfactory in the Qt
> > terminal is the fact that you can't set a size preference, the
> > size you manually set via "set term qt size XX,YY" is ignored,
> 
> Is that issue specific to OS X ? On my system, it works as expected.

I must amend my previous statement.
"set term qt size" seems to have started working at some point (recently?).
It used to be ignored entirely, and I did not recheck.

> > and any resizing you do using the mouse is not persistent.
> Does that mean that the window resizes to default after each plot command ?

I mean that if I resize with the mouse in one gnuplot session,
the size is not remembered for the next gnuplot session.
It's debatable whether this should be the default, but I would
at least like to have an option in the tools widget to save the
current size as the default.

By the way, is there a some way to toggle the toolbar itself on and off?  
I'd like to conserve vertical screen space.

Alternatively, would it be possible to write the mouse coordinates into a widget
contained in the toolbar rather than into the status bar?   That would also
conserve vertical space.  And it might have the side-effect of working around
the current OSX glitch of not properly allocating space for the status bar.  

	Ethan

Re: enhanced_recursion() and do_event(), can they be redesigned?

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

On Thu, Feb 27, 2014 at 7:55 AM, Jérôme Lodewyck wrote:
> Le mercredi 26 février 2014 22:02:13 sfeam a écrit :
>> The one bit that I would say is still unsatisfactory in the Qt
>> terminal is the fact that you can't set a size preference, the
>> size you manually set via "set term qt size XX,YY" is ignored,
>
> Is that issue specific to OS X ? On my system, it works as expected.

On OS X it works *almost* as expected.

- the first window is too small (x axis is covered with status bar),
but the second plot fixes that
- if I use "set term qt size 1000,800", the size of the first plot is
right, but the window holding the plot is too small (it looks like it
had the default size), so bottom right part of the plot is hidden (if
I disable replotting on resize, resizing the window leads to the whole
plot being visible)
- if I use "set term qt size 200,200", I get what you see in attachment
- it's hard to tell exactly, but very often the first plot after
changing the size with "set term qt size" has wrong dimensions and the
second one works just fine

In principle it works most of the time (except when it doesn't).

>> and any resizing you do using the mouse is not persistent.
>
> Does that mean that the window resizes to default after each plot command ?

It doesn't resize for me. If I resize the window with mouse, the next
plot properly adapts to that size.

Mojca

Re: enhanced_recursion() and do_event(), can they be redesigned?

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

On 02/27/2014 12:46 AM, Jérôme Lodewyck wrote:
> Le mardi 25 février 2014 23:39:38 Daniel J Sebald a écrit :
>>> So could you point out a specific past or present problem in the Qt
>>> terminal that is due to the fact that no event loop is running in the
>>> inboard driver ?
>>
>> The answer is "no".  But the follow up to that is I really didn't search
>> for that.  I'm trying to solve the problem of the Qt terminal apparently
>> not working on Mac OSX or Windows the way it should in combination with
>> the fact that I don't have Mac OSX or Windows.  So I'm striving for an
>> event loop in hopes that makes the setup work better on all platforms. I
>> can't answer your question...that is, without looking into greater
>> detail of the Qt source code.
>
> Maybe I am wrong, but I think that adding an event loop will not make things
> work better. All the difficulties we had to make the Qt terminal work on all
> platforms are related to correctly setting the size of the plot window

I just sent a post identifying where the problem is with sizing, but it 
will take a little more to fix properly.


>  and
> correctly integrating the initialization of the QLocalSocket into the workflow
> of the main gnuplot program; which are problems that you will also face with
> an event loop.
> If you are motivated to pursue your idea, we will be able to balance whether
> things are less quirky or not with an event loop, but as Ethan said, things
> are already working almost correctly.

The event loop is on hold.  Let's clean up QProcess, QLocalSocket 
workflow first.

Dan

Re: enhanced_recursion() and do_event(), can they be redesigned?

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

On 02/27/2014 12:02 AM, sfeam wrote:

> The one bit that I would say is still unsatisfactory in the Qt
> terminal is the fact that you can't set a size preference, the
> size you manually set via "set term qt size XX,YY" is ignored,
> and any resizing you do using the mouse is not persistent.
> If you can figure out how to fix that then Mojca and I at least
> would be happier, and probably future Qt users as well.

I'm not seeing that on Linux.  The window size seems to work fine, as 
far as I can tell.  The information is being sent.  Is some kind of 
strange combination of switching between windows and sizes?  The 
following does seem some somewhat suspect:

	// Set plot size
	if (qt_setSize)
	{
		term->xmax = qt_oversampling*qt_setWidth;
		term->ymax = qt_oversampling*qt_setHeight;
		qt_setSize = false;
	}

If 'size' is set in the options then the term structure is updated and 
setSize cleared.  But what if one then just switches the term number?

set term qt 4
plot x
set term qt 5 size 300,300
plot x**2
set term qt 4
plot x

I just confirmed that doesn't work properly.  Is that what you are 
referring to?  Intermixing that qt_setSize test with the streams sent to 
the outboard program might fix that size-persistence issue, i.e., the 
size command doesn't get sent unless the user actually specified the size.

	qt->out << GESetCtrl << qt_optionCtrl;
	if (qt_setSize)
	{
		term->xmax = qt_oversampling*qt_setWidth;
		term->ymax = qt_oversampling*qt_setHeight;
		// Set plot size
		qt->out << GESetWidgetSize << QSize(term->xmax, 
term->ymax)/qt_oversampling;
		// Initialize the scene
		qt->out << GESetSceneSize << QSize(term->xmax, 
term->ymax)/qt_oversampling;
		qt_setSize = false;
	}
	qt->out << GEClear;

I tried something like that and it doesn't work exactly right either. 
I'll have to look at that later.

BTW, I also notice that the maximum size is kind of small.  Try

set term qt 6 size 800,800
plot x

and it doesn't look any larger than the default plot size.  Going 
smaller works though:

set term qt 5 size 300,300
plot x**2

Another BTW, the mouse scroll wheel button (center button) seems a 
little odd.  Using that in one Qt window causes plot activity, but it 
also cause plot activity in another Qt plot window that is open.

Dan

Re: enhanced_recursion() and do_event(), can they be redesigned?

[Jérôme L. <lod...@us...>]

Le mercredi 26 février 2014 22:02:13 sfeam a écrit :
> The one bit that I would say is still unsatisfactory in the Qt
> terminal is the fact that you can't set a size preference, the
> size you manually set via "set term qt size XX,YY" is ignored,

Is that issue specific to OS X ? On my system, it works as expected.

> and any resizing you do using the mouse is not persistent.

Does that mean that the window resizes to default after each plot command ?

Jérôme

Re: enhanced_recursion() and do_event(), can they be redesigned?

[Jérôme L. <lod...@us...>]

Le mardi 25 février 2014 23:39:38 Daniel J Sebald a écrit :
> > So could you point out a specific past or present problem in the Qt
> > terminal that is due to the fact that no event loop is running in the
> > inboard driver ?
> 
> The answer is "no".  But the follow up to that is I really didn't search
> for that.  I'm trying to solve the problem of the Qt terminal apparently
> not working on Mac OSX or Windows the way it should in combination with
> the fact that I don't have Mac OSX or Windows.  So I'm striving for an
> event loop in hopes that makes the setup work better on all platforms. I
> can't answer your question...that is, without looking into greater
> detail of the Qt source code.

Maybe I am wrong, but I think that adding an event loop will not make things 
work better. All the difficulties we had to make the Qt terminal work on all 
platforms are related to correctly setting the size of the plot window and 
correctly integrating the initialization of the QLocalSocket into the workflow 
of the main gnuplot program; which are problems that you will also face with 
an event loop.
If you are motivated to pursue your idea, we will be able to balance whether 
things are less quirky or not with an event loop, but as Ethan said, things 
are already working almost correctly.
 
> > motivation for this was a significant performance increase: the
> > initialization of a QApplication requires more than 0.5 s against a few
> > 10ms for a QCoreApplication. Moving back the font metric business in the
> > main gnuplot program will require to instantiate again a QApplication
> > and thus cancel this performance improvement.
> 
> The 0.5 s happened every time a new Qt window is opened?

No, only for the first one. But my motivation for this patch was that I have 
developed a monitoring application that fires about 20 gnuplot instances that 
forward their plots to a single Qt application (much like the embed_example, 
but with a gnuplot process dedicated tor each plot). With qt_term.cpp using a 
QApplication, my application took more than 10s to start up. 

> So, how about as a first step this weekend I take just the QProcess
> startup code and make a nice diff/patch for you to try out and tweak how
> you see fit.

Let's see !

Jérôme

Re: enhanced_recursion() and do_event(), can they be redesigned?

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

On Wednesday, 26 February 2014 11:29:52 PM Daniel J Sebald wrote:
>  Why couldn't the terminal API have a timeout specifier, i.e.,
> 
> int qt_waitforinput(int ms)
> 
> and then only have the Qt terminal pertinent code while gnuplot core 
> watches for the other input routes?

Why would there be a timeout?   If you are waiting for the user
to finish inspecting their plot before continuing, that could
take a long time.  They might even go off for lunch before deciding
to hit <cr> or click the mouse.  They'd be rather annoyed if they
came back from lunch to find that the plot had disappeared or was
no longer selectable.

Anyhow, it seems like as of today we have Qt working on all three
platforms with maybe some quirks about slow font handling on OSX
that we probably can't do a whole lot about.
  
The one bit that I would say is still unsatisfactory in the Qt
terminal is the fact that you can't set a size preference, the
size you manually set via "set term qt size XX,YY" is ignored,
and any resizing you do using the mouse is not persistent.
If you can figure out how to fix that then Mojca and I at least
would be happier, and probably future Qt users as well. 

	Ethan
 

Re: enhanced_recursion() and do_event(), can they be redesigned?

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

On 02/26/2014 12:46 AM, Bastian Märkisch wrote:
> Am 26.02.2014 06:39, schrieb Daniel J Sebald:
>> On 02/24/2014 09:59 AM, Jérôme Lodewyck wrote:
>>> So could you point out a specific past or present problem in the Qt
>>> terminal that is due to the fact that no event loop is running in the
>>> inboard driver ?
>>
>> The answer is "no". But the follow up to that is I really didn't search
>> for that. I'm trying to solve the problem of the Qt terminal apparently
>> not working on Mac OSX or Windows the way it should in combination with
>> the fact that I don't have Mac OSX or Windows. So I'm striving for an
>> event loop in hopes that makes the setup work better on all platforms. I
>> can't answer your question...that is, without looking into greater
>> detail of the Qt source code.
>>
>
> FWIW, Qt runs nicely on Windows. The only real issue there was to
> implement a way to handle all possible types of events (console, stdin,
> Qt pipe, Windows messages) at the same time. That has been solved in a
> non-portable way, but so is the code using select() on Unix-like
> systems. See the ChangeLog entry on 2014-02-14 and the SF patch tracker
> #645.

There is a lot to read there, but I get the overall idea.  That select() 
(and analogous Windows code) looks like another case of something that 
might be better in the core code.  Looking at qt_waitforinput() it seems 
it cycles through all the possible input modes allotting 1 millisecond 
to input.  Why couldn't the terminal API have a timeout specifier, i.e.,

int qt_waitforinput(int ms)

and then only have the Qt terminal pertinent code while gnuplot core 
watches for the other input routes?

In any case, Qt does have a fairly robust key sequence mechanism, so 
CNTRL-C etc via gnuplot_qt shouldn't be too difficult.  I placed a short 
stream output for the socket name when gnuplot_qt starts up and had no 
problem reading that standard output after waitForReadyRead(), etc.  If 
I understand correctly, Qt queues the standard output until something 
reads it (which would normally be a console or something).  Can't that 
be utilized?

I switched the QProcess to the normal one, not detached, which gives 
better control.  BTW, someone raised the question about persistent 
gnuplot_qt.  Switching this QProcess at least doesn't hurt that 
prospect, as right now I have the gnuplot_qt window hanging around 
always after gnuplot exits (probably a bug).  This weekend I'll attempt 
a good patch of this QProcess change for the patch tracker.

Dan

Re: Building with Qt depends on pkg-config, Qt 5 term doesn't work on OS X

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

On Wednesday, 26 February, 2014 18:04:14 Allin Cottrell wrote:
> On Wed, 26 Feb 2014, Mojca Miklavec wrote:
> 
> > On Wed, Feb 26, 2014 at 9:54 PM, Ethan A Merritt wrote:
> >> On Wednesday, 26 February, 2014 09:24:37 Mojca Miklavec wrote:
> >>> After applying your first patch only the first gnuplot run took half a
> >>> minute to start. Subsequent runs take 4 seconds at most which is
> >>> totally acceptable.
> >>
> >> OK, I have applied that first patch for #ifdef Q_OS_MAC only.
> >
> > Thank you, it works fine now. But is it on purpose that every mac/qt5
> > user will now get the following printed?
> >
> > Terminal type set to 'qt'
> > gnuplot> plot cos(x)
> > Error: short read from gnuplot_qt socket while expecting font metrics
> > Error: short read from gnuplot_qt socket while expecting font metrics
> > gnuplot>
> 
> Yes, because users of qt5 on Macs are a big nuisance and deserve to 
> be punished. Not.
> 
> What do you think? Maybe it has to do with debugging? If, perchance, 
> that might be needed ;-)

All of the qDebug() messages are of the "this is not supposed to happen"
variety.  The one above does not trigger on windows or linux, and if I
understand correctly does not trigger on OSX with Qt4 either.   Whether
it points to a problem with Qt5 per se or to a larger problem with OSX
font handling I do not know, but either way it really is fingering a fixable
problem.  If nothing else it should allow OSX users to diagnose
semi-quantitatively whether tweaks to their font setup improve or degrade
the performance.

	Ethan