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

Re: Offering help with repository conversion

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

On Thu, Feb 20, 2014 at 9:16 AM, Daniel J Sebald wrote:
> On 02/19/2014 09:43 AM, Eric S. Raymond wrote:
>> I maintain a tool called reposurgeon that edits and convers
>> version-control repositories, and a front end for it called
>> cvs-fast-export that does what its name says.
>>
>> Recently a gnuplot contributor attempting to set up a local git mirror of
>> the gnuplot repository for his own use approached me with a bug report
>> about cvs-fast-export which I was able to resolve. In the process I
>> ran a test conversion of the gnuplot history to git.
>>
>> I am therefore in a position to state that converting your production
>> repository out of CVS into a modern distributed VCS would not be
>> very difficult. If I had an inside collaborator familiar with the
>> project history I think it would be about a week's work.  Most of that
>> effort would be lifting CVS version references in comments into
>> a useful form.
>>
>> I couldn't do it right now, as I'm presently engaged in converting the
>> (much larger and messier) Emacs repository.  But I could help this
>> happen in the relatively near-term future.  As a past (and possibly
>> future) GNUPLOT contributor myself I feel I have some interest in
>> making it happen.
>
> I think a more modern source control program for gnuplot would be good.

Yes. I would really love to see gnuplot switch to a different version
control system. Reasons include ill-behaviour from time to time, CVS
tends to loose data and doesn't know how to handle certain operations
(like moving files around), it's very inconvenient to use and it's
hard to keep track of patches.

>   Some on the list might feel there aren't enough mods to move from CVS,
> but I'm pretty sure others would like a more modern VCS if they were
> used to it.  It aids in development by providing good diff tools,
> exchanging patches, changesets, push/pull, etc.

One huge advantage over the current situation would be that patches
wouldn't get outdated so soon. Whenever someone submits a patch to the
tracker, it either needs to be updated on regular basis if others want
to test it or it will fail to work. I cannot speak about mercurial
because I don't know it (I suspect it's similar), but with git
applying an old patch usually works out-of-the-box. I actually use
git's patching functionality to automatically migrate patches from an
old versions to the new version of code for projects without any
connection to git – I make a new git repository just for the sake of
that "patch upgrade".

> However, I'm partial to
> Mercurial at the moment.  I'm not saying git wouldn't be considered, but
> it would take some convincing that git is preferable to Mercurial.
> (They are both about the same, and both very nice, but I think Mercurial
> is more straightforward.)

This is all just an endless political debate and any argument for git
can probably find a counter-argument for mercurial (and vice-versa).
The tool of choice should be whatever developers of a particular
project prefer, but anything is better than CVS and the sooner it's
left behind, the better.

I would be perfectly happy with subversion as well, but now that other
powerful tools exist, it makes more sense to switch to one of those.

I've chosen git for a few other projects also because it was easy
enough to change history, particularly during the initial
conversion/import from cvs or zips. (That is for example: change
committer's email, fix some inconsistent commit timestamps and
comments, fix some faulty commits and file permissions, merge multiple
repositories into one, merge some commits that shouldn't be separated,
...) But that is not of crucial importance here. (And also because
GitHub is simply great and easy to use.) But I'm not a developer to
have a vote about it.

One pro-git argument would be that the converted repository is
basically ready. (I also made a conversion of the repository a few
years ago on https://github.com/gnuplot/gnuplot, but it's buggy and
doesn't always correspond to what's in CVS. Using cvs-fast-export does
the job a lot better. There were a few minor problems, but those were
fixed.)

But if developers would choose mercurial, that would be fine as well.

> To convert the existing CVS repository I suppose I'd approach it by
> writing in a scripted language with access to unix commands some program
> that successively gets the versions from CVS followed by an appropriate
> commit to the new repository

But why reinventing the wheel instead of, say, patching another tool
that is already specialized in doing exactly that (that is: in case
there are some new problems discovered during conversion)?

Keep in mind that you also need to take care of properly converting
.cvignore files, take care of a number of branches, tags etc.

Nobody says it isn't doable, but why spending days on writing yet
another buggy converter that would be abandoned after doing the job
and would do a suboptimal job anyway?

> with the extracted comment used during the
> commit steps.  One would have to check status for new or deleted files,
> but I think it would be doable.  Just let the computer run overnight.

With existing tools the job can be done in about an hour
(cvs-fast-export generates a 3 GB plain text file for import into
another version control system).

Mojca

Re: Offering help with repository conversion

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

On 02/19/2014 09:43 AM, Eric S. Raymond wrote:
> I maintain a tool called reposurgeon that edits and convers
> version-control repositories, and a front end for it called
> cvs-fast-export that does what its name says.
>
> Recently a gnuplot contributor attempting to set up a local git mirror of
> the gnuplot repository for his own use approached me with a bug report
> about cvs-fast-export which I was able to resolve. In the process I
> ran a test conversion of the gnuplot history to git.
>
> I am therefore in a position to state that converting your production
> repository out of CVS into a modern distributed VCS would not be
> very difficult. If I had an inside collaborator familiar with the
> project history I think it would be about a week's work.  Most of that
> effort would be lifting CVS version references in comments into
> a useful form.
>
> I couldn't do it right now, as I'm presently engaged in converting the
> (much larger and messier) Emacs repository.  But I could help this
> happen in the relatively near-term future.  As a past (and possibly
> future) GNUPLOT contributor myself I feel I have some interest in
> making it happen.

