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

Re: replotting in-line data and autoscaling

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

On Friday, 27 April 2018 13:18:50 Dima Kogan wrote:
> Ethan A Merritt <sf...@us...> writes:
> 
> >> Yeah. I think the auto-writeback logic proposed earlier is the more
> >> complete way to do this.
> 
> A crude prototype patch is attached. It unconditionally saves the
> writeback before each plot, and unconditionally restores it before each
> refresh (not replot). Works for the test case here. With a bit of
> extending, I'd like to see something like this be included.

Looks promising!

I have applied your patch, lightly edited, to the development version
and removed the code it replaces.  The change fixes a problem with
"refresh" in 3D plots that I was not aware of.

I'd like to see this change tested in the development version for
one cycle before applying it to the stable series, because it does
change the use of the axis writeback flag and so has in theory a
potential to break existing scripts that use "set xrange nowriteback".
That was always a very obscure option so there may well not be any
such scripts.

While testing I managed to trigger a bad state after an "unzoom"
operation of a plot with logscale axes.  But then I couldn't 
reproduce it so I can't say for sure that it was really the new
code at fault.  It's hard to automate testing of zoom/unzoom
and window redraw operations.

If no one complains about the changed status of the writeback flag
there is one further step of simplification possible by setting that
flag in the default axis structures for x/y/etc rather than 
setting it all over again in every plot and splot command.

	Ethan 

Re: pre-release testing version of gnuplot 5.2.3

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

I have uploaded 5.2.3 testing windows binary packages.

Tatsuro



----- Original Message -----
> From: Tatsuro MATSUOKA <tma...@ya...>
> To: Merritt Ethan <sf...@us...>; gnu...@li...
> Cc: 
> Date: 2018/4/28, Sat 10:52
> Subject: Re: pre-release testing version of gnuplot 5.2.3
> 
> Now I am compiling on windows.
> After fishing I will upload windows binary packages on the testing directory.
> 
> Tatsuro
> 
> 
> 
> ----- Original Message -----
>>  From: sfeam via gnuplot-beta <gnu...@li...>
>>  To: gnu...@li...
>>  Cc: 
>>  Date: 2018/4/27, Fri 10:31
>>  Subject: pre-release testing version of gnuplot 5.2.3
>> 
>>  I have uploaded a 5.2.3 tarball to the "testing" section of the
>>  gnuplot files folder on SourceForge.
>>    
>>      https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/
>>      gnuplot-5.2.3-testing.tar.gz
>> 
>> 
>>  So far as I know there is nothing unusual about this patchlevel
>>  release.  It is the usual mix of bugfixes and a few features 
>>  back-ported from the development version.  However it is the first
>>  release tarball prepared from a git branch rather than from our
>>  old cvs repository.  That shouldn't make any difference but I
>>  suppose it is possible that something comes out a little different.
>> 
>>  Please use the testing tarball to confirm a successful build or
>>  report build errors.  If no problems are found I expect to make a
>>  regular release of 5.2.3 next week.
>> 
>>      Ethan
>> 
>> 
> ------------------------------------------------------------------------------
>>  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
>> 
> 
> ------------------------------------------------------------------------------
> 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
> 

Re: pre-release testing version of gnuplot 5.2.3

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

Now I am compiling on windows.
After fishing I will upload windows binary packages on the testing directory.

Tatsuro



----- Original Message -----
> From: sfeam via gnuplot-beta <gnu...@li...>
> To: gnu...@li...
> Cc: 
> Date: 2018/4/27, Fri 10:31
> Subject: pre-release testing version of gnuplot 5.2.3
> 
> I have uploaded a 5.2.3 tarball to the "testing" section of the
> gnuplot files folder on SourceForge.
>   
>     https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/
>     gnuplot-5.2.3-testing.tar.gz
> 
> 
> So far as I know there is nothing unusual about this patchlevel
> release.  It is the usual mix of bugfixes and a few features 
> back-ported from the development version.  However it is the first
> release tarball prepared from a git branch rather than from our
> old cvs repository.  That shouldn't make any difference but I
> suppose it is possible that something comes out a little different.
> 
> Please use the testing tarball to confirm a successful build or
> report build errors.  If no problems are found I expect to make a
> regular release of 5.2.3 next week.
> 
>     Ethan
> 
> ------------------------------------------------------------------------------
> 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
> 

