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

Re: Aw: Re: Do we still need MSDOS support?

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

> 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 

Re: Do we still need MSDOS support?

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

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
> 

Re: Aw: Re: Do we still need MSDOS support?

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

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

Aw: Re: Do we still need MSDOS support?

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

> 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

Re: Do we still need MSDOS support?

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

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.

Re: Do we still need MSDOS support?

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

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

Re: Do we still need MSDOS support?

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

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.

Re: Do we still need MSDOS support?

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

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

Do we still need MSDOS support?

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

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?

Inconsitency between configure build and Windows build after commit 9d0f14(was Re: commit 9d0f14)

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

----- Original Message -----

> From: Tatsuro MATSUOKA <tma...@ya...>
> To: Mojca Miklavec <moj...@gm...>; Ethan Merritt <eam...@gm...>
> Cc: gnu...@li...; Merritt Ethan <sf...@us...>
> Date: 2018/3/23, Fri 16:43
> Subject: Re: commit 9d0f14
> 
> ----- Original Message -----
> 
>>  From: Mojca Miklavec 
>>  To: Ethan Merritt 
>>  Cc: gnuplot-beta ; Ethan A Merritt
>>  Date: 2018/3/23, Fri 05:16
>>  Subject: Re: commit 9d0f14
>> 
>>  On 22 March 2018 at 19:26, Ethan Merritt wrote:
>>> 
>>>   Here's a different idea.
>>>   Does git gurantee to preserve the modification date attribute of files 
> in
>>>   the repository?
>> 
>>  I'm not sure what you are asking exactly, but:
>> 
>>  - Git doesn't remember original modification time of any file. That
>>  is: you cannot take a file that was last modified on March 1st, commit
>>  it today, clone repository and get that info about the 1st of March in
>>  any way. The original modification timestamp is lost.
>>  - What git *does* remember is commit timestamp, or rather two
>>  timestamps, timestamp of when the author committed this first and then
>>  another timestamp in case of further
>>  modifications/merging/rebasing/cherry-picking etc. (git calls that
>>  "author" and "committer" timestamp; you can manually 
> specify 
>>  those
>>  timestamps of course, but that's a different issue)
>> 
>>  When you switch back and forth between branches, the last modification
>>  time of files on the disk will change, I think.
>> 
>>  There is a way to enforce a consistent timing with a built-in function
>>  to generate tarbals for example, but I don't think you can rely on
>>  that feature unless you take some special care. By default all the
>>  files you check out will have the timestamp of the time when you
>>  cloned repository or pulled in new changes or switched between
>>  branches rather than the timestamp of the actual change in repository.
>> 
>>>   I observe that it does this in practice, but maybe it is not a 
> guarantee.
>>>   We don't really need to alter the _contents_ of a timestamp file,  
> just 
>>  its
>>>   modification date.
>> 
>>  See above, I don't believe this would in practice be any less random
>>  than the build timestamp. Ok, at least it will be reproducible on the
>>  same machine, so slightly less randomness :)
>> 
>>  Here are some ideas:
>>    
>> 
> https://stackoverflow.com/questions/1704907/how-can-i-get-my-c-code-to-automatically-print-out-its-git-version-hash
>> 
>>  If the only problem of "git describe" is support for 
> out-of-source
>>  builds, couldn't the Makefile simply do something like
>> 
>>      # remember current build-dir
>>      cd source-dir
>>      version=`git describe ...`
>>      cd build-dir
>>      echo $version > versionfile.txt
>> 
>>  (consider this to be pseudo-code). If git fails in this case, then go
>>  for version written elsewhere of course.
>> 
>>  Mojca
>> 
> 
> 
> In my opinion, for development version of open source software, 
> git or mercurial version hash is essential.
> 
> I vote to the Mojca's proposal.
> 
> Tatsuro
> 

On Unixy platform, mechanism of timestamp.h is changed.
However, windows Makefile is not changed accordingly.

I personally do not like the change of commit 9d0f14.
However, inconsistency is not also good thing.