I think a more modern source control program for gnuplot would be good. 
  Some on the list might feel there aren't enough mods to move from CVS, 
but I'm pretty sure others would like a more modern VCS if they were 
used to it.  It aids in development by providing good diff tools, 
exchanging patches, changesets, push/pull, etc.  However, I'm partial to 
Mercurial at the moment.  I'm not saying git wouldn't be considered, but 
it would take some convincing that git is preferable to Mercurial. 
(They are both about the same, and both very nice, but I think Mercurial 
is more straightforward.)

To convert the existing CVS repository I suppose I'd approach it by 
writing in a scripted language with access to unix commands some program 
that successively gets the versions from CVS followed by an appropriate 
commit to the new repository with the extracted comment used during the 
commit steps.  One would have to check status for new or deleted files, 
but I think it would be doable.  Just let the computer run overnight.

Dan

Offering help with repository conversion

[<es...@th...>]

I maintain a tool called reposurgeon that edits and convers
version-control repositories, and a front end for it called
cvs-fast-export that does what its name says.

Recently a gnuplot contributor attempting to set up a local git mirror of
the gnuplot repository for his own use approached me with a bug report
about cvs-fast-export which I was able to resolve. In the process I
ran a test conversion of the gnuplot history to git.

I am therefore in a position to state that converting your production
repository out of CVS into a modern distributed VCS would not be
very difficult. If I had an inside collaborator familiar with the
project history I think it would be about a week's work.  Most of that 
effort would be lifting CVS version references in comments into
a useful form.

I couldn't do it right now, as I'm presently engaged in converting the
(much larger and messier) Emacs repository.  But I could help this
happen in the relatively near-term future.  As a past (and possibly
future) GNUPLOT contributor myself I feel I have some interest in
making it happen.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Political language... is designed to make lies sound truthful and murder respectable, and to give an appearance of solidity to pure wind.
                -- George Orwell

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

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

On 02/12/2014 08:50 PM, Daniel J Sebald wrote:
> On 02/12/2014 02:49 PM, Thomas Bleher wrote:
>> * Daniel J Sebald<dan...@ie...>   [2014-02-12 06:36]:
>>> In any case, I suggest adding the sleep as Ethan has done.  There is
>>> no reason that should be running at 100%.  In fact, there is
>>> probably a preferred way to do this without polling loops.  I
>>> learned a little bit about Qt working on Octave and Qt has this
>>> paradigm of signals and slots and the developers suggest adhering to
>>> the concept otherwise can get kind of dodgy (not in this simple
>>> case...but cases where widget IDs are floating about).
>>>
>>> signal:  something that a Qt object emits
>>> slot:  the destination of the signal which can
>>>          be of any number, e.g., five other
>>>          objects could connect a slot to a signal
>>>
>>> Anyhow, I don't have time to look at this right now, but if one
>>> looks at the documentation for a Qt socket:
>>>
>>> http://qt-project.org/doc/qt-4.8/qlocalsocket.html#connectToServer
>>>
>>> it indicates that a signal is emitted when the connection is
>>> complete and there is a signal emitted when there is an error.  So
>>> the proper thing to do is to first make connections to the socket
>>> sort of like the following ("success" and "failed" are custom member
>>> functions):
>>>
>>> connect (createdsocket, SIGNAL (connected ()), watcher, SLOT (success ()));
>>> connect (createdsocket, SIGNAL (error ()), watcher, SLOT (failed ()));
>>>
>>> and then tell the socket to attempt to connect to the server:
>>>
>>> createdsocket->connectToServer (name)
>>>
>>> There is no need to check in a loop for anything.  Either the socket
>>> will successfully connect and emit "connected" at which point
>>> "success()" will get called or the socket will timeout and emit
>>> "error" at which point "failed()" will get called.
>>>
>>> One can get very creative about connections made, the number of
>>> slots watching a signal, doing this dynamically, etc.  So instead of
>>> a recursive routine, it might be multiple connections, or
>>> dynamically reconnect/disconnect in the "failed()" slot.  Etc.
>>
>> signals and slots are indeed very nice, but they need a Qt event loop to
>> work correctly. I don't think it is possible to add the Qt event loop to
>> gnuplot without major surgery. (Well, you can start a local event loop
>> using QEventLoop inside a function, but in this case it's just more work
>> to get the same result we already have).
>
> Good point, but we'll see if we can make it work somehow.  It's worth at
> least a couple hours time to test whether it is feasible.  It would seem
> that the place to start the Qt event loop along with setting up initial
> signals/slots would be upon calling "term qt".  The good thing is that
> the graphics is done in the satellite Qt program.  The bits accessible
> to gnuplot core don't need graphics, so perhaps that Qt event loop could
> be run in a different, non-main thread without too much work.

I've a good start on the separate thread for Qt.  I think it is going to 
work, but it will probably be next weekend until I finish.  I just don't 
have the time right now.  So Mojca, you'll have to wait a week I guess.

It's been pretty straightforward up to this point.  I just laid things 
out the way the Qt documentation shows.  The separate thread starts and 
now timers definitely work as expected.  I have signals going across 
without much problems.  The external program gnuplot_qt shows up.  There 
are two remaining issues:

1) Timing.  Since this is signaling into a thread rather than calling, 
the signal returns right away and gnuplot core continues onward not 
having valid values for settings (i.e., x, y dimensions, etc.).  While 
that goes on, the other thread has problems and 30 seconds later 
complaints show up in qDebug(), and 30 seconds later once again, and 30 
seconds later is the last try.  I know how to fix this.  It just takes a 
QMutex and putting it to sleep and have the object in the QThread wake 
it when it has finished or timed out.  I've done it before.