Re: replotting in-line data and autoscaling

[Dima K. <gn...@di...>]

Ethan A Merritt <sf...@us...> writes:

>> Yeah. I think the auto-writeback logic proposed earlier is the more
>> complete way to do this.

A crude prototype patch is attached. It unconditionally saves the
writeback before each plot, and unconditionally restores it before each
refresh (not replot). Works for the test case here. With a bit of
extending, I'd like to see something like this be included.

Re: replotting in-line data and autoscaling

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

On Friday, April 27, 2018 11:21:29 AM PDT Dima Kogan wrote:
> Ethan A Merritt <sf...@us...> writes:
> 
> > The stupid error I found was in code that only dealt with the x axis
> > of the current plot (so either x or x2).
> 
> Hmmm. I see a very outwardly-similar problem if I "set logscale y"
> instead of "set logscale x" in that test script. Do you see it too?

Yes I see it too.
But there is no y axis fixup code analogous to the x axis fixup code,
So there is not an analogous stupid error that I can fix with one line of code.

	Ethan

> >> I can imagine that x2 and y2 axes are affected and maybe 3d axes. And
> >> maybe other stuff. Handling x,y,x2,y2 should hit most of the use cases,
> >> probably.
> >
> > A higher-level fix is required so that all axes are correctly re-evaluated
> > on refresh.  The difficulty comes from trying to handle both pure
> > "replot/refresh" requests and zoom operations.
> 
> Yeah. I think the auto-writeback logic proposed earlier is the more
> complete way to do this.

Re: replotting in-line data and autoscaling

[Dima K. <gn...@di...>]

Ethan A Merritt <sf...@us...> writes:

> The stupid error I found was in code that only dealt with the x axis
> of the current plot (so either x or x2).

Hmmm. I see a very outwardly-similar problem if I "set logscale y"
instead of "set logscale x" in that test script. Do you see it too?


>> I can imagine that x2 and y2 axes are affected and maybe 3d axes. And
>> maybe other stuff. Handling x,y,x2,y2 should hit most of the use cases,
>> probably.
>
> A higher-level fix is required so that all axes are correctly re-evaluated
> on refresh.  The difficulty comes from trying to handle both pure
> "replot/refresh" requests and zoom operations.

Yeah. I think the auto-writeback logic proposed earlier is the more
complete way to do this.

Thanks
dima

Re: replotting in-line data and autoscaling

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

On Thursday, April 26, 2018 11:50:25 PM PDT Dima Kogan wrote:
> sfeam <sf...@us...> writes:
> 
> > Heh.  And indeed I found a stupid error that failed to check for
> > logscaling at one point during the "refresh" command that is substituted
> > for "replot" for inline data.  I make no guarantee that it fixes
> > everything but it does work on your test script.
> >
> > The larger routine that this error is embedded in all looks suspect
> > to me, but changing the whole thing is more than I'm going to tackle
> > right now.
> >
> > Can you test the stupid-error fix using git tip for the development
> > version? I'll run some additional tests here also. If nothing bad
> > turns up I'll make a decision about including it in 5.2.3 also.
> 
> Thanks for doing this so quickly. I just tested it, and it indeed makes
> the test script work. Your commit to fix that problem only touches the x
> axis. I changed the test script to "set logscale y" instead of x to see
> if that's also broken, and indeed it is. Can you do whatever you did
> with the x axis to the y axis?

The stupid error I found was in code that only dealt with the x axis
of the current plot (so either x or x2).

> I can imagine that x2 and y2 axes are affected and maybe 3d axes. And
> maybe other stuff. Handling x,y,x2,y2 should hit most of the use cases,
> probably.

A higher-level fix is required so that all axes are correctly re-evaluated
on refresh.  The difficulty comes from trying to handle both pure
"replot/refresh" requests and zoom operations.  

	Ethan

Re: replotting in-line data and autoscaling

[Dima K. <gn...@di...>]

sfeam <sf...@us...> writes:

> Heh.  And indeed I found a stupid error that failed to check for
> logscaling at one point during the "refresh" command that is substituted
> for "replot" for inline data.  I make no guarantee that it fixes
> everything but it does work on your test script.
>
> The larger routine that this error is embedded in all looks suspect
> to me, but changing the whole thing is more than I'm going to tackle
> right now.
>
> Can you test the stupid-error fix using git tip for the development
> version? I'll run some additional tests here also. If nothing bad
> turns up I'll make a decision about including it in 5.2.3 also.