Tatsuro 

Re: commit 9d0f14

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

> On 22 March 2018 at 19:26, Ethan Merritt wrote:
>>
>> Here's a different idea.
>> Does git gurantee to preserve the modification date attribute of files in
>> the repository?

Mojca Miklavec <moj...@gm...> said (on 2018/03/22):
> I'm not sure what you are asking exactly, but:
> 
> - Git doesn't remember original modification time of any file. ...
> 
> When you switch back and forth between branches, the last modification
> time of files on the disk will change, I think.
> ...
> If the only problem of "git describe" is support for out-of-source
> builds, couldn't the Makefile simply do something like
> 
>     # remember current build-dir
>     cd source-dir
>     version=`git describe ...`
>     cd build-dir
>     echo $version > versionfile.txt
> 
> (consider this to be pseudo-code). ...

As Mojca mentioned, git does not preserve m-time. Make would not
work properly unless git touched the changed files when
switching branches or doing any other file-modifying operations.

The underlying problem is that all the metadata is tracked in
the .git directory, and you're asking a metadata question to be
answered without having the .git directory. There is not any
more a (somewhat) redundant file within the repository that also
tracks metadata.

If building in a different directory from the source, setting
the GIT_DIR environment variable will allow git commands,
including git-describe, to work. But if there is no .git
directory at all, all the metadata has been stripped and it
can't be recovered anymore unless some action was taken to
preserve it before stripping it away.

Re: commit 9d0f14

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

----- Original Message -----

> From: Mojca Miklavec 
> To: Ethan Merritt 
> Cc: gnuplot-beta ; Ethan A Merritt
> Date: 2018/3/23, Fri 05:16
> Subject: Re: commit 9d0f14
> 
> On 22 March 2018 at 19:26, Ethan Merritt wrote:
>> 
>>  Here's a different idea.
>>  Does git gurantee to preserve the modification date attribute of files in
>>  the repository?
> 
> I'm not sure what you are asking exactly, but:
> 
> - Git doesn't remember original modification time of any file. That
> is: you cannot take a file that was last modified on March 1st, commit
> it today, clone repository and get that info about the 1st of March in
> any way. The original modification timestamp is lost.
> - What git *does* remember is commit timestamp, or rather two
> timestamps, timestamp of when the author committed this first and then
> another timestamp in case of further
> modifications/merging/rebasing/cherry-picking etc. (git calls that
> "author" and "committer" timestamp; you can manually specify 
> those
> timestamps of course, but that's a different issue)
> 
> When you switch back and forth between branches, the last modification
> time of files on the disk will change, I think.
> 
> There is a way to enforce a consistent timing with a built-in function
> to generate tarbals for example, but I don't think you can rely on
> that feature unless you take some special care. By default all the
> files you check out will have the timestamp of the time when you
> cloned repository or pulled in new changes or switched between
> branches rather than the timestamp of the actual change in repository.
> 
>>  I observe that it does this in practice, but maybe it is not a guarantee.
>>  We don't really need to alter the _contents_ of a timestamp file,  just 
> its
>>  modification date.
> 
> See above, I don't believe this would in practice be any less random
> than the build timestamp. Ok, at least it will be reproducible on the
> same machine, so slightly less randomness :)
> 
> Here are some ideas:
>   
> https://stackoverflow.com/questions/1704907/how-can-i-get-my-c-code-to-automatically-print-out-its-git-version-hash
> 
> If the only problem of "git describe" is support for out-of-source
> builds, couldn't the Makefile simply do something like
> 
>     # remember current build-dir
>     cd source-dir
>     version=`git describe ...`
>     cd build-dir
>     echo $version > versionfile.txt
> 
> (consider this to be pseudo-code). If git fails in this case, then go
> for version written elsewhere of course.
> 
> Mojca
> 


In my opinion, for development version of open source software, 
git or mercurial version hash is essential.

I vote to the Mojca's proposal.

Tatsuro

Re: commit 9d0f14

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

