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

Re: (gnuplot:4180): WARNING

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

On 21/05/17 19:17, Daniel J Sebald wrote:
> On 05/20/2017 09:51 PM, Tatsuro MATSUOKA wrote:
>> Hello
>>
>> >From updated of cygwin, I sometimes meets
>>
>> ** (gnuplot:4180): WARNING **: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.a11y.Bus exited with status 1
>>
>>
>> What is this?
> 
> I searched the Internet and those who see this also attempt to guess
> what it might be.  It seems difficult to reproduce exactly.  A lot of
> the discussion seems to revolve around delays in the bus driver.  Is
> this perhaps the slow-loading font issue manifesting as a bus error with
> updated cygwin?
> 
> Dan
> 
> 

FWIW: I'm not running CVS gnuplot so I'm not seeing this error but I do 
see a lot of this kind of thing on Fedora with other software , like 
Eclipse, for example.

I don't think it is gnuplot specific.


Peter.

Re: (gnuplot:4180): WARNING

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

On 05/20/2017 09:51 PM, Tatsuro MATSUOKA wrote:
> Hello
>
>>From updated of cygwin, I sometimes meets
>
> ** (gnuplot:4180): WARNING **: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.a11y.Bus exited with status 1
>
>
> What is this?

I searched the Internet and those who see this also attempt to guess 
what it might be.  It seems difficult to reproduce exactly.  A lot of 
the discussion seems to revolve around delays in the bus driver.  Is 
this perhaps the slow-loading font issue manifesting as a bus error with 
updated cygwin?

Dan

(gnuplot:4180): WARNING

[Tatsuro M. <tma...@ya...>]

Hello

From updated of cygwin, I sometimes meets 

** (gnuplot:4180): WARNING **: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.a11y.Bus exited with status 1


What is this?

Tatsuro

Re: removal of dxf term from default build

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

On Saturday, 20 May 2017 08:22:41 AM Karl-Friedrich Ratzsch wrote:
> Hi,
> 
> last week two old legacy terminals were removed from the default
> target in the 5.1cvs tree. While corel is indeed likely not useful
> any more, I wanted to point out that Autodesk's dxf is still the
> standard 2D vector exchange format, that can be read in by every
> program in the CAD/CAM business.

Excellent.  My sneaky scheme to flush out potential maintainers
for ancient terminal types is succeeding :-) :-)

Can you confirm that at least one of the current generation of CAD
programs can import something useful from gnuplot?    

Any other gnuplot + CAD users out there?


The limit of my  ability to check functionality was to confirm that
gnuplot 5.0.6 produces essentially the same output as gnuplot version
3.7.2 from 2002.  But the dxf driver code itself is older yet.
The code in current cvs is only trivially different from the code initially
imported into "gnuplot beta" in 1998 to start the SourceForge repository.
Comments in the header push it back another 3 years at least.

So on the one hand it's great if code from 23 years is still useful,
but are there no features from decades of gnuplot development 
that would make it just a little bit more useful?

In other words, if the terminal is going to be including in the current
default build don't you think it should support current default features?

Wouldn't it be more useful if it handled (off the top of my head)
  - rectangles/circles/objects in general
  - control of linetypes, dot-dash patterns, etc

By the same token, the gnuplot source code says it adheres to the
format for Autocad Release 10 (1988) format DWGR10).
Autocad is now at release 32 and uses DWG2018 file format.
If we're going to continue to claim support for autocad output, wouldn't it be nice
to check if there are matching capabilities on both sides that have
been introduced over the last 20 years?

	Ethan

> Especially some of the freeware CAD suites just cannot construct
> lines via mathematical formulas, and it's still a hassle imo with
> e.g. Inventor.
> 
> So, unless it becomes really broken, it'd be nice to keep it at
> least in future binaries, for those who cannot easily make their own
> build. As long as you can do simple black and white line plots, it's
> still useful.
>
> Best, Karl

Re: removal of dxf term from default build

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

On 20/05/17 07:22, Karl-Friedrich Ratzsch wrote:
> Hi,
> 
> last week two old legacy terminals were removed from the default
> target in the 5.1cvs tree. While corel is indeed likely not useful
> any more, I wanted to point out that Autodesk's dxf is still the
> standard 2D vector exchange format, that can be read in by every
> program in the CAD/CAM business.
> 
> Especially some of the freeware CAD suites just cannot construct
> lines via mathematical formulas, and it's still a hassle imo with
> e.g. Inventor.
> 
> So, unless it becomes really broken, it'd be nice to keep it at
> least in future binaries, for those who cannot easily make their own
> build. As long as you can do simple black and white line plots, it's
> still useful.
> 
> Best, Karl
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Interesting, I had not thought of using gnuplot but it could potentially 
be a valid means of producing involute profiles for gear wheels.

