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

"save" does not save mouse settings - should it?

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

"save" writes out  currently defined functions, variables,  and most "set" options.
The current terminal and the last plot command are included as comments.

"save" does not write out information about current linetype definitions, 
mouse settings, or window properties.   If gnuplot is re-run later, the
linetypes and some window properties are taken from the current user's
environment or initialization files, not from loading a saved plot file.
But there is currently no way to save or restore mouse settings.

Should there be a command "save mouse"?
Should some or all mouse settings be included in the regular "save" output?
As comments?

I ran into this issue in developing a new demo illustrating forward and
reverse coordinate transforms used for map projections.
Having the mouse readout report latitude and longitude rather than
screen position required adding a new option to define the inverse
projection function. The new command is
     set mouse mouseformat function <inv-projection(x,y)>

The demo works nicely in interactive mode but
-  the new mode is not supported by offline mousing (svg, canvas terminals)
-  the inverse projection function appears nowhere in the output from "save"
    because none of the "set mouse ..." properties are saved.

Lack of saved mouse settings was already a problem if you wanted a
custom mouse output format:
   set mouse mouseformat "x: %.4f X-UNITS   y: %.2f Y-UNITS" 

	Ethan

Re: gnuplot_date[] in timestamp.h is empty building source from git in case of build directory being special

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

Commit  [ce2464] modify recipe for regenerating timestamp.h during build from git source
by Mojca solves the issue.

Thanks!

Tatsuro