On 22 March 2018 at 19:26, Ethan Merritt wrote:
>
> Here's a different idea.
> Does git gurantee to preserve the modification date attribute of files in
> the repository?

I'm not sure what you are asking exactly, but:

- Git doesn't remember original modification time of any file. That
is: you cannot take a file that was last modified on March 1st, commit
it today, clone repository and get that info about the 1st of March in
any way. The original modification timestamp is lost.
- What git *does* remember is commit timestamp, or rather two
timestamps, timestamp of when the author committed this first and then
another timestamp in case of further
modifications/merging/rebasing/cherry-picking etc. (git calls that
"author" and "committer" timestamp; you can manually specify those
timestamps of course, but that's a different issue)

When you switch back and forth between branches, the last modification
time of files on the disk will change, I think.

There is a way to enforce a consistent timing with a built-in function
to generate tarbals for example, but I don't think you can rely on
that feature unless you take some special care. By default all the
files you check out will have the timestamp of the time when you
cloned repository or pulled in new changes or switched between
branches rather than the timestamp of the actual change in repository.

> I observe that it does this in practice, but maybe it is not a guarantee.
> We don't really need to alter the _contents_ of a timestamp file,  just its
> modification date.

See above, I don't believe this would in practice be any less random
than the build timestamp. Ok, at least it will be reproducible on the
same machine, so slightly less randomness :)

Here are some ideas:
   https://stackoverflow.com/questions/1704907/how-can-i-get-my-c-code-to-automatically-print-out-its-git-version-hash

If the only problem of "git describe" is support for out-of-source
builds, couldn't the Makefile simply do something like

    # remember current build-dir
    cd source-dir
    version=`git describe ...`
    cd build-dir
    echo $version > versionfile.txt

(consider this to be pseudo-code). If git fails in this case, then go
for version written elsewhere of course.

Mojca

Re: commit 9d0f14

[Ethan M. <eam...@gm...>]

On Thu, Mar 22, 2018 at 8:17 AM, sfeam via gnuplot-beta <
gnu...@li...> wrote:

> On Thursday, 22 March 2018 10:26:33 Mojca Miklavec wrote:
> > On 22 March 2018 at 02:34, Tatsuro MATSUOKA wrote:
> > >  [9d0f14] (HEAD, master) by Ethan A Merritt Ethan A Merritt
> > >
> > > another try at timestamp.h, this time using build date
> > >
> > > The Makefile rule for timestamp.h was broken when we switched from
> > > cvs to git, since it relied on ChangeLog always being current.
> > > Proposed replacement rules have so far failed to work for out-of-tree
> > > builds or builds from a snapshot rather than a full git clone.
> > > This attempt simply uses the current build date, which admittedly may
> > > not be newer than the last-modified date but at least has the virtue
> > > of not depending on git.
>

[snip]


> This whole approach is less satisfactory than the old (CVS) mechanism
> of checking the top of the ChangeLog file.  What I really want, I think,
> is an option attached to the "git commit" command that automatically
> modifies the timestamp file to match the commit date.   The file itself,
> not the metadata.  Something that persists outside of the git context.
>
>         Ethan
>
>
Here's a different idea.
Does git gurantee to preserve the modification date attribute of files in
the repository?
I observe that it does this in practice, but maybe it is not a guarantee.
We don't really need to alter the _contents_ of a timestamp file,  just its
modification date.
So it would be sufficient if there is a way to automate that "git commit"
does a "touch + stage"
on the timestamp file regardless of what files are otherwise in the commit.
The Makefile rule is then dead simple, since checking the modification date
of a file
is exactly what make was designed for.

Re: commit 9d0f14

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