Someone has videos showing how to do this is Blender, which gives very 
nice £d models but is a bit of an up hilll struggle.

Maybe using Gnuplot would be a better option to create the outline and 
save as DXF.  I probably never thought of this because I did not know it 
had a DXF terminal.

Thanks for pointing that out.  I would second the idea of keeping it 
since it is still very much valid in CAD/CAM context, not obsolete.

Peter.

removal of dxf term from default build

[Karl-Friedrich R. <mai...@gm...>]

Hi,

last week two old legacy terminals were removed from the default
target in the 5.1cvs tree. While corel is indeed likely not useful
any more, I wanted to point out that Autodesk's dxf is still the
standard 2D vector exchange format, that can be read in by every
program in the CAD/CAM business.

Especially some of the freeware CAD suites just cannot construct
lines via mathematical formulas, and it's still a hassle imo with
e.g. Inventor.

So, unless it becomes really broken, it'd be nice to keep it at
least in future binaries, for those who cannot easily make their own
build. As long as you can do simple black and white line plots, it's
still useful.

Best, Karl

Re: Time to think of version 5.2?

[Tatsuro M. <tma...@ya...>]

----- Original Message -----
> From: sfeam <sf...@us...>
> To: gnu...@li...
> Cc: 
> Date: 2017/5/13, Sat 13:15
> Subject: Time to think of version 5.2?
> 
> All opinions welcome!
> 
> It has been 3 years since the initial release candidate for version 5.0
> (5.0-rc1 May 2014)
> 
> I am thinking that it's about time to split off a branch of the current 
> development
> source tree that will become version 5.2.   The development tree itself will 
> then
> be renumbered from 5.1 to 5.3.
> 
> This would not by itself mean that we are ready to put out a 5.2-rc1 for 
> testing,
> but it does mean that after the split new patches applied to the
> development branch would not automatically also affect the stable branch 5.2.
> For that reason I don't want to make the split if there are a bunch of 
> patches
> likely to arrive soon or fixes that will be needed for both the stable and 
> development
> branches.
> 
> So I'm asking.
> 
> - Are there any outstanding issues that should be fixed before an initial
> testing version of 5.2?
> 
> - I know that Bastian has been gradually converting the Windows code from 
> GDI/GDI+ to a newer DirectWrite API.  Is this in a reasonable state or is there 
> more work coming that should go in before branching off 5.2?
> 
> - Are there any other arguments for or against starting a 5.2-stable branch?
> 
> Regardless of timing of a 5.2 branch I expect that there will be a release
> 5.0.7 in Sep/Oct of 2017.  
> 
> 
>     Ethan 

Great! I completely agree with your proposal.

Tatsuro

Time to think of version 5.2?

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

All opinions welcome!

It has been 3 years since the initial release candidate for version 5.0
(5.0-rc1 May 2014)

I am thinking that it's about time to split off a branch of the current development
source tree that will become version 5.2.   The development tree itself will then
be renumbered from 5.1 to 5.3.

This would not by itself mean that we are ready to put out a 5.2-rc1 for testing,
but it does mean that after the split new patches applied to the
development branch would not automatically also affect the stable branch 5.2.
For that reason I don't want to make the split if there are a bunch of patches
likely to arrive soon or fixes that will be needed for both the stable and development
branches.

So I'm asking.

- Are there any outstanding issues that should be fixed before an initial
testing version of 5.2?

- I know that Bastian has been gradually converting the Windows code from 
GDI/GDI+ to a newer DirectWrite API.  Is this in a reasonable state or is there 
more work coming that should go in before branching off 5.2?

- Are there any other arguments for or against starting a 5.2-stable branch?

Regardless of timing of a 5.2 branch I expect that there will be a release
5.0.7 in Sep/Oct of 2017.   


	Ethan 

Seeking input for gnuplot article

[lee P. <ho...@gm...>]

