gnuplot-beta Mailing List for gnuplot (Page 37)

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

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

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.

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 

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.

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

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

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

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

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

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

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/>*

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/>*

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/>*

*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/>*

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

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

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.

> To my knowledge there have only been official releases using DJGPP in the
> more recent past:  4.0 by HBB, 4.2-4.6 by Tatsuro (I think)
> 
Yes. I provided binaries from 4.2-4.6.
 On 64 bit windows, 16 bit MS-DOS does not work and I used Dosbox.
However, in the Dosbox at the time cannot treat long file name.
So I give up to provide DJGPP packages at the point gnuplot began to use
file name in long file name style.
(On native MS-DOS, 8+3 characters can be used as file names.) 

Tatsuro 

Oops!  Correction:


> I myself do not use MSDOS any longer but l do think that it is the time to kill 
> MSDOS.


I myself do not use MSDOS any longer but l do >not< think that it is the time to kill 
MSDOS.
 

----- Original Message -----
> From: Tatsuro MATSUOKA 
> To: Ethan A Merritt ; "gnuplot-beta
> Cc: 
> Date: 2018/4/5, Thu 06:43
> Subject: Re: Do we still need MSDOS support?
> 
> MSDOS works 16 bit but DJGPP works on 32bit.
> 
> gnuplot no longer works on 16bit MSDOS but works on MSDOS with DJGPP extention.
> 
> #ifdef MSDOS
> is for now MSDOS with DJGPP.
> 
> I myself do not use MSDOS any longer but l do think that it is the time to kill 
> MSDOS.
> 
> Recently Bastian pushed a commit for MSDOS with DJGPP.
> 
> [1eb149] by  Bastian Maerkisch
> 
> Extend support for "set encoding locale" on non-Windows systems
> 
> The Windows locale code also applies to DJGPP/MSDOS. Add a few more
> explicit checks for other systems. Move the relevant code from misc.c|h
> and winmain.c|h to encoding.c|h.
> 
> Tatsuro
> 
> --- gnuplot-beta
>>  A possibly foolish question from someone far outside the DOS/Windows 
> world...
>> 
>>  Many places in the gnuplot code are marked
>>  #ifdef MSDOS ...
>> 
>>  I thought that MSDOS referred to 16-bit legacy code that we
>>  no longer support.  Maybe I am mistaken.
>> 
>>  Who/what needs this code?
>>  Should the test be replaced by a test for _WIN32 instead?
>> 
>>  Maybe or maybe not the same question-
>> 
>>  Can we get rid of the macros HUGE  and GPFAR?
>>  Can we get rid of GP_FARMALLOC?
>> 
>> 
> ------------------------------------------------------------------------------
>>  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
> 

On Wednesday, April 4, 2018 11:19:18 PM PDT Bastian Märkisch wrote:
> > Gesendet: Donnerstag, 05. April 2018 um 00:23 Uhr
> > Am 04.04.2018 um 22:47 schrieb Ethan A Merritt via gnuplot-beta:
> > > 
> > > I thought that MSDOS referred to 16-bit legacy code that we
> > > no longer support.  Maybe I am mistaken.
> > 
> > You are, kinda.  MSDOS refers to the operating system, but not 
> > necessarily in its original 16-bit incarnation.  We still do carry 
> > support for DJGPP, which is a 32-bit target working on top of MSDOS.  It 
> > has suffered some bit-rot since I last tried to build it, but it should 
> > still be viable.
> 
> A few months ago I was asking myself if gnuplot could still be 
> compiled on MSDOS. Here are my findings:
> 
> In fact there are (at least) three 32bit MSDOS compilers which were 
> used in the past:
> DJGPP:  Still under active development, POSIX, gcc 7.2 available, 
>    as well as cross-compilers
> OpenWatcom:  Development stale/slowed down, also supported for 
>    gnuplot on Windows
> 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.

What are your thoughts?

	Ethan