Thanks for doing this so quickly. I just tested it, and it indeed makes
the test script work. Your commit to fix that problem only touches the x
axis. I changed the test script to "set logscale y" instead of x to see
if that's also broken, and indeed it is. Can you do whatever you did
with the x axis to the y axis?

I can imagine that x2 and y2 axes are affected and maybe 3d axes. And
maybe other stuff. Handling x,y,x2,y2 should hit most of the use cases,
probably.

Thanks again

Re: replotting in-line data and autoscaling

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

On Thursday, 26 April 2018 22:39:38 Dima Kogan wrote:
> 
> sfeam <sf...@us...> writes:
> 
> > I have a strong aversion to complicated last-minute changes before a
> > release. If there's some stupid error in the logic because of log
> > scaling that might have a trivial fix. But re-doing the way autoscale
> > + replot works sounds like a major change that I'd want to have tested
> > in the development version for a while before it went into a minor
> > level release.
> 
> OK. Yes. Let's then talk about it separated from this release.

Heh.  And indeed I found a stupid error that failed to check for
logscaling at one point during the "refresh" command that is substituted
for "replot" for inline data.  I make no guarantee that it fixes
everything but it does work on your test script. 

The larger routine that this error is embedded in all looks suspect
to me, but changing the whole thing is more than I'm going to tackle
right now.

Can you test the stupid-error fix using git tip for the development version?
I'll run some additional tests here also.  If nothing bad turns up I'll make
a decision about including it in 5.2.3 also.

	Ethan


> 
> 
> > I agree this is undesirable, but I don't see an immediate fix.
> > There are at least a couple of work-arounds however
> >
> > 1) Don't replot in-line data.  That didn't use to be possible at
> >    all and as you have found the change to allow it was imperfect.
> >    Put the data in a datablock instead.
> >
> > 2) Use writeback/restore:
> > 	set xrange [*:*] writeback
> > 	plot '-'
> > 	...
> > 	set xrange restore
> > 	replot
> 
> Neither of these work for me. 99% of my (quite heavy) gnuplot usage is
> via this frontend: https://github.com/dkogan/feedgnuplot
> 
> It'd be great if we supported this sort of interface natively, but
> that's a separate (and bigger) conversation. Inline data is a core
> assumption of this tool. And since the window manager is doing the
> replotting, I'm not explicitly sending the "replot" command, so I can't
> explicitly ask gnuplot to save/restore the writeback.
> 
> The earlier discussion was this:
> 
>   https://sourceforge.net/p/gnuplot/bugs/1947/
> 
> The suggestion was:
> 
>   when plotting:
>     if( we have only inline data)
>     {
>       save writeback
>     }
> 
>   when replotting:
>     if( we have only inline data &&
>         current plot ranges are those
>         computed from the autoranging )
>     {
>       restore writeback
>     }
> 
> This assumes the data doesn't change for the replot, which is true in
> the case of inline data. This actually makes replotting inline data is
> easier than data in a file.
> 
> Do you see downsides here?
> 
> Thanks.
> 
> ------------------------------------------------------------------------------
> 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

Re: replotting in-line data and autoscaling

[Dima K. <gn...@di...>]

sfeam <sf...@us...> writes:

> I have a strong aversion to complicated last-minute changes before a
> release. If there's some stupid error in the logic because of log
> scaling that might have a trivial fix. But re-doing the way autoscale
> + replot works sounds like a major change that I'd want to have tested
> in the development version for a while before it went into a minor
> level release.

OK. Yes. Let's then talk about it separated from this release.


> I agree this is undesirable, but I don't see an immediate fix.
> There are at least a couple of work-arounds however
>
> 1) Don't replot in-line data.  That didn't use to be possible at
>    all and as you have found the change to allow it was imperfect.
>    Put the data in a datablock instead.
>
> 2) Use writeback/restore:
> 	set xrange [*:*] writeback
> 	plot '-'
> 	...
> 	set xrange restore
> 	replot

Neither of these work for me. 99% of my (quite heavy) gnuplot usage is
via this frontend: https://github.com/dkogan/feedgnuplot

