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

Re: lua help build, autotools update

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

On 11/16/2014 04:00 PM, Hans-Bernhard Bröker wrote:
> Am 16.11.2014 um 18:20 schrieb Daniel J Sebald:
>> On 11/15/2014 05:02 AM, Hans-Bernhard Bröker wrote:
>>
>>> As an aside, I propose to upgrade the entire auto-tools configuration to
>>> current versions (autoconf 2.69, automake 1.14). Some of our automake
>>> support scripts are almost a decade out of date... This I will only
>>> check in after some discussion.
>>
>> If it is a minor change. My system is about three years old with a few
>> minor upgrades and has autoconf 2.66, automake 1.11.1. The only
>> reluctance would be if any tools require the builder (common user, not
>> bundle maintainer) to upgrade.
>
> It would require people using the CVS source to have the autotools
> versions mentioned above, or newer. Those are both at least a year old
> now, so it's not like I would be requiring bleeding-edge versions ;-)
>
>> Changelogs will be part of the "changeset", written by whomever
>> creates the changeset (just follow the defined format).
>
> Absolutely not. ChangeLog has to be maintained anyway.

One could probably generate the ChangeLog by using some kind of git or 
hg command to list the comments of the repository.  Place it in the 
"prepare" script or something.  For example, here's a hypothetical 
printout of the comments for changesets of a project:

+++++

[sebald@ someproject]$ hg log

changeset:   5:5faee0bf6335
tag:         tip
user:        Dan Sebald <dan@sebald>
date:        Fri Nov 14 13:55:34 2014 -0400
files:       file1.cpp
description:
First line is a summary of what was changed (bug #2949)

* file1.cc: Change the average code to great code.


changeset:   19207:0b12e3693ed4
user:        Buster Keaton <buster@keaton>
date:        Sun Nov 16 20:24:42 2014 -0400
files:       file2.cpp file2.h
description:
Add some hot new feature (patch #1298)

* file2.cpp: This is C++ code.

* file2.h: Header file for file2.cpp containing class declarations.

+++++

That could be done as part of the autoconf stage because with git and hg 
the whole repository exists in the programmer's project.  (That's 
different from CVS in which the comm link to the remote repository has 
to be active in order to do "cvs diff", for example.)

Also, one stipulation is that the current CVS gnuplot repository would 
have be translated and somehow write a script or program that would put 
the existing ChangeLog into the comment of each changeset, i.e., we'd 
still have the whole history.


>> It's much
>> easier to browse through changes in git and hg, create changeset, etc.
>
> For those working off work-in-progress sources, sure. But what about
> people using an actual release version?

Here's the repository for Octave:  http://hg.savannah.gnu.org/hgweb/octave/

The web interface is automatically generated by Mercurial (it's launched 
using the "hg serve" command), and I'm guessing Git has something 
similar.  It's where I go to when I want to check activity.  There is a 
graph page for following what might be happening on the release branch, 
etc.  I've seen better graph displays, but it's OK.

For releases there's no repository, just the generated ChangeLog, I suppose.


>> * True hidden surface code. (I've had in mind for a while to generalize
>> the hidden line segment code to hidden triangle surfaces.)
>
> That wouldn't be a generalization. It'd be a complete re-implementation
> that has essentially no relation to the existing code.

The hidden line segment code isn't too bad.  That's the starting point. 
  Instead of line segments, which are cut at intersections and pieces 
discarded, it becomes little triangular surfaces which are cut into 
smaller sections with some linear algebra, then discard various pieces. 
  I think we actually have that part of the problem from someone 
already--but that's not the hard part.

If you were thinking about the "painters" algorithm that is currently 
used to simulate hidden surfaces, no that's not the starting point.


>> * Better integration with other programs using emerging trends (say SQL
>> or something).
>
> Wow, ROTFL. That must be the first time in well over 20 years that
> anyone has called SQL, of all things, an "emerging trend". ;-)

Well, for me.  Can't be too careful.  :-)

Dan

Re: interactive terminal (was: Re: lua help build, autotools update)

[Philipp K. J. <ja...@ie...>]

> 
> * click a button labeled "add title", and get a dialog window that
> says "set title" followed by an input line where i can enter
> whatever would come after the keyword on the console. There is an
> "OK" button which silently executes the command, possibly a second
> button that automatically says "replot" afterwards.
> 
> * said dialog window has a few additional buttons which fill in or
> remove further "title" options to/from the input line, and i can
> re-open it any time.
> 
> * whenever i right-click into the plot, i get a menu that says "set
> label", "set arrow", plus whatever fits at the location.