2) Reorganization.  I think the number of ways connectToServer tries to 
connect can be simplified, without recursion.  The complaints from Qt 
are along the lines of some child objects being created in a thread 
different from its parent.  Shouldn't be difficult to fix with some 
better reorganization.  I've already broken the Qt class declarations 
into individual files QtTerminalEmitter.h (same main thread as gnuplot) 
and QtTerminalInterface.h (separate thread), which is similar to the 
rest of the Qt code in the qtterminal directory.

More next weekend or later in the week.

Dan

Re: Error when configuring with --disable-mouse

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

On Sunday, 16 February 2014 12:33:02 PM sfeam wrote:
> On Sunday, 16 February 2014 01:24:05 PM Daniel J Sebald wrote:
> > On 02/16/2014 12:57 PM, Bastian Märkisch wrote:
> > > Building without USE_MOUSE defined has been broken for a long time on
> > > Windows and (if I remember correctly) on OS/2, too. The question for me
> > > is hence, if it is worth still supporting it. Is there a need for builds
> > > without mouse?
> > 
> > Good question.  I'm defining it out right now for development purposes, 
> > but could probably get by manually commenting out a line or two.
> 
> ./configure --disable-mouse --disable-wxwidgets --without-x
> 
> builds correctly here.  

I should have said "builds correctly here after fixing the conditional
statement in command.c that Dan reported".

	Ethan

Re: Error when configuring with --disable-mouse

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

On Sunday, 16 February 2014 01:24:05 PM Daniel J Sebald wrote:
> On 02/16/2014 12:57 PM, Bastian Märkisch wrote:
> > Building without USE_MOUSE defined has been broken for a long time on
> > Windows and (if I remember correctly) on OS/2, too. The question for me
> > is hence, if it is worth still supporting it. Is there a need for builds
> > without mouse?
> 
> Good question.  I'm defining it out right now for development purposes, 
> but could probably get by manually commenting out a line or two.

./configure --disable-mouse --disable-wxwidgets --without-x

builds correctly here.  In other words, if you don't build the terminals
that support mousing then you don't need the mouse support :-)
I could imagine that someone would want to build a stripped-down
configuration without these terminals, but it's probably not common.

One option would be to make the configure scripts force --enable-mouse
if any of the terminals that require it are selected.
That definitely includes wxt, qt, and x11.
Probably also caca, ggi, pm, vgagl. Maybe others.

	Ethan
 




> 
> Dan
> 
> 
> >
> > Bastian
> >
> > Am 16.02.2014 10:20, schrieb Daniel J Sebald:
> >> I'm seeing an error message when the mouse is disabled:
> >>
> >> gnuplot-testmouse]# ./prepare; ./configure --disable-mouse
> >>
> >> ...
> >>
> >> command.c: In function ‘timed_pause’:
> >> command.c:1353:13: error: ‘struct TERMENTRY’ has no member named
> >> ‘waitforinput’
> >> make[3]: *** [command.o] Error 1
> >>
> >> Dan
> >>
> >> ------------------------------------------------------------------------------
> >>
> >> Android apps run on BlackBerry 10
> >> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> >> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> >> Get your Android app in front of a whole new audience. Start now.
> >> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
> >>
> >> _______________________________________________
> >> gnuplot-beta mailing list
> >> gnu...@li...
> >> Membership management via:
> >> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> >>
> >
> >
> 
> 

Re: Error when configuring with --disable-mouse

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

On 02/16/2014 12:57 PM, Bastian Märkisch wrote:
> Building without USE_MOUSE defined has been broken for a long time on
> Windows and (if I remember correctly) on OS/2, too. The question for me
> is hence, if it is worth still supporting it. Is there a need for builds
> without mouse?

Good question.  I'm defining it out right now for development purposes, 
but could probably get by manually commenting out a line or two.

Dan


>
> Bastian
>
> Am 16.02.2014 10:20, schrieb Daniel J Sebald:
>> I'm seeing an error message when the mouse is disabled:
>>
>> gnuplot-testmouse]# ./prepare; ./configure --disable-mouse
>>
>> ...
>>
>> command.c: In function ‘timed_pause’:
>> command.c:1353:13: error: ‘struct TERMENTRY’ has no member named
>> ‘waitforinput’
>> make[3]: *** [command.o] Error 1
>>
>> Dan
>>
>> ------------------------------------------------------------------------------
>>
>> Android apps run on BlackBerry 10
>> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
>> Now with support for Jelly Bean, Bluetooth, Mapview and more.
>> Get your Android app in front of a whole new audience. Start now.
>> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
>>
>> _______________________________________________
>> gnuplot-beta mailing list
>> gnu...@li...
>> Membership management via:
>> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>>
>
>

-- 

Dan Sebald
email: daniel(DOT)sebald(AT)ieee(DOT)org
URL: http://www(DOT)dansebald(DOT)com

Re: Error when configuring with --disable-mouse

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

Building without USE_MOUSE defined has been broken for a long time on 
Windows and (if I remember correctly) on OS/2, too. The question for me 
is hence, if it is worth still supporting it. Is there a need for builds 
without mouse?

Bastian