> Gesendet: Donnerstag, 05. April 2018 um 00:23 Uhr
> Am 04.04.2018 um 22:47 schrieb Ethan A Merritt via gnuplot-beta:
> > 
> > I thought that MSDOS referred to 16-bit legacy code that we
> > no longer support.  Maybe I am mistaken.
> 
> You are, kinda.  MSDOS refers to the operating system, but not 
> necessarily in its original 16-bit incarnation.  We still do carry 
> support for DJGPP, which is a 32-bit target working on top of MSDOS.  It 
> has suffered some bit-rot since I last tried to build it, but it should 
> still be viable.

A few months ago I was asking myself if gnuplot could still be 
compiled on MSDOS. Here are my findings:

In fact there are (at least) three 32bit MSDOS compilers which were 
used in the past:
DJGPP:  Still under active development, POSIX, gcc 7.2 available, 
   as well as cross-compilers
OpenWatcom:  Development stale/slowed down, also supported for 
   gnuplot on Windows
EMX:  Used on DOS and OS/2, so removing support for it might break
   OS/2, too (Petr?)

I have tested building with DJGPP and OpenWatcom. There's indeed some bit-rot,
but that can be easily fixed. I just pushed my local "msdos-platform" branch
to my gnuplot "fork" on SF.  Beware of frequent rebases, though.

To my knowledge there have only been official releases using DJGPP in the
more recent past:  4.0 by HBB, 4.2-4.6 by Tatsuro (I think)

> 
> Building and testing the executables built by/for that target is getting 
> ever more tricky these days, what with all the usual desktop platforms 
> being 64-bit, so they can no longer executabe any 16-bit code (down to 
> and including the 16-bit "stub" that starts the 32-bit DJGPP runtime 
> environment).  So you need a VirtualBox setup or similar to run it.  But 
> OTOH, DJGPP on FREEDOS may well be the only version of gnuplot that 
> would still work on truly old boxes that won't support any "modern" 
> Linux any more...

If you build for Windows using cygwin or MSYS/MSYS2, compiling for DJGPP
is actually pretty straightforward using the cross-compilers.  I have updated
the DJGPP makefile to do that and also enabled out-of-tree builds.  Changes
are still entangled with my work on the "svga" terminal, though. It can
be found in the "djsvga-terminal" branch in my "fork". Beware of rebases here,
too.

For the fun of it, I also added most of the modern gnuplot features
to the djsvga terminal:  RGB and palette colors, enhanced text, filled polygons
and boxes, images, and mousing. Since the underlying GRX/MGRX graphics library
is also available on Windows and Linux, this terminal can be maintained even 
without testing on DOS.

The plan was to clean up the patches before integration into mainline gnuplot.
This should resurrect DOS as an actively supported platform.

> 
> > Should the test be replaced by a test for _WIN32 instead?
> 
> No.
> 
> > Can we get rid of the macros HUGE  and GPFAR?
> 
> GPFAR: almost certainly yes.  We've long since dropped support for all 
> platforms that needed it (segmented architectures like Win16 and 16-bit 
> DOS).
> 
> HUGE is a different issue, as that's about quirky floating point 
> support, not the target OS.  Or was it GPHUGE you were thinking of? 
> That one can actually go, too, if GPFAR does.  Those are two parts of 
> the same technique.
> 
> > Can we get rid of GP_FARMALLOC?
> 
> That would go wherever GPFAR does.

As an aside:  PROTO could now finally go there, too.

  Bastian

On 4 April 2018 at 23:43, Tatsuro MATSUOKA wrote:
> MSDOS works 16 bit but DJGPP works on 32bit.
>
> gnuplot no longer works on 16bit MSDOS but works on MSDOS with DJGPP extention.
>
> #ifdef MSDOS
> is for now MSDOS with DJGPP.
>
> I myself do not use MSDOS any longer but l do think that it is the time to kill MSDOS.

I'm not a developer, but I fully agree.

Dropping support for MSDOS doesn't mean that you no longer allow
people to run gnuplot there, it merely means that the "dinosaurs" who
still depend on it will not be able to use gnuplot version 6 (or
5.whatever-the-next-version-is). But: what exactly are the benefits of
the latest not-yet-released version of gnuplot that DOS users would so
desperately need? There's a lot of development going on in making GUI
terminals better, none of which will benefit those users.