It'd be great if we supported this sort of interface natively, but
that's a separate (and bigger) conversation. Inline data is a core
assumption of this tool. And since the window manager is doing the
replotting, I'm not explicitly sending the "replot" command, so I can't
explicitly ask gnuplot to save/restore the writeback.

The earlier discussion was this:

  https://sourceforge.net/p/gnuplot/bugs/1947/

The suggestion was:

  when plotting:
    if( we have only inline data)
    {
      save writeback
    }

  when replotting:
    if( we have only inline data &&
        current plot ranges are those
        computed from the autoranging )
    {
      restore writeback
    }

This assumes the data doesn't change for the replot, which is true in
the case of inline data. This actually makes replotting inline data is
easier than data in a file.

Do you see downsides here?

Thanks.

Re: pre-release testing version of gnuplot 5.2.3

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

On Thursday, 26 April 2018 21:02:12 Dima Kogan wrote:
> sfeam via gnuplot-beta <gnu...@li...> writes:
> 
> > I have uploaded a 5.2.3 tarball to the "testing" section of the
> > gnuplot files folder on SourceForge.
> 
> I found a bug earlier that I haven't yet got around to reporting or
> trying to fix. Just confirmed that it's still an issue with this new
> build. Would you mind taking a look before this release becomes
> official?
> 
> The bug: autoscaling of plots with any logscale axes doesn't work on a
> replot. For instance, the attached script produces reasonable
> autoscaling initially, but after a "replot", it is broken. This is
> significant because everyone using a tiling window manager ends up
> replotting at least once before looking at any plot.

I agree this is undesirable, but I don't see an immediate fix.
There are at least a couple of work-arounds however

1) Don't replot in-line data.  That didn't use to be possible at
   all and as you have found the change to allow it was imperfect.
   Put the data in a datablock instead.

2) Use writeback/restore:
	set xrange [*:*] writeback
	plot '-'
	... 
	set xrange restore
	replot
 
> I vaguely recall a discussion at some point in the past where we talked
> about the "replot" command just recalling the axis extents from the
> initial plot command if it is sure the data hasn't changed (which is
> true for inline data, such as here). Should we do that?

I vaguely recall that also but I don't remember the details.

I'll look into it. However I have a strong aversion to complicated
last-minute changes before a release.  If there's some stupid
error in the logic because of log scaling that might have a 
trivial fix.  But re-doing the way autoscale + replot works sounds
like a major change that I'd want to have tested in the development
version for a while before it went into a minor level release.

	cheers,

		Ethan 

Re: pre-release testing version of gnuplot 5.2.3

[Dima K. <gn...@di...>]

sfeam via gnuplot-beta <gnu...@li...> writes:

> I have uploaded a 5.2.3 tarball to the "testing" section of the
> gnuplot files folder on SourceForge.

I found a bug earlier that I haven't yet got around to reporting or
trying to fix. Just confirmed that it's still an issue with this new
build. Would you mind taking a look before this release becomes
official?

The bug: autoscaling of plots with any logscale axes doesn't work on a
replot. For instance, the attached script produces reasonable
autoscaling initially, but after a "replot", it is broken. This is
significant because everyone using a tiling window manager ends up
replotting at least once before looking at any plot.

I vaguely recall a discussion at some point in the past where we talked
about the "replot" command just recalling the axis extents from the
initial plot command if it is sure the data hasn't changed (which is
true for inline data, such as here). Should we do that?

Thanks.

pre-release testing version of gnuplot 5.2.3

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

I have uploaded a 5.2.3 tarball to the "testing" section of the
gnuplot files folder on SourceForge.
   
    https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/
    gnuplot-5.2.3-testing.tar.gz


So far as I know there is nothing unusual about this patchlevel
release.  It is the usual mix of bugfixes and a few features 
back-ported from the development version.  However it is the first
release tarball prepared from a git branch rather than from our
old cvs repository.  That shouldn't make any difference but I
suppose it is possible that something comes out a little different.

Please use the testing tarball to confirm a successful build or
report build errors.  If no problems are found I expect to make a
regular release of 5.2.3 next week.

	Ethan

Re: Windows (native and Cygwin) build fail in internal.c

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

