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

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

[Allin C. <cot...@wf...>]

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

Allin Cottrell

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

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

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>

>> Now the only long delay comes from that long timeout after closing
>> gnuplot_qt. Gnuplot throws "Error: short read from gnuplot_qt socket"
>> when I quit gnuplot_qt, so it's probably aware that gnuplot_qt is no
>> longer present. In such cases it could try to open a new gnuplot_qt
>> faster than in 30 seconds.
>
> When you say "after closing gnuplot_qt", do you mean closing the
> window, or do you mean killing the process?

Killing it (= right mouse click -> Quit). I'm sorry for not being exact.

> Simply closing the window should not have much effect; the program will
> reopen the window as needed.

Indeed.

> Killing the process does indeed trigger
> that 30 second timeout.   A fix for that is also now in cvs.

Great, thank you. It works as expected now.

Thanks a lot for fixing all the issues and making Qt work again on Macs.

-------------------

Among the remaining "visible flaws" only those come to my mind now:

- the first plot gets too small window and the lower part of the plot
is not visible; the difference is exactly the status bar; the second
plot gets resized and gets the proper size; curiously enough this is
now a problem with both Qt 4 and Qt 5 and must have been introduced
with one of the recent changes (when I last tested only the reported
size was changed, but there was no visible effect)

- the default font is way too small; on my 13" notebook the numbers
are only 1,5 mm high (7 pixels); I don't know the reason, but on wxt
the font looks a lot better; maybe I should test a simple Qt
application to see what defaults it uses

- horizontal scrolling goes in the wrong direction since a while (and
scrolling is way too fast for precise trackpads) – but both "problems"
are present in other terminals as well

- in Qt 5 the application doesn't show any icon (I already
investigated a while back without luck) – that's just cosmetics though
and doesn't hurt functionality in any way

Mojca

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

> Now the only long delay comes from that long timeout after closing
> gnuplot_qt. Gnuplot throws "Error: short read from gnuplot_qt socket"
> when I quit gnuplot_qt, so it's probably aware that gnuplot_qt is no
> longer present. In such cases it could try to open a new gnuplot_qt
> faster than in 30 seconds.

When you say "after closing gnuplot_qt", do you mean closing the
window, or do you mean killing the process? 
Simply closing the window should not have much effect; the program will
reopen the window as needed.   Killing the process does indeed trigger
that 30 second timeout.   A fix for that is also now in cvs.

	Ethan

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

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

On Wed, Feb 26, 2014 at 6:13 AM, sfeam wrote:
> On Tuesday, 25 February 2014 10:36:59 PM Mojca Miklavec wrote:
>> I now also tested with Qt4. Qt 4 doesn't print that long list of
>> errors and starts instantly (as opposed to Qt 5).
>>
>> But if I exit the Qt window and plot again, it now also takes about 30
>> seconds to plot a new window.
>>
>> Mojca
>
> So if I understand correctly, OSX + Qt4 is now working correctly
> except for a problem with font intialization elsewhere in the system.

I believe Qt 4 has worked properly for a couple of days.

Font initialization is only a problem on Qt 5.


I thought I had problems with font initialization in Qt 4, but it
turned out that when I quit gnuplot_qt, gnuplot was merely waiting for
30 seconds for this timeout:
    QDateTime timeout = QDateTime::currentDateTime().addMSecs(30000);

> OSX_+ Qt5 has at least the same problem with font initialization and
> possibly an additional delay before the first plot.

Only Qt 5 is throwing

Error: short read from gnuplot_qt socket while expecting font metrics
Error: short read from gnuplot_qt socket while expecting font metrics
Error: short read from gnuplot_qt socket while expecting font metrics
gnuplot> qt_processTermEvent received a GE_fontprops event. This
should not have happened

and is having problems with font metrics without your patch (sent
off-list). Qt 4 works fine already for the first plot.

> These don't really seem to be gnuplot problems at all,

That 30 second delay *is* a gnuplot "problem".

> so I suggest you hunt around to see what other OSX users are
> reporting about font problems.

I don't know if I have any Qt 5-based application on my system, but I
don't remember any other program having that problem. I remember
loooooong starting times of wxWidgets terminal in gnuplot on windows
when fc-cache was being run (similar for mplayer, vlc player and a
couple of other programs).

> I found a couple of reports
> that say OSX has a problem with large numbers of installed fonts,
> and the only solution they offered was to uninstall as many
> fonts as possible.   That sounds like a crock to me, but in any
> case it's not something we can fix in gnuplot.

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.

Now the only long delay comes from that long timeout after closing
gnuplot_qt. Gnuplot throws "Error: short read from gnuplot_qt socket"
when I quit gnuplot_qt, so it's probably aware that gnuplot_qt is no
longer present. In such cases it could try to open a new gnuplot_qt
faster than in 30 seconds.

(I'm not saying that there are no Qt bugs introduced in Qt 5, I'm just
not sure how exactly to report them. I would probably need to send
them minimal examples reproducing the same problematic behaviour.)

> That isn't to say that no workaround is possible.
> Based on my current understanding, you could work around this
> problem entirely with Qt4 by having gnuplot save its font cache
> at the end of each qt session

There were no problems with font caching on Qt 4.

Mojca

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

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

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.

   Bastian

Re: Version 4.6.5 released

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

Am 26.02.2014 06:25, schrieb Tait:
>
>> There is testing binary for windows available in the folder
>> in the files --> gnuplot --> "Testing (pre-release) binaries"
>>
>> Release announcement appended below.
>
> In previous (recent) gnuplot releases, the default Windows terminal
> has been wxt. This build not only defaults back to the windows
> terminal, but does not support wxt at all. Is this intentional?
>

Well, it can hardly default to the wxt terminal in a build without it ;)
But no, leaving out wxt wasn't intentional and it is also still the 
default if it is built-in. Uploading rc2 just now.

   Bastian

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

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

On 02/24/2014 09:59 AM, Jérôme Lodewyck wrote:
> Hi,
>
> I got a bit confused about your motivations for introducing an event
> loop in the "inboard" qt terminal. In qt_term.cpp, we use, by design, a
> very limited set of the Qt library, and rather push as much
> functionality as possible the in the gnuplot_qt "outboard" program.

That's all fine.  I've no intention of moving anything from gnuplot_qt 
over to the qt_term.cpp.

I've written several times that the reason for supplying an event loop 
to the code is because I'm suspicious of the overall functionality of Qt 
code on all platforms without the event loop.  But read on below...


>  And
> I think that this set of functions doesn't require an event loop to work
> properly (As a matter of fact, I can observe by commenting out the
> QCoreApplication declaration in qt_term.cpp that it doesn't even require
> an instantiation of QCoreApplication to work -- except from the Windows
> specific QCoreApplication::applicationDirPath() call). More
> specifically, we use
> - Storage classes (QString, QImage, QColor...) that just gather
> information but use no event mechanism.
> - QLocalSocket that, according to the Qt documentation, can work without
> an event loop:
> "Although QLocalSocket is designed for use with an event loop, it's
> possible to use it without one. In that case, you must use
> waitForConnected(), waitForReadyRead(), waitForBytesWritten(), and
> waitForDisconnected() which blocks until the operation is complete or
> the timeout expires.". In fact, I can imagine that the gnuplot inboard
> driver is perhaps precisely the kind of programs that the Qt developers
> had in mind when they wrote this sentence: a program that cannot run a
> Qt event loop because it implements its own event loop, but that still
> wants to send messages to another auxiliary program that runs a Qt event
> loop to manage a GUI.