YES! 

And further: click an existing label or arrow,
and be able to edit or move it.

> 
> * e.g. when the cursor is on the legend, i can change the "set key"
> options, or on an individual key, i get to change the plot colour,
> linewidth, key text, ...

YES!

> 
> * clicking on the axis labels lets me change the text, etc.
> 
> * possibility to drag the legend to another position where it
> doesn´t collide with my data.
> 
> * upon editing labels, there is a dropdown list of available fonts,
> and possibly one that inserts symbols as utf-8 characters.

YES!

> 
> * a "set grid" button (oh wait, wxt already has that ;-) )
> 

It does, but something that would guide the casual
user through tics and tic labels would be welcome!

> ....
> 
> This would help immensely in optically tuning plots, while still all
> the versatility of old-school gp-scripting is retained.
> 
> Such an interactive terminal could then (later) also allow adding
> further plots , changing the "using" statement, plot style, etc., to
> the point where it becomes an "Origin" clone, only one that is
> easily script- and programmable. Inline @heredata could be imported,
> sorted, edited in additional spreadsheet windows, without ever
> breaking backward compatibility.
> 
> Looking a few years into the future,
> 
>   Karl
> 
> 
> P.S. It should optionally be possible to strip the saved script from
> all settings that were not changed from the default/not used in the
> present plot, so it can easily be edited and re-used. (That´d be a
> cool feature also without an interactive terminal.)

Re: lua help build, autotools update

[Hans-Bernhard B. <HBB...@t-...>]

Am 16.11.2014 um 18:20 schrieb Daniel J Sebald:
> On 11/15/2014 05:02 AM, Hans-Bernhard Bröker wrote:
>
>> As an aside, I propose to upgrade the entire auto-tools configuration to
>> current versions (autoconf 2.69, automake 1.14).  Some of our automake
>> support scripts are almost a decade out of date...  This I will only
>> check in after some discussion.
>
> If it is a minor change.  My system is about three years old with a few
> minor upgrades and has autoconf 2.66, automake 1.11.1.  The only
> reluctance would be if any tools require the builder (common user, not
> bundle maintainer) to upgrade.

It would require people using the CVS source to have the autotools 
versions mentioned above, or newer.  Those are both at least a year old 
now, so it's not like I would be requiring bleeding-edge versions ;-)

>   Changelogs will be part of the "changeset", written by whomever
> creates the changeset (just follow the defined format).

Absolutely not.  ChangeLog has to be maintained anyway.

> It's much
> easier to browse through changes in git and hg, create changeset, etc.

For those working off work-in-progress sources, sure.  But what about 
people using an actual release version?

> * True hidden surface code.  (I've had in mind for a while to generalize
> the hidden line segment code to hidden triangle surfaces.)

That wouldn't be a generalization.  It'd be a complete re-implementation 
that has essentially no relation to the existing code.

> * Better integration with other programs using emerging trends (say SQL
> or something).

Wow, ROTFL.  That must be the first time in well over 20 years that 
anyone has called SQL, of all things, an "emerging trend".  ;-)

Re: wxt file-save oddity

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

Re. gvfs. This is a standard part of the gnome kit. It's moderately 
useful if you like GUI file managers, as it lets them "see inside" 
things like zipfiles, ftp directories, SMB shares, etc.

I think Ethan was onto something with his experiment featuring the 
10 second pause. There was a change in gvfs volume-monitor behavior 
in late 2012: "proxy volume monitor: Get session bus on demand. Do 
not connect to session bus at module load, let proxies to get a bus 
when needed." See 
https://mail.gnome.org/archives/commits-list/2012-November/msg00069.html

So I guess what's happening is that when the original gnuplot 
process is still running, the state is such that "get session bus" 
works right, and the child then inherits the required connection. 
But if the original process exits first, the state of the child no 
longer supports initiating "get session bus".

Why this should be, I have no idea, but (maybe) it kinda chimes with 
Daniel's comments about how the gnuplot hand-over-on-fork is 
managed.

Allin Cottrell

Re: wxt file-save oddity

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