----- Original Message -----
> From: Hans-Bernhard Bröker 
> To: gnuplot-beta
> Cc: 
> Date: 2018/4/21, Sat 06:55
> Subject: Re: Windows (native and Cygwin) build fail in internal.c
> 
> Am 20.04.2018 um 02:48 schrieb Ethan A Merritt:
>>  As I understand it, the C99 standard requires that  __PRI64_PREFIX
>>  is defined in the file <inttypes.h>.
> 
> No, it doesn't require that. It requires macros PRId64 and friends to exist, 
> iff the compiler claims C99 conformance and has an int64_t.  But that's 
> about it.
> 
> The __PRI64_PREFIX you used is just an implementation detail of whatever libc 
> you looked at.  Those two leading underscores (followed by anything else but 
> "STD") are pretty much a dead giveaway.  As should be the fact that 
> this macro does not actually appear in any of the documentation ;-)
> 
Commit [3a8253]  solves the issue both on Cygwin and MinGW.

Thanks!

Tatsuro

Re: Windows (native and Cygwin) build fail in internal.c

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

Am 20.04.2018 um 02:48 schrieb Ethan A Merritt:
> As I understand it, the C99 standard requires that  __PRI64_PREFIX
> is defined in the file <inttypes.h>.

No, it doesn't require that. It requires macros PRId64 and friends to 
exist, iff the compiler claims C99 conformance and has an int64_t.  But 
that's about it.

The __PRI64_PREFIX you used is just an implementation detail of whatever 
libc you looked at.  Those two leading underscores (followed by anything 
else but "STD") are pretty much a dead giveaway.  As should be the fact 
that this macro does not actually appear in any of the documentation ;-)

Re: Windows (native and Cygwin) build fail in internal.c

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

On Thursday, April 19, 2018 4:59:24 PM PDT Tatsuro MATSUOKA wrote:
> After commit on 2018-04-18,
> Cygwin build fail in internal.c
> 
> 
> 
> gcc -DHAVE_CONFIG_H -I. -I../../gnuplot-gnuplot-main/src -I..  -I../term -I../../gnuplot-gnuplot-main/term -DBINDIR=\"/opt/gp530/bin\" -DX11_DRIVER_DIR=\"/opt/gp530/libexec/gnuplot/5.3\" -DQT_DRIVER_DIR=\"/opt/gp530/libexec/gnuplot/5.3\" -DGNUPLOT_SHARE_DIR=\"/opt/gp530/share/gnuplot/5.3\" -DGNUPLOT_PS_DIR=\"/opt/gp530/share/gnuplot/5.3/PostScript\" -DGNUPLOT_JS_DIR=\"/opt/gp530/share/gnuplot/5.3/js\" -DGNUPLOT_LUA_DIR=\"/opt/gp530/share/gnuplot/5.3/lua\" -DCONTACT=\"gnu...@li...\" -DHELPFILE=\"/opt/gp530/share/gnuplot/5.3/gnuplot.gih\" -DGNUPLOT_X11=\"`echo gnuplot_x11 | sed 's,x,x,'`.exe\" -DXAPPLRESDIR=\"/etc/X11/app-defaults/\"   -I/usr/local/include  -I/usr/include  -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/freetype2
>  -I/usr/include/libpng16 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include  -g -O2 -MT internal.o -MD -MP -MF $depbase.Tpo -c -o internal.o ../../gnuplot-gnuplot-main/src/internal.c &&\
> mv -f $depbase.Tpo $depbase.Po
> ../../gnuplot-gnuplot-main/src/internal.c: In function 'f_sprintf':
> ../../gnuplot-gnuplot-main/src/internal.c:1652:62: error: '__PRI64_PREFIX' undeclared (first use in this function)
>        char *newformat = gp_alloc(strlen(next_start) + strlen(__PRI64_PREFIX) + 1, NULL);
>                                                               ^~~~~~~~~~~~~~
> ../../gnuplot-gnuplot-main/src/internal.c:1652:62: note: each undeclared identifier is reported only once for each function it appears in
> 
> 
> The same error happened native windows build.
> 
> 
> On WSL (ubuntu 16.04) no error appears
> 
> Is this a bug of gnuplot or problem of windows side?

This new piece of code was added to allow the format specifiers
"%d" and "%x" and "%i" to work even if the integer being printed
requires 64 bits rather than 32 bits. 
See the discussion attached  to Bug #2037.
Before this change the program would print out "NaN" in this case.
We can go back to that for platforms that do not allow a better solution,
but let's try to figure out why it is failing for cygwin.