On Thursday, 22 March 2018 10:26:33 Mojca Miklavec wrote:
> On 22 March 2018 at 02:34, Tatsuro MATSUOKA wrote:
> >  [9d0f14] (HEAD, master) by Ethan A Merritt Ethan A Merritt
> >
> > another try at timestamp.h, this time using build date
> >
> > The Makefile rule for timestamp.h was broken when we switched from
> > cvs to git, since it relied on ChangeLog always being current.
> > Proposed replacement rules have so far failed to work for out-of-tree
> > builds or builds from a snapshot rather than a full git clone.
> > This attempt simply uses the current build date, which admittedly may
> > not be newer than the last-modified date but at least has the virtue
> > of not depending on git.
> 
> I just wanted to warn you that you will almost definitely get a
> request from Debian (as soon as you release the version that will
> behave this way and they try to package it) to stop doing that in the
> name of reproducible builds.

Release versions of gnuplot have the release date in this slot.
The timestamp is only used when you build the development version
directly from source.
 
>     https://reproducible-builds.org
> 
> My suggestion would be to:
> (a) Check if you are building from git and if so, run "git describe"
> to determine the version. That's probably by far the best way to
> determine the version.

If you build from a snapshot then git has no handle on the source
and cannot tell you anything about it.  So testing for git itself
does not help.

Even if you build from a working git clone, the previous makefile
recipes to invoke git failed for out-of-tree builds because the
directory structure during the build does not match that in the
git config file.  It was really annoying to me that "make distcheck"
would always fail for this reason.  This may be fixable, but the
fix would have to come from someone more clever than me.  
Checking the date was the best I could come up with.

> (b) When not building from git, you would usually build from a
> released tarball which should necessarily have the version written
> somewhere anyway and then you know which version that is exactly.

Building from a release tarball continues to work as it always has.


> Of course there are exceptions, like if someone deletes .git or
> fetches the zip from the download link from SF or GitHub or wherever,
> but you cannot solve all problems and the build date is totally
> useless in itself. I can probably build gnuplot 1.0 today and that
> won't tell you anything about the exact version I have in case I
> submit a bug report.

If you build any previous version, even a patchlevel release,
you get the release date.

I'd be happy to use a different Makefile rule if it covers
all the cases people are using.  The previous two attempts worked
some of the time but triggered bug reports from people using a
snapshot or building out of tree.

This whole approach is less satisfactory than the old (CVS) mechanism
of checking the top of the ChangeLog file.  What I really want, I think,
is an option attached to the "git commit" command that automatically
modifies the timestamp file to match the commit date.   The file itself,
not the metadata.  Something that persists outside of the git context. 
 

	Ethan

Re: commit 9d0f14

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

Mojca Miklavec <moj...@gm...> writes:

> My suggestion would be to:
> (a) Check if you are building from git and if so, run "git describe"
> to determine the version. That's probably by far the best way to
> determine the version.
>
> (b) When not building from git, you would usually build from a
> released tarball which should necessarily have the version written
> somewhere anyway and then you know which version that is exactly.

Furthermore, this proposal gives you what you actually want: some sort
of user-visible indication of the version they're running that they can
include in bug reports. A date does not do this.

Re: Re: commit 9d0f14

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

--- mojca.miklavec.lists
> On 22 March 2018 at 02:34, Tatsuro MATSUOKA wrote:
> >  [9d0f14] (HEAD, master) by Ethan A Merritt Ethan A Merritt
> >
> > another try at timestamp.h, this time using build date
> >
> > The Makefile rule for timestamp.h was broken when we switched from
> > cvs to git, since it relied on ChangeLog always being current.
> > Proposed replacement rules have so far failed to work for out-of-tree
> > builds or builds from a snapshot rather than a full git clone.
> > This attempt simply uses the current build date, which admittedly may
> > not be newer than the last-modified date but at least has the virtue
> > of not depending on git.
> 
> I just wanted to warn you that you will almost definitely get a
> request from Debian (as soon as you release the version that will
> behave this way and they try to package it) to stop doing that in the
> name of reproducible builds.
> 
>     https://reproducible-builds.org
> 
> My suggestion would be to:
> (a) Check if you are building from git and if so, run "git describe"
> to determine the version. That's probably by far the best way to
> determine the version.
> (b) When not building from git, you would usually build from a
> released tarball which should necessarily have the version written
> somewhere anyway and then you know which version that is exactly.
> 
> Of course there are exceptions, like if someone deletes .git or
> fetches the zip from the download link from SF or GitHub or wherever,
> but you cannot solve all problems and the build date is totally
> useless in itself. I can probably build gnuplot 1.0 today and that
> won't tell you anything about the exact version I have in case I
> submit a bug report.
> 
> Mojca