On 11/16/2014 02:13 PM, sfeam wrote:
> On Sunday, 16 November 2014 02:00:06 PM Daniel J Sebald wrote:
>> On 11/16/2014 01:38 PM, sfeam wrote:
>>> On Sunday, 16 November 2014 02:12:28 PM Allin Cottrell wrote:
>>>
>>>>   Here's another funny. If I do
>>>
>>>>
>>>
>>>>   sudo gnuplot -persist plotfile
>>>
>>>>
>>>
>>>>   there's no delay in opening the file dialog via the Save button in the
>>>
>>>>   wxt plot window. Cf. http://ubuntuforums.org/showthread.php?t=1092467
>>>
>>> This seems to be a bug in gvfs, which claims to be
>>>
>>> "a Virtual File System library based on gio and Glib".
>>>
>>> gvfs is installed on my machine, but does not seem to be needed by anything.
>>>
>>> If I remove every package with "*gvfs*" in its name:
>>>
>>> urpme gvfs gvfs-archive gvfs-fuse gvfs-gphoto2 gvfs-iphone gvfs-mtp
>>> gvfs-smb lib64gvfscommon0
>>>
>>> I get no errors or warnings about dependencies, and the
>>>
>>> gnuplot + wxt + Export problem goes away.
>>>
>>> Dan - does your machine have gvfs? If so, what version?
>>
>> Yes.  Version 1.6.6-1.  These processes are all resident, but sleeping:
>>
>> Dan
>
> Huh.  That's much older.  The version I deleted was gvfs-1.18.3-1.mga4.x86_64
>
> I wonder if there's a reliable way to have the program say
> "I don't want any gvfs, thanks" rather than disabling it for the entire system?
> Then again, maybe if I were running a Gnome desktop gvfs would actually work.
> So far as I can tell the whole gvfs infrastructure is not relevant to KDE.

In the links you provided previously, the comments were that they 
downgraded in order to fix the problem (i.e., went back to an older 
version).

Could you check the order in which the wx_atexit() is called on your 
system with

fprintf(stderr, "wxThread::Entry before OnRun\n");
	wxTheApp->OnRun();
fprintf(stderr, "wxThread::Entry after OnRun\n");

fprintf(stderr, "wxt_atexit before wxt_handling_persist true\n");
	wxt_handling_persist = true;
fprintf(stderr, "wxt_atexit after wxt_handling_persist true\n");

I'm wondering if you and Allin are seeing a different issue (gvfs bug) 
than I am (non main thread no longer having GUI mutex locked).

Thanks,

Dan

Re: interactive terminal (was: Re: lua help build, autotools update)

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

On Sunday, 16 November 2014 09:02:31 PM Karl Ratzsch wrote:
> P.S. It should optionally be possible to strip the saved script from
> all settings that were not changed from the default/not used in the
> present plot, so it can easily be edited and re-used. (That´d be a
> cool feature also without an interactive terminal.)

That is what the gpsavediff tool is for.
It is a contributed script that you can get from the SourceForge site:

  wget http://gnuplot.sourceforge.net/scripts/files/gpsavediff

You can either run it after the fact to clean up a save file,
or have the save command pipe through it:

   save "|gpsavediff > saved_session.gp"

I would love to have it integrated into gnuplot as a
built-in command, but I haven't come up with a clean
way to do that.

	Ethan

Re: wxt file-save oddity

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

On Sunday, 16 November 2014 02:00:06 PM Daniel J Sebald wrote:
> On 11/16/2014 01:38 PM, sfeam wrote:
> > On Sunday, 16 November 2014 02:12:28 PM Allin Cottrell wrote:
> >
> >>  Here's another funny. If I do
> >
> >>
> >
> >>  sudo gnuplot -persist plotfile
> >
> >>
> >
> >>  there's no delay in opening the file dialog via the Save button in the
> >
> >>  wxt plot window. Cf. http://ubuntuforums.org/showthread.php?t=1092467
> >
> > This seems to be a bug in gvfs, which claims to be
> >
> > "a Virtual File System library based on gio and Glib".
> >
> > gvfs is installed on my machine, but does not seem to be needed by anything.
> >
> > If I remove every package with "*gvfs*" in its name:
> >
> > urpme gvfs gvfs-archive gvfs-fuse gvfs-gphoto2 gvfs-iphone gvfs-mtp
> > gvfs-smb lib64gvfscommon0
> >
> > I get no errors or warnings about dependencies, and the
> >
> > gnuplot + wxt + Export problem goes away.
> >
> > Dan - does your machine have gvfs? If so, what version?
> 
> Yes.  Version 1.6.6-1.  These processes are all resident, but sleeping:
>
> Dan