As I understand it, the C99 standard requires that  __PRI64_PREFIX 
is defined in the file <inttypes.h>.
The 64-bit integer code in gnuplot tests for HAVE_INTTYPES_H  to
see if the compiler supports this part of the C99 standard. 

But I could be wrong.  It is very hard to figure out exactly which C standard
requires what.   It is possible that the standard only requires definition of
  PRIo64  PRIu64 PRIx64 PRIX64 
and the PREFIX that they share was added as a convenience by glibc without
the standard requiring it. But you are using gcc so I would have expected
the PREFIX definition to be there.

What version of gcc are you using?
Is the symbol  HAVE_INTTTYPE_H  defined in your configuration?
Does inttypes.h contain any definitions for the 64bit integer formats?

Does your cygwin C compiler support a compile option -std=gnu99?
If so that might work.

	Ethan



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


-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
MS 357742,   University of Washington, Seattle 98195-7742

Windows (native and Cygwin) build fail in internal.c

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

After commit on 2018-04-18,
Cygwin build fail in internal.c



gcc -DHAVE_CONFIG_H -I. -I../../gnuplot-gnuplot-main/src -I..  -I../term -I../../gnuplot-gnuplot-main/term -DBINDIR=\"/opt/gp530/bin\" -DX11_DRIVER_DIR=\"/opt/gp530/libexec/gnuplot/5.3\" -DQT_DRIVER_DIR=\"/opt/gp530/libexec/gnuplot/5.3\" -DGNUPLOT_SHARE_DIR=\"/opt/gp530/share/gnuplot/5.3\" -DGNUPLOT_PS_DIR=\"/opt/gp530/share/gnuplot/5.3/PostScript\" -DGNUPLOT_JS_DIR=\"/opt/gp530/share/gnuplot/5.3/js\" -DGNUPLOT_LUA_DIR=\"/opt/gp530/share/gnuplot/5.3/lua\" -DCONTACT=\"gnu...@li...\" -DHELPFILE=\"/opt/gp530/share/gnuplot/5.3/gnuplot.gih\" -DGNUPLOT_X11=\"`echo gnuplot_x11 | sed 's,x,x,'`.exe\" -DXAPPLRESDIR=\"/etc/X11/app-defaults/\"   -I/usr/local/include  -I/usr/include  -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/freetype2
 -I/usr/include/libpng16 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include  -g -O2 -MT internal.o -MD -MP -MF $depbase.Tpo -c -o internal.o ../../gnuplot-gnuplot-main/src/internal.c &&\
mv -f $depbase.Tpo $depbase.Po
../../gnuplot-gnuplot-main/src/internal.c: In function 'f_sprintf':
../../gnuplot-gnuplot-main/src/internal.c:1652:62: error: '__PRI64_PREFIX' undeclared (first use in this function)
       char *newformat = gp_alloc(strlen(next_start) + strlen(__PRI64_PREFIX) + 1, NULL);
                                                              ^~~~~~~~~~~~~~
../../gnuplot-gnuplot-main/src/internal.c:1652:62: note: each undeclared identifier is reported only once for each function it appears in


The same error happened native windows build.


On WSL (ubuntu 16.04) no error appears

Is this a bug of gnuplot or problem of windows side?


Tatsuro

Re: Fwd: How to plot .gnu files in version 5.2

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

The question is not appropriate for gnuplot-beta list.
Aim for gnuplot-beta list is for development of gnuplot.

Please re-post to gnuplot-info list

gnu...@li...

Other your posts also should be submitted to there.


Tatsuro

----- Original Message -----
>From: Abdul Jalil 
>To: gnuplot-beta
>Date: 2018/4/11, Wed 18:35
>Subject: Fwd: How to plot .gnu files in version 5.2
> 
>
>
>
>ABDUL JALIL
>Lecturer
>Department of Physics
>00923315192550,0519057214
>Allama Iqbal Open university, Islamabad Pakistan.
>http://www.aiou.edu.pk/
>
>
>---------- Forwarded message ----------
>From: Abdul Jalil <jal...@gm...>
>Date: Sat, Dec 30, 2017 at 5:02 PM
>Subject: How to plot .gnu files in version 5.2
>To: gnu...@li...
>
>
>
>Dear Sir
>
>
>I am a new user of gnuplot , please can you guide me how can I plot these attached files I have window version of gnuplot.
>
>ABDUL JALIL
>Lecturer
>Department of Physics
>00923315192550,0519057214
>Allama Iqbal Open university, Islamabad Pakistan.
>http://www.aiou.edu.pk/
>
>
>------------------------------------------------------------------------------
>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
>
>
>