I'm writing an article on the new features in gnuplot 5.1 for LWN
(https://lwn.net/). I would like to include some information on
gnuplot's developer community: who works on gnuplot, why do they
do it, interesting anecdotes; that kind of thing. Also, notable features
that are planned for future releases. If you are a gnuplot developer and
would like to contribute a few sentences along these lines, with or
without attribution, please email me at le...@le....

Thanks!

Re: Turn auto-ticks on automatically for zoom mode?

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

On Friday, 14 April, 2017 12:26:34 Daniel J Sebald wrote:
> On 04/11/2017 12:00 AM, pl...@pi... wrote:
> >>  Zooming is a
> >> random thing, so there's no way the person who places the manual ticks
> >> can anticipate what adequate annotation might be.
> >
> > The zoom is random but presumably the ticks have some systematic basis.
> >
> > What is kind of situation where manual ticks are needed?  Is the
> > solution to this to be able to supply some kind of  non-auto rule for
> > tick placement?
> 
> Very general.  The application just wants to have the ticks placed 
> according to its rules, I guess.
> 
> What I meant by random is not the tick placement, but the box that the 
> user selects to zoom into.  There's no way for whomever manually places 
> the ticks to anticipate, say, more denser ticks in an area the viewer 
> might look at more closely, i.e., zooming is really something only 
> gnuplot controls.  So if the rule is to go to auto-placement in zoom 
> mode, and back to manual placement when leaving zoom mode it might be 
> just fine.

Did you try the earlier suggestion to use the "add" keyword when
specifying tics manually?    That really should do pretty much 
what you are asking for already, and if not then perhaps you can
suggest a way to improve it.


	Ethan

Re: Turn auto-ticks on automatically for zoom mode?

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

On 04/11/2017 12:00 AM, pl...@pi... wrote:
> On 10/04/17 23:25, Ethan A Merritt wrote:
>>  Zooming is a
>> random thing, so there's no way the person who places the manual ticks
>> can anticipate what adequate annotation might be.
>
> The zoom is random but presumably the ticks have some systematic basis.
>
> What is kind of situation where manual ticks are needed?  Is the
> solution to this to be able to supply some kind of  non-auto rule for
> tick placement?

Very general.  The application just wants to have the ticks placed 
according to its rules, I guess.

What I meant by random is not the tick placement, but the box that the 
user selects to zoom into.  There's no way for whomever manually places 
the ticks to anticipate, say, more denser ticks in an area the viewer 
might look at more closely, i.e., zooming is really something only 
gnuplot controls.  So if the rule is to go to auto-placement in zoom 
mode, and back to manual placement when leaving zoom mode it might be 
just fine.

Perhaps one could argue that if the user zooms in just a fraction to cut 
of some portion of the view, say, zoom 0.95 of the view, then the ticks 
might jump to something different...or maybe the programmer doesn't want 
any ticks and when zooming the ticks re-appearing might be undesired. 
Maybe there is rare cases where auto-ticks in zoom are unwanted.

Dan

Re: Turn auto-ticks on automatically for zoom mode?

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

On 04/11/2017 07:34 AM, Petr Mikulik wrote:
>>> Some observations:
>>>
>>> * I see that the "help zoom" documentation indicates "Zooming is usually
>>> accomplished by holding down the left mouse button".  For me it is the
>>> left mouse button.
>>
>> I meant to write for me it is the _right_ button.
>
> It depends on hand - for me it is most frequently the left mouse button.
> So that might be better to write "with mouse button 3" as later in the
> same text.
>
>> However, there is nothing in the documentation that suggests what or
>> where the "option" refers to...  OK, after looking around a bit, I see
>> that the options refer to "mouse".  It might be nice to mention in the
>> documentation that this refers to an option for "mouse".
>
> Would you prefer to start "help zoom" by "Zooming by mouse is usually
> accomplished by ..."?

Maybe something like adding

  See 'set mouse' for options.

at the end of the entry.  This comes about because users are allowed to 
shortcut some of the documentation entries.  Technically it should be 
"help set mouse zoom", I guess.  But "help zoom" takes one there too. 
It's analogous to an HTML-based online manual/help page with no backward 
links, i.e., How did I get here?

Another example is "help set mouse input".  Here's a case where there is 
no shortcut, i.e., no "help input", yet the documentation indicates

"
gnuplot> help mouse input
  [snip]
  See also the command `set mouse`.
"

when the "mouse" is a requisite, e.g., "help mouse input" is the 
shortest path.

Dan

Re: Turn auto-ticks on automatically for zoom mode?

[Petr M. <mi...@ph...>]

>> Some observations:
>>
>> * I see that the "help zoom" documentation indicates "Zooming is usually
>> accomplished by holding down the left mouse button".  For me it is the
>> left mouse button.
>
> I meant to write for me it is the _right_ button.

It depends on hand - for me it is most frequently the left mouse button. So 
that might be better to write "with mouse button 3" as later in the same text.

> However, there is nothing in the documentation that suggests what or where 
> the "option" refers to...  OK, after looking around a bit, I see that the 
> options refer to "mouse".  It might be nice to mention in the documentation 
> that this refers to an option for "mouse".

Would you prefer to start "help zoom" by "Zooming by mouse is usually 
accomplished by ..."?

---
PM

Re: Turn auto-ticks on automatically for zoom mode?

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

On 10/04/17 23:25, Ethan A Merritt wrote:
>  Zooming is a
> random thing, so there's no way the person who places the manual ticks
> can anticipate what adequate annotation might be.

The zoom is random but presumably the ticks have some systematic basis.

What is kind of situation where manual ticks are needed?  Is the 
solution to this to be able to supply some kind of  non-auto rule for 
tick placement?

Peter.

Re: Turn auto-ticks on automatically for zoom mode?

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

On 04/10/2017 07:00 PM, Daniel J Sebald wrote:

> Some observations:
>
> * I see that the "help zoom" documentation indicates "Zooming is usually
> accomplished by holding down the left mouse button".  For me it is the
> left mouse button.

I meant to write for me it is the _right_ button.

Dan

Re: Turn auto-ticks on automatically for zoom mode?

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

On 04/10/2017 05:25 PM, Ethan A Merritt wrote:
> On Monday, 10 April, 2017 16:39:41 Daniel J Sebald wrote:
[snip]
>> What are people's thoughts on forcing auto-ticks to "on" when going into
>> zoom mode?  I recall a discussion from many years ago about zooming done
>> in the outboard driver without the aid of gnuplot-core plotting, and one
>> of the reasons it was a no-go was because doing zooming that way didn't
>> create new tick marks and left plot symbols overly large, etc.  That's
>> pretty much the same scenario with manual tick placement.  Zooming is a
>> random thing, so there's no way the person who places the manual ticks
>> can anticipate what adequate annotation might be.
>
> I have thought about but never seriously looked at introducing the
> notion of a "zoom tic" variant.  These tics would be hidden at the
> initially specified resolution but would appear if you zoomed in
> enough (whatever "enough" might be).
> The idea was to work around the limitation you mention of zooming
> after the fact in svg/pdf/canvas/... viewers.

The zoom tics would disappear after pressing "u" to go back to full 
range, correct?

The good thing is that the mouse coordinates and ruler are always there 
as a fall-back of sorts.  With that, one can measure the start and stop 
of some points of interest.  Of course, the zoom box also displays 
coordinates so that too can be used in a roundabout way to get dimensions.

Some observations:

* I see that the "help zoom" documentation indicates "Zooming is usually 
accomplished by holding down the left mouse button".  For me it is the 
left mouse button.  I know it can change depending on system, but which 
is the most likely to be the case?

* Also, "help zoom" indicates "The option `zoomcoordinates` determines 
if the coordinates of the zoom box are
  drawn at the edges while zooming. This is on by default. If the option 
`zoomjump` is on"  However, there is nothing in the documentation that 
suggests what or where the "option" refers to...  OK, after looking 
around a bit, I see that the options refer to "mouse".  It might be nice 
to mention in the documentation that this refers to an option for "mouse".

Dan

Re: Turn auto-ticks on automatically for zoom mode?

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

On Monday, 10 April, 2017 16:39:41 Daniel J Sebald wrote:
> I'm working with an application right now that manually places tick 
> marks for axes.  When a plot with manual tics is zoomed, typically the x 
> and y axes don't have any tick marks on screen because the manually 
> placed tics are outside the view.  Or maybe it is just one tick visible, 
> but one tick really isn't helpful for judging dimension.

One option is to use the "add" keyword with manually placed tics.
That way they supplement rather than replacing the auto-generated tics.
Well, unless the manually added tic is at the same coordinate as an
auto-generated tics - then it does replace it.
 
> What are people's thoughts on forcing auto-ticks to "on" when going into 
> zoom mode?  I recall a discussion from many years ago about zooming done 
> in the outboard driver without the aid of gnuplot-core plotting, and one 
> of the reasons it was a no-go was because doing zooming that way didn't 
> create new tick marks and left plot symbols overly large, etc.  That's 
> pretty much the same scenario with manual tick placement.  Zooming is a 
> random thing, so there's no way the person who places the manual ticks 
> can anticipate what adequate annotation might be.

I have thought about but never seriously looked at introducing the
notion of a "zoom tic" variant.  These tics would be hidden at the
initially specified resolution but would appear if you zoomed in
enough (whatever "enough" might be).
The idea was to work around the limitation you mention of zooming
after the fact in svg/pdf/canvas/... viewers.

	Ethan

Turn auto-ticks on automatically for zoom mode?

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

I'm working with an application right now that manually places tick 
marks for axes.  When a plot with manual tics is zoomed, typically the x 
and y axes don't have any tick marks on screen because the manually 
placed tics are outside the view.  Or maybe it is just one tick visible, 
but one tick really isn't helpful for judging dimension.

What are people's thoughts on forcing auto-ticks to "on" when going into 
zoom mode?  I recall a discussion from many years ago about zooming done 
in the outboard driver without the aid of gnuplot-core plotting, and one 
of the reasons it was a no-go was because doing zooming that way didn't 
create new tick marks and left plot symbols overly large, etc.  That's 
pretty much the same scenario with manual tick placement.  Zooming is a 
random thing, so there's no way the person who places the manual ticks 
can anticipate what adequate annotation might be.

Dan

Re: encoding question

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

On 02/04/17 04:41, sfeam wrote:
> On Saturday, 25 March 2017 07:42:32 PM Allin Cottrell wrote:
>> On Fri, 24 Mar 2017, Allin Cottrell wrote:
>>
>>> On Fri, 24 Mar 2017, Ethan A Merritt wrote:
>>>
>>>> On Friday, 24 March, 2017 14:57:11 Allin Cottrell wrote:
>>>>>
>>>>> I ran an experiment to try to assess this. Booted Windows 8 (ugh) and
>>>>> created a directory named Beauté (that's with an e-acute) on my
>>>>> Desktop. I then created two copies of a simple gnuplot script to
>>>>> produce a PNG file. Each included the line
>>>>>
>>>>> set output 'c:/users/cottrell/desktop/Beauté/test.png'
>>>>>
>>>>> (encoded in cp1251). The two files were identical except that one of
>>>>> them included the line
>>>>>
>>>>> set encoding utf8
>>>>>
>>>>> before the "set output" line. (And the accented character in the
>>>>> output filename was the only non-ASCII character in the files.)
>>>>>
>>>>> I then called wgnuplot.exe on the two scripts from the command line in
>>>>> a cmd.exe window. The one without "set encoding utf8" worked to
>>>>> produce the PNG, the other didn't. To see what was happening I then
>>>>> tried opening wgnuplot interactively and using the "load" command to
>>>>> run the scripts. The variant without "set encoding" again worked fine;
>>>>> the other one gave:
>>>>>
>>>>> set output 'c:/users/cottrell/desktop/Beaut?/test.png'
>>>>>   cannot open file; output not changed
>>>>>
>>>>> (note that in gnuplot's error message echoing the "set output" line
>>>>> the e-acute has been changed to a question mark, actually not an
>>>>> ASCII question mark but an "unrecognized glyph" symbol).
>>>>>
>>>>> It therefore seems that "set encoding" has somehow altered gnuplot's
>>>>> reading of the bytes in the output filename.
>>>>
>>>> No, I don't think that is what is happening.
>>>>
>>>>> (Once again, those bytes
>>>>> are identical in the two files.) If gnuplot had simply passed the
>>>>> incoming cp1251 bytes to the OS, surely the output file would have
>>>>> been opened OK in both cases.
>>>>
>>>> What seems to be happening is that in syscfg.h on Windows it says
>>>> /* The unicode/encoding support requires translation of file names */
>>>>    #define fopen win_fopen
>>>>
>>>> and wmain.c:win_fopen() indeed tries to translate the name from the
>>>> current gnuplot encoding into Windows Unicode text.
>>>> I think the comment is wrong. File names should *not* be translated,
>>>> as you are finding out.  The current gnuplot encoding is a separate
>>>> thing from the encoding used in the sourcecode of the script.
>>>>
>>>> I only see this code in the development version, not in the source
>>>> for 5.0.5 or 5.0.6.  So I guess your bug report is specifically for
>>>> the development version?
>>>>
>>>> I'll defer to the Windows crowd here, but my tentative diagnosis
>>>> is that addition of a win_fopen() wrapper for fopen() in 5.1 should
>>>> be reverted.
>>>
>>> Aha, this is very interesting! Yes, I'm using the development
>>> version on Windows so your diagnosis seems very plausible. But
>>> actually, now I (think) I understand what's going on, I _like_ the
>>> idea behind win_fopen.
>>>
>>> If I've got this right, it would let me standardize on
>>> consistently UTF-8 gnuplot script files (including representing
>>> Windows paths in UTF-8), and let gnuplot take care of recoding
>>> paths on the fly as needed for interaction with the OS.
>>>
>>> It's ugly and error-prone to mix text encodings in a single file,
>>> but I guess that's what you have to do with gnuplot 5.0 if you
>>> want (a) to represent titles, labels and so on in UTF-8, but (b)
>>> to include Windows filenames that contain non-ASCII characters. It
>>> sounds like gnuplot 5.1 could improve on that. I can now try the
>>> experiment of keeping "set encoding utf8" but recoding Windows
>>> paths to UTF-8 when writing them into a gnuplot script. If that
>>> works, I'm happy!
>>
>> The experiment was successful. I could create a clean UTF-8 encoded
>> gnuplot script (including a non-ASCII Windows path for "set
>> output"), and gnuplot's win_fopen handled interaction with the OS
>> correctly in the background. So I would definitely be in favor of
>> keeping win_fopen.
>>
>> (Reminder for anyone trying to follow this: win_fopen is a special
>> facility in the development version of gnuplot. It has the effect of
>> recoding filenames in a gnuplot script from whatever is set via "set
>> encoding" to Windows-compatible 16-bit Unicode before they are
>> passed to the C-library function fopen().)
>>
>> Allin Cottrell
>
> Can you suggest where in the documentation we could add this information?
> Putting it under "encoding" will not help unless the poor user who hits it
> has already diagnosed it as an encoding problem.
> Where did you look when you first hit the original problem?
>
>    Ethan
>

If there are cross-platform issues, then maybe the doc should contain a 
section on that, at least as a central point linking to more specific 
information on individual issues.

Also "encoding" is a rather programmer's or solution derived perspective 
not a user's perspective. The user probably does not think he is 
"encoding" anything.

 From the user's point of view it is probably do with accented vowels, 
natural language or non-English language filenames, labels or whatever.

I have commented on a few such cases in the past where the info is there 
but you need to know the answer in order to find it because it is not 
linked to anything related to the user's problem.


Gnuplot makes platform abstraction fairly transparent but there always 
seems to be a few things which are not completely OS  agnostic.

Peter.

Re: encoding question

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

On Saturday, 25 March 2017 07:42:32 PM Allin Cottrell wrote:
> On Fri, 24 Mar 2017, Allin Cottrell wrote:
> 
> > On Fri, 24 Mar 2017, Ethan A Merritt wrote:
> >
> >> On Friday, 24 March, 2017 14:57:11 Allin Cottrell wrote:
> >>> 
> >>> I ran an experiment to try to assess this. Booted Windows 8 (ugh) and
> >>> created a directory named Beauté (that's with an e-acute) on my
> >>> Desktop. I then created two copies of a simple gnuplot script to
> >>> produce a PNG file. Each included the line
> >>> 
> >>> set output 'c:/users/cottrell/desktop/Beauté/test.png'
> >>> 
> >>> (encoded in cp1251). The two files were identical except that one of
> >>> them included the line
> >>> 
> >>> set encoding utf8
> >>> 
> >>> before the "set output" line. (And the accented character in the
> >>> output filename was the only non-ASCII character in the files.)
> >>> 
> >>> I then called wgnuplot.exe on the two scripts from the command line in
> >>> a cmd.exe window. The one without "set encoding utf8" worked to
> >>> produce the PNG, the other didn't. To see what was happening I then
> >>> tried opening wgnuplot interactively and using the "load" command to
> >>> run the scripts. The variant without "set encoding" again worked fine;
> >>> the other one gave:
> >>> 
> >>> set output 'c:/users/cottrell/desktop/Beaut?/test.png'
> >>>   cannot open file; output not changed
> >>> 
> >>> (note that in gnuplot's error message echoing the "set output" line
> >>> the e-acute has been changed to a question mark, actually not an
> >>> ASCII question mark but an "unrecognized glyph" symbol).
> >>> 
> >>> It therefore seems that "set encoding" has somehow altered gnuplot's
> >>> reading of the bytes in the output filename.
> >> 
> >> No, I don't think that is what is happening.
> >> 
> >>> (Once again, those bytes
> >>> are identical in the two files.) If gnuplot had simply passed the
> >>> incoming cp1251 bytes to the OS, surely the output file would have
> >>> been opened OK in both cases.
> >> 
> >> What seems to be happening is that in syscfg.h on Windows it says
> >> /* The unicode/encoding support requires translation of file names */
> >>    #define fopen win_fopen
> >> 
> >> and wmain.c:win_fopen() indeed tries to translate the name from the
> >> current gnuplot encoding into Windows Unicode text.
> >> I think the comment is wrong. File names should *not* be translated,
> >> as you are finding out.  The current gnuplot encoding is a separate
> >> thing from the encoding used in the sourcecode of the script.
> >> 
> >> I only see this code in the development version, not in the source
> >> for 5.0.5 or 5.0.6.  So I guess your bug report is specifically for
> >> the development version?
> >> 
> >> I'll defer to the Windows crowd here, but my tentative diagnosis
> >> is that addition of a win_fopen() wrapper for fopen() in 5.1 should
> >> be reverted.
> >
> > Aha, this is very interesting! Yes, I'm using the development 
> > version on Windows so your diagnosis seems very plausible. But 
> > actually, now I (think) I understand what's going on, I _like_ the 
> > idea behind win_fopen.
> >
> > If I've got this right, it would let me standardize on 
> > consistently UTF-8 gnuplot script files (including representing 
> > Windows paths in UTF-8), and let gnuplot take care of recoding 
> > paths on the fly as needed for interaction with the OS.
> >
> > It's ugly and error-prone to mix text encodings in a single file, 
> > but I guess that's what you have to do with gnuplot 5.0 if you 
> > want (a) to represent titles, labels and so on in UTF-8, but (b) 
> > to include Windows filenames that contain non-ASCII characters. It 
> > sounds like gnuplot 5.1 could improve on that. I can now try the 
> > experiment of keeping "set encoding utf8" but recoding Windows 
> > paths to UTF-8 when writing them into a gnuplot script. If that 
> > works, I'm happy!
> 
> The experiment was successful. I could create a clean UTF-8 encoded 
> gnuplot script (including a non-ASCII Windows path for "set 
> output"), and gnuplot's win_fopen handled interaction with the OS 
> correctly in the background. So I would definitely be in favor of 
> keeping win_fopen.
> 
> (Reminder for anyone trying to follow this: win_fopen is a special 
> facility in the development version of gnuplot. It has the effect of 
> recoding filenames in a gnuplot script from whatever is set via "set 
> encoding" to Windows-compatible 16-bit Unicode before they are 
> passed to the C-library function fopen().)
> 
> Allin Cottrell

Can you suggest where in the documentation we could add this information?
Putting it under "encoding" will not help unless the poor user who hits it
has already diagnosed it as an encoding problem.
Where did you look when you first hit the original problem?

   Ethan

Re: A dozen unused return value warnings

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

Does anyone have a better understanding of this comment for do_system()?

/* (am, 19980929)
  * OS/2 related note: cmd.exe returns 255 if called w/o argument.
  * i.e. calling a shell by "!" will always end with an error message.
  * A workaround has to include checking for EMX,OS/2, two environment
  *  variables,...
  */

What are the environment variables?  OS/2 isn't an environment variable. 
  There is an OS2 pre-compile flag, e.g.,:

#  elif defined(OS2)

so don't we already know if this is OS2 and can adjust accordingly?

Note, when changing do_system() to int, I'm going to drop

     if (!cmd)
	return 0;

because both system() and _wsystem() accept NULL commands in a 
meaningful way.  It's a query for which a return value of 0 means no 
command-processor available and not-0 means command-processor is 
available.  If cmd is non-NULL, then it is the usual 0 means success, 
non-zero means error code.

Dan

Re: A dozen unused return value warnings

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

On 03/30/2017 08:02 AM, Hans-Bernhard Bröker wrote:
> Am 29.03.2017 um 21:01 schrieb Daniel J Sebald:
>> On my system, configuration results in the unused return variable flag
>> being set.  Attached is a diff file with code changes to get rid of
>> those warnings.
>
> Doing the change like that is just wrong:
>
>> -    freopen("/dev/null","w",stdout);
>> -    freopen("/dev/null","w",stderr);
>> +    if (freopen("/dev/null","w",stdout));
>> +    if (freopen("/dev/null","w",stderr));
>
> The usual, widely accepted way of doing that is to cast an unused return
> value to (void), i.e.:
>
>    (void)freopen("/dev/null","w",stdout);
>    (void)freopen("/dev/null","w",stderr);

That was my initial thought, but I had read on a couple discussion lists 
that void-cast doesn't work for some compilers any more.


>> Should the above really be included in Qt?  I don't think that Qt C++
>> files need to use FPRINTF() any more for debugging.
>
> That doesn't help with debugging non-QT, non-C++ files in gnuplot at
> all, though.
>
>> Qt has it's own
>> messaging system:
>
> That's nice to know, but doesn't help us much, because we still want to
> be able to work _without_ any Qt involved, too.

The Qt terminal is a separate compilation and process.  I tried Ethan's 
idea of simply closing stderr and stdout rather than reopening.  (fclose 
doesn't return anything, so no warning.)  I can't see any difference in 
behavior of persist mode.  I see a comment online about someone trying 
to redirect std::cerr and std::cout, so I would guess they are separate 
entities:

http://qtforum.org/article/678/redirecting-cout-cerr-to-qdebug.html

Dan

Re: A dozen unused return value warnings

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

Am 29.03.2017 um 21:01 schrieb Daniel J Sebald:
> On my system, configuration results in the unused return variable flag
> being set.  Attached is a diff file with code changes to get rid of
> those warnings.

Doing the change like that is just wrong:

> -    freopen("/dev/null","w",stdout);
> -    freopen("/dev/null","w",stderr);
> +    if (freopen("/dev/null","w",stdout));
> +    if (freopen("/dev/null","w",stderr));

The usual, widely accepted way of doing that is to cast an unused return 
value to (void), i.e.:

    (void)freopen("/dev/null","w",stdout);
    (void)freopen("/dev/null","w",stderr);

> Should the above really be included in Qt?  I don't think that Qt C++
> files need to use FPRINTF() any more for debugging.

That doesn't help with debugging non-QT, non-C++ files in gnuplot at 
all, though.

> Qt has it's own
> messaging system:

That's nice to know, but doesn't help us much, because we still want to 
be able to work _without_ any Qt involved, too.

A dozen unused return value warnings

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

On my system, configuration results in the unused return variable flag 
being set.  Attached is a diff file with code changes to get rid of 
those warnings.

One in particular I have a question about:

diff -u -r1.6 QtGnuplotApplication.cpp
--- src/qtterminal/QtGnuplotApplication.cpp	29 Jan 2014 15:48:51 -0000	1.6
+++ src/qtterminal/QtGnuplotApplication.cpp	29 Mar 2017 18:47:43 -0000
@@ -80,8 +80,8 @@
  	// Some programs executing gnuplot -persist may be waiting for all 
default
  	// handles to be closed before they consider the sub-process finished.
  	// Using freopen() ensures that debug fprintf()s won't crash.
-	freopen("/dev/null","w",stdout);
-	freopen("/dev/null","w",stderr);
+	if (freopen("/dev/null","w",stdout));
+	if (freopen("/dev/null","w",stderr));
  }

Should the above really be included in Qt?  I don't think that Qt C++ 
files need to use FPRINTF() any more for debugging.  Qt has it's own 
messaging system:

http://doc.qt.io/qt-4.8/debug.html

qDebug(), qWarning(), qCritical(), qFatal().

Dan

CVS build issue

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

Cross-building current CVS gnuplot with mingw-w64 (gcc-5.4.0) I'm 
getting an error from wgdiplus.cpp, namely that swprintf_s is 
undefined.

I notice that on lines 42-45 there's a mechanism to handle this for 
the Watcom compiler:

#ifdef __WATCOMC__
// swprintf_s is missing from <cwchar>
# define swprintf_s(s, c, f, ...) swprintf(s, c, f, __VA_ARGS__)
#endif

so I would suggest this might be extended:

#if defined(__WATCOMC__) || defined(__MINGW64__)
// swprintf_s is missing from <cwchar>
# define swprintf_s(s, c, f, ...) swprintf(s, c, f, __VA_ARGS__)
#endif

(though maybe there's a more robust fix).

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