Huh.  That's much older.  The version I deleted was gvfs-1.18.3-1.mga4.x86_64

I wonder if there's a reliable way to have the program say
"I don't want any gvfs, thanks" rather than disabling it for the entire system?
Then again, maybe if I were running a Gnome desktop gvfs would actually work.
So far as I can tell the whole gvfs infrastructure is not relevant to KDE.

	Ethan

interactive terminal (was: Re: lua help build, autotools update)

[Karl R. <ra...@un...>]

On 16.11.2014 18:20, Daniel J Sebald wrote:
> * An interactive terminal?  That's been attempted (but not gotten very 
> far) going back twenty years.  I've never been real motivated on this 
> one because it doesn't fit my method of working with data.  I prefer to 
> do plotting as commands, not sculpture.

The idea has some attraction, although I positively hate "sculpting"
data into plots with programs like Origin or Excel. I´m not sure
what exactly you mean by "interactive terminal", so i´ll go
speculate a bit.

Suppose i have an initial plot in the interactive terminal. Now i´d
love to be able to

* click a button labeled "add title", and get a dialog window that
says "set title" followed by an input line where i can enter
whatever would come after the keyword on the console. There is an
"OK" button which silently executes the command, possibly a second
button that automatically says "replot" afterwards.

* said dialog window has a few additional buttons which fill in or
remove further "title" options to/from the input line, and i can
re-open it any time.

* whenever i right-click into the plot, i get a menu that says "set
label", "set arrow", plus whatever fits at the location.

* e.g. when the cursor is on the legend, i can change the "set key"
options, or on an individual key, i get to change the plot colour,
linewidth, key text, ...

* clicking on the axis labels lets me change the text, etc.

* possibility to drag the legend to another position where it
doesn´t collide with my data.

* upon editing labels, there is a dropdown list of available fonts,
and possibly one that inserts symbols as utf-8 characters.

* a "set grid" button (oh wait, wxt already has that ;-) )

....

This would help immensely in optically tuning plots, while still all
the versatility of old-school gp-scripting is retained.

Such an interactive terminal could then (later) also allow adding
further plots , changing the "using" statement, plot style, etc., to
the point where it becomes an "Origin" clone, only one that is
easily script- and programmable. Inline @heredata could be imported,
sorted, edited in additional spreadsheet windows, without ever
breaking backward compatibility.

Looking a few years into the future,

  Karl


P.S. It should optionally be possible to strip the saved script from
all settings that were not changed from the default/not used in the
present plot, so it can easily be edited and re-used. (That´d be a
cool feature also without an interactive terminal.)

Re: wxt file-save oddity

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

On 11/16/2014 01:38 PM, sfeam wrote:
> On Sunday, 16 November 2014 02:12:28 PM Allin Cottrell wrote:
>
>>  Here's another funny. If I do
>
>>
>
>>  sudo gnuplot -persist plotfile
>
>>
>
>>  there's no delay in opening the file dialog via the Save button in the
>
>>  wxt plot window. Cf. http://ubuntuforums.org/showthread.php?t=1092467
>
> This seems to be a bug in gvfs, which claims to be
>
> "a Virtual File System library based on gio and Glib".
>
> gvfs is installed on my machine, but does not seem to be needed by anything.
>
> If I remove every package with "*gvfs*" in its name:
>
> urpme gvfs gvfs-archive gvfs-fuse gvfs-gphoto2 gvfs-iphone gvfs-mtp
> gvfs-smb lib64gvfscommon0
>
> I get no errors or warnings about dependencies, and the
>
> gnuplot + wxt + Export problem goes away.
>
> Dan - does your machine have gvfs? If so, what version?

Yes.  Version 1.6.6-1.  These processes are all resident, but sleeping:

  1754 ?        00:00:00 gvfsd
  1763 ?        00:00:00 gvfs-fuse-daemo
  1775 ?        00:00:00 gvfs-gdu-volume
  1785 ?        00:00:00 gvfs-gphoto2-vo
  1787 ?        00:00:00 gvfs-afc-volume
  2007 ?        00:00:00 gvfsd-trash
  2064 ?        00:00:00 gvfsd-metadata
  2066 ?        00:00:00 gvfsd-burn

Dan

Re: wxt file-save oddity

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

On Sunday, 16 November 2014 02:12:28 PM Allin Cottrell wrote:
> Here's another funny. If I do
> 
> sudo gnuplot -persist plotfile
> 
> there's no delay in opening the file dialog via the Save button in the 
> wxt plot window. Cf. http://ubuntuforums.org/showthread.php?t=1092467