----- Original Message -----
> From: Dima Kogan <gn...@di...>
> To: gnu...@li...
> Cc: 
> Date: 2018/2/14, Wed 04:32
> Subject: Re: gnuplot_date[] in timestamp.h is empty building source from git in case of build directory being special
> 
>T atsuro MATSUOKA <tma...@ya...> writes:
> 
>>  case
>> 
>>  cd (source tree)
>> 
>>  ./prepare
>>  cd ..
>>  mkdir .build
>>  cd ,build
>>  ../gnuplot-main/configure
>>  make
>> 
>>  give empty gnuplot_date[] in timestamp.h
> 
> OK, that makes sense. This patch will fix it:
> 
> diff --git a/src/Makefile.am b/src/Makefile.am
> index 9c57550f7..1ce9735a4 100644
> --- a/src/Makefile.am
> +++ b/src/Makefile.am
> @@ -110,7 +110,7 @@ timestamp.h: $(top_srcdir)/.git/${git_current} Makefile
>          @echo Making $@
>          @echo "#ifndef GNUPLOT_TIMEBASE_H_INCLUDED" >$@t
>          @echo "#define GNUPLOT_TIMEBASE_H_INCLUDED" >>$@t
> -    @echo "const char gnuplot_date[] = \"`git log -1 --format=%ci 
> | cut -b-11`\";" >>$@t
> +    @echo "const char gnuplot_date[] = \"`git --git-dir 
> '$(top_srcdir)/.git' log -1 --format=%ci | cut -b-11`\";" 
>>> $@t
>          @echo "#endif /* GNUPLOT_TIMEBASE_H_INCLUDED */" >> $@t
>          @if cmp -s $@ $@t; then rm -f $@t; else mv $@t $@; fi
> 
> If the 
> 
> ------------------------------------------------------------------------------
> 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: gnuplot_date[] in timestamp.h is empty building source from git in case of build directory being special

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

Tatsuro MATSUOKA <tma...@ya...> writes:

> case
>
> cd (source tree)
>
> ./prepare
> cd ..
> mkdir .build
> cd ,build
> ../gnuplot-main/configure
> make
>
> give empty gnuplot_date[] in timestamp.h

OK, that makes sense. This patch will fix it:

 diff --git a/src/Makefile.am b/src/Makefile.am
 index 9c57550f7..1ce9735a4 100644
 --- a/src/Makefile.am
 +++ b/src/Makefile.am
 @@ -110,7 +110,7 @@ timestamp.h: $(top_srcdir)/.git/${git_current} Makefile
         @echo Making $@
         @echo "#ifndef GNUPLOT_TIMEBASE_H_INCLUDED" >$@t
         @echo "#define GNUPLOT_TIMEBASE_H_INCLUDED" >>$@t
 -	@echo "const char gnuplot_date[] = \"`git log -1 --format=%ci | cut -b-11`\";" >>$@t
 +	@echo "const char gnuplot_date[] = \"`git --git-dir '$(top_srcdir)/.git' log -1 --format=%ci | cut -b-11`\";" >>$@t
         @echo "#endif /* GNUPLOT_TIMEBASE_H_INCLUDED */" >> $@t
         @if cmp -s $@ $@t; then rm -f $@t; else mv $@t $@; fi

If the 

gnuplot_date[] in timestamp.h is empty building source from git in case of build directory being special

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

The previous thread


gnuplot_date[] in timestamp.h is empty after "make" in building source from git

https://sourceforge.net/p/gnuplot/mailman/gnuplot-beta/thread/165023.485.qm%40web103109.mail.kks.yahoo.co.jp/#msg36223866

is not correct.
case 1:

cd (source tree)

./prepare

./configure
make

give correct gnuplot_date[] in timestamp.h


case 2:

cd (source tree)

./prepare

mkdir .build
cd .build

../configure
make

also give correct gnuplot_date[] in timestamp.h

Assuming that source tree directory name is gnuplot-main

case

cd (source tree)

./prepare
cd ..
mkdir .build
cd ,build
../gnuplot-main/configure
make

give empty gnuplot_date[] in timestamp.h


In case of cvs source, I could get correct gnuplot_date[] in timestamp.h
even in case 3.

What is happening?

Tatsuro


case 3

Re: gnuplot_date[] in timestamp.h is empty after "make" in building source from git

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

>>  I checked out git source
>>  git clone https://git.code.sf.net/p/gnuplot/gnuplot-main gnuplot 
>> 
>>  and
>> 
>>  ./prepare
>>  ./configure (options)
>>  make
>> 
>>  The produced src/timestamp.h is
>> 
>>  #ifndef GNUPLOT_TIMEBASE_H_INCLUDED
>>  #define GNUPLOT_TIMEBASE_H_INCLUDED
>>  const char gnuplot_date[] = "";
>>  #endif /* GNUPLOT_TIMEBASE_H_INCLUDED */
>> 
>>  I have observed the above on Cygwin and ubuntu 16.04.
>> 
>>  What is happening?
> 
> Works here:
> 
>   dima@scrawny:/tmp/gnuplot-main/src$ make -n timestamp.h
>   echo Making timestamp.h
>   echo "#ifndef GNUPLOT_TIMEBASE_H_INCLUDED" >timestamp.ht
>   echo "#define GNUPLOT_TIMEBASE_H_INCLUDED" >>timestamp.ht
>   echo "const char gnuplot_date[] = \"`git log -1 --format=%ci | 
> cut -b-11`\";" >>timestamp.ht
>   echo "#endif /* GNUPLOT_TIMEBASE_H_INCLUDED */" >> 
> timestamp.ht
>   if cmp -s timestamp.h timestamp.ht; then rm -f timestamp.ht; else mv 
> timestamp.ht timestamp.h; fi
> 
>   dima@scrawny:/tmp/gnuplot-main/src$ make timestamp.h 
>   Making timestamp.h
> 
>   dima@scrawny:/tmp/gnuplot-main/src$ cat timestamp.h 
>   #ifndef GNUPLOT_TIMEBASE_H_INCLUDED
>   #define GNUPLOT_TIMEBASE_H_INCLUDED
>   const char gnuplot_date[] = "2018-02-11 ";
>   #endif /* GNUPLOT_TIMEBASE_H_INCLUDED */
> 
>   dima@scrawny:/tmp/gnuplot-main/src$ git log -1 --format=%ci | cut -b-11
>   2018-02-11 
> 
> Which part of that is different for you? Note that this logic changed
> semi-recently in dd0c5adaa638647

Ah!

It seems that current mechanism does not build proper timestamp.h
in case of off-place build.

Correctly, what I have done.

git clone https://git.code.sf.net/p/gnuplot/gnuplot-main gnuplot
./prepare
mkdir build
cd build
../configure (options)
make

The aboves give empty gnuplot_date[]

If I execute on place build

git clone https://git.code.sf.net/p/gnuplot/gnuplot-main gnuplot
./prepare
./configure (options)
make

The aboves give correct gnuplot_date[]

Tatsuro

Re: gnuplot_date[] in timestamp.h is empty after "make" in building source from git

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

Tatsuro MATSUOKA <tma...@ya...> writes:

> I checked out git source
> git clone https://git.code.sf.net/p/gnuplot/gnuplot-main gnuplot 
>
> and
>
> ./prepare
> ./configure (options)
> make
>
> The produced src/timestamp.h is
>
> #ifndef GNUPLOT_TIMEBASE_H_INCLUDED
> #define GNUPLOT_TIMEBASE_H_INCLUDED
> const char gnuplot_date[] = "";
> #endif /* GNUPLOT_TIMEBASE_H_INCLUDED */
>
> I have observed the above on Cygwin and ubuntu 16.04.
>
> What is happening?

Works here:

  dima@scrawny:/tmp/gnuplot-main/src$ make -n timestamp.h
  echo Making timestamp.h
  echo "#ifndef GNUPLOT_TIMEBASE_H_INCLUDED" >timestamp.ht
  echo "#define GNUPLOT_TIMEBASE_H_INCLUDED" >>timestamp.ht
  echo "const char gnuplot_date[] = \"`git log -1 --format=%ci | cut -b-11`\";" >>timestamp.ht
  echo "#endif /* GNUPLOT_TIMEBASE_H_INCLUDED */" >> timestamp.ht
  if cmp -s timestamp.h timestamp.ht; then rm -f timestamp.ht; else mv timestamp.ht timestamp.h; fi

  dima@scrawny:/tmp/gnuplot-main/src$ make timestamp.h 
  Making timestamp.h

  dima@scrawny:/tmp/gnuplot-main/src$ cat timestamp.h 
  #ifndef GNUPLOT_TIMEBASE_H_INCLUDED
  #define GNUPLOT_TIMEBASE_H_INCLUDED
  const char gnuplot_date[] = "2018-02-11 ";
  #endif /* GNUPLOT_TIMEBASE_H_INCLUDED */

  dima@scrawny:/tmp/gnuplot-main/src$ git log -1 --format=%ci | cut -b-11
  2018-02-11 

Which part of that is different for you? Note that this logic changed
semi-recently in dd0c5adaa638647

Re: gnuplot_date[] in timestamp.h is empty after "make" in building source from git

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

> I think that it is not a bug but a git trouble.

> 
> I checked out git source
> git clone https://git.code.sf.net/p/gnuplot/gnuplot-main gnuplot 
> 
> and
> 
> ./prepare
> ./configure (options)
> make
> 
> The produced src/timestamp.h is
> 
> #ifndef GNUPLOT_TIMEBASE_H_INCLUDED
> #define GNUPLOT_TIMEBASE_H_INCLUDED
> const char gnuplot_date[] = "";
> #endif /* GNUPLOT_TIMEBASE_H_INCLUDED */
> 
> I have observed the above on Cygwin and ubuntu 16.04.
> 
> What is happening?
> 
> 
> Tatsuro
> 

On windows build, 
const char gnuplot_date[]
is set properly. Therefore git image itself perhaps does not have problems.

Tatsuro

gnuplot_date[] in timestamp.h is empty after "make" in building source from git

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

Hello

I think that it is not a bug but a git trouble.

I checked out git source
git clone https://git.code.sf.net/p/gnuplot/gnuplot-main gnuplot 

and

./prepare
./configure (options)
make

The produced src/timestamp.h is

#ifndef GNUPLOT_TIMEBASE_H_INCLUDED
#define GNUPLOT_TIMEBASE_H_INCLUDED
const char gnuplot_date[] = "";
#endif /* GNUPLOT_TIMEBASE_H_INCLUDED */

I have observed the above on Cygwin and ubuntu 16.04.

What is happening?


Tatsuro

Fwd: ACTION REQUIRED -- SourceForge Network Update for gnuplot.info

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

Someone know what to do with this? 

   Ethan

----------  Forwarded Message  ----------

Subject: ACTION REQUIRED -- SourceForge Network Update for gnuplot.info
Date: Wednesday, 07 February 2018, 23:20:35
From: SourceForge. net <no...@sl...>
To: eam...@gm...

Hello, admin of SourceForge project gnuplot:

Due to upcoming network changes at SourceForge, the IP address for hosting
gnuplot.info and www.gnuplot.info will soon change.  Because DNS for your site
is managed outside of our network, you will need to log into your domain name's
respective DNS control panel and update its IP address to point to our new
network.  We recommend performing this update as soon as possible to prevent
downtime for your site.  The former IP addresses will be retired no later than
February 14, 2018.

Please see the settings below and update the records for your domain
accordingly.  If you have any questions, don't hesitate to contact us at
sfn...@sl...

Updated DNS Settings for gnuplot.info and www.gnuplot.info:
  A-Record    216.105.38.10
  
If any of these are subdomains (like 'www.') then we recommend using a CNAME
instead of A record.
  CNAME       vhost.sourceforge.net.

If your DNS provider has a feature that lets you create an "A" record from a
domain name (sometimes called an "ANAME" virtual record) you can use
vhost.sourceforge.net for the root of a domain.

Our documentation for hosting custom domains is at
https://sourceforge.net/p/forge/documentation/Custom%20VHOSTs/

Thank you for your understanding and continued support,

--
SourceForge DevOps & Support
sfn...@sl...
-----------------------------------------

Re: more timestamp problems

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

On Mon, 29 Jan 2018, sfeam via gnuplot-beta wrote:

> On Monday, 29 January 2018 22:42:21 Dima Kogan wrote:
>
>> And also the main sf page: https://sourceforge.net/projects/gnuplot/ has
>> a nav-bar where "Code" goes to CVS and "gnuplot-main" goes to git. Can
>> whoever please make ths more sensible?
>
> I wish.
> There is no obvious way to name/rename those tabs.

I think you have to delete and recreate them.

Allin Cottrell

Re: more timestamp problems

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

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

> My interest in having a correct date is to increase the chance of
> getting complete information in a bug report.

That's definitely important, but the date is not the same as the
version, which is the thing you really want. How about we print the git
hash instead of the date? That's available in theory (in the directory
name you get from that archive).


> But I haven't had great luck in trying to create a Makefile rule that
> works.

I can write the Makefile rule, but these git-less archives lack the
necessary information. What would you like? If we can't/don't want to
get rid of those archives, how about we move to version strings, and
I'll give you a Makefile patch?

Re: more timestamp problems

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

On Monday, 29 January 2018 22:42:21 Dima Kogan wrote:
> sfeam <sf...@us...> writes:
> 
> > Your Makefile seems to be from last year sometime.
> 
> Oh yeah. My git remote was still pointing to Mojca's unofficial mirror.
> After some poking around, I found the new git repo, but it was hard to
> find. Can we (whoever has the access) please put a git link here:
> 
>   http://www.gnuplot.info/download.html

OK, although as you point out below it wouldn't be necessary if the
tabs on the main page toolbar had better labels.

> And also the main sf page: https://sourceforge.net/projects/gnuplot/ has
> a nav-bar where "Code" goes to CVS and "gnuplot-main" goes to git. Can
> whoever please make ths more sensible?

I wish.
There is no obvious way to name/rename those tabs.
The "edit" function only allows you to move them around or delete them
altogether. I've never seen any documentation for the SourceForge interface.

> OK, as for the issue at hand, what we're doing is this: (yes?)
> 
>   - We're generating a 'gnuplot_date' string to be printed out when the
>     user runs 'gnuplot'
> 
>   - If we're building from version control, we want to take the date of
>     the most recent commit
> 
>   - If we're building a release, DEVELOPMENT_VERSION will not be
>     defined, and we'll use the hard-coded string in version.c
> 
>   - If we somehow have a tarball that is NOT a release, then we have a
>     problem
> 
> I don't see any way to do this "properly", but I argue that non-release
> non-version-controlled tarballs are a bad idea, and we shouldn't be
> making them available (is turning that off an option?) If you
> care-enough to grab the bleeding edge you should be using version
> control.

Not sure I agree with that.  Unless you are already familiar with 
git (or Hg or svn or ...) that's an unnecessary extra hurdle.
 
> Or if we really want to make this code path work, I think your idea of
> simply using the current date is perfectly reasonable. At worst, we'll
> print a slightly wrong thing in the startup screen, which will then be
> ignored by the user anyway.

My interest in having a correct date is to increase the chance of getting
complete information in a bug report. But I haven't had great luck in
trying to create a Makefile rule that works.

	Ethan

Re: more timestamp problems

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

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

> Your Makefile seems to be from last year sometime.

Oh yeah. My git remote was still pointing to Mojca's unofficial mirror.
After some poking around, I found the new git repo, but it was hard to
find. Can we (whoever has the access) please put a git link here:

  http://www.gnuplot.info/download.html

And also the main sf page: https://sourceforge.net/projects/gnuplot/ has
a nav-bar where "Code" goes to CVS and "gnuplot-main" goes to git. Can
whoever please make ths more sensible?


OK, as for the issue at hand, what we're doing is this: (yes?)

  - We're generating a 'gnuplot_date' string to be printed out when the
    user runs 'gnuplot'

  - If we're building from version control, we want to take the date of
    the most recent commit

  - If we're building a release, DEVELOPMENT_VERSION will not be
    defined, and we'll use the hard-coded string in version.c

  - If we somehow have a tarball that is NOT a release, then we have a
    problem

I don't see any way to do this "properly", but I argue that non-release
non-version-controlled tarballs are a bad idea, and we shouldn't be
making them available (is turning that off an option?) If you
care-enough to grab the bleeding edge you should be using version
control.

Or if we really want to make this code path work, I think your idea of
simply using the current date is perfectly reasonable. At worst, we'll
print a slightly wrong thing in the startup screen, which will then be
ignored by the user anyway.

Sorry I have no magic insight, but this isn't a battle worth fighting, I
think.

dima

Re: more timestamp problems

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

On Monday, 29 January 2018 21:46:20 Dima Kogan wrote:
> sfeam via gnuplot-beta <gnu...@li...> writes:
> 
> > Shige Takeno points out (Bug #2016) that ./prepare; ./configure; make
> > is currently not working if you start with a git snapshot downloaded
> > from SourceForge.   That's because the snapshot is a *.zip file that
> > doesn't include the git metadata, so the attempt to create
> > timestamp.h by querying git cannot work.
> >
> > I wonder if we have control over the script on sf.net that creates
> > a snapshot?   Maybe that script could generate timestamp.h on the fly?
> >
> > Another possibility is to assume that anyone downloading a snapshot
> > will unpack it immediately, in which case the timestamp can be the
> > creation date of the top level source directory.
> 
> I want to say we're doing something we shouldn't be doing, but I can't
> quite figure out what's happening. The bug report is here:
> https://sourceforge.net/p/gnuplot/bugs/2016/
> 
> The reporter says he sees this barf:
> 
>   cut: ../.git/HEAD: No such file or directory
>   make: *** No rule to make target ../.git/', needed bytimestamp.h'. Stop.
> 
> The timestamp.h rule I see is this:
> 
>   timestamp.h: $(top_srcdir)/ChangeLog Makefile
>           @echo Making $@
>           @echo "#ifndef GNUPLOT_TIMEBASE_H_INCLUDED" >$@t
>           @echo "#define GNUPLOT_TIMEBASE_H_INCLUDED" >>$@t
>           @head -1 $< | sed -e 's,\(^[0-9-]* \).*$$,const char gnuplot_date[] = "\1";,' >>$@t
>           @echo "#endif /* GNUPLOT_TIMEBASE_H_INCLUDED */" >> $@t
>           @if cmp -s $@ $@t; then rm -f $@t; else mv $@t $@; fi

I get the same failure here.
But I see a different Makefile ruleset

BUILT_SOURCES = timestamp.h
git_current := $(shell cut -c6- $(top_srcdir)/.git/HEAD)
timestamp.h: $(top_srcdir)/.git/${git_current} Makefile
        @echo Making $@
        @echo "#ifndef GNUPLOT_TIMEBASE_H_INCLUDED" >$@t
        @echo "#define GNUPLOT_TIMEBASE_H_INCLUDED" >>$@t
        @echo "const char gnuplot_date[] = \"`git log -1 --format=%ci | cut -b-11`\";" >>$@t
        @echo "#endif /* GNUPLOT_TIMEBASE_H_INCLUDED */" >> $@t
        @if cmp -s $@ $@t; then rm -f $@t; else mv $@t $@; fi
> 
> What is invoking cut and touching git? I don't see it.

Your Makefile seems to be from last year sometime.
We used to generate timestamp.h from ChangeLog, but git and ChangeLog do not
play nicely together so Bastian modified it to query the git metadata:

%%%%%%%%%%%%
commit dd0c5adaa6386470b207838b4296491bb0b15ac3
Author: Bastian Maerkisch <bma...@we...>
Date:   Tue Dec 26 11:10:52 2017 +0100

    Generate timestamp from last git commit date
    
    Generation of the timestamp relied on the latest date in the ChangeLog.
    This may no longer be correct.  Instead, we now query git for the last
    commit date.  Only works for development builds from a git checkout, but
    for release builds the date is hard-coded in src/version.c.
%%%%%%%%%%%%

Unfortunately the new mechanism covers building from git and building
from a release tarball but not building from an auto-generated snapshot.

	Ethan

Re: more timestamp problems

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

Oh, and building gitless snapshots is what all the distros do, so they
either already crossed this hurdle, or they haven't yet hit it. I don't
see any obvious patches in Debian, but I don't understand the problem
either, so maybe I'm not looking at the right thing.

Re: more timestamp problems

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

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

> Shige Takeno points out (Bug #2016) that ./prepare; ./configure; make
> is currently not working if you start with a git snapshot downloaded
> from SourceForge.   That's because the snapshot is a *.zip file that
> doesn't include the git metadata, so the attempt to create
> timestamp.h by querying git cannot work.
>
> I wonder if we have control over the script on sf.net that creates
> a snapshot?   Maybe that script could generate timestamp.h on the fly?
>
> Another possibility is to assume that anyone downloading a snapshot
> will unpack it immediately, in which case the timestamp can be the
> creation date of the top level source directory.

I want to say we're doing something we shouldn't be doing, but I can't
quite figure out what's happening. The bug report is here:
https://sourceforge.net/p/gnuplot/bugs/2016/

The reporter says he sees this barf:

  cut: ../.git/HEAD: No such file or directory
  make: *** No rule to make target ../.git/', needed bytimestamp.h'. Stop.

The timestamp.h rule I see is this:

  timestamp.h: $(top_srcdir)/ChangeLog Makefile
          @echo Making $@
          @echo "#ifndef GNUPLOT_TIMEBASE_H_INCLUDED" >$@t
          @echo "#define GNUPLOT_TIMEBASE_H_INCLUDED" >>$@t
          @head -1 $< | sed -e 's,\(^[0-9-]* \).*$$,const char gnuplot_date[] = "\1";,' >>$@t
          @echo "#endif /* GNUPLOT_TIMEBASE_H_INCLUDED */" >> $@t
          @if cmp -s $@ $@t; then rm -f $@t; else mv $@t $@; fi

What is invoking cut and touching git? I don't see it.

more timestamp problems

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

Shige Takeno points out (Bug #2016) that ./prepare; ./configure; make
is currently not working if you start with a git snapshot downloaded
from SourceForge.   That's because the snapshot is a *.zip file that
doesn't include the git metadata, so the attempt to create
timestamp.h by querying git cannot work.

I wonder if we have control over the script on sf.net that creates
a snapshot?   Maybe that script could generate timestamp.h on the fly?

Another possibility is to assume that anyone downloading a snapshot
will unpack it immediately, in which case the timestamp can be the
creation date of the top level source directory.

	other ideas?

		Ethan

How to plot .gnu files in version 5.2

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

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

Aw: Re: Fw: Re: git equivalent to pulling the most recent date from ChangeLog?

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

> Von: "Bastian Märkisch" <bma...@we...>
> > Von: "Dima Kogan" <gn...@di...>
> > > Bastian M�rkisch <bma...@we...> writes:
> > >         @echo "#ifndef GNUPLOT_TIMEBASE_H_INCLUDED" >$@t
> > >         @echo "#define GNUPLOT_TIMEBASE_H_INCLUDED" >>$@t
> > > -       @head -1 $< | sed -e 's,\(^[0-9-]* \).*$$,const char gnuplot_date[] = "\1";,' >>$@t
> > > +       @echo "const char gnuplot_date[] = \"`git log -1 --format=%ci | cut -b-11`\";" >>$@t
> > >         @echo "#endif /* GNUPLOT_TIMEBASE_H_INCLUDED */" >> $@t
> > >         @if cmp -s $@ $@t; then rm -f $@t; else mv $@t $@; fi
> > 
> > Presumably this will barf when building from a release tarball WITHOUT
> > the git metadata (i.e. what the distros do), right? Or is timestamp.h
> > not built in those cases?
> 
> At least it wouldn't need to be built.  It's only included by src/version.c for the development
> version.  Instead, the date is hard-coded there.
> 
>   Bastian

FWIW I put a merge request on SF:
https://sourceforge.net/p/gnuplot/gnuplot-main/merge-requests/4/

Aw: Re: Fw: Re: git equivalent to pulling the most recent date from ChangeLog?

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

> Von: "Dima Kogan" <gn...@di...>
> > Bastian M�rkisch <bma...@we...> writes:
> >         @echo "#ifndef GNUPLOT_TIMEBASE_H_INCLUDED" >$@t
> >         @echo "#define GNUPLOT_TIMEBASE_H_INCLUDED" >>$@t
> > -       @head -1 $< | sed -e 's,\(^[0-9-]* \).*$$,const char gnuplot_date[] = "\1";,' >>$@t
> > +       @echo "const char gnuplot_date[] = \"`git log -1 --format=%ci | cut -b-11`\";" >>$@t
> >         @echo "#endif /* GNUPLOT_TIMEBASE_H_INCLUDED */" >> $@t
> >         @if cmp -s $@ $@t; then rm -f $@t; else mv $@t $@; fi
> 
> Presumably this will barf when building from a release tarball WITHOUT
> the git metadata (i.e. what the distros do), right? Or is timestamp.h
> not built in those cases?

At least it wouldn't need to be built.  It's only included by src/version.c for the development
version.  Instead, the date is hard-coded there.

  Bastian

Re: Fw: Aw: Re: git equivalent to pulling the most recent date from ChangeLog?

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

Bastian Mrkisch <bma...@we...> writes:

> diff --git a/src/Makefile.am b/src/Makefile.am
> index 0af79fe..9c57550 100644
> --- a/src/Makefile.am
> +++ b/src/Makefile.am
> @@ -105,11 +105,12 @@ endif
>  
>  DISTCLEANFILES = timestamp.h
>  BUILT_SOURCES = timestamp.h
> -timestamp.h: $(top_srcdir)/ChangeLog Makefile
> +git_current := $(shell cut -c6- $(top_srcdir)/.git/HEAD)
> +timestamp.h: $(top_srcdir)/.git/${git_current} Makefile
>         @echo Making $@
>         @echo "#ifndef GNUPLOT_TIMEBASE_H_INCLUDED" >$@t
>         @echo "#define GNUPLOT_TIMEBASE_H_INCLUDED" >>$@t
> -       @head -1 $< | sed -e 's,\(^[0-9-]* \).*$$,const char gnuplot_date[] = "\1";,' >>$@t
> +       @echo "const char gnuplot_date[] = \"`git log -1 --format=%ci | cut -b-11`\";" >>$@t
>         @echo "#endif /* GNUPLOT_TIMEBASE_H_INCLUDED */" >> $@t
>         @if cmp -s $@ $@t; then rm -f $@t; else mv $@t $@; fi

Re: Fw: Aw: Re: git equivalent to pulling the most recent date from ChangeLog?

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

(accidentally hit "send" prematurely. Trying again.)


Bastian Mrkisch <bma...@we...> writes:

>         @echo "#ifndef GNUPLOT_TIMEBASE_H_INCLUDED" >$@t
>         @echo "#define GNUPLOT_TIMEBASE_H_INCLUDED" >>$@t
> -       @head -1 $< | sed -e 's,\(^[0-9-]* \).*$$,const char gnuplot_date[] = "\1";,' >>$@t
> +       @echo "const char gnuplot_date[] = \"`git log -1 --format=%ci | cut -b-11`\";" >>$@t
>         @echo "#endif /* GNUPLOT_TIMEBASE_H_INCLUDED */" >> $@t
>         @if cmp -s $@ $@t; then rm -f $@t; else mv $@t $@; fi

Presumably this will barf when building from a release tarball WITHOUT
the git metadata (i.e. what the distros do), right? Or is timestamp.h
not built in those cases?

Re: git equivalent to pulling the most recent date from ChangeLog?

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

On 12/25/2017 03:20 PM, Mojca Miklavec wrote:
> On 25 December 2017 at 20:10, sfeam via gnuplot-beta wrote:
>> Building from git tip fails to insert a valid date into
>> the "last modified" field.   This used to be pulled from the
>> top of ChangeLog and inserted into timestamp.h but that
>> mechanism does not track the date of git commits.
>>
>> On that note, I see that git commits keep their original date
>> (of construction?) rather than the date they were committed.
> 
> There are two separate dates. Author date and committer date. I don't
> know how SourceForge works, but on GitHub at least the committer date
> would correspond to the timestamp of clicking the "merge" button of
> pull requests. Still, that doesn't help with you committing your local
> changes directly.
> 
>> That means "git log" returns non-sequential dates in the
>> history of changes.  That does not seem like a great idea.
>> Is there a setting somewhere that tells git to stamp each
>> commit with the current date instead?
> 
> No. Git is a distributed version control system and it doesn't treat
> SourceForge any different from your local repository.
> 
> Note that before pushing anything to the public repository you can
> arbitrarily change both author and commit timestamps of any given
> commit (you can prepare a script that will fix anything you want), but
> you cannot enforce any special setting on the server.
> 
> If you committed something 10 days ago and the development on
> SourceForge was active in the meantime, your local commit will not be
> modified, at least not automatically. If you rebase your commit, the
> author date (the one you see) will stay 10 days behind, only the
> commit date will change to match the timestamp of when you ran the
> rebase.
> 
> I'm pretty sure that it's possible for you to set up something locally
> that will modify the timestamps of your own commits before pushing to
> SourceForge, but that doesn't guarantee that any other developer will
> do the same and there's probably nothing you can do about it (short of
> being the only one with commit rights).
> 
> Also, if you cherry-pick commits from master branch to some stable
> branch, the author dates will not change.

This may be why some groups devise a strategy like doing personal 
development in separate branches then merge the branch to the master or 
stable.  Is there a new commit date associated with the merge?  That 
way, if one is interested in only the master branch, say, then the log 
can be filtered for that:

linux@ ~/gnuplot/git_repository/gnuplot-git $ git log --branches=master 
| grep '5\.2\.2'
linux@ ~/gnuplot/git_repository/gnuplot-git $ git log --all | grep '5\.2\.2'
     Bump version to 5.2.2

where 5.2.2 is on a separate branch from master.

Dan

Fw: Aw: Re: git equivalent to pulling the most recent date from ChangeLog?

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

Forgot to reply to the list.

> > On Monday, 25 December 2017 22:08:24 Bastian Märkisch wrote:
> > > > Building from git tip fails to insert a valid date into
> > > > the "last modified" field.   This used to be pulled from the
> > > > top of ChangeLog and inserted into timestamp.h but that 
> > > > mechanism does not track the date of git commits.
> > > 
> > > That might do the trick:
> > >   git log -1 --format=%ci | cut -b-10
> > > 
> > >   Bastian
> > 
> > That looks promising.
> > Can someone wrap that in the appropriate Makefile syntax to
> > substitute for the rule currently in src/Makefile.am?
> > 
> > timestamp.h: $(top_srcdir)/ChangeLog Makefile
> >         @echo Making $@
> >         @echo "#ifndef GNUPLOT_TIMEBASE_H_INCLUDED" >$@t
> >         @echo "#define GNUPLOT_TIMEBASE_H_INCLUDED" >>$@t
> >         @head -1 $< | sed -e 's,\(^[0-9-]* \).*$$,const char gnuplot_date[] = "\1";,' >>$@t
> >         @echo "#endif /* GNUPLOT_TIMEBASE_H_INCLUDED */" >> $@t
> >         @if cmp -s $@ $@t; then rm -f $@t; else mv $@t $@; fi
> > 
> > 
> > 
> > I suppose the dependency rule would become something like
> > 
> > timestamp.h: $(top_srcdir)/.git/objects Makefile
> > 
> > but how does one get "make" to track the change status of .git/objects ?
> > 
> > 	Ethan
> 
> 
> Pleae find below my attempt on a solution.  Note that the dependency
> "trick" is taken from 
> http://www.howtobuildsoftware.com/index.php/how-do/ceio/git-makefile-hook-track-branch-changes-from-a-makefile
> 
>   Bastian
> 
> diff --git a/src/Makefile.am b/src/Makefile.am
> index 0af79fe..9c57550 100644
> --- a/src/Makefile.am
> +++ b/src/Makefile.am
> @@ -105,11 +105,12 @@ endif
>  
>  DISTCLEANFILES = timestamp.h
>  BUILT_SOURCES = timestamp.h
> -timestamp.h: $(top_srcdir)/ChangeLog Makefile
> +git_current := $(shell cut -c6- $(top_srcdir)/.git/HEAD)
> +timestamp.h: $(top_srcdir)/.git/${git_current} Makefile
>         @echo Making $@
>         @echo "#ifndef GNUPLOT_TIMEBASE_H_INCLUDED" >$@t
>         @echo "#define GNUPLOT_TIMEBASE_H_INCLUDED" >>$@t
> -       @head -1 $< | sed -e 's,\(^[0-9-]* \).*$$,const char gnuplot_date[] = "\1";,' >>$@t
> +       @echo "const char gnuplot_date[] = \"`git log -1 --format=%ci | cut -b-11`\";" >>$@t
>         @echo "#endif /* GNUPLOT_TIMEBASE_H_INCLUDED */" >> $@t
>         @if cmp -s $@ $@t; then rm -f $@t; else mv $@t $@; fi
>

Re: Aw: git problem: "insufficient permission"

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

On Monday, 25 December 2017 22:19:23 Bastian Märkisch wrote:
> > All of a sudden I am getting the following error when I try to
> > push to gnuplot-main on SourceForge.   Any ideas?
> 
> I was seeing this, too.  Might be related to some SF outage - I am experiencing some error 500 for the web pages.
> It is working for now again for me.  Did you do anything to fix it?

I'm not sure.
  
I went to the URL
   https://sourceforge.net/p/gnuplot/gnuplot-main/ci/master/tree/
and when I tried to select a file to look at this triggered a spinning
icon with a message "re-analyzing repository".   When the operation
finished, things were back to normal. I don't know if that
happened only because I am a project admin and tried to access a file
or whether the same thing would have happened anyway.  
 
> Btw. where is the repo located. Can it be accessed via SF shell access?

Yes.
	ssh -t user,gn...@sh... create
    cd /home/git/p/gnuplot
    file *
		gnuplot-main.git: directory


	Cheers,

		Ethan

   
> Merry Christmas,
> 
>   Bastian
>