Mojca

Just as an anecdote. I recently asked if there were any users who
would miss mac ppc binaries for some C++11 software. One user replied
that he would miss them. Then I asked which version he had installed
at that point and if he can try to compile himself just to see if he
would be successful. It turned out he had an old version installed
anyway and the computer was at some remote location he rarely visits,
so he could not even try.

On Thursday, 05 April 2018 00:23:15 Hans-Bernhard Bröker wrote:
> Am 04.04.2018 um 22:47 schrieb Ethan A Merritt via gnuplot-beta:
> > 
> > I thought that MSDOS referred to 16-bit legacy code that we
> > no longer support.  Maybe I am mistaken.
> 
> You are, kinda.  MSDOS refers to the operating system, but not 
> necessarily in its original 16-bit incarnation.  We still do carry 
> support for DJGPP, which is a 32-bit target working on top of MSDOS.  It 
> has suffered some bit-rot since I last tried to build it, but it should 
> still be viable.
> 
> Building and testing the executables built by/for that target is getting 
> ever more tricky these days, what with all the usual desktop platforms 
> being 64-bit, so they can no longer executabe any 16-bit code (down to 
> and including the 16-bit "stub" that starts the 32-bit DJGPP runtime 
> environment).  So you need a VirtualBox setup or similar to run it.  But 
> OTOH, DJGPP on FREEDOS may well be the only version of gnuplot that 
> would still work on truly old boxes that won't support any "modern" 
> Linux any more...
> 
> > Should the test be replaced by a test for _WIN32 instead?
> 
> No.
> 
> > Can we get rid of the macros HUGE  and GPFAR?
> 
> GPFAR: almost certainly yes.  We've long since dropped support for all 
> platforms that needed it (segmented architectures like Win16 and 16-bit 
> DOS).
> 
> HUGE is a different issue, as that's about quirky floating point 
> support, not the target OS.  Or was it GPHUGE you were thinking of? 

Yeah, sorry. Of course I meant GPHUGE.

> That one can actually go, too, if GPFAR does.  Those are two parts of 
> the same technique.
> 
> > Can we get rid of GP_FARMALLOC?
> 
> That would go wherever GPFAR does.

Thanks.

One more question:  
The emx/gcc compile environment looks pretty moribund compared
to cygwin, mingw, and even djgpp.  Can we get rid of the code
chunks marked
    if defined(__EMX__)

		Ethan

Am 04.04.2018 um 22:47 schrieb Ethan A Merritt via gnuplot-beta:
> 
> I thought that MSDOS referred to 16-bit legacy code that we
> no longer support.  Maybe I am mistaken.

You are, kinda.  MSDOS refers to the operating system, but not 
necessarily in its original 16-bit incarnation.  We still do carry 
support for DJGPP, which is a 32-bit target working on top of MSDOS.  It 
has suffered some bit-rot since I last tried to build it, but it should 
still be viable.

Building and testing the executables built by/for that target is getting 
ever more tricky these days, what with all the usual desktop platforms 
being 64-bit, so they can no longer executabe any 16-bit code (down to 
and including the 16-bit "stub" that starts the 32-bit DJGPP runtime 
environment).  So you need a VirtualBox setup or similar to run it.  But 
OTOH, DJGPP on FREEDOS may well be the only version of gnuplot that 
would still work on truly old boxes that won't support any "modern" 
Linux any more...

> Should the test be replaced by a test for _WIN32 instead?

No.

> Can we get rid of the macros HUGE  and GPFAR?

GPFAR: almost certainly yes.  We've long since dropped support for all 
platforms that needed it (segmented architectures like Win16 and 16-bit 
DOS).

HUGE is a different issue, as that's about quirky floating point 
support, not the target OS.  Or was it GPHUGE you were thinking of? 
That one can actually go, too, if GPFAR does.  Those are two parts of 
the same technique.

> Can we get rid of GP_FARMALLOC?

That would go wherever GPFAR does.