Am 16.02.2014 10:20, schrieb Daniel J Sebald:
> I'm seeing an error message when the mouse is disabled:
>
> gnuplot-testmouse]# ./prepare; ./configure --disable-mouse
>
> ...
>
> command.c: In function ‘timed_pause’:
> command.c:1353:13: error: ‘struct TERMENTRY’ has no member named
> ‘waitforinput’
> make[3]: *** [command.o] Error 1
>
> Dan
>
> ------------------------------------------------------------------------------
> Android apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience.  Start now.
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

Re: Possible compilation error in QtGraphicsScene.h

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

On 02/16/2014 11:46 AM, Daniel J Sebald wrote:
> In the file QtGraphicsScene.h is:
>
> #define EAM_BOXED_TEXT 1
>
> Should that be there?  It seems it could override the settings of
> config.h.  Or doesn't it make a difference because the terminal will
> just be including something that doesn't get used?

Oh, I just realized why that is there.  It is to provide the signal/slot 
definitions for the moc_### files.  At least it was at one time, 
perhaps.  When Qt does it's pre-processing, it isn't including config.h 
apparently and acting accordingly.  It just looks for the "signals" and 
"slots" directives.

Hmm, I suppose one solution is to not worry about defining out signals 
and slots in Qt header files.  That is leave out the #ifdef in the 
following:

signals:
#ifdef EAM_BOXED_TEXT
     void sig_boxed_text(unsigned int x, unsigned int y, int option);
#endif

At this link is described another way of getting definitions in the MOC 
compilation:

http://qt-project.org/doc/qt-4.8/moc.html

  moc_%.cpp: %.h
          moc $(DEFINES) $(INCPATH) $< -o $@

but of course DEFINES has to hold something.

I'm not going to worry about this and just go with leaving out the 
#ifdef in signals/slots.

Dan

Possible compilation error in QtGraphicsScene.h

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

In the file QtGraphicsScene.h is:

#define EAM_BOXED_TEXT 1

Should that be there?  It seems it could override the settings of 
config.h.  Or doesn't it make a difference because the terminal will 
just be including something that doesn't get used?

I guess there is a similar sort of thing in this configuration files:

config/config.mgw:#define EAM_BOXED_TEXT 1
config/config.nt:#define EAM_BOXED_TEXT 1


Dan

Re: Error when configuring with --disable-mouse

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

On 02/16/2014 03:20 AM, Daniel J Sebald wrote:
> I'm seeing an error message when the mouse is disabled:
>
> gnuplot-testmouse]# ./prepare; ./configure --disable-mouse
>
> ...
>
> command.c: In function ‘timed_pause’:
> command.c:1353:13: error: ‘struct TERMENTRY’ has no member named
> ‘waitforinput’
> make[3]: *** [command.o] Error 1

Also, when I try to fix this I get a cascade of errors about 
x11_update_key_box and toggling something or other.  As a temporary 
measure, I selectively went through and commented out a dozen locations 
with "#ifdef USE_MOUSE".  Eventually it compiled.

I also notice that, as far as the terminal, it seems that when the mouse 
is used, the first terminal function called is this one:

int  qt_waitforinput(int)
{
std::cout << "foo16";
exit(0);
}

Shouldn't it be qt_init() that is called first?  I looked at this 
because I'm experimenting with the Qt terminal and if the wrong value 
happens to be returned for qt_waitforinput() gnuplot goes into an 
infinite loop spitting out the same character.  I wouldn't worry about 
that part of it, because this is an experimental state, but I'm just 
curious why term_init() isn't the first thing called.  If the idea is 
that the mouse can generate something in waitforinput(), shouldn't the 
mouse be valid first before waiting on input?

Dan

Error when configuring with --disable-mouse

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

I'm seeing an error message when the mouse is disabled:

gnuplot-testmouse]# ./prepare; ./configure --disable-mouse

...

command.c: In function ‘timed_pause’:
command.c:1353:13: error: ‘struct TERMENTRY’ has no member named 
‘waitforinput’
make[3]: *** [command.o] Error 1

Dan

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

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

