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

Re: gnuplot on WSL (Windows Subsystem for Linux)

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

Correction.


Un-comment  deb-src lines in the main file /etc/apt/sources.list

and 

 source /etc/apt/sources.list

Tatsuro
--- tma...@ya... wrote:
> Although I still use Cygwin but I gradually move to WSL.
> 
> I could build gnuplot on WSL(Ubunutu 16.04)
> 
> Install WSL and ubunutu
> 
> https://nickjanetakis.com/blog/using-wsl-and-mobaxterm-to-create-a-linux-dev-environment-on-windows
> 
> But I use VcXsrv as X-server instead.
> https://sourceforge.net/projects/vcxsrv/
> 
> Install gnuplot5
>  sudo apt install gnuplot5
> 
> But version is 5.0.3(OLD!!)
> However, the above sets several runtime libraries.
> 
> Un-comment  deb-src lines in the main file /etc/apt/sources.list
>  sudo apt build-dep gnuplot5
> 
> To do the above allmost build and dev tools are installed.
> 
> 
> Additional
>  sudo apt install libcaca-dev
>  sudo apt install libcerf-dev
> 
> Download 
> 
>  gnuplot-5.2.2.tar.gz
> wget https://downloads.sourceforge.net/project/gnuplot/gnuplot/5.2.2/gnuplot-5.2.2.tar.gz
> 
> Extract
> 
> tar -xvzf gnuplot-5.2.2.tar.gz
> 
> cd gnuplot-5.2.2
> 
> ./configure --with-qt=qt=5 --with-caca --with-wx-single-threaded
> (--with-wx-single-threaded is needed on my PC)
> 
> Check the configure output carefully!!
> 
> make
> make check
> sudo make install
> 
> For dev version
> install below
>  sudo apt install automake
>  sudo apt install autoconf
> 
>  sudo apt install git
> 
> 
> git clone https://git.code.sf.net/p/gnuplot/gnuplot-main gnuplot
> cd gnuplot
> ./prepare
> mkdir .build
> cd .build
> ../configure --prefix=/opt/gp530 --with-qt=qt5 --with-caca --with-wx-single-threaded
> make
> make check
> sudo make install
> 
> Build on WSL is slow due to slow fork but faster than Cygwin.
> 
> I can use flawless qt-terminal on Windows PC by WSL!!
> 
> 
> 
> 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

gnuplot on WSL (Windows Subsystem for Linux)

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

Although I still use Cygwin but I gradually move to WSL.

I could build gnuplot on WSL(Ubunutu 16.04)

Install WSL and ubunutu

https://nickjanetakis.com/blog/using-wsl-and-mobaxterm-to-create-a-linux-dev-environment-on-windows

But I use VcXsrv as X-server instead.
https://sourceforge.net/projects/vcxsrv/

Install gnuplot5
 sudo apt install gnuplot5

But version is 5.0.3(OLD!!)
However, the above sets several runtime libraries.

Un-comment  deb-src lines in the main file /etc/apt/sources.list
 sudo apt build-dep gnuplot5

To do the above allmost build and dev tools are installed.


Additional
 sudo apt install libcaca-dev
 sudo apt install libcerf-dev

Download 

 gnuplot-5.2.2.tar.gz
wget https://downloads.sourceforge.net/project/gnuplot/gnuplot/5.2.2/gnuplot-5.2.2.tar.gz

Extract

tar -xvzf gnuplot-5.2.2.tar.gz

cd gnuplot-5.2.2

./configure --with-qt=qt=5 --with-caca --with-wx-single-threaded
(--with-wx-single-threaded is needed on my PC)

Check the configure output carefully!!

make
make check
sudo make install

For dev version
install below
 sudo apt install automake
 sudo apt install autoconf

 sudo apt install git


git clone https://git.code.sf.net/p/gnuplot/gnuplot-main gnuplot
cd gnuplot
./prepare
mkdir .build
cd .build
../configure --prefix=/opt/gp530 --with-qt=qt5 --with-caca --with-wx-single-threaded
make
make check
sudo make install

Build on WSL is slow due to slow fork but faster than Cygwin.

I can use flawless qt-terminal on Windows PC by WSL!!



Tatsuro

qt terminal on Cygwin

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

I have tried the patch for qt-5.4.0 in the below thread

https://sourceforge.net/p/gnuplot/mailman/message/33212164/

For gnuplot
--- old/src/qtterminal/qt_term.cpp    2014-12-30 19:52:59.000000000 +0100
+++ new/src/qtterminal/qt_term.cpp    2015-01-04 01:25:03.219400000 +0100
@@ -273,7 +273,19 @@
     // The QLocalSocket::waitForConnected does not respect the time out argument when
     // the gnuplot_qt application is not yet started or has not yet self-initialized.
     // To wait for it, we need to implement the timeout ourselves
+#ifdef __CYGWIN__
+    QDateTime timeout = QDateTime::currentDateTime().addMSecs(5000);
+    char const * const sockname =
+            qt->socket.fullServerName().toLocal8Bit().constData();
+    do
+    {
+        usleep(300000);
+
+    } while(access(sockname, F_OK) != 0 && QDateTime::currentDateTime() < timeout);
+    timeout = QDateTime::currentDateTime().addMSecs(1000);
+#else
     QDateTime timeout = QDateTime::currentDateTime().addMSecs(30000);
+#endif
     do
     {
         qt->socket.connectToServer(server);



For qt

--- a/qtbase-opensource-src-5.4.0/src/network/socket/qlocalsocket_unix.cpp    2014-12-25 19:48:59.845052000 +0100
+++ b/qtbase-opensource-src-5.4.0/src/network/socket/qlocalsocket_unix.cpp    2014-12-25 18:41:32.359905400 +0100
@@ -240,6 +240,7 @@ void QLocalSocket::connectToServer(OpenM
                         QLatin1String("QLocalSocket::connectToServer"));
         return;
     }
+#ifndef Q_OS_CYGWIN
     // set non blocking so we can try to connect and it won't wait
     int flags = fcntl(d->connectingSocket, F_GETFL, 0);
     if (-1 == flags
@@ -248,6 +249,7 @@ void QLocalSocket::connectToServer(OpenM
                 QLatin1String("QLocalSocket::connectToServer"));
         return;
     }
+#endif
 
     // _q_connectToSocket does the actual connecting
     d->connectingName = d->serverName;


Now Qt version for cygwin is 5.9.4

However, code of corresponding part is changed to

    // create the socket
    if (-1 == (d->connectingSocket = qt_safe_socket(PF_UNIX, SOCK_STREAM, 0, O_NONBLOCK))) {
        d->errorOccurred(UnsupportedSocketOperationError,
                        QLatin1String("QLocalSocket::connectToServer"));
        return;
    }

I commented out the above


The result is

gnuplot> pl x
gnuplot> pl x
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-MATSUOKA LAB'
Could not connect to existing gnuplot_qt. Starting a new one.
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-MATSUOKA LAB'

Warning: slow font initializationgnuplot>


But the situation is the same as before modification.

Any suggestions?

I at the moment use wxt terminal on Cygwin

Tatsuro

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