Request for assistance

[Abdul J. <jal...@gm...>]

Dear Sir
I ma using window version of gnuplot,how can i plot .gnu data?
when I am trying to load .gu file i got this error.(file attached)


gnuplot> load 'bulkek.gnu'

gnuplot> plot 'bulkek.dat' u 1:2 w lp lw 2 pt 7  ps 0.2 lc rgb 'black', 0 w
l lw 2
                                                                          ^
         "bulkek.gnu", line 19: "with" allowed only after parametric
function fully specified





*ABDUL JALILLecturerDepartment of Physics00923315192550,0519057214*
*Allama Iqbal Open university,** Islamabad Pakistan.*
*http://www.aiou.edu.pk/ <http://www.aiou.edu.pk/>*

Plotting problem

[Abdul J. <jal...@gm...>]

Dear Users

How can we plot .gnu data on window based gnuplot software?
secondlly how can we avoid from such an eroor?

gnuplot> set terminal  png truecolor enhanced  font ",60" size 1920, 1680
                           ^
         "slabek.gnu", line 5: invalid color spec, must be xRRGGBB









*ABDUL JALILLecturerDepartment of Physics00923315192550,0519057214*
*Allama Iqbal Open university,** Islamabad Pakistan.*
*http://www.aiou.edu.pk/ <http://www.aiou.edu.pk/>*

Fwd: How to plot .gnu files in version 5.2

[Abdul J. <jal...@gm...>]

Dear Users
what is the reason of this error how can we avoid from this?

Could not find/open font when opening font "arial", using internal
non-scalable fon








*ABDUL JALILLecturerDepartment of Physics00923315192550,0519057214*
*Allama Iqbal Open university,** Islamabad Pakistan.*
*http://www.aiou.edu.pk/ <http://www.aiou.edu.pk/>*

---------- Forwarded message ----------
From: Abdul Jalil <jal...@gm...>
Date: Wed, Apr 11, 2018 at 5:35 PM
Subject: Fwd: How to plot .gnu files in version 5.2
To: gnu...@li...






*ABDUL JALILLecturerDepartment of Physics00923315192550,0519057214*
*Allama Iqbal Open university,** Islamabad Pakistan.*
*http://www.aiou.edu.pk/ <http://www.aiou.edu.pk/>*

---------- Forwarded message ----------
From: Abdul Jalil <jal...@gm...>
Date: Sat, Dec 30, 2017 at 5:02 PM
Subject: How to plot .gnu files in version 5.2
To: gnu...@li...


Dear Sir

I am a new user of gnuplot , please can you guide me how can I plot these
attached files I have window version of gnuplot.




*ABDUL JALILLecturerDepartment of Physics00923315192550,0519057214*
*Allama Iqbal Open university,** Islamabad Pakistan.*
*http://www.aiou.edu.pk/ <http://www.aiou.edu.pk/>*

Fwd: How to plot .gnu files in version 5.2

[Abdul J. <jal...@gm...>]

*ABDUL JALILLecturerDepartment of Physics00923315192550,0519057214*
*Allama Iqbal Open university,** Islamabad Pakistan.*
*http://www.aiou.edu.pk/ <http://www.aiou.edu.pk/>*

---------- Forwarded message ----------
From: Abdul Jalil <jal...@gm...>
Date: Sat, Dec 30, 2017 at 5:02 PM
Subject: How to plot .gnu files in version 5.2
To: gnu...@li...


Dear Sir

I am a new user of gnuplot , please can you guide me how can I plot these
attached files I have window version of gnuplot.




*ABDUL JALILLecturerDepartment of Physics00923315192550,0519057214*
*Allama Iqbal Open university,** Islamabad Pakistan.*
*http://www.aiou.edu.pk/ <http://www.aiou.edu.pk/>*

Re: Do we still need MSDOS support?

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