This seems to be a bug in gvfs, which claims to be 
"a Virtual File System library based on gio and Glib".

gvfs is installed on my machine, but does not seem to be needed by anything.

If I remove every package with "*gvfs*" in its name:

urpme gvfs gvfs-archive gvfs-fuse gvfs-gphoto2 gvfs-iphone gvfs-mtp gvfs-smb lib64gvfscommon0

I get no errors or warnings about dependencies, and the 
gnuplot + wxt + Export problem goes away.

Dan - does your machine have gvfs?  If so, what version?

	Ethan

Re: wxt file-save oddity

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

Here's another funny. If I do

sudo gnuplot -persist plotfile

there's no delay in opening the file dialog via the Save button in the 
wxt plot window. Cf. http://ubuntuforums.org/showthread.php?t=1092467

-- 
Allin Cottrell
Department of Economics
Wake Forest University, NC

Re: lua help build, autotools update

[Philipp K. J. <ja...@ie...>]

[snip]

> 
> Philipp asked about moving forward with gnuplot.  What I could
> imagine is maybe next summer attempting an overhaul of the code with
> a recent autoconf/vcs(git or hg)/compiler(C++) and better internal
> organization. What currently exists, 5.0 series, could be a stable
> platform until the upgrade becomes stable, which might even be a
> couple years away from starting the effort.  For those who haven't
> used git or hg, I'm certain they'll be happy to be done with CVS and
> maintaining the Changelog file. Changelogs will be part of the
> "changeset", written by whomever creates the changeset (just follow
> the defined format).  It's much easier to browse through changes in
> git and hg, create changeset, etc.
> 
> It depends on how much new features we expect to add.  I can think of
> a few:
> 
> * True hidden surface code.  (I've had in mind for a while to
> generalize the hidden line segment code to hidden triangle surfaces.)
> * WXT terminal as outboard driver.
> * Arrays of plots (data retention) rather than "multiplot".
> * An interactive terminal?  That's been attempted (but not gotten
> very far) going back twenty years.  I've never been real motivated on
> this one because it doesn't fit my method of working with data.  I
> prefer to do plotting as commands, not sculpture.
> * New plot types, as always.
> * Better integration with other programs using emerging trends (say
> SQL or something).

One thing to add: clean-up/documentation of some
of the internal core data structures? For instance,
I'd like to make some minor bug fixes to the kdens
smoothing method, but could not figure out what the
various elements of "struct curvepoints" do and how
they interact (and the preprocessor macros to access
them). 

> 
> Is that enough to justify an overhaul?  Don't know.

Agreed.

Re: lua help build, autotools update

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

On 11/15/2014 05:02 AM, Hans-Bernhard Bröker wrote:

> As an aside, I propose to upgrade the entire auto-tools configuration to
> current versions (autoconf 2.69, automake 1.14).  Some of our automake
> support scripts are almost a decade out of date...  This I will only
> check in after some discussion.

If it is a minor change.  My system is about three years old with a few 
minor upgrades and has autoconf 2.66, automake 1.11.1.  The only 
reluctance would be if any tools require the builder (common user, not 
bundle maintainer) to upgrade.  Building gnuplot is pretty easy and any 
minor additional work might be a barrier for some.

Philipp asked about moving forward with gnuplot.  What I could imagine 
is maybe next summer attempting an overhaul of the code with a recent 
autoconf/vcs(git or hg)/compiler(C++) and better internal organization. 
  What currently exists, 5.0 series, could be a stable platform until 
the upgrade becomes stable, which might even be a couple years away from 
starting the effort.  For those who haven't used git or hg, I'm certain 
they'll be happy to be done with CVS and maintaining the Changelog file. 
  Changelogs will be part of the "changeset", written by whomever 
creates the changeset (just follow the defined format).  It's much 
easier to browse through changes in git and hg, create changeset, etc.

It depends on how much new features we expect to add.  I can think of a few:

* True hidden surface code.  (I've had in mind for a while to generalize 
the hidden line segment code to hidden triangle surfaces.)
* WXT terminal as outboard driver.
* Arrays of plots (data retention) rather than "multiplot".
* An interactive terminal?  That's been attempted (but not gotten very 
far) going back twenty years.  I've never been real motivated on this 
one because it doesn't fit my method of working with data.  I prefer to 
do plotting as commands, not sculpture.
* New plot types, as always.
* Better integration with other programs using emerging trends (say SQL 
or something).