Am 14.02.2014 21:35, schrieb Mojca Miklavec:
> On Fri, Feb 14, 2014 at 9:05 PM, Bastian Märkisch wrote:
>> The workaround for a non-functional call to QLocalSocket.waitForBytesWritten
>> in qt_flushOutBuffer seems to have a timing problem  - on Windows at least.
>>
>> The sequence of flush and waitForBytesWritten(-1) dead locks and stalls
>> gnuplot. This is easy to trigger when e.g. rotating 3d graphs rapidly with
>> the mouse.
>>
>> Just using waitForBytesWritten(-1) directly seems to work just fine, though.
>> This is to be also indicated by a comment ("update: seems to work with Qt
>> 4.5.") there. The patch attached is conditional on Qt >= 4.5. Could somebody
>> please test if that also works  on Linux/Mac?
>
> No, it doesn't. I get
>      QAbstractSocket::waitForBytesWritten() is not allowed in UnconnectedState
> printed to the terminal and then I'm unable to do any interaction with
> the mouse at all. Some plots from demos are not even displayed.
>
> Mojca
>

Thanks for the feedback. So I kept the loop but added another check for 
bytesToWrite > 0 which should do no harm in any case, but prevents 
stalling on Windows. Code is in CVS.

   Bastian

Re: [gnuplot:news] sfeam created post Release announcement for gnuplot 4.6.4

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

Better late than never: you can find release candidates for Windows 
binaries at
http://www.gnuplot.info/development/binaries/

Please test them before we release the packages officially on SF.

   Bastian


Am 09.10.2013 06:47, schrieb Ethan Merritt:
>                 GNUPLOT  VERSION  4.6.4
>          ===================================
>
> This is an incremental release of gnuplot version 4.6.
> A short list of changes since the previous patchlevel (version 4.6.3)
> is given below and in the NEWS file. Detailed information is in ChangeLog.
>
>
>   New features, changes and fixes since gnuplot version 4.6.3
>
>   * NEW Ctrl-Break interrupts fitting run in wgnuplot
>   * CHANGE treat empty fields in a csv file as "missing" rather than "bad"
>   * CHANGE allow reference to more than one column header in 'using' or
>     'title'
>   * CHANGE install-info is no longer a default "make install" target
>   * CHANGE if a polar plot is autoscaled, try to place the origin at the
>     center
>   * FIX svg and canvas terminal mousing of inverted axis coordinates
>   * FIX emf failed to initialize font correctly on some systems
>   * FIX timedata columns can now be referred to via column(N) and
>     column("HEAD")
>   * FIX qt terminal toggling of enhanced text elements in plot with labels
>   * FIX color/pattern generated for key entries of columnstacked histograms
>   * FIX hitting ^C twice forces temination of wxt session hung by lost
>     X-server
>   * FIX win terminal failed to properly adjust plot border after window
>     resize
>   * FIX several conditions in which macros were not expanded during
>     command input
>   * FIX promote a string containing only digits to INTGR rather than CMPLX
>   * FIX 'set grid front' caused failure to initialize location of axis
>     zero point
>   * FIX very poor precision in mouse coords reported by x11 in -persist mode
>   * FIX parsing of $# (the number of arguments in a "call"). It's not a
>     comment!
>   * FIX memory leak of cropped images using pngcairo terminal
>   * FIX "lc variable" now iterates over linetype colors (not styles) as
>     documented
>   * FIX rtics were sometimes drawn with length 0
>
> ------------------------------------------------------------------------
>
> Sent from sourceforge.net because you indicated interest in
> https://sourceforge.net/p/gnuplot/news/2013/10/release-announcement-for-gnuplot-464/
>
> To unsubscribe from further messages, please visit
> https://sourceforge.net/auth/subscriptions/
>

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

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

On Fri, Feb 14, 2014 at 9:05 PM, Bastian Märkisch wrote:
> The workaround for a non-functional call to QLocalSocket.waitForBytesWritten
> in qt_flushOutBuffer seems to have a timing problem  - on Windows at least.
>
> The sequence of flush and waitForBytesWritten(-1) dead locks and stalls
> gnuplot. This is easy to trigger when e.g. rotating 3d graphs rapidly with
> the mouse.
>
> Just using waitForBytesWritten(-1) directly seems to work just fine, though.
> This is to be also indicated by a comment ("update: seems to work with Qt
> 4.5.") there. The patch attached is conditional on Qt >= 4.5. Could somebody
> please test if that also works  on Linux/Mac?

No, it doesn't. I get
    QAbstractSocket::waitForBytesWritten() is not allowed in UnconnectedState
printed to the terminal and then I'm unable to do any interaction with
the mouse at all. Some plots from demos are not even displayed.

Mojca

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

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

On Fri, Feb 14, 2014 at 8:46 PM, Ethan A Merritt wrote:
> On Saturday, 08 February, 2014 03:01:09 Mojca Miklavec wrote:
>
>> Yes. I'm using 4.8.5. (Unfortunately the maintainer of Qt 4 gave up on
>> Qt 5 for some reason – apparently too much work and too many problems
>> when he tried to create a package and nobody else is willing to step
>> in. But I did successfully link gnuplot against a different Qt
>> installation and I could try to repeat that now to check whether
>> current solution works in 5.2.
>
> Can you try with the "official" Qt-for-OSX package?
>
>   http://qt-project.org/doc/qt-5/macosx.html

I definitely plan to test gnuplot with Qt 5, but ...

> If that works, we can simply recommend that people use it
> rather than fighting with 3rd-party packages.

And start fighting with instructions on how to compile gnuplot and
octave on their own? Esp. because it's probably not exactly trivial to
configure gnuplot to find the Qt headers and libraries. And I would
not even attempt to use octave if I had to compile it myself.

Qt 5 isn't supported in MacPorts (lack of manpower to port the complex
package), I don't find it in Fink either. And while HomeBrew provides
Qt 5, gnuplot links against Qt 4 there as well. And no gnuplot
developer is creating binary packages with gnuplot for Mac.

So basically all the package managers are currently using Qt 4 for
gnuplot. Asking users to compile gnuplot (and Octave) themselves just
to work around a bug ... sounds a bit nasty.

Mojca

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

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

The workaround for a non-functional call to 
QLocalSocket.waitForBytesWritten in qt_flushOutBuffer seems to have a 
timing problem  - on Windows at least.

The sequence of flush and waitForBytesWritten(-1) dead locks and stalls 
gnuplot. This is easy to trigger when e.g. rotating 3d graphs rapidly 
with the mouse.

Just using waitForBytesWritten(-1) directly seems to work just fine, 
though. This is to be also indicated by a comment ("update: seems to 
work with Qt 4.5.") there. The patch attached is conditional on Qt >= 
4.5. Could somebody please test if that also works  on Linux/Mac?

   Bastian


Am 14.02.2014 06:52, schrieb Jérôme Lodewyck:
> I agree with Ethan that an event loop should not be necessary in qt_qterm.cpp.
> However, if someone wants to experiment, I have already made such an attempt
> to integrate a Qt event loop within the gnuplot event loop in
> http://sourceforge.net/p/gnuplot/patches/645/
> in eventloop.patch
>
> Jérôme
>
>
> Le mercredi 12 février 2014 20:14:19 sfeam a écrit :
>> I don't agree that an event loop is needed for this particular purpose.
>> We don't have a case of asynchronous processes sending each other
>> signals at random times.  We just want some way for the daughter
>> process to signal back to the parent process "I'm ready now, you can
>> proceed".   And we want some way for the parent to wait for this
>> signal without burning CPU cycles.   One would think from its name that
>> QLocalSocket::waitForConnected() provides exactly this service, but
>> evidently it doesn't.    At least in linux it should be possible to have the
>> parent call sigwait(), and the daughter call kill(parent_pid, SIGUSR1). No
>> need to involve Qt in this.
>>
>> 	Ethan
>

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

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

On Saturday, 08 February, 2014 03:01:09 Mojca Miklavec wrote:

> Yes. I'm using 4.8.5. (Unfortunately the maintainer of Qt 4 gave up on
> Qt 5 for some reason – apparently too much work and too many problems
> when he tried to create a package and nobody else is willing to step
> in. But I did successfully link gnuplot against a different Qt
> installation and I could try to repeat that now to check whether
> current solution works in 5.2. 

Can you try with the "official" Qt-for-OSX package?

  http://qt-project.org/doc/qt-5/macosx.html

If that works, we can simply recommend that people use it
rather than fighting with 3rd-party packages.

	Ethan

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

[Yuriy K. <yu...@gm...>]

Daniel J Sebald wrote:
> On 02/13/2014 05:09 AM, Yuriy Kaminskiy wrote:
>> sfeam wrote:
>>> On Wednesday, 12 February 2014 08:50:18 PM Daniel J Sebald wrote:
>>>> On 02/12/2014 02:49 PM, Thomas Bleher wrote:
>>>>> * Daniel J Sebald<dan...@ie...>   [2014-02-12 06:36]:
[...]
>>>> Local event loop might work, but that seems like a lot of overhead to
>>>> communicate every time with a remote program with any sort of high
>>>> bandwidth.  Local event loops are what dialog boxes can and often use.
>>>> Overhead isn't an issue there.
>>> I don't agree that an event loop is needed for this particular purpose.
>>> We don't have a case of asynchronous processes sending each other
>>> signals at random times.  We just want some way for the daughter
>>> process to signal back to the parent process "I'm ready now, you can
>>> proceed".   And we want some way for the parent to wait for this
>>> signal without burning CPU cycles.   One would think from its name that
>>> QLocalSocket::waitForConnected() provides exactly this service, but
>>> evidently it doesn't.    At least in linux it should be possible to have the
>>> parent call sigwait(), and the daughter call kill(parent_pid, SIGUSR1).
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> No need to involve Qt in this.
>> Signals is *increadibly* fragile IPC mechanism. There are very hard restriction
>> on what is permitted in signal handlers (that frequently violated, which result
>> in very hard-to-catch and nasty bugs), you can easily end up with racy code,
>> signals may lost, etc.
> 
> I've not experienced such a thing and found, so far, Qt signals/slots 
> fairly robust.  Mutexes seem to work rather well for across thread 

I refer here to "asynchronous signals" - see `man 7 signal` and `man 2
sigaction`, `man 3 sigwait`, `man 2 kill`, etc, *not* to Qt's signals/slots (I
don't think they are anyhow related; besides, Qt signals are not "IPC mechanism").

> traffic.  Do you have an example of a race condition?  I can't think of 
> any hard and fast rules other than one isn't supposed to cast the object 
> ID and use it as an object pointer because the object could be deleted. 
>   (Emitted signals are fine because any time an object is deleted, all 
> its connections are removed along with it.)
> 
> Within a thread there shouldn't be a race condition because signals are 
> processed right away, if I remember correctly.  Across thread are 
> treated differently.  They are queued.  But there is where the Mutex 
> comes into play.  By temporarily suspending a worker process (typically 
> on the order of milliseconds) and having the thread awoken when tasks 
> are complete, race conditions are avoided.

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

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

I agree with Ethan that an event loop should not be necessary in qt_qterm.cpp. 
However, if someone wants to experiment, I have already made such an attempt 
to integrate a Qt event loop within the gnuplot event loop in 
http://sourceforge.net/p/gnuplot/patches/645/
in eventloop.patch

Jérôme


Le mercredi 12 février 2014 20:14:19 sfeam a écrit :
> I don't agree that an event loop is needed for this particular purpose.
> We don't have a case of asynchronous processes sending each other
> signals at random times.  We just want some way for the daughter
> process to signal back to the parent process "I'm ready now, you can
> proceed".   And we want some way for the parent to wait for this
> signal without burning CPU cycles.   One would think from its name that
> QLocalSocket::waitForConnected() provides exactly this service, but
> evidently it doesn't.    At least in linux it should be possible to have the
> parent call sigwait(), and the daughter call kill(parent_pid, SIGUSR1). No
> need to involve Qt in this.
> 
> 	Ethan

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

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

On 02/13/2014 05:09 AM, Yuriy Kaminskiy wrote:
> sfeam wrote:
>> On Wednesday, 12 February 2014 08:50:18 PM Daniel J Sebald wrote:
>>> On 02/12/2014 02:49 PM, Thomas Bleher wrote:
>>>> * Daniel J Sebald<dan...@ie...>   [2014-02-12 06:36]:
>>>>> In any case, I suggest adding the sleep as Ethan has done.  There is
>>>>> no reason that should be running at 100%.  In fact, there is
>>>>> probably a preferred way to do this without polling loops.  I
>>>>> learned a little bit about Qt working on Octave and Qt has this
>>>>> paradigm of signals and slots and the developers suggest adhering to
>>>>> the concept otherwise can get kind of dodgy (not in this simple
>>>>> case...but cases where widget IDs are floating about).
>>>>>
>>>>> signal:  something that a Qt object emits
>>>>> slot:  the destination of the signal which can
>>>>>          be of any number, e.g., five other
>>>>>          objects could connect a slot to a signal
>>>>>
>>>>> Anyhow, I don't have time to look at this right now, but if one
>>>>> looks at the documentation for a Qt socket:
>>>>>
>>>>> http://qt-project.org/doc/qt-4.8/qlocalsocket.html#connectToServer
>>>>>
>>>>> it indicates that a signal is emitted when the connection is
>>>>> complete and there is a signal emitted when there is an error.  So
>>>>> the proper thing to do is to first make connections to the socket
>>>>> sort of like the following ("success" and "failed" are custom member
>>>>> functions):
>>>>>
>>>>> connect (createdsocket, SIGNAL (connected ()), watcher, SLOT (success ()));
>>>>> connect (createdsocket, SIGNAL (error ()), watcher, SLOT (failed ()));
>>>>>
>>>>> and then tell the socket to attempt to connect to the server:
>>>>>
>>>>> createdsocket->connectToServer (name)
>>>>>
>>>>> There is no need to check in a loop for anything.  Either the socket
>>>>> will successfully connect and emit "connected" at which point
>>>>> "success()" will get called or the socket will timeout and emit
>>>>> "error" at which point "failed()" will get called.
>>>>>
>>>>> One can get very creative about connections made, the number of
>>>>> slots watching a signal, doing this dynamically, etc.  So instead of
>>>>> a recursive routine, it might be multiple connections, or
>>>>> dynamically reconnect/disconnect in the "failed()" slot.  Etc.
>>>> signals and slots are indeed very nice, but they need a Qt event loop to
>>>> work correctly. I don't think it is possible to add the Qt event loop to
>>>> gnuplot without major surgery. (Well, you can start a local event loop
>>>> using QEventLoop inside a function, but in this case it's just more work
>>>> to get the same result we already have).
>>> Good point, but we'll see if we can make it work somehow.  It's worth at
>>> least a couple hours time to test whether it is feasible.  It would seem
>>> that the place to start the Qt event loop along with setting up initial
>>> signals/slots would be upon calling "term qt".  The good thing is that
>>> the graphics is done in the satellite Qt program.  The bits accessible
>>> to gnuplot core don't need graphics, so perhaps that Qt event loop could
>>> be run in a different, non-main thread without too much work.
>>>
>>> Local event loop might work, but that seems like a lot of overhead to
>>> communicate every time with a remote program with any sort of high
>>> bandwidth.  Local event loops are what dialog boxes can and often use.
>>> Overhead isn't an issue there.
>>
>> I don't agree that an event loop is needed for this particular purpose.
>> We don't have a case of asynchronous processes sending each other
>> signals at random times.  We just want some way for the daughter
>> process to signal back to the parent process "I'm ready now, you can
>> proceed".   And we want some way for the parent to wait for this
>> signal without burning CPU cycles.   One would think from its name that
>> QLocalSocket::waitForConnected() provides exactly this service, but
>> evidently it doesn't.    At least in linux it should be possible to have the
>> parent call sigwait(), and the daughter call kill(parent_pid, SIGUSR1).
>> No need to involve Qt in this.
>
> Signals is *increadibly* fragile IPC mechanism. There are very hard restriction
> on what is permitted in signal handlers (that frequently violated, which result
> in very hard-to-catch and nasty bugs), you can easily end up with racy code,
> signals may lost, etc.

I've not experienced such a thing and found, so far, Qt signals/slots 
fairly robust.  Mutexes seem to work rather well for across thread 
traffic.  Do you have an example of a race condition?  I can't think of 
any hard and fast rules other than one isn't supposed to cast the object 
ID and use it as an object pointer because the object could be deleted. 
  (Emitted signals are fine because any time an object is deleted, all 
its connections are removed along with it.)

Within a thread there shouldn't be a race condition because signals are 
processed right away, if I remember correctly.  Across thread are 
treated differently.  They are queued.  But there is where the Mutex 
comes into play.  By temporarily suspending a worker process (typically 
on the order of milliseconds) and having the thread awoken when tasks 
are complete, race conditions are avoided.

Dan

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

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

Here is a patch that applies on top of CVS. You are right : showing the 
window should be done regardless on whether the size has changed or not.

Jérôme

Le 13/02/2014 11:23, Mojca Miklavec a écrit :
> Just another observation before I test further: it wasn't just a
> problem of first-time plot. It was also *sometimes* a problem of the
> first plot after closing the plotting window. But that was
> semi-random. Sometimes it worked and sometimes it didn't. This could
> have been related to whether a new plot was a different one or not or
> maybe related to timing.
>
> I would say that it's a problem that
>      if (!parent->isVisible())
> is hidden inside
>      if (s != viewport->size())
> because the reverse can be true: c may well be equal to
> viewport->size(), but parent may not be visible. I don't know the code
> well enough, but it looks like parent is not visible whenever I close
> the plotting window (or during the initial plot).
>
> Mojca
>

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

[Yuriy K. <yu...@gm...>]

sfeam wrote:
> On Wednesday, 12 February 2014 08:50:18 PM Daniel J Sebald wrote:
>> On 02/12/2014 02:49 PM, Thomas Bleher wrote:
>>> * Daniel J Sebald<dan...@ie...>  [2014-02-12 06:36]:
>>>> In any case, I suggest adding the sleep as Ethan has done.  There is
>>>> no reason that should be running at 100%.  In fact, there is
>>>> probably a preferred way to do this without polling loops.  I
>>>> learned a little bit about Qt working on Octave and Qt has this
>>>> paradigm of signals and slots and the developers suggest adhering to
>>>> the concept otherwise can get kind of dodgy (not in this simple
>>>> case...but cases where widget IDs are floating about).
>>>>
>>>> signal:  something that a Qt object emits
>>>> slot:  the destination of the signal which can
>>>>         be of any number, e.g., five other
>>>>         objects could connect a slot to a signal
>>>>
>>>> Anyhow, I don't have time to look at this right now, but if one
>>>> looks at the documentation for a Qt socket:
>>>>
>>>> http://qt-project.org/doc/qt-4.8/qlocalsocket.html#connectToServer
>>>>
>>>> it indicates that a signal is emitted when the connection is
>>>> complete and there is a signal emitted when there is an error.  So
>>>> the proper thing to do is to first make connections to the socket
>>>> sort of like the following ("success" and "failed" are custom member
>>>> functions):
>>>>
>>>> connect (createdsocket, SIGNAL (connected ()), watcher, SLOT (success ()));
>>>> connect (createdsocket, SIGNAL (error ()), watcher, SLOT (failed ()));
>>>>
>>>> and then tell the socket to attempt to connect to the server:
>>>>
>>>> createdsocket->connectToServer (name)
>>>>
>>>> There is no need to check in a loop for anything.  Either the socket
>>>> will successfully connect and emit "connected" at which point
>>>> "success()" will get called or the socket will timeout and emit
>>>> "error" at which point "failed()" will get called.
>>>>
>>>> One can get very creative about connections made, the number of
>>>> slots watching a signal, doing this dynamically, etc.  So instead of
>>>> a recursive routine, it might be multiple connections, or
>>>> dynamically reconnect/disconnect in the "failed()" slot.  Etc.
>>> signals and slots are indeed very nice, but they need a Qt event loop to
>>> work correctly. I don't think it is possible to add the Qt event loop to
>>> gnuplot without major surgery. (Well, you can start a local event loop
>>> using QEventLoop inside a function, but in this case it's just more work
>>> to get the same result we already have).
>> Good point, but we'll see if we can make it work somehow.  It's worth at 
>> least a couple hours time to test whether it is feasible.  It would seem 
>> that the place to start the Qt event loop along with setting up initial 
>> signals/slots would be upon calling "term qt".  The good thing is that 
>> the graphics is done in the satellite Qt program.  The bits accessible 
>> to gnuplot core don't need graphics, so perhaps that Qt event loop could 
>> be run in a different, non-main thread without too much work.
>>
>> Local event loop might work, but that seems like a lot of overhead to 
>> communicate every time with a remote program with any sort of high 
>> bandwidth.  Local event loops are what dialog boxes can and often use. 
>> Overhead isn't an issue there.
> 
> I don't agree that an event loop is needed for this particular purpose.
> We don't have a case of asynchronous processes sending each other
> signals at random times.  We just want some way for the daughter
> process to signal back to the parent process "I'm ready now, you can
> proceed".   And we want some way for the parent to wait for this
> signal without burning CPU cycles.   One would think from its name that
> QLocalSocket::waitForConnected() provides exactly this service, but 
> evidently it doesn't.    At least in linux it should be possible to have the
> parent call sigwait(), and the daughter call kill(parent_pid, SIGUSR1).
> No need to involve Qt in this.

Signals is *increadibly* fragile IPC mechanism. There are very hard restriction
on what is permitted in signal handlers (that frequently violated, which result
in very hard-to-catch and nasty bugs), you can easily end up with racy code,
signals may lost, etc.
And kill(parent_pid,SIGUSR1) is, obviously, racy and dangerous (parent process
can die before children noticed, pid can be reused, and you can kill wrong
process [and default handler for SIGUSR1 terminates process!]).

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

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

On Thu, Feb 13, 2014 at 5:56 AM, sfeam wrote:
>
> Based on this and our off-line back and forth debugging, I am pretty
> sure that the attached patch will fix your problem that the first plot
> is not drawn.

It does fix the first plot, but not the first plot after I close a qt
window. Here's what I get:

Terminal type set to 'qt'
gnuplot> plot x # OK
 -> resizing
gnuplot> plot x # OK (but why resizing?)
gnuplot>  -> resizing

gnuplot> plot x # OK
gnuplot> plot x # OK
gnuplot>            # close the window
gnuplot> plot x # NOT SHOWN
gnuplot> plot x # OK (but why resizing twice?)
 -> resizing
gnuplot>  -> resizing

gnuplot>


The logic is still wrong.

Mojca

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

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

On Thu, Feb 13, 2014 at 11:56 AM, Jérôme Lodewyck wrote:
> Here is a patch that applies on top of CVS.

But it doesn't work properly.

Now the window is shown, but it has the wrong size to start with (it
shows just the top left corner of the plot).

Mojca