I agree with Mojca’s statement.

Octave uses mecurial.
Hg-ID is represented in build process and it is presereved  in a file.

Tatsuro

Re: commit 9d0f14

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

On 22 March 2018 at 02:34, Tatsuro MATSUOKA wrote:
>  [9d0f14] (HEAD, master) by Ethan A Merritt Ethan A Merritt
>
> another try at timestamp.h, this time using build date
>
> The Makefile rule for timestamp.h was broken when we switched from
> cvs to git, since it relied on ChangeLog always being current.
> Proposed replacement rules have so far failed to work for out-of-tree
> builds or builds from a snapshot rather than a full git clone.
> This attempt simply uses the current build date, which admittedly may
> not be newer than the last-modified date but at least has the virtue
> of not depending on git.

I just wanted to warn you that you will almost definitely get a
request from Debian (as soon as you release the version that will
behave this way and they try to package it) to stop doing that in the
name of reproducible builds.

    https://reproducible-builds.org

My suggestion would be to:
(a) Check if you are building from git and if so, run "git describe"
to determine the version. That's probably by far the best way to
determine the version.
(b) When not building from git, you would usually build from a
released tarball which should necessarily have the version written
somewhere anyway and then you know which version that is exactly.

Of course there are exceptions, like if someone deletes .git or
fetches the zip from the download link from SF or GitHub or wherever,
but you cannot solve all problems and the build date is totally
useless in itself. I can probably build gnuplot 1.0 today and that
won't tell you anything about the exact version I have in case I
submit a bug report.

Mojca

Re: commit 9d0f14

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

On Thursday, 22 March 2018 13:14:35 Tatsuro MATSUOKA wrote:
> ----- Original Message -----
> 
> > From: sfeam 
> > To: gnuplot-beta
> > Cc: Tatsuro MATSUOKA 
> > Date: 2018/3/22, Thu 11:59
> > Subject: Re: commit 9d0f14
> > 
> > On Wednesday, 21 March 2018 19:39:55 sfeam via gnuplot-beta wrote:
> >>  On Thursday, 22 March 2018 10:34:14 Tatsuro MATSUOKA wrote:
> >>  >  [9d0f14] (HEAD, master) by Ethan A Merritt Ethan A Merritt
> >>  > 
> >>  > another try at timestamp.h, this time using build date
> >>  > 
> >>  > The Makefile rule for timestamp.h was broken when we switched from
> >>  > cvs to git, since it relied on ChangeLog always being current.
> >>  > Proposed replacement rules have so far failed to work for out-of-tree
> >>  > builds or builds from a snapshot rather than a full git clone.
> >>  > This attempt simply uses the current build date, which admittedly may
> >>  > not be newer than the last-modified date but at least has the virtue
> >>  > of not depending on git.
> >>  > 
> >>  > 
> >>  > However, git date reflects last commit date and not newer than build 
> > date.
> >>  > Build date is not later than the last commit date.
> >>  > It is usually newer than the last commit date.
> >> 
> >>  Yes.  The text of the commit message was wrong.
> >>  Sorry.
> >> 
> >>  I wish there was a way to edit commit messages afterwards.
> >>  That is the thing I dislike the about about git so far.
> > 
> >        s/dislike the about about/dislike the most about/
> > 
> >>  You cannot go back and fix typos or errors in the commit
> >>  messages.
> > 
> >     like that :-)
> > 
> > 
> >>      Ethan
> >> 
> >>  > 
> >>  > Tatsuro
> 
> 
> The terms "last modified" indicate source modification but not build timing.
> I feel that the term "last modified" is not point to the state after commit 9d0f14.
> 
> The term should also changed to be "build date and time".

  Good point.
  I was mostly concerned with finding a mechanism that works, but yes the
  text printed out by the program should be adjusted to match.

    Ethan