Is that enough to justify an overhaul?  Don't know.

Dan

Re: wxt file-save oddity

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

On Sun, 16 Nov 2014, Daniel J Sebald wrote:

> Generally, gnuplot is not using wxWidgets event loop (because otherwise it 
> would be unable to do anything).  But then, when gnuplot exits with persist, 
> it passes event loop processing off to wxWidgets using wxTheApp->OnRun().
>
> However, that means that even though the wxWidgets objects function properly 
> (because events are handled by OnRun()) gnuplot can no longer manage events 
> or in fact do anything.  I just confirmed that is the case.  The WXT plot 
> window left behind by persist is basically frozen. Try right mouse click, or 
> scaling the window and the plot is fragmented. [...]

I don't find that to be the case at all. The wxt window left open by 
"gnuplot -persist plotfile" works fine, in general: it resizes 
correctly, responds to right-mouse as expected, and all the menu 
buttons work apart from the delay in the case of Save.

The same goes for the case where gnuplot is started interactively, a 
wxt plot is displayed, then I do "quit" at the gnuplot CLI: the wxt 
window works fine apart from Save.

Re. the file dialog I suspect there's some sort of required gvfs/gio 
initialization that is not being inherited (fully) by the child on 
fork().

Allin Cottrell

Re: wxt file-save oddity

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

On Sat, 15 Nov 2014, sfeam wrote:

> On Saturday, 15 November 2014 07:18:36 PM Daniel J Sebald wrote:
>
>>
>> When the hang happens on your system, is the their a daemon in the
>> process list or is the gnuplot process active and consuming CPU?
>
> I see the same as shown by the trace that Allin posted.
> The main process is gone, and the child process is in a
> poll() somewhere in a wxt library routine that bizarrely
> seems (from its name) to have something to do with audio.

I think that in this context "volume" refers to file systems, not 
decibels. It would make sense that opening a file-save dialog might 
trigger some sort of scan of volumes in that sense.

Allin Cottrell
>
> #0  0x00007fc0e243e30d in poll () from /lib64/libc.so.6
> #1  0x00007fc0e6715434 in g_main_context_iterate.isra.24 () from /lib64/libglib-2.0.so.0
> #2  0x00007fc0e671589a in g_main_loop_run () from /lib64/libglib-2.0.so.0
> #3  0x00007fc0e53ed2e9 in initable_init () from /lib64/libgio-2.0.so.0
> #4  0x00007fc0e537c54a in g_initable_new_valist () from /lib64/libgio-2.0.so.0
> #5  0x00007fc0e537c62c in g_initable_new () from /lib64/libgio-2.0.so.0
> #6  0x00007fc0d44e4bbd in gvfs_remote_volume_monitor_proxy_new_for_bus_sync ()
>   from /usr/lib64/gio/modules/libgioremote-volume-monitor.so
>
> 	Ethan

Re: gnuplot.info unavailable?

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

Am 16.11.2014 um 14:34 schrieb Clark Gaylord:
> On Sun, 16 Nov 2014 09:11:03 +0100, Bastian Märkisch wrote:
>>
>> I am getting a DNS error for www.gnuplot.info. Does anybody know what is
>> going on?
>
> Working now. You may need TTL to expire.
>
> Clark
>

Thanks for the quick response! Working here now, too.

   Bastian

Re: gnuplot.info unavailable?

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

On Sun, 16 Nov 2014 09:11:03 +0100, Bastian Märkisch wrote:
> 
> I am getting a DNS error for www.gnuplot.info. Does anybody know what is 
> going on?

Working now. You may need TTL to expire.

Clark

Re: gnuplot.info unavailable?

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

On Sun, 16 Nov 2014 09:11:03 +0100, Bastian Märkisch wrote:
> I am getting a DNS error for www.gnuplot.info. Does anybody know what is 
> going on?

It looks like the wildcard DNS entry is not returning correctly for www.gnuplot.info. I've added a separate A record for that name but it isn't returning yet. I fixed the AAAA record yesterday, which for some odd reason has been broken for a while.

I'll check on it after a little while and see of the updated A record has propagated.

The records for "gnuplot.info" is working, but the www record isn't. Not sure what's up with that.

Clark

Re: gnuplot.info unavailable?

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

I'll check into it.

We moved our DNS yesterday and I may have missed something.

Thanks

--
Clark Gaylord
cla...@fa...

