gnuplot-beta

fit does not accept same range parameters as plot for time data

[<pl...@pi...>]

Hi

I have subset of a datafile that I can plot with plot command by 
defining a range.
The same range parameter is refused by fit:

     f(x)=a*exp(-(x-t0)/b)+c
     format="%Y%m%d %H %M"
     set timefmt format
     set xdata time
     plot ["20150925 02 33": "20150925 07 14"] "valana.txt"  u 1:4 w l

     a=b=c=t0=1;   fit f(x)  ["20150925 02 33": "20150925 07 14"] 
"data.txt"  u 1:4 via a,b,c


data looks like this:

20150923 15 20 22.3 16.1
20150923 15 40 22.3 16.1
20150923 15 49 22.9 16.4

The fit command shows the following error:

   internal error: substring range specifiers must have integer values


I thought the intention was that the two commands functioned in a 
similar way. Why can't fit accept the range specifier in the same format 
as plot?

Regards, Peter.

Re: fit does not accept same range parameters as plot for time data

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

On Sunday, 27 September 2015 08:50:54 AM pl...@pi... wrote:
> Hi
> 
> I have subset of a datafile that I can plot with plot command by 
> defining a range.
> The same range parameter is refused by fit:
> 
>      f(x)=a*exp(-(x-t0)/b)+c
>      format="%Y%m%d %H %M"
>      set timefmt format
>      set xdata time
>      plot ["20150925 02 33": "20150925 07 14"] "valana.txt"  u 1:4 w l
> 
>      a=b=c=t0=1;   fit f(x)  ["20150925 02 33": "20150925 07 14"] 
> "data.txt"  u 1:4 via a,b,c
> 
> 
> data looks like this:
> 
> 20150923 15 20 22.3 16.1
> 20150923 15 40 22.3 16.1
> 20150923 15 49 22.9 16.4
> 
> The fit command shows the following error:
> 
>    internal error: substring range specifiers must have integer values
> 
> 
> I thought the intention was that the two commands functioned in a 
> similar way. Why can't fit accept the range specifier in the same format 
> as plot?

This doesn't answer your question of why that particular command fails,
but ...

As always, I recommend never placing a range specifier inside the
plot (or fit) command.

Instead use:

   set xrange ["20150925 02 33": "20150925 07 14"]
   plot  "valana.txt"  u 1:4 w l
   a=b=c=t0=1;   
   fit f(x) "data.txt"  u 1:4 via a,b,c

Does that work better?

	Ethan

./configure dependencies

[<pl...@pi...>]

Hi,

I'm trying to configure a CVS build on 64bit Fed22 but I'm finding some 
inconsistencies:

wxt terminal: no (requires C++, wxWidgets>2.6, cairo>0.9, pango>1.10)
   Qt terminal: no (use --with-qt or --with-qt=qt4 to enable

in order find out exactly what is missing I look further up and see:


checking whether c++ accepts -g... no
checking dependency style of c++... none
configure: WARNING: No C++ compiler found. The wxWidgets terminal will 
not be compiled.
checking for wx-config... /bin/wx-config
checking for CAIROPANGO... yes
checking for PANGO_1_10_2... no
checking for CAIROPDF... yes
checking for CAIROEPS... yes
configure: WARNING: No C++ compiler found. The Qt terminal will not be 
compiled.
checking for QT... yes


Pango detections seems broken since :

dnf install pango
Package pango-1.36.8-6.fc22.x86_64 is already installed, skipping.







Also C++ compiler is installed and stdc++ and its source are present:
Package libstdc++-5.1.1-4.fc22.x86_64 is already installed, skipping.
Package libstdc++-devel-5.1.1-4.fc22.x86_64 is already installed, 
skipping.

# which cpp
/bin/cpp
[root@localhost gnuplot]# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/5.1.1/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap 
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr 
--mandir=/usr/share/man --infodir=/usr/share/info 
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared 
--enable-threads=posix --enable-checking=release --enable-multilib 
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions 
--enable-gnu-unique-object --enable-linker-build-id 
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array 
--disable-libgcj --with-default-libstdcxx-abi=c++98 --with-isl 
--enable-libmpx --enable-gnu-indirect-function --with-tune=generic 
--with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 5.1.1 20150618 (Red Hat 5.1.1-4) (GCC)


Why is it not detecting c++ and getting the wrong idea about pango 
versions?

TIA, Peter.

Re: ./configure dependencies

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

On Tuesday, 29 September 2015 01:32:40 AM pl...@pi... wrote:
> Hi,
> 
> I'm trying to configure a CVS build on 64bit Fed22 but I'm finding some 
> inconsistencies:
> 
> wxt terminal: no (requires C++, wxWidgets>2.6, cairo>0.9, pango>1.10)
>    Qt terminal: no (use --with-qt or --with-qt=qt4 to enable
> 
> in order find out exactly what is missing I look further up and see:
> 
> 
> checking whether c++ accepts -g... no
> checking dependency style of c++... none
> configure: WARNING: No C++ compiler found. The wxWidgets terminal will 
> not be compiled.

I'd need to see the contents of config.log to figure out what went
wrong there. 

> checking for wx-config... /bin/wx-config
> checking for CAIROPANGO... yes
> checking for PANGO_1_10_2... no
> checking for CAIROPDF... yes
> checking for CAIROEPS... yes
> configure: WARNING: No C++ compiler found. The Qt terminal will not be 
> compiled.
> checking for QT... yes
> 
> 
> Pango detections seems broken since :
> 
> dnf install pango
> Package pango-1.36.8-6.fc22.x86_64 is already installed, skipping.

The build dependencies are for the *-devel package, not the library
itself.  Do you have pango-devel ?


> 
> 
> 
> 
> 
> 
> Also C++ compiler is installed and stdc++ and its source are present:
> Package libstdc++-5.1.1-4.fc22.x86_64 is already installed, skipping.
> Package libstdc++-devel-5.1.1-4.fc22.x86_64 is already installed, 
> skipping.
> 
> # which cpp
> /bin/cpp
> [root@localhost gnuplot]# gcc -v
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/5.1.1/lto-wrapper
> Target: x86_64-redhat-linux
> Configured with: ../configure --enable-bootstrap 
> --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr 
> --mandir=/usr/share/man --infodir=/usr/share/info 
> --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared 
> --enable-threads=posix --enable-checking=release --enable-multilib 
> --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions 
> --enable-gnu-unique-object --enable-linker-build-id 
> --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array 
> --disable-libgcj --with-default-libstdcxx-abi=c++98 --with-isl 
> --enable-libmpx --enable-gnu-indirect-function --with-tune=generic 
> --with-arch_32=i686 --build=x86_64-redhat-linux
> Thread model: posix
> gcc version 5.1.1 20150618 (Red Hat 5.1.1-4) (GCC)
> 
> 
> Why is it not detecting c++ and getting the wrong idea about pango 
> versions?
> 
> TIA, Peter.
> 
> 

reread doesn't

[<pl...@pi...>]

Hi

I am producing a graph ( SVG ) by using load command.

To refresh it periodically, I have a pause and a reread at the end.

The problem is the reread does NOT reread the file. I seems to have an 
internal buffer and just pretends to reread.

I can not find anything that would force an actual reread of the file.


It would be extremely useful if it did really reread the file on disk 
since this would allow another process to modify it.

I seem to recall that there was some complication with this same 
functionality needing to support pipes or direct input.

Is there not a way to force a actual reload of the file? Maybe a ' 
reread really ' option.

regards, Peter.

Re: reread doesn't

[Karl-Friedrich R. <ra...@un...>]

Am 29.09.2015 um 12:04 schrieb pl...@pi...:
> I am producing a graph ( SVG ) by using load command.
>
> To refresh it periodically, I have a pause and a reread at the end.
>
> The problem is the reread does NOT reread the file. I seems to have an 
> internal buffer and just pretends to reread.
>
> I can not find anything that would force an actual reread of the file.
>
>
> It would be extremely useful if it did really reread the file on disk 
> since this would allow another process to modify it.
>
> I seem to recall that there was some complication with this same 
> functionality needing to support pipes or direct input.
>
> Is there not a way to force a actual reload of the file? Maybe a ' 
> reread really ' option.

How about

     gnuplot -e  "while (1) {call 'plot.gp'; pause 10}"

?

Re: ./configure dependencies

[<pl...@pi...>]

Le 29.09.2015 09:51, Mojca Miklavec a écrit :
>> Also C++ compiler is installed and stdc++ and its source are present:
>> Package libstdc++-5.1.1-4.fc22.x86_64 is already installed, skipping.
>> Package libstdc++-devel-5.1.1-4.fc22.x86_64 is already installed,
>> skipping.
>> 
>> # which cpp
>> /bin/cpp
> 
> cpp is not a C++ compiler. The C++ compiler is either "g++" or "cc" or
> something along those lines.
> 
> But do send the logs as Ethan suggested.
> 
> Mojca


duh, of course, it's the pre-processor. Thanks.

however, symlinking /bin/cc does not fix it

I'll send a full log to Ethan off list

Peter

Re: reread doesn't

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

On Tuesday, 29 September 2015 12:04:04 PM pl...@pi... wrote:
> Hi
> 
> I am producing a graph ( SVG ) by using load command.
> 
> To refresh it periodically, I have a pause and a reread at the end.

You can only have one plot in an svg output file, "refresh it" is
not an option.  You would have to close it, reopen another file
with the same name, and write a new plot into it.
Is that what your script does?

"reread" only resets the input file, not the output file.
It is possible you misunderstand where the "reload" command
needs to go.  Is there an "unset output" before it?


> The problem is the reread does NOT reread the file. I seems to have an 
> internal buffer and just pretends to reread.

Not sure who you mean by "I".
If you mean gnuplot, then no.
But if you mean the operating system, then probably yes.
Gnuplot's "reread" command tells the system to go back to the
beginning of the file.  That is a "rewind" operation, not a
"close and re-open for reading" operation.

> I can not find anything that would force an actual reread of the file.
> 
> It would be extremely useful if it did really reread the file on disk 
> since this would allow another process to modify it.

No, sorry.  File systems don't work that way.  If somebody else
writes on top of a file you already have open for reading, that 
is probably not going to do what you seem to expect.

 > I seem to recall that there was some complication with this same 
> functionality needing to support pipes or direct input.
> 
> Is there not a way to force a actual reload of the file? Maybe a ' 
> reread really ' option.


	Ethan

Re: reread doesn't

[<pl...@pi...>]

Le 29.09.2015 18:14, sfeam a écrit :
> On Tuesday, 29 September 2015 12:04:04 PM pl...@pi... wrote:
> 
>> Hi
> 
>> 
> 
>> I am producing a graph ( SVG ) by using load command.
> 
>> 
> 
>> To refresh it periodically, I have a pause and a reread at the end.
> 
> You can only have one plot in an svg output file, "refresh it" is
> 
> not an option. You would have to close it, reopen another file
> 
> with the same name, and write a new plot into it.
> 
> Is that what your script does?
> 
> "reread" only resets the input file, not the output file.
> 
> It is possible you misunderstand where the "reload" command
> 
> needs to go. Is there an "unset output" before it?
> 
>> The problem is the reread does NOT reread the file. I seems to have
> an
> 
>> internal buffer and just pretends to reread.
> 
> Not sure who you mean by "I".


sorry, typo, I meant "it" ie gnuplot as you surmised.


> 
> If you mean gnuplot, then no.
> 
> But if you mean the operating system, then probably yes.
> 
> Gnuplot's "reread" command tells the system to go back to the
> 
> beginning of the file. That is a "rewind" operation, not a
> 
> "close and re-open for reading" operation.
> 
>> I can not find anything that would force an actual reread of the
> file.
> 
>> 
> 
>> It would be extremely useful if it did really reread the file on
> disk
> 
>> since this would allow another process to modify it.
> 
> No, sorry. File systems don't work that way. If somebody else
> 
> writes on top of a file you already have open for reading, that
> 
> is probably not going to do what you seem to expect.
> 
>  > I seem to recall that there was some complication with this same
> 
>> functionality needing to support pipes or direct input.
> 
>> 
> 
>> Is there not a way to force a actual reload of the file? Maybe a '
> 
>> reread really ' option.
> 
>  Ethan


Thanks, reread is basically doing a seek(0), not a close and open which 
I what I was looking for, which is why I was looking for "reread really" 
type solution. Reread does what it says, in fact.

  What I was needing was a 'reload'.  That would indeed require closing 
the output file before using it.


Yes, I do close the svg by unset output;

regard, Peter.