Yes, probably so.  I read the documentation about the event loop in some 
of these socket functions.


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


> To my knowledge, here are the issues that arose on non Linux platform:
> - OSX: in the past, there was no gnuplot_qt independent process, and the
> GUI was rather managed in a thread. As you point out, this is not
> supported in Qt, and while it kind of happened to work with Linux, it
> failed on OSX.

Yes, that's not right.


> - OSX: currently, the QtGnuplotWidget has a hard time to resize itself
> to the correct size, but it is specific to the gnuplot_qt outboard driver.

I thought Mojca said gnuplot Qt term on OSX is failing to run.


> - All platforms: waitForConnected() immediatly returns if not socket is
> found (in particular, this happens when the gnuplot_qt program is still
> being initialized), even when a timeout is set. This was solved by
> introducing a custom timeout mechanism, but could more elegantly be
> solved by some communication mechanism between gnuplot ("inboard") and
> gnuplot_qt ("outboard"). I can see that part of your code actually
> implements this.

Correct.  That custom timeout is bad.


> Concerning QApplication vs. QCoreApplication & font metrics:
> Until recently, the inboard driver (qt_term.cpp) used to instantiate a
> QApplication to determine the font metrics (no event loop was required
> for this though, and more generally, no Qt event loop, nor Qt event
> based mechanism has ever been running in the main gnuplot thread). As
> Ethan said, this mechanism has been moved to the "outboard" gnuplot_qt
> program, and now the inboard driver only instantiate a QCoreApplication
> (which, as I said above, even turns out not to be necessary in practice,
> although the Qt documentation does not certify this point). The
> 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?


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

It will be a performance loss, yes.  I can't see it being 3x, though, if 
I were to iron out some things.  OK, so just a couple points:

1) Mojca reports the trial-and-error code I sent runs similar to what 
I'm seeing.  So we know we should be able to achieve platform independence.

2) I think the thing we agree on is that the way the QProcess is created 
and the way the link is established to gnuplot_qt isn't very good.  That 
while-loop approach shouldn't be needed.

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.

If it turns out that an event loop issue is a source of problem, we can 
probably split the API into those that do and don't need an event loop. 
  For example, I doubt the critical slowdown for the 1 M point example 
you cite needs to use signal/slots and can go directly to the socket. 
It's probably one move after another.  But just speculation.  First 
let's tackle the comm-link code.

Dan

Re: Version 4.6.5 released

[Tait <gnu...@t4...>]

> There is testing binary for windows available in the folder
> in the files --> gnuplot --> "Testing (pre-release) binaries"
> 
> Release announcement appended below.

In previous (recent) gnuplot releases, the default Windows terminal
has been wxt. This build not only defaults back to the windows
terminal, but does not support wxt at all. Is this intentional?

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

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

On Tuesday, 25 February 2014 10:36:59 PM Mojca Miklavec wrote:
> I now also tested with Qt4. Qt 4 doesn't print that long list of
> errors and starts instantly (as opposed to Qt 5).
> 
> But if I exit the Qt window and plot again, it now also takes about 30
> seconds to plot a new window.
> 
> Mojca

So if I understand correctly, OSX + Qt4 is now working correctly
except for a problem with font intialization elsewhere in the system.

OSX_+ Qt5 has at least the same problem with font initialization and
possibly an additional delay before the first plot.

These don't really seem to be gnuplot problems at all,
so I suggest you hunt around to see what other OSX users are
reporting about font problems.  I found a couple of reports 
that say OSX has a problem with large numbers of installed fonts,
and the only solution they offered was to uninstall as many
fonts as possible.   That sounds like a crock to me, but in any
case it's not something we can fix in gnuplot.

That isn't to say that no workaround is possible.
Based on my current understanding, you could work around this
problem entirely with Qt4 by having gnuplot save its font cache
at the end of each qt session and read it in again at the start
of the next session.  Then you would hit this lethargic system
response only when you requested a never-used-before font.

Maintaining a private font cache would be wasted effort on
linux, but if you want to code up something for OSX-only
inclusion go right ahead.

	Ethan

Re: Repository conversion

[Clark G. <cla...@fa...>]

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.

I asked my most "worldly" developer to assess the two for my team's purposes. Joel Sposky's blog posts on distributed code management and his hginit.com site were also illustrative. And we decided on hg. The more seasoned devs in the group have enjoyed this decision and the ops guys live with it well (they certainly would not be more at home with git).

But in my day job I do not have to concern myself too much with the inconvenience of consensus. ;-) YMMV.

With that said, do check out Joel's post and hginit.com.

Cheers
Clark