> 
> Tatsuro
> 

Re: commit 9d0f14

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

----- Original Message -----

> From: sfeam 
> To: gnuplot-beta
> Cc: Tatsuro MATSUOKA 
> Date: 2018/3/22, Thu 11:59
> Subject: Re: commit 9d0f14
> 
> On Wednesday, 21 March 2018 19:39:55 sfeam via gnuplot-beta wrote:
>>  On Thursday, 22 March 2018 10:34:14 Tatsuro MATSUOKA wrote:
>>  >  [9d0f14] (HEAD, master) by Ethan A Merritt Ethan A Merritt
>>  > 
>>  > another try at timestamp.h, this time using build date
>>  > 
>>  > The Makefile rule for timestamp.h was broken when we switched from
>>  > cvs to git, since it relied on ChangeLog always being current.
>>  > Proposed replacement rules have so far failed to work for out-of-tree
>>  > builds or builds from a snapshot rather than a full git clone.
>>  > This attempt simply uses the current build date, which admittedly may
>>  > not be newer than the last-modified date but at least has the virtue
>>  > of not depending on git.
>>  > 
>>  > 
>>  > However, git date reflects last commit date and not newer than build 
> date.
>>  > Build date is not later than the last commit date.
>>  > It is usually newer than the last commit date.
>> 
>>  Yes.  The text of the commit message was wrong.
>>  Sorry.
>> 
>>  I wish there was a way to edit commit messages afterwards.
>>  That is the thing I dislike the about about git so far.
> 
>        s/dislike the about about/dislike the most about/
> 
>>  You cannot go back and fix typos or errors in the commit
>>  messages.
> 
>     like that :-)
> 
> 
>>      Ethan
>> 
>>  > 
>>  > Tatsuro


The terms "last modified" indicate source modification but not build timing.
I feel that the term "last modified" is not point to the state after commit 9d0f14.

The term should also changed to be "build date and time".

Tatsuro

Re: commit 9d0f14

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

On 22 March 2018 at 04:18, sfeam wrote:
> On Thursday, 22 March 2018 04:04:26 Mojca Miklavec wrote:
>> On 22 March 2018 at 03:39, sfeam via gnuplot-beta wrote:
>> >
>> > I wish there was a way to edit commit messages afterwards.
>> > That is the thing I dislike the about about git so far.
>> > You cannot go back and fix typos or errors in the commit
>> > messages.
>>
>> You can.
>>
>> "git commit --amend" for the latest message
>> "git rebase -i HEAD~<N>" for <N> latest commits
>>
>> You can arbitrarily use these before pushing the changes to the
>> server. Once they are on the server you can still do this (with force
>> pushing)
>
> I know you can do it locally, but it does not work once it
> has been pushed to SourceForge.  The --amend and --force
> modifiers are rejected on the SourceForge end.

On github it's configurable whether you allow it, maybe even on
per-branch basis. It might be the same on SF.

>> , but you may cause inconvenience to other users who might
>> have synced the sources in the meantime, so it's not recommended.
>
> I can understand how it might cause an inconvenience if the
> change was made retrospectively to the source file itself,
> but I fail to see a problem from correcting an error in the
> commit message.

Git has integrity checking built in. Modifying commit message changes
commit shasum and people who synced end up with incompatible copies.

Modifying commit message is equally bad for git as changing files and
equally bad as stealth updates of released tarballs (package manager
fetches gcc sources and performs some checksums, but then upstream
decides to change the tarball in some minor way without changing its
filename, checksums are no longer valid and packages no longer work).

For SVN it's easier because everything lives on the server, there are
no integrity checks and commit numbers don't change.

> If I get annoyed enough I may think harder about moving the main
> repository off SourceForge.   The remote interface is very clunky.

I've been suggesting that for ages :)

Mojca

Re: commit 9d0f14

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