... thumbed on Android
    auto-correct may have improved this message ...On Nov 16, 2014 2:11 AM, Bastian Märkisch <bma...@we...> wrote:
>
>
> I am getting a DNS error for www.gnuplot.info. Does anybody know what is 
> going on? 
>
>    Bastian 
>
>
>
> ------------------------------------------------------------------------------ 
> Comprehensive Server Monitoring with Site24x7. 
> Monitor 10 servers for $9/Month. 
> Get alerted through email, SMS, voice calls or mobile push notifications. 
> Take corrective actions from your mobile device. 
> http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk 
> _______________________________________________ 
> gnuplot-beta mailing list 
> gnu...@li... 
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta 

Re: wxt file-save oddity

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

On 11/16/2014 01:31 AM, Daniel J Sebald wrote:
> On 11/15/2014 10:09 PM, sfeam wrote:
>> On Saturday, 15 November 2014 08:32:38 PM Daniel J Sebald wrote:
>>
>>>   I meant "zombie", not daemon.
>>
>> I don't see a zombie. The original process really does exit.
>>
>>>   There must be some way of doing this without having to stop/restart a
>>
>>>   thread in the process.
>>
>> The problem does not depend stop/start of a thread.
>>
>> It acts the same even if gnuplot is built in single-threaded mode.
>>
>> The exit+persist procedure is to fork(), leaving a parent and a child.
>>
>> The parent calls atexit() and exits. The child is supposed
>>
>> to maintain the plot window. Both the parent and child can
>>
>> be a single thread. I don't say that this is necessarily the
>>
>> only possible procedure or the best procedure, but that's the
>>
>> way it currently works.
>
> The fork idea is OK.  (Well, so-so.  Remember there's the limitation of
> WXT not being an outboard driver.)
>
> I'm wondering about this hunk of code though:
>
> 		/* (re)start gui loop */
> 		wxTheApp->OnRun();
>
> If I'm understanding correctly, there is some sort of custom event
> handling whereby gnuplot manages input events and then shuffles them off
> to wxWidgets with the ::SendEvent( wxEvent&event) function.  I.e.,
>
> /* wrapper for AddPendingEvent or ProcessEvent */
> void wxtApp::SendEvent( wxEvent&event)
> {
> #ifdef WXT_MULTITHREADED
> 	AddPendingEvent(event);
> #else /* !WXT_MULTITHREADED */
> 	ProcessEvent(event);
> #endif /* !WXT_MULTITHREADED */
> }
>
> Generally, gnuplot is not using wxWidgets event loop (because otherwise
> it would be unable to do anything).  But then, when gnuplot exits with
> persist, it passes event loop processing off to wxWidgets using
> wxTheApp->OnRun().

OK, I was mistaken on that.  There's another ->OnRun() in the code. 
This one as part of wxtThread::Entry():

	/* gui loop */
	wxTheApp->OnRun();

	/* Workaround for a deadlock when the main thread will Wait() for this one.
	 * This issue comes from the fact that our gui main loop is not in the
	 * main thread as wxWidgets was written for. */
	wxt_MutexGuiLeave();


Maybe that's where the problem is.  The wxt_MutexGuiLeave() routine 
looks like:

void wxt_MutexGuiLeave()
{
	FPRINTF2((stderr,"unlocking gui mutex\n"));
#ifdef WXT_MULTITHREADED
	if (!wxt_handling_persist)
		wxMutexGuiLeave();
#endif /* WXT_MULTITHREADED */
}

I think the idea is that if the window is persistent and exiting, then 
do not leave go of the Mutex, i.e., GUI access from non-main-thread.

However, I've just done some fprintf's on my system to find that this 
may not happen in the right order.  The "wxt_handling_persist" variable 
is set to "true" inside wxt_atexit().  However, what I'm seeing is that

	/* gui loop */
	wxTheApp->OnRun();

inside wxtThread::Entry() [repeat the one inside wxtThread::Entry()] 
completes prior to wxt_atexit() call.  So "wxt_handling_persist" isn't 
set when OnRun() initially exits.  I'm guessing that is what the 
original intent of this variable was, otherwise it doesn't seem to have 
any purpose inside of wxt_atexit().

That does seem like it could be an issue here, i.e., the persistent WXT 
terminal window is trying to access widgets for which it doesn't have a 
lock on the GUI resources.

Dan

gnuplot.info unavailable?

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

I am getting a DNS error for www.gnuplot.info. Does anybody know what is 
going on?

   Bastian