On Feb 24, 2014 4:51 PM, Mojca Miklavec <moj...@gm...> wrote:
>
> On Mon, Feb 24, 2014 at 9:13 PM, Tait wrote:
> > "Eric S. Raymond" said (on 2014/02/24):
> >> (2) Where do you want to land?
> >>
> >> As bzr is now moribund, the realistic alternatives are Subversion,
> >> git, and hg.  But I mention Subversion only for completeness; the
> >> advantages of distributed VCS are huge and if you're going to incur
> >> the transition costs of moving away from CVS either git or hg would
> >> have a much higher functional payoff.
> >
> > I'd not heard Bazaar was moribund... they seem to be still making new
> > releases? (... However, SourceForge doesn't appear to support bzr, so
> > it's probably moot to this discussion.)
>
> While they might make new releases, the popularity lags way behind.
> (And consequently there are way less tools and services supporting
> it.) Also, Bazaar is not the only alternative, but all other tools
> have even lower popularity and adoption. So yes, discussing anything
> but those three doesn't seem worth it.
>
> > Has anyone studied/published how many projects have switched from Hg
> > to git, and vice-versa?
>
> That's difficult enough, but you can feed the search engine with
> "convert git mercurial" and figure out that just about every hit
> explains how to convert from mercurial to git. The first hit about
> conversion from git to mercurial was from the time when bitbucket was
> the only provider of free hosting of private repositories and only
> supported mercurial.
>
> > From my personal anecdotal experience, I know
> > of a couple that have hg->git (mostly due to difficulties with
> > branching), but none that have git->hg.
>
> ... which confirms the above observation.
>
> > Support for all three (#bzr, #mercurial, #git) can be had on
> > irc.freenode.net. #Git is by far the largest channel of those (for
> > whatever that's worth)
>
> The "mean" explanation would be that git must be so difficult to use
> that its users need most support ;)
>
> > and seems to have the largest list of projects
> > using it, so momentum seems to favor git there.
>
> Here are some numbers, showing about three times more git users than
> those of mercurial:
>
> http://zeroturnaround.com/rebellabs/devprod-report-revisited-version-control-systems-in-2013/
> http://qa.debian.org/popcon-graph.php?packages=subversion+git+mercurial+bazaar&show_installed=on&show_vote=on&want_legend=on&want_ticks=on&from_date&to_date&hlght_date&date_fmt=%25Y-%25m
> http://wiki.bazaar.canonical.com/BzrPopularity
> http://bazaarvcs.wordpress.com/2010/02/15/bazaar-adoption-growing-strongly/
>     (they stopped writing the blog in 2012)
> http://stackoverflow.com/questions/995636/popularity-of-git-mercurial-bazaar-vs-which-to-recommend
>     latest counting of tags on stackoverflow – git: 37547, mercurial: 5878
>
> (In the spirit of the same argument as above about BitBucket driving
> the git->hg conversion, I would dare to claim that GitHub contributed
> a lot towards the high popularity of git.)
>
> Anyway, whatever tool (out of the three) would be chosen ... it would
> be a lot better than CVS.
>
> Mojca
>
> ------------------------------------------------------------------------------
> Flow-based real-time traffic analytics software. Cisco certified tool.
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> Customize your own dashboards, set traffic alerts and generate reports.
> Network behavioral analysis & security monitoring. All-in-one tool.
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

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

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

I've added an option ./configure --with-qt=qt5
that will forcibly try to build with qt5 rather than falling back to trying qt4
and possibly failing.

	Ethan

On Monday, 24 February, 2014 21:38:20 Mojca Miklavec wrote:
> On Mon, Feb 24, 2014 at 8:54 PM, Ethan A Merritt wrote:
> > On Monday, 24 February, 2014 20:28:05 Mojca Miklavec wrote:
> >> Despite this, I still believe that configuration should work properly
> >> when pkg-config is absent.
> >
> > I seem to recall that we have had this discussion before.
> > pkg-config is just a tool that sets various paths and definitions.
> > If it is not present you can still set those paths and definitions yourself.
> 
> Except that it doesn't work in case of Qt 5.
> 
> > The warnings emitted by ./configure about not finding a pkg-config
> > file are just informational, not fatal errors.
> 
> They are not fatal, but in case of Qt 5 there is no way to enable the
> Qt terminal without a working pkg-config.
> 
> > For example, libcerf has no *.pc file so ./configure reports
> >
> > %%%%
> > Package requirements (libcerf) were not met:
> > No package 'libcerf' found
> > Consider adjusting the PKG_CONFIG_PATH environment variable if you
> > installed software in a non-standard prefix.
> > Alternatively, you may set the environment variables LIBCERF_CFLAGS
> > and LIBCERF_LIBS to avoid the need to call pkg-config.
> > See the pkg-config man page for more details.
> > %%%%
> >
> > But in fact none of that is needed because libcerf.so is installed in
> > a standard system location and is found automatically and included
> > in the gnuplot build despite being unknown to pkg-config.
> >
> > Now if you are saying that the PKG_CHECK_MODULES macro
> > itself is problematic, then I suppose you can add it as a null operation
> > in m4/apple.m4
> 
> No, I'm not saying that PKG_CHECK_MODULES macro is problematic. All
> I'm saying is that the logic in configure.in is wrong for Qt in case
> of missing pkg-configure.
> 
> If pkg-config is missing, configure sets
>     enable_qt_ok=yes
>     try_qt4=yes
> Because
>     PKG_CHECK_MODULES_NOFAIL(QT, [Qt5Core Qt5Gui Qt5Network Qt5Svg
> Qt5PrintSupport])
> fails, it doesn't set "try_qt4=no", so the code happily continues in
>     if test ${try_qt4} != no; then
> The code
>     PKG_CHECK_MODULES_NOFAIL(QT, [QtCore >= 4.5 QtGui >= 4.5 QtNetwork
> >= 4.5 QtSvg >= 4.5])
> fails again and then
>     if test $pkg_failed != no; then
>         enable_qt_ok=no
>         AC_MSG_WARN([The Qt terminal will not be compiled.])
> is happily executed and the Qt terminal gets disabled.
> 
> So in contrast to libcerf or any other library, missing pkg-config
> currently doesn't allow compilation of the Qt terminal at all.
> 
> Disabling pkg-config for all Apples seems unreasonable because some
> machines (using MacPorts, HomeBrew or Fink) do provide it. Also, there
> exists a folder <QTDIR5>/lib/pkgconfig, but setting PKG_CONFIG_PATH
> alone doesn't help in case of existing Qt 4 in MacPorts/Fink and
> compiling gnuplot without MacPorts/Fink/HomeBrew is a bit of a pain
> anyway.
> 
> (Maybe --with-qt=qt5 would help after all if you need to know which
> version of Qt is being used when pkg-config is missing, but I leave
> that to you. I would imagine that an argument to --with-qt would be
> something like --with-qt=/path/to/qtdir5 anyway.)
> 
> Mojca
> 
> ------------------------------------------------------------------------------
> Flow-based real-time traffic analytics software. Cisco certified tool.
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> Customize your own dashboards, set traffic alerts and generate reports.
> Network behavioral analysis & security monitoring. All-in-one tool.
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Repository conversion

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

On Mon, Feb 24, 2014 at 9:13 PM, Tait wrote:
> "Eric S. Raymond" said (on 2014/02/24):
>> (2) Where do you want to land?
>>
>> As bzr is now moribund, the realistic alternatives are Subversion,
>> git, and hg.  But I mention Subversion only for completeness; the
>> advantages of distributed VCS are huge and if you're going to incur
>> the transition costs of moving away from CVS either git or hg would
>> have a much higher functional payoff.
>
> I'd not heard Bazaar was moribund... they seem to be still making new
> releases? (... However, SourceForge doesn't appear to support bzr, so
> it's probably moot to this discussion.)

While they might make new releases, the popularity lags way behind.
(And consequently there are way less tools and services supporting
it.) Also, Bazaar is not the only alternative, but all other tools
have even lower popularity and adoption. So yes, discussing anything
but those three doesn't seem worth it.

> Has anyone studied/published how many projects have switched from Hg
> to git, and vice-versa?

That's difficult enough, but you can feed the search engine with
"convert git mercurial" and figure out that just about every hit
explains how to convert from mercurial to git. The first hit about
conversion from git to mercurial was from the time when bitbucket was
the only provider of free hosting of private repositories and only
supported mercurial.

> From my personal anecdotal experience, I know
> of a couple that have hg->git (mostly due to difficulties with
> branching), but none that have git->hg.

... which confirms the above observation.

> Support for all three (#bzr, #mercurial, #git) can be had on
> irc.freenode.net. #Git is by far the largest channel of those (for
> whatever that's worth)

The "mean" explanation would be that git must be so difficult to use
that its users need most support ;)

> and seems to have the largest list of projects
> using it, so momentum seems to favor git there.

Here are some numbers, showing about three times more git users than
those of mercurial:

http://zeroturnaround.com/rebellabs/devprod-report-revisited-version-control-systems-in-2013/
http://qa.debian.org/popcon-graph.php?packages=subversion+git+mercurial+bazaar&show_installed=on&show_vote=on&want_legend=on&want_ticks=on&from_date&to_date&hlght_date&date_fmt=%25Y-%25m
http://wiki.bazaar.canonical.com/BzrPopularity
http://bazaarvcs.wordpress.com/2010/02/15/bazaar-adoption-growing-strongly/
    (they stopped writing the blog in 2012)
http://stackoverflow.com/questions/995636/popularity-of-git-mercurial-bazaar-vs-which-to-recommend
    latest counting of tags on stackoverflow – git: 37547, mercurial: 5878

(In the spirit of the same argument as above about BitBucket driving
the git->hg conversion, I would dare to claim that GitHub contributed
a lot towards the high popularity of git.)

Anyway, whatever tool (out of the three) would be chosen ... it would
be a lot better than CVS.

Mojca

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

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

On Mon, Feb 24, 2014 at 9:12 PM, Bastian Märkisch <bma...@we...> wrote:
> Am 24.02.2014 20:39, schrieb Ethan A Merritt:
>> On Monday, 24 February, 2014 20:28:05 Mojca Miklavec wrote:
>>> On Mon, Feb 24, 2014 at 7:25 PM, Ethan A Merritt wrote:
>>>
>>> The problem is that -I/opt/local/include seems to be the first
>>> argument to compiler "no matter what". I inspected the Makefiles a bit
>>> and it seems that this is set by CPPFLAGS. I'm not exactly sure what
>>> sets it, but the workaround seems to be to set
>>>      export INCLUDES="$QT_CFLAGS"
>>> which puts the paths to Qt5 in front of everything else. Without that,
>>> Qt4 is always found first.
>>>
>>> Despite this, I still believe that configuration should work properly
>>> when pkg-config is absent.
>>>
>>> Weird enough, after I have compiled gnuplot in a slightly different
>>> way (without excluding MacPorts libraries, but maybe only the timing
>>> has changed), I get
>>>
>>> gnuplot> plot sin(x)
>>> QIODevice::write: device not open
>>> QIODevice::write: device not open
>
> Adding this snippet to qt_flushOutBuffer() solves that problem:
>
>         if (!qt || !qt->socket.isValid())
>                 return;

This avoids the QIODevice warnings/errors. But in general I still get either

Terminal type set to 'qt'
gnuplot> plot sin(x)
Error: short read from gnuplot_qt socket
gnuplot> quit
$ Event not swallowed ! 1041
############### WRONG readEvent  0 6851

or

Terminal type set to 'qt'
gnuplot> plot sin(x)
Error: short read from gnuplot_qt socket
gnuplot> qt_processTermEvent received a GE_fontprops event. This
should not have happened

gnuplot> plot sin(x)

depending on how much I wait before quitting.

Mojca

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

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

On Mon, Feb 24, 2014 at 8:54 PM, Ethan A Merritt wrote:
> On Monday, 24 February, 2014 20:28:05 Mojca Miklavec wrote:
>> Despite this, I still believe that configuration should work properly
>> when pkg-config is absent.
>
> I seem to recall that we have had this discussion before.
> pkg-config is just a tool that sets various paths and definitions.
> If it is not present you can still set those paths and definitions yourself.

Except that it doesn't work in case of Qt 5.

> The warnings emitted by ./configure about not finding a pkg-config
> file are just informational, not fatal errors.

They are not fatal, but in case of Qt 5 there is no way to enable the
Qt terminal without a working pkg-config.

> For example, libcerf has no *.pc file so ./configure reports
>
> %%%%
> Package requirements (libcerf) were not met:
> No package 'libcerf' found
> Consider adjusting the PKG_CONFIG_PATH environment variable if you
> installed software in a non-standard prefix.
> Alternatively, you may set the environment variables LIBCERF_CFLAGS
> and LIBCERF_LIBS to avoid the need to call pkg-config.
> See the pkg-config man page for more details.
> %%%%
>
> But in fact none of that is needed because libcerf.so is installed in
> a standard system location and is found automatically and included
> in the gnuplot build despite being unknown to pkg-config.
>
> Now if you are saying that the PKG_CHECK_MODULES macro
> itself is problematic, then I suppose you can add it as a null operation
> in m4/apple.m4

No, I'm not saying that PKG_CHECK_MODULES macro is problematic. All
I'm saying is that the logic in configure.in is wrong for Qt in case
of missing pkg-configure.

If pkg-config is missing, configure sets
    enable_qt_ok=yes
    try_qt4=yes
Because
    PKG_CHECK_MODULES_NOFAIL(QT, [Qt5Core Qt5Gui Qt5Network Qt5Svg
Qt5PrintSupport])
fails, it doesn't set "try_qt4=no", so the code happily continues in
    if test ${try_qt4} != no; then
The code
    PKG_CHECK_MODULES_NOFAIL(QT, [QtCore >= 4.5 QtGui >= 4.5 QtNetwork
>= 4.5 QtSvg >= 4.5])
fails again and then
    if test $pkg_failed != no; then
        enable_qt_ok=no
        AC_MSG_WARN([The Qt terminal will not be compiled.])
is happily executed and the Qt terminal gets disabled.

So in contrast to libcerf or any other library, missing pkg-config
currently doesn't allow compilation of the Qt terminal at all.

Disabling pkg-config for all Apples seems unreasonable because some
machines (using MacPorts, HomeBrew or Fink) do provide it. Also, there
exists a folder <QTDIR5>/lib/pkgconfig, but setting PKG_CONFIG_PATH
alone doesn't help in case of existing Qt 4 in MacPorts/Fink and
compiling gnuplot without MacPorts/Fink/HomeBrew is a bit of a pain
anyway.

(Maybe --with-qt=qt5 would help after all if you need to know which
version of Qt is being used when pkg-config is missing, but I leave
that to you. I would imagine that an argument to --with-qt would be
something like --with-qt=/path/to/qtdir5 anyway.)

Mojca

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

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

On Monday, 24 February, 2014 21:12:17 Bastian Märkisch wrote:
> >> gnuplot> plot sin(x)
> >> QIODevice::write: device not open
> >> QIODevice::write: device not open
> 
> The reason for these is the section below in qt_graphics(). The first 
> time it is called the qt->socket is not yet open and thus the call to 
> qt_flushOutBuffer will fail:
> 
>         qt->out << GEDesactivate;
>         qt_flushOutBuffer();
>         qt_connectToServer();
> 
> Adding this snippet to qt_flushOutBuffer() solves that problem:
> 
>         if (!qt || !qt->socket.isValid())
>                 return;
> 
> But maybe the order of commands in qt_graphics() should be changed instead.

I think the order is correct.  It wants to flush and close any previous
connection before starting a new one.   The message comes when
there was no previous connection.  

Curiously, I see these warnings on some machines but not others.
I've no idea why.  But your check in qt_flushOutBuffer() looks correct.
	
	Ethan

>    Bastian
> 

Re: Repository conversion

[Tait <gnu...@t4...>]

"Eric S. Raymond" <es...@th...> said (on 2014/02/24):
> (2) Where do you want to land?
> 
> As bzr is now moribund, the realistic alternatives are Subversion,
> git, and hg.  But I mention Subversion only for completeness; the
> advantages of distributed VCS are huge and if you're going to incur
> the transition costs of moving away from CVS either git or hg would
> have a much higher functional payoff.

I'd not heard Bazaar was moribund... they seem to be still making new
releases? (... However, SourceForge doesn't appear to support bzr, so
it's probably moot to this discussion.)

Has anyone studied/published how many projects have switched from Hg
to git, and vice-versa? From my personal anecdotal experience, I know
of a couple that have hg->git (mostly due to difficulties with
branching), but none that have git->hg.

Support for all three (#bzr, #mercurial, #git) can be had on
irc.freenode.net. #Git is by far the largest channel of those (for
whatever that's worth) and seems to have the largest list of projects
using it, so momentum seems to favor git there. Hg doesn't have the
concept of an index (or stage, depending on the age of the
documentation), so it will be more similar to CVS/SVN in work flow.

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

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

Am 24.02.2014 20:39, schrieb Ethan A Merritt:
> On Monday, 24 February, 2014 20:28:05 Mojca Miklavec wrote:
>> On Mon, Feb 24, 2014 at 7:25 PM, Ethan A Merritt wrote:
>>
>> The problem is that -I/opt/local/include seems to be the first
>> argument to compiler "no matter what". I inspected the Makefiles a bit
>> and it seems that this is set by CPPFLAGS. I'm not exactly sure what
>> sets it, but the workaround seems to be to set
>>      export INCLUDES="$QT_CFLAGS"
>> which puts the paths to Qt5 in front of everything else. Without that,
>> Qt4 is always found first.
>>
>> Despite this, I still believe that configuration should work properly
>> when pkg-config is absent.
>>
>> Weird enough, after I have compiled gnuplot in a slightly different
>> way (without excluding MacPorts libraries, but maybe only the timing
>> has changed), I get
>>
>> gnuplot> plot sin(x)
>> QIODevice::write: device not open
>> QIODevice::write: device not open

The reason for these is the section below in qt_graphics(). The first 
time it is called the qt->socket is not yet open and thus the call to 
qt_flushOutBuffer will fail:

	qt->out << GEDesactivate;
	qt_flushOutBuffer();
	qt_connectToServer();

Adding this snippet to qt_flushOutBuffer() solves that problem:

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

But maybe the order of commands in qt_graphics() should be changed instead.

   Bastian

>
> I get those messages also.  They seem to be harmless.
>
>> Error: short read from gnuplot_qt socket
>> gnuplot> qt_processTermEvent received a GE_fontprops event. This
>> should not have happened
>
> But that, as it self-declares, should not happen.
> Let me think about what it might mean.
>
>> gnuplot> plot sin(x)
>>
>> but the mouse events work. The first plot is still very weird with
>> wrong font initializations.
>
> That is consistent with the error message you showed.
> The font metrics information for the first plot was apparently
> delivered to the wrong recipient and/or at the wrong time.
>
> 	Ethan
>
>
> ------------------------------------------------------------------------------
> Flow-based real-time traffic analytics software. Cisco certified tool.
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> Customize your own dashboards, set traffic alerts and generate reports.
> Network behavioral analysis & security monitoring. All-in-one tool.
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

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

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

On Monday, 24 February, 2014 20:28:05 Mojca Miklavec wrote:
> Despite this, I still believe that configuration should work properly
> when pkg-config is absent.

I seem to recall that we have had this discussion before.
pkg-config is just a tool that sets various paths and definitions.
If it is not present you can still set those paths and definitions yourself.
The warnings emitted by ./configure about not finding a pkg-config
file are just informational, not fatal errors.

For example, libcerf has no *.pc file so ./configure reports

%%%%
Package requirements (libcerf) were not met:
No package 'libcerf' found
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.
Alternatively, you may set the environment variables LIBCERF_CFLAGS
and LIBCERF_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
%%%%

But in fact none of that is needed because libcerf.so is installed in
a standard system location and is found automatically and included
in the gnuplot build despite being unknown to pkg-config.

Now if you are saying that the PKG_CHECK_MODULES macro
itself is problematic, then I suppose you can add it as a null operation
in m4/apple.m4


	Ethan

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

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

On Monday, 24 February, 2014 20:28:05 Mojca Miklavec wrote:
> On Mon, Feb 24, 2014 at 7:25 PM, Ethan A Merritt wrote:
> 
> The problem is that -I/opt/local/include seems to be the first
> argument to compiler "no matter what". I inspected the Makefiles a bit
> and it seems that this is set by CPPFLAGS. I'm not exactly sure what
> sets it, but the workaround seems to be to set
>     export INCLUDES="$QT_CFLAGS"
> which puts the paths to Qt5 in front of everything else. Without that,
> Qt4 is always found first.
> 
> Despite this, I still believe that configuration should work properly
> when pkg-config is absent.
> 
> Weird enough, after I have compiled gnuplot in a slightly different
> way (without excluding MacPorts libraries, but maybe only the timing
> has changed), I get
> 
> gnuplot> plot sin(x)
> QIODevice::write: device not open
> QIODevice::write: device not open

I get those messages also.  They seem to be harmless.

> Error: short read from gnuplot_qt socket
> gnuplot> qt_processTermEvent received a GE_fontprops event. This
> should not have happened

But that, as it self-declares, should not happen.
Let me think about what it might mean. 

> gnuplot> plot sin(x)
> 
> but the mouse events work. The first plot is still very weird with
> wrong font initializations.

That is consistent with the error message you showed.
The font metrics information for the first plot was apparently 
delivered to the wrong recipient and/or at the wrong time.

	Ethan

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

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

On Mon, Feb 24, 2014 at 7:25 PM, Ethan A Merritt wrote:
> On Monday, 24 February, 2014 19:01:02 Mojca Miklavec wrote:
>> Hi,
>>
>> I tried to test gnuplot with Qt5, but there is one flaw in the
>> configure script: I need to have pkg-config installed if I want to
>> build with Qt 5 even if I provide QT_CFLAGS and QT_LIBS.
>>
>> I have pkg-config and lots of other libraries installed via MacPorts,
>> but MacPorts doesn't provide Qt5. The problem is that as soon as any
>> given library (like libpng, libreadline, ...) comes from MacPorts that
>> means that -I/path/to/macports/include and -L/path/to/macports/lib
>> will consequently also pick Qt4 headers and libraries from MacPorts
>> instead of taking them from the location specified by QT_CFLAGS and
>> QT_LIBS, so I need to either uninstall Qt 4 from MacPorts or remove
>> any dependency on MacPorts.
>
> That doesn't follow.  The situation is the same on linux in the sense
> that whichever Qt version is found first will be used by default.

The problem is that -I/opt/local/include seems to be the first
argument to compiler "no matter what". I inspected the Makefiles a bit
and it seems that this is set by CPPFLAGS. I'm not exactly sure what
sets it, but the workaround seems to be to set
    export INCLUDES="$QT_CFLAGS"
which puts the paths to Qt5 in front of everything else. Without that,
Qt4 is always found first.

Despite this, I still believe that configuration should work properly
when pkg-config is absent.

Weird enough, after I have compiled gnuplot in a slightly different
way (without excluding MacPorts libraries, but maybe only the timing
has changed), I get

gnuplot> plot sin(x)
QIODevice::write: device not open
QIODevice::write: device not open
Error: short read from gnuplot_qt socket
gnuplot> qt_processTermEvent received a GE_fontprops event. This
should not have happened

gnuplot> plot sin(x)

but the mouse events work. The first plot is still very weird with
wrong font initializations. Something is still misbehaving.

Mojca

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

[Ethan A M. <merritt@u.washington.edu>]

On Monday, 24 February, 2014 19:23:00 Mojca Miklavec wrote:
> On Mon, Feb 24, 2014 at 7:01 PM, Mojca Miklavec wrote:
> >
> > I will compare the results with the released version (with branch 4.6)

The modifications to allow building with Qt5 are only in 4.7, not in 4.6

	Ethan



> Which fails to compile (apart from similar problems related to missing
> pkg-config).
> 
> ../../src/qtterminal/qt_term.cpp:137:19: error: no member named
> 'toAscii' in 'QString'
>                 execlp(filename.toAscii().data(), "gnuplot_qt", (char*)NULL);
>                        ~~~~~~~~ ^
> ../../src/qtterminal/qt_term.cpp:138:56: error: no member named
> 'toAscii' in 'QString'
>                 fprintf(stderr, "Expected Qt driver: %s\n",
> filename.toAscii().data());
>                                                             ~~~~~~~~ ^
> ../../src/qtterminal/qt_term.cpp:308:34: error: allocation of
> incomplete type 'QApplication'
>         QApplication* application = new QApplication(argc, (char**)( NULL));
>                                         ^~~~~~~~~~~~
> /path/to/qt/5.2.1/clang_64/lib/QtCore.framework/Headers/qobject.h:457:18:
> note: forward declaration of 'QApplication'
>     friend class QApplication;
>                  ^
> 3 errors generated.
> 
> 
> After fixing this one way too many other compile errors are thrown, so
> I didn't even attempt to proceed.
> 
> Mojca
> 
> ------------------------------------------------------------------------------
> Flow-based real-time traffic analytics software. Cisco certified tool.
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> Customize your own dashboards, set traffic alerts and generate reports.
> Network behavioral analysis & security monitoring. All-in-one tool.
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

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

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

On Monday, 24 February, 2014 19:01:02 Mojca Miklavec wrote:
> Hi,
> 
> I tried to test gnuplot with Qt5, but there is one flaw in the
> configure script: I need to have pkg-config installed if I want to
> build with Qt 5 even if I provide QT_CFLAGS and QT_LIBS.
> 
> I have pkg-config and lots of other libraries installed via MacPorts,
> but MacPorts doesn't provide Qt5. The problem is that as soon as any
> given library (like libpng, libreadline, ...) comes from MacPorts that
> means that -I/path/to/macports/include and -L/path/to/macports/lib
> will consequently also pick Qt4 headers and libraries from MacPorts
> instead of taking them from the location specified by QT_CFLAGS and
> QT_LIBS, so I need to either uninstall Qt 4 from MacPorts or remove
> any dependency on MacPorts.

That doesn't follow.  The situation is the same on linux in the sense
that whichever Qt version is found first will be used by default.
On my machines qt5 is found before qt4 if both are present.
You can override this by
  ./configure --with-qt=qt4

If you like, I can add a similar configure option --with-qt=qt5
but alternatively you can just make sure that the qt5 directories come 
before the MacPorts/qt4 directories in your various path statements.

	Ethan


> 
> But if I remove MacPorts from PATH completely, gnuplot refuses to
> include Qt due to lack of pkg-config:
> 
> checking for QT... configure: WARNING:
> The pkg-config script could not be found or is too old.  Make sure it
> is in your PATH or set the PKG_CONFIG environment variable to the full
> path to pkg-config.
> 
> Alternatively, you may set the environment variables QT_CFLAGS
> and QT_LIBS to avoid the need to call pkg-config.
> See the pkg-config man page for more details.
> 
> To get pkg-config, see <http://www.freedesktop.org/software/pkgconfig>.
> checking for QT... configure: WARNING:
> The pkg-config script could not be found or is too old.  Make sure it
> is in your PATH or set the PKG_CONFIG environment variable to the full
> path to pkg-config.
> 
> Alternatively, you may set the environment variables QT_CFLAGS
> and QT_LIBS to avoid the need to call pkg-config.
> See the pkg-config man page for more details.
> 
> To get pkg-config, see <http://www.freedesktop.org/software/pkgconfig>.
> configure: WARNING: The Qt terminal will not be compiled.
> checking that generated files are newer than configure... done
> 
> 
> Can the configure script please be changed in such a way that
> pkg-config becomes optional in the case of Qt (5)? I don't have any
> simple patch ready for that, but you can see below what I needed apart
> from hacking the ./configure[.in] just to get a rough idea.
> 
> 
> There is a chance that I've screwed something up (or that there are
> problems with the repository I'm using), but gnuplot with Qt 5 seems
> pretty nonfunctional on Mac OS X.
> 
> It starts with
> 
> > plot sin(x)
> QIODevice::write: device not open
> QIODevice::write: device not open
> Error: short read from gnuplot_qt socket
> 
> then nevertheress plots something, but uses the wrong dimensions and
> doesn't allocate any space for fonts. The second plot works better and
> uses proper dimensions (I can send screenshots if anyone is
> interested). The third plot throws:
> 
> qt_processTermEvent received a GE_fontprops event. This should not have happened
> 
> Mouse events (increasing or decreasing the window) don't work at all.
> Or rather: they do work in a weird way. If I try to move the second
> plot around, the second plot isn't changed, but the third plot is
> moved. If I increase or decrease the window, the plot doesn't change,
> but the next plot adapts to those dimensions.
> 
> If I type "quit" to fast (soon after the first plot), the following is thrown:
> 
> > Event not swallowed ! 1041
> ############### WRONG readEvent  0 6851
> 
> I'm sorry for not testing Qt 5 earlier, but it's relatively
> non-trivial to figure out how to build gnuplot against Qt 5.2 on Mac.
> Here is what I eventually used:
> 
> export QT_PATH=/path/to/qt/5.2.1/clang_64
> 
> export QT_LIBS="-F$QT_PATH/lib \
> -framework QtCore \
> -framework QtGui \
> -framework QtWidgets \
> -framework QtNetwork \
> -framework QtSvg \
> -framework QtPrintSupport"
> 
> # NOTE: CFLAGS usually look more like
> #     -framework QtCore,
> # but then it would need to be used as
> #     #include <QtCore/QtCore>
> #
> # Current use of headers requires the weird
> # -I$QT_PATH/lib/QtCore.framework/Headers
> 
> export QT_CFLAGS="-F$QT_PATH/lib \
> -I$QT_PATH/lib/QtCore.framework/Headers \
> -I$QT_PATH/lib/QtGui.framework/Headers \
> -I$QT_PATH/lib/QtWidgets.framework/Headers \
> -I$QT_PATH/lib/QtNetwork.framework/Headers \
> -I$QT_PATH/lib/QtSvg.framework/Headers"
> 
> export UIC=$QT_PATH/bin/uic
> export MOC=$QT_PATH/bin/moc
> export RCC=$QT_PATH/bin/rcc
> 
> export CC=clang
> export CXX=clang++
> 
> export EMACS=no
> 
> export PATH=/usr/bin:/bin:/usr/sbin:/sbin
> 
> ./configure --with-qt --prefix=$PWD/inst
> 
> 
> I can test the latest released version to see how that behaves, but it
> would be of enormous help when testing numerous patches if the
> repository was using some other version control system. I'm unable to
> work with CVS and I have a somewhat screwed-up GIT mirror (thanks to
> bugs in "git cvsimport"). Combined with all other problems related to
> non-trivial Qt5 configuration ... there are simply a lot of obstacles
> preventing easy testing.
> 
> I will compare the results with the released version (with branch 4.6)
> next, but really ... it would help me a lot if conversion to git was
> done prior to that.
> 
> Thank you,
>     Mojca
> 
> ------------------------------------------------------------------------------
> Flow-based real-time traffic analytics software. Cisco certified tool.
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> Customize your own dashboards, set traffic alerts and generate reports.
> Network behavioral analysis & security monitoring. All-in-one tool.
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

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

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

On Mon, Feb 24, 2014 at 7:01 PM, Mojca Miklavec wrote:
>
> I will compare the results with the released version (with branch 4.6)

Which fails to compile (apart from similar problems related to missing
pkg-config).

../../src/qtterminal/qt_term.cpp:137:19: error: no member named
'toAscii' in 'QString'
                execlp(filename.toAscii().data(), "gnuplot_qt", (char*)NULL);
                       ~~~~~~~~ ^
../../src/qtterminal/qt_term.cpp:138:56: error: no member named
'toAscii' in 'QString'
                fprintf(stderr, "Expected Qt driver: %s\n",
filename.toAscii().data());
                                                            ~~~~~~~~ ^
../../src/qtterminal/qt_term.cpp:308:34: error: allocation of
incomplete type 'QApplication'
        QApplication* application = new QApplication(argc, (char**)( NULL));
                                        ^~~~~~~~~~~~
/path/to/qt/5.2.1/clang_64/lib/QtCore.framework/Headers/qobject.h:457:18:
note: forward declaration of 'QApplication'
    friend class QApplication;
                 ^
3 errors generated.


After fixing this one way too many other compile errors are thrown, so
I didn't even attempt to proceed.

Mojca

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

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

Hi,

I tried to test gnuplot with Qt5, but there is one flaw in the
configure script: I need to have pkg-config installed if I want to
build with Qt 5 even if I provide QT_CFLAGS and QT_LIBS.

I have pkg-config and lots of other libraries installed via MacPorts,
but MacPorts doesn't provide Qt5. The problem is that as soon as any
given library (like libpng, libreadline, ...) comes from MacPorts that
means that -I/path/to/macports/include and -L/path/to/macports/lib
will consequently also pick Qt4 headers and libraries from MacPorts
instead of taking them from the location specified by QT_CFLAGS and
QT_LIBS, so I need to either uninstall Qt 4 from MacPorts or remove
any dependency on MacPorts.

But if I remove MacPorts from PATH completely, gnuplot refuses to
include Qt due to lack of pkg-config:

checking for QT... configure: WARNING:
The pkg-config script could not be found or is too old.  Make sure it
is in your PATH or set the PKG_CONFIG environment variable to the full
path to pkg-config.

Alternatively, you may set the environment variables QT_CFLAGS
and QT_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.

To get pkg-config, see <http://www.freedesktop.org/software/pkgconfig>.
checking for QT... configure: WARNING:
The pkg-config script could not be found or is too old.  Make sure it
is in your PATH or set the PKG_CONFIG environment variable to the full
path to pkg-config.

Alternatively, you may set the environment variables QT_CFLAGS
and QT_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.

To get pkg-config, see <http://www.freedesktop.org/software/pkgconfig>.
configure: WARNING: The Qt terminal will not be compiled.
checking that generated files are newer than configure... done


Can the configure script please be changed in such a way that
pkg-config becomes optional in the case of Qt (5)? I don't have any
simple patch ready for that, but you can see below what I needed apart
from hacking the ./configure[.in] just to get a rough idea.


There is a chance that I've screwed something up (or that there are
problems with the repository I'm using), but gnuplot with Qt 5 seems
pretty nonfunctional on Mac OS X.

It starts with

> plot sin(x)
QIODevice::write: device not open
QIODevice::write: device not open
Error: short read from gnuplot_qt socket

then nevertheress plots something, but uses the wrong dimensions and
doesn't allocate any space for fonts. The second plot works better and
uses proper dimensions (I can send screenshots if anyone is
interested). The third plot throws:

qt_processTermEvent received a GE_fontprops event. This should not have happened

Mouse events (increasing or decreasing the window) don't work at all.
Or rather: they do work in a weird way. If I try to move the second
plot around, the second plot isn't changed, but the third plot is
moved. If I increase or decrease the window, the plot doesn't change,
but the next plot adapts to those dimensions.

If I type "quit" to fast (soon after the first plot), the following is thrown:

> Event not swallowed ! 1041
############### WRONG readEvent  0 6851

I'm sorry for not testing Qt 5 earlier, but it's relatively
non-trivial to figure out how to build gnuplot against Qt 5.2 on Mac.
Here is what I eventually used:

export QT_PATH=/path/to/qt/5.2.1/clang_64

export QT_LIBS="-F$QT_PATH/lib \
-framework QtCore \
-framework QtGui \
-framework QtWidgets \
-framework QtNetwork \
-framework QtSvg \
-framework QtPrintSupport"

# NOTE: CFLAGS usually look more like
#     -framework QtCore,
# but then it would need to be used as
#     #include <QtCore/QtCore>
#
# Current use of headers requires the weird
# -I$QT_PATH/lib/QtCore.framework/Headers

export QT_CFLAGS="-F$QT_PATH/lib \
-I$QT_PATH/lib/QtCore.framework/Headers \
-I$QT_PATH/lib/QtGui.framework/Headers \
-I$QT_PATH/lib/QtWidgets.framework/Headers \
-I$QT_PATH/lib/QtNetwork.framework/Headers \
-I$QT_PATH/lib/QtSvg.framework/Headers"

export UIC=$QT_PATH/bin/uic
export MOC=$QT_PATH/bin/moc
export RCC=$QT_PATH/bin/rcc

export CC=clang
export CXX=clang++

export EMACS=no

export PATH=/usr/bin:/bin:/usr/sbin:/sbin

./configure --with-qt --prefix=$PWD/inst


I can test the latest released version to see how that behaves, but it
would be of enormous help when testing numerous patches if the
repository was using some other version control system. I'm unable to
work with CVS and I have a somewhat screwed-up GIT mirror (thanks to
bugs in "git cvsimport"). Combined with all other problems related to
non-trivial Qt5 configuration ... there are simply a lot of obstacles
preventing easy testing.

I will compare the results with the released version (with branch 4.6)
next, but really ... it would help me a lot if conversion to git was
done prior to that.

Thank you,
    Mojca

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

[Jérôme L. <jer...@no...>]

Hi,

	I got a bit confused about your motivations for introducing an event 
loop in the "inboard" qt terminal. In qt_term.cpp, we use, by design, a 
very limited set of the Qt library, and rather push as much 
functionality as possible the in the gnuplot_qt "outboard" program. And 
I think that this set of functions doesn't require an event loop to work 
properly (As a matter of fact, I can observe by commenting out the 
QCoreApplication declaration in qt_term.cpp that it doesn't even require 
an instantiation of QCoreApplication to work -- except from the Windows 
specific QCoreApplication::applicationDirPath() call). More 
specifically, we use
- Storage classes (QString, QImage, QColor...) that just gather 
information but use no event mechanism.
- QLocalSocket that, according to the Qt documentation, can work without 
an event loop:
"Although QLocalSocket is designed for use with an event loop, it's 
possible to use it without one. In that case, you must use 
waitForConnected(), waitForReadyRead(), waitForBytesWritten(), and 
waitForDisconnected() which blocks until the operation is complete or 
the timeout expires.". In fact, I can imagine that the gnuplot inboard 
driver is perhaps precisely the kind of programs that the Qt developers 
had in mind when they wrote this sentence: a program that cannot run a 
Qt event loop because it implements its own event loop, but that still 
wants to send messages to another auxiliary program that runs a Qt event 
loop to manage a GUI.

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 ?
To my knowledge, here are the issues that arose on non Linux platform:
- OSX: in the past, there was no gnuplot_qt independent process, and the 
GUI was rather managed in a thread. As you point out, this is not 
supported in Qt, and while it kind of happened to work with Linux, it 
failed on OSX.
- OSX: currently, the QtGnuplotWidget has a hard time to resize itself 
to the correct size, but it is specific to the gnuplot_qt outboard driver.
- Windows: Watching at the same time the standard input and a 
QLocalSocket file descriptor is not supported on Windows using select() 
or the Qt API (which might use select() under the hood). This issue is 
not related to the EventLoop or not EventLoop question and has been 
recently fixed by specific calls to the win32 API.
- All platforms: waitForConnected() immediatly returns if not socket is 
found (in particular, this happens when the gnuplot_qt program is still 
being initialized), even when a timeout is set. This was solved by 
introducing a custom timeout mechanism, but could more elegantly be 
solved by some communication mechanism between gnuplot ("inboard") and 
gnuplot_qt ("outboard"). I can see that part of your code actually 
implements this.

Concerning QApplication vs. QCoreApplication & font metrics:
Until recently, the inboard driver (qt_term.cpp) used to instantiate a 
QApplication to determine the font metrics (no event loop was required 
for this though, and more generally, no Qt event loop, nor Qt event 
based mechanism has ever been running in the main gnuplot thread). As 
Ethan said, this mechanism has been moved to the "outboard" gnuplot_qt 
program, and now the inboard driver only instantiate a QCoreApplication 
(which, as I said above, even turns out not to be necessary in practice, 
although the Qt documentation does not certify this point). The 
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.

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.

Jérôme



Le 24/02/2014 08:10, Daniel J Sebald a écrit :
> On 02/24/2014 12:16 AM, sfeam wrote:
>> On Sunday, 23 February 2014 11:22:42 PM Daniel J Sebald wrote:
>>> On 02/23/2014 10:35 PM, sfeam wrote:
>>>> On Sunday, 23 February 2014 10:04:42 PM Daniel J Sebald wrote:
>>>>>
>>>>> 	// Set plot size
>>>>> 	if (qt_setSize)
>>>>> 	{
>>>>> 		term->xmax = qt_oversampling*qt_setWidth;
>>>>> 		term->ymax = qt_oversampling*qt_setHeight;
>>>>> 		qt_setSize = false;
>>>>> 	}
>>>>>
>>>>> In a separate thread, the "term->xmax =" will be done asynchronously.
>>>>> Hence a mutex/wait is needed to make sure the code in the separate
>>>>> thread has updated term->xmax and term->max before the core thread can
>>>>> continue onward.
>>>>
>>>> Ah. Now I'm with you.
>>>> Yeah, this is the piece of code that has changed the most in qt
>>>> because nothing seems to work properly on both linux and OSX.
>>>> You are quite correct that term->foo should not be referenced in
>>>> this part of the terminal driver.  It is supposed to return the revised
>>>> font information via an event GP_fontprops.  And it _was_ doing that
>>>> at one point.  I've now lost track of all the work-arounds and what
>>>> exactly they fixed, but certainly it would be good if you can get
>>>> back to the original intent.  You can look at other terminal
>>>> drivers as a model if needed.
>>>
>>> OK, thanks.  I'll look that over.  I think that may be the one thing
>>> that isn't working yet for what I've done, i.e., some text isn't showing
>>> up probably owing to the core is told the font height is zero.
>>
>> Let me summarize a bit of the history.
>>
>> - The core code and the qt_term bits of Qt are in the same process.
>>     Call this "inboard"
>>     The screen display is being managed by a separate Qt process.
>>     Call this "outboard"
>>     The inboard and outboard processes operate asynchronously.
>>
>> - To reserve space for some text element on the next plot, the core
>>     code needs to know how big the current font is so it sends a query
>>     to the inboard terminal driver.  This request can come either via
>>     term->set_font()  or in enhanced text mode via term->put_text.
>>
>> - It would be simplest if the inboard terminal driver could just reply
>>     immediately with the requested font metrics. No communication back
>>     and forth with the outboard terminal driver is required.  This is what
>>     the Qt terminal used to do, and still does in version 4.6.
>>     The font size information is obtained by calling
>>     QFontMetrics metrics(QFont(qt_currentFontName, qt_currentFontSize));
>>     Since the inboard driver and the core code are in the same process,
>>     the inboard driver can just set term->h_char and term->v_char
>>     directly and that's the end of it.
>>
>> - Now here comes the problem.  Apparently calling QFontMetrics without
>>     there being a full QApplication and maybe [not sure] an event
>>     doesn't work properly.  In particular is was causing problems
>>     on OSX, and it was ugly even on linux.
>>     See the comments in version 4.6 qt_term.cpp
>>     // Create a QApplication without event loop for QObject's that need it,
>>     // namely font handling
>>     // A better strategy would be to transfer the font handling to the
>>     // QtGnuplotWidget, but it would require
>>     // some synchronization between the widget and the gnuplot process.
>>
>> - So in January Jérôme followed through on that comment and moved
>>     the QFontMetrics call over to the outboard driver for version 4.7.
>>     That simplified things in one way, but introduced a new complication.
>>     Now the inboard driver has to send a change font request to the
>>     outboard driver (a different process) and then wait for the resulting
>>     size information to be sent back via a QEvent.   That's where
>>     waitforinput() and do_event() suddenly become involved where
>>     they hadn't been previously.  It was also slower, so he later
>>     introduced a cache of font metrics on the inboard side but let's
>>     disregard that for now.
>>
>> - So now I gather you are working to have an event loop in the
>>     inboard driver again, although I've lost track of exactly why.
>
> Hopefully to make OSX and Windows behave the same as Unix.  I don't know
> for sure because Qt is a big creature, but I suspect that if there is no
> event loop that timers aren't guaranteed to work and who knows what
> else.  So by providing an event, I'm hoping Qt performs the same on all
> platforms.  It's just following the examples that Qt documentation gives.
>
>
>>     But in that case I think it makes sense to move the
>>     font metrics query back into the inboard driver as well.
>>     At which point we return to a setup in which waitforinput()
>>     and do_event() are not involved in font processing.
>>
>> So much for font handling and the involvement of enhanced text
>> processing.
>>
>> There is a separate issue, however, that has been at the heart of
>> the recent attempts to get OSX working.  Information about the
>> size of the display window necessarily comes from the outboard
>> driver, which is a separate process. Right now this window size
>> information is also passed using a GE_fontprops event, but there's no
>> good reason for that.  It really should have a separate event type
>> to reduce confusion.  But changing the name of the event wouldn't
>> change the information flow in any way.
>
> Oh, OK.  Thanks.  I've got the big picture now and I think we will
> probably converge on something here that is about right.
>
> I'll correct one thing in that list which is I believe the issue is not
> the presence of the QApplication in the main process, but that the
> QApplication cannot have an event loop.  That is, one can't issue
> application.exec(), because doing so will hang gnuplot while
> application.exec() blocks to handle all of its realtime traffic
> (signals, slots, system calls, etc).  Graphics in Qt must be done in a
> main thread; it can't be done in a separate thread.  That leaves the Qt
> graphics code to be run in a separate process.  (Note, I've fixed the
> process communications a bit so that there aren't these while loops that
> keep trying to establish a connection to some external service.)
>
> The QApplication issue is why I've set out to put the bulk of the
> terminal interface code in a separate thread because in the separate
> thread and event loop, i.e., thread.exec(), is perfectly fine.  The
> thread acts on its own.  My preliminary code indicates there is no
> problem sending signals back and forth across that thread.  So, with an
> event loop running in the second thread, all the timers and whatever
> else should be fine--the only restriction being that graphics cannot be
> done there.  If it turns out OSX doesn't behave the same in the thread
> that has an event loop, then something isn't right with Qt.  (We'll know
> soon.)
>
> So here is what I'm aiming for right now, sort of combining everything:
>
>      MAIN PROGRAM         |       QTHREAD        ||  GNUPLOT_QT
>                           |                      ||  (outboard)
>                           |                      ||
>    gnuplot core           |  QtTerminalInterface ||  Currently has a
>    QtTerminalEmitter      |  (active event loop) ||  few things we hope
>    (inactive event loop)  |                      ||  to move back into
>                           |                      ||  QtTerminalInterface
>
> where the single line means separate thread and the double line means a
> separate process.
>
> OK, for the most part I'll be offline for the week.
>
> Dan
>
> ------------------------------------------------------------------------------
> Flow-based real-time traffic analytics software. Cisco certified tool.
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> Customize your own dashboards, set traffic alerts and generate reports.
> Network behavioral analysis & security monitoring. All-in-one tool.
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>