On Thursday, 22 March 2018 04:04:26 Mojca Miklavec wrote:
> On 22 March 2018 at 03:39, sfeam via gnuplot-beta wrote:
> >
> > I wish there was a way to edit commit messages afterwards.
> > That is the thing I dislike the about about git so far.
> > You cannot go back and fix typos or errors in the commit
> > messages.
> 
> You can.
> 
> "git commit --amend" for the latest message
> "git rebase -i HEAD~<N>" for <N> latest commits
> 
> You can arbitrarily use these before pushing the changes to the
> server. Once they are on the server you can still do this (with force
> pushing)

I know you can do it locally, but it does not work once it
has been pushed to SourceForge.  The --amend and --force
modifiers are rejected on the SourceForge end.

> , but you may cause inconvenience to other users who might
> have synced the sources in the meantime, so it's not recommended.

I can understand how it might cause an inconvenience if the
change was made retrospectively to the source file itself,
but I fail to see a problem from correcting an error in the
commit message.

If I get annoyed enough I may think harder about moving the main
repository off SourceForge.   The remote interface is very clunky.

	Ethan

 
> Mojca

Re: commit 9d0f14

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

On 22 March 2018 at 03:39, sfeam via gnuplot-beta wrote:
>
> I wish there was a way to edit commit messages afterwards.
> That is the thing I dislike the about about git so far.
> You cannot go back and fix typos or errors in the commit
> messages.

You can.

"git commit --amend" for the latest message
"git rebase -i HEAD~<N>" for <N> latest commits

You can arbitrarily use these before pushing the changes to the
server. Once they are on the server you can still do this (with force
pushing), but you may cause inconvenience to other users who might
have synced the sources in the meantime, so it's not recommended.

Mojca

Re: commit 9d0f14

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

On Wednesday, 21 March 2018 19:39:55 sfeam via gnuplot-beta wrote:
> On Thursday, 22 March 2018 10:34:14 Tatsuro MATSUOKA wrote:
> >  [9d0f14] (HEAD, master) by Ethan A Merritt Ethan A Merritt
> > 
> > another try at timestamp.h, this time using build date
> > 
> > The Makefile rule for timestamp.h was broken when we switched from
> > cvs to git, since it relied on ChangeLog always being current.
> > Proposed replacement rules have so far failed to work for out-of-tree
> > builds or builds from a snapshot rather than a full git clone.
> > This attempt simply uses the current build date, which admittedly may
> > not be newer than the last-modified date but at least has the virtue
> > of not depending on git.
> > 
> > 
> > However, git date reflects last commit date and not newer than build date.
> > Build date is not later than the last commit date.
> > It is usually newer than the last commit date.
> 
> Yes.  The text of the commit message was wrong.
> Sorry.
> 
> I wish there was a way to edit commit messages afterwards.
> That is the thing I dislike the about about git so far.

       s/dislike the about about/dislike the most about/

> You cannot go back and fix typos or errors in the commit
> messages.

    like that :-)


> 	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

Re: commit 9d0f14

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

On Thursday, 22 March 2018 10:34:14 Tatsuro MATSUOKA wrote:
>  [9d0f14] (HEAD, master) by Ethan A Merritt Ethan A Merritt
> 
> another try at timestamp.h, this time using build date
> 
> The Makefile rule for timestamp.h was broken when we switched from
> cvs to git, since it relied on ChangeLog always being current.
> Proposed replacement rules have so far failed to work for out-of-tree
> builds or builds from a snapshot rather than a full git clone.
> This attempt simply uses the current build date, which admittedly may
> not be newer than the last-modified date but at least has the virtue
> of not depending on git.
> 
> 
> However, git date reflects last commit date and not newer than build date.
> Build date is not later than the last commit date.
> It is usually newer than the last commit date.

Yes.  The text of the commit message was wrong.
Sorry.

I wish there was a way to edit commit messages afterwards.
That is the thing I dislike the about about git so far.
You cannot go back and fix typos or errors in the commit
messages.

	Ethan

> 
> Tatsuro