Re: wxt file-save oddity

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

On 11/15/2014 10:09 PM, sfeam wrote:
> On Saturday, 15 November 2014 08:32:38 PM Daniel J Sebald wrote:
>
>>  I meant "zombie", not daemon.
>
> I don't see a zombie. The original process really does exit.
>
>>  There must be some way of doing this without having to stop/restart a
>
>>  thread in the process.
>
> The problem does not depend stop/start of a thread.
>
> It acts the same even if gnuplot is built in single-threaded mode.
>
> The exit+persist procedure is to fork(), leaving a parent and a child.
>
> The parent calls atexit() and exits. The child is supposed
>
> to maintain the plot window. Both the parent and child can
>
> be a single thread. I don't say that this is necessarily the
>
> only possible procedure or the best procedure, but that's the
>
> way it currently works.

The fork idea is OK.  (Well, so-so.  Remember there's the limitation of 
WXT not being an outboard driver.)

I'm wondering about this hunk of code though:

		/* (re)start gui loop */
		wxTheApp->OnRun();

If I'm understanding correctly, there is some sort of custom event 
handling whereby gnuplot manages input events and then shuffles them off 
to wxWidgets with the ::SendEvent( wxEvent &event) function.  I.e.,

/* wrapper for AddPendingEvent or ProcessEvent */
void wxtApp::SendEvent( wxEvent &event)
{
#ifdef WXT_MULTITHREADED
	AddPendingEvent(event);
#else /* !WXT_MULTITHREADED */
	ProcessEvent(event);
#endif /* !WXT_MULTITHREADED */
}

Generally, gnuplot is not using wxWidgets event loop (because otherwise 
it would be unable to do anything).  But then, when gnuplot exits with 
persist, it passes event loop processing off to wxWidgets using 
wxTheApp->OnRun().

However, that means that even though the wxWidgets objects function 
properly (because events are handled by OnRun()) gnuplot can no longer 
manage events or in fact do anything.  I just confirmed that is the 
case.  The WXT plot window left behind by persist is basically frozen. 
Try right mouse click, or scaling the window and the plot is fragmented. 
  What's more, the wxWidget events of OnRun() no longer work at that 
point either.

This wxApp->OnRun() is sort of a trick to make the WXT terminal seem 
persistent, but it isn't persistent in the sense that Qt terminal is, or 
X11 terminal is.  Gnuplot child process is still running and everything 
still available (it's just no longer at the command line).  Is there 
some way that the core gnuplot event handling can be called instead of 
calling wxApp->OnRun()?  The right way is the outboard setup, but in 
lieu of that might as well make the WXT terminal fully functional when 
persistent.

Dan

Re: wxt file-save oddity

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

This bug tracker item from Debian seems relevant:
 
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=577470

The trace there is nearly the same as we are seeing.
I don't see a true resolution to the problem in that thread.
Apparently it involved a version mismatch in gnome/dbus/gvfs
components, but all the versions mentioned are much older
than I have now.

	Ethan

Re: wxt file-save oddity

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

On Saturday, 15 November 2014 08:32:38 PM Daniel J Sebald wrote:
> I meant "zombie", not daemon.

I don't see a zombie.  The original process really does exit.

> There must be some way of doing this without having to stop/restart a 
> thread in the process.

The problem does not depend stop/start of a thread.
It acts the same even if gnuplot is built in single-threaded mode.

The exit+persist procedure is to fork(), leaving a parent and a child.
The parent calls atexit() and exits.  The child is supposed
to maintain the plot window.  Both the parent and child can
be a single thread.  I don't say that this is necessarily the
only possible procedure or the best procedure, but that's the
way it currently works.

	Ethan

Re: wxt file-save oddity

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

Here's a fun one.

I don't know what it means exactly, but it seems to  offer a hint
that suitable initialization might prevent this problem:

  ./gnuplot -persist -e 'set term wxt ; plot sinc(x) ; pause 10'

1) If you let the 10 seconds elapse so that the main thread exits,
then clicking the Export-to-File button will hang as described.

2) But if you click the button _during_ the 10 second window,
everything is fine.  That by itself is no surprise, but all
subsequent clicks on that same widget work immediately even
though the 10 seconds window is long over.  

So clicking on it once while the main thread is still active
"primes the pump". If we knew the critical piece of this,
we could maybe invoke it on program entry, or when the plot window
first appears, and that would make subsequent Export operations
in -persist mode work smoothly.

	Ethan