On Friday, 06 April 2018 08:53:52 sfeam via gnuplot-beta wrote:
> On Friday, 06 April 2018 15:27:10 Petr Mikulik wrote:
> > I build gnuplot on OS/2 via gcc/emx. The binary then runs on OS/2, 
> > eCommStation, DOS with emx.exe or rsx.exe. Thus it is necessary to keep 
> > __OS2__ and __EMX__.
> > 
> > The gcc/emx I use is gcc 2.8.1, and it does not know command line option 
> > "-std=c99".
> 
> Do you use (or build) the emxvga terminal?
> The source is basically untouched since 2002.
> 
> > I've prepared some patches for OS/2 in 2017 but not committed them due to the 
> > transfer of cvs to git. I'll have to learn how to submit them.
> > 
> > BTW, would not C99 syntax break VMS/VAX compilers? Its makefile is still 
> > in the config/ directory.

I went back and looked at the documentation.
C99 has been supported by the OpenVMS C compiler since the mid 2000s.
So I don't think that by itself is a concern.

> VMS support is also a candidate for being dropped.
> I was myself test-building releases on VMS through version 4.6
> but I no longer have a bootable VMS machine.   To the extent that VMS
> lives on in the larger world, it is via emulation on virtual machines.
> I have not been able to find any mention of gnuplot being used in that
> context, but even if it is I imagine that the output is not via
> the VAX Windowing System (vws.trm).
> 	
> 	Ethan

Re: Do we still need MSDOS support?

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

On Friday, 06 April 2018 15:27:10 Petr Mikulik wrote:
> I build gnuplot on OS/2 via gcc/emx. The binary then runs on OS/2, 
> eCommStation, DOS with emx.exe or rsx.exe. Thus it is necessary to keep 
> __OS2__ and __EMX__.
> 
> The gcc/emx I use is gcc 2.8.1, and it does not know command line option 
> "-std=c99".

Do you use (or build) the emxvga terminal?
The source is basically untouched since 2002.

> I've prepared some patches for OS/2 in 2017 but not committed them due to the 
> transfer of cvs to git. I'll have to learn how to submit them.
> 
> BTW, would not C99 syntax break VMS/VAX compilers? Its makefile is still 
> in the config/ directory.

VMS support is also a candidate for being dropped.
I was myself test-building releases on VMS through version 4.6
but I no longer have a bootable VMS machine.   To the extent that VMS
lives on in the larger world, it is via emulation on virtual machines.
I have not been able to find any mention of gnuplot being used in that
context, but even if it is I imagine that the output is not via
the VAX Windowing System (vws.trm).
	
	Ethan



> Petr
> 
> 
> >> EMX:  Used on DOS and OS/2, so removing support for it might break
> >>    OS/2, too (Petr?)
> >
> > Petr:
> >
> > Are you still building gnuplot on OS/2?
> > What toolset[s] are needed for that?
> >
> > In particular I am wondering if the __EMX__ conditional code and the
> > emxvga.trm driver can be removed.
> >
> > The EMX project web page seems to show that the most recent
> > supported gcc is 3.0.4 (from 2002).  I suspect that if we move to
> > requiring a compiler that accepts C99 syntax that version is too old.
> 
> 
> ------------------------------------------------------------------------------
> 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

Re: Do we still need MSDOS support?

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

I build gnuplot on OS/2 via gcc/emx. The binary then runs on OS/2, 
eCommStation, DOS with emx.exe or rsx.exe. Thus it is necessary to keep 
__OS2__ and __EMX__.

The gcc/emx I use is gcc 2.8.1, and it does not know command line option 
"-std=c99".

I've prepared some patches for OS/2 in 2017 but not committed them due to the 
transfer of cvs to git. I'll have to learn how to submit them.

BTW, would not C99 syntax break VMS/VAX compilers? Its makefile is still 
in the config/ directory.

Petr


>> EMX:  Used on DOS and OS/2, so removing support for it might break
>>    OS/2, too (Petr?)
>
> Petr:
>
> Are you still building gnuplot on OS/2?
> What toolset[s] are needed for that?
>
> In particular I am wondering if the __EMX__ conditional code and the
> emxvga.trm driver can be removed.
>
> The EMX project web page seems to show that the most recent
> supported gcc is 3.0.4 (from 2002).  I suspect that if we move to
> requiring a compiler that accepts C99 syntax that version is too old.