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

Re: GNUPLOT script - plotting data in real time with scrolling

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

On Thu, 06 Mar 2008 18:46:07 +0100, <pl...@pi...> wrote:

Slight correction, it was the second link that was identical in content  
and clicking on the link therein to the older thread that sent Opera into  
a cpuburn loop.

Dont have time to mess further just thought I'd warn there's some mangling  
content on that site.

;)


> Dont know what kind of shit is on that link but it just sent my cpu to
> 100% ( with Opera).
>
> In fact it's identical to the original msg here so there seems little
> point in posting it.
>
> :(
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

Re: GNUPLOT script - plotting data in real time with scrolling

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

On Wed, 05 Mar 2008 12:13:33 +0100, ifryd <if...@o2...> wrote:

>
> Hi,
>
> I almost finished my master degree work but I have some problems using
> GNUPLOT script dedicated for almost real plotting on screen Wink
>
> Not so long time ago I posted this thread about visualisation data on
> screen:
>
> http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=56718&highlight=
> My previous post about plotting data on the screen
>

Dont know what kind of shit is on that link but it just sent my cpu to  
100% ( with Opera).

In fact it's identical to the original msg here so there seems little  
point in posting it.

:(

linecolor rgb bug for mesh plots ?

[kahacjde <kai...@gm...>]

Hello,

I noticed the following problem in octave3.0.0/gnuplot4.2.2 (wxt terminal).
When I try to plot a 3D mesh with "hidden on" and a rgb color set, only the
white facet without grid are drawn. 

Please have a look at the script below. If I change "set hidden" to "unset
hidden" a magenta grid is drawn, but with "set hidden" it is not (only white
facets). 

Also, if I I use 

'set style line 1 default;'

instead of 

'set style line 1 linewidth 0.500000 pointsize 1.000000 linecolor rgbcolor
"#FF00FF";'

and 'set hidden' it works as expected - a grid with hidden line removal and
the default (green) color is drawn.

Is this a bug in the script or a gnuplot problem?

Thanks in advance,
Kai 

--script starts here ---

set terminal wxt enhanced;

reset;
set autoscale fix;
set origin 0, 0;
set size 1, 1;
set size noratio;
set grid xtics;
set grid ytics;
set grid ztics;
set grid nomxtics;
set grid nomytics;
set grid nomztics;
set grid layerdefault;
set format x "%g";
set xtics border textcolor rgb "#000000";
set format y "%g";
set ytics border textcolor rgb "#000000";
set format z "%g";
set ztics border textcolor rgb "#000000";
set parametric;
set style data lines;
set surface;
#set style line 1 default;
set style line 1 linewidth 0.500000 pointsize 1.000000 linecolor rgbcolor
"#FF00FF";
set hidden3d;
set xrange [1.0:3.0] noreverse;
set yrange [1.0:3.0] noreverse;
set zrange [0.0:1.0] noreverse;
set border 895;
unset key;
set style data lines;
set ticslevel 0;
set view 60, 322.5;
splot "-" using ($1):($2):($3):($4) title "" with lines linestyle 1 ;
1 1 1 1
1 2 0 0
1 3 0 0

2 1 0 0
2 2 1 1
2 3 0 0

3 1 0 0
3 2 0 0
3 3 1 1

e


--- script end ---
-- 
View this message in context: http://www.nabble.com/linecolor-rgb-bug-for-mesh-plots---tp15873158p15873158.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

Re: POV-Ray Terminal

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

On Wed, 5 Mar 2008, Ethan Merritt wrote:

> > agree with Timothée that a pseudo-3D plot command could be  
> > accomplished, by adding in a depth dimension.
> 
> That has historically (e.g. MS Excel) led to absolutely horrible 
> plots, in which the spiffy 3D effects actively obscure 
> interpretation of the data being plotted. I will argue strongly 
> that we should not do this.

My 2 cents with Ethan.  For support, see for example Edward 
Tufte, The Visual Display of Quantitative Information. Cranking 
the dimensionality of the display artifact above the 
dimensionality of the data = obfuscation.

Allin Cottrell

Re: POV-Ray Terminal

[Ethan M. <merritt@u.washington.edu>]

On Wednesday 05 March 2008 02:14, Daniel Farrell wrote:
> Hello,
> 
> Is it a lot of work to get a working POV-ray terminal for splot? 

Please see earlier discussion thread:
   http://marc.info/?t=111331376100001&r=1&w=2


I believe POVRay is a bad choice for this purpose.
Depending on what you want to achieve, you either want an interative
terminal (e.g. OpenGL, VRML) or you want piped output to a separate
renderer.  To the best of my knowledge, POVRay is not suitable for
either of these.

> agree with Timothée that a pseudo-3D plot command could be  
> accomplished, by adding in a depth dimension.

That has historically (e.g. MS Excel) led to absolutely horrible
plots, in which the spiffy 3D effects actively obscure interpretation
of the data being plotted. I will argue strongly that we should not do this.


-- 
Ethan A Merritt

GNUPLOT script - plotting data in real time with scrolling

[ifryd <if...@o2...>]

Hi,

I almost finished my master degree work but I have some problems using
GNUPLOT script dedicated for almost real plotting on screen Wink

Not so long time ago I posted this thread about visualisation data on
screen:

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=56718&highlight=
My previous post about plotting data on the screen 

Thanks to gintaras_bar from AVR_freaks forum I received really nice script
for plotting in real time.

I tried to change it and adjust it to my needs but actually it is hard to
scroll nicly the screen in  desired speed. Additionaly some undesired plots
occur which are not connected with the samples.
Below I am enclosing these scripts:

plot_log_file.bat: 

REM batch file for starting data plot, from log file
"C:\Program Files\gnuplot422\bin\pgnuplot" init_plot.gnp 

script file for gnuplot initialization init_plot.gnp: 


#### gnuplot script, which is initializing plotting process ####
#

# this variable holds value how many lines are used to plot data already
processed_lines=0

# this constant defines how many lines_from_the_end_of_file to plot (change
according to your needs)
lines_from_the_end_of_file=3000

# this constant defines how many new data lines are received every second
(change according to your needs)
lines_per_second_received=1

# log file to be plotted
file2plot='com_port.log'

# how data should look on a screen
set style data lines

# call script, which does real time plotting
call 'real_time_plot.gnp' 

and my script file which runs real time plot real_time_plot.gnp: 


#
#### gnuplot script, which is plotting in the real time (well, almost :)  )
####
#

# this part expects one column of data per line (row) and is
# plotting lines_from_the_end_of_file if started together with logging
process.
# If started later, when file is bigger than lines_from_the_end_of_file,
# it is plotting more lines.
# if (processed_lines<lines_from_the_end_of_file) plot file2plot; else plot
file2plot every ::processed_lines-lines_from_the_end_of_file

# if you need whole file to be plotted
#plot file2plot

# if you need more columns (series) to plot
#plot file2plot using 1 title 'Col1', file2plot using 2 title 'Col2'

set tmargin 0
set bmargin 0
set lmargin 3
set rmargin 3

unset xtics

set multiplot
set origin 0,0.85
set size 1,0.15
if (processed_lines<lines_from_the_end_of_file) plot file2plot using 1; else
plot file2plot every ::processed_lines-lines_from_the_end_of_file using 1
# plot file2plot using 1

set origin 0,0.7
set size 1,0.15
if (processed_lines<lines_from_the_end_of_file) plot file2plot using 2; else
plot file2plot every ::processed_lines-lines_from_the_end_of_file using 2
#plot file2plot using 2

set origin 0,0.65
set size 1,0.05
if (processed_lines<lines_from_the_end_of_file) plot file2plot using 3; else
plot file2plot every ::processed_lines-lines_from_the_end_of_file using 3
#plot file2plot using 3

set origin 0,0.60
set size 1,0.05
if (processed_lines<lines_from_the_end_of_file) plot file2plot using 4; else
plot file2plot every ::processed_lines-lines_from_the_end_of_file using 4
#plot file2plot using 4

set origin 0,0.55
set size 1,0.05
if (processed_lines<lines_from_the_end_of_file) plot file2plot using 5; else
plot file2plot every ::processed_lines-lines_from_the_end_of_file using 5
#plot file2plot using 5

set origin 0,0.50
set size 1,0.05
if (processed_lines<lines_from_the_end_of_file) plot file2plot using 6; else
plot file2plot every ::processed_lines-lines_from_the_end_of_file using 6
#plot file2plot using 6

set origin 0,0.45
set size 1,0.05
if (processed_lines<lines_from_the_end_of_file) plot file2plot using 7; else
plot file2plot every ::processed_lines-lines_from_the_end_of_file using 7
#plot file2plot using 7

set origin 0,0.40
set size 1,0.05
if (processed_lines<lines_from_the_end_of_file) plot file2plot using 8; else
plot file2plot every ::processed_lines-lines_from_the_end_of_file using 8
#plot file2plot using 8

set origin 0,0.35
set size 1,0.05
if (processed_lines<lines_from_the_end_of_file) plot file2plot using 9; else
plot file2plot every ::processed_lines-lines_from_the_end_of_file using 9
#plot file2plot using 9

set origin 0,0.30
set size 1,0.05
if (processed_lines<lines_from_the_end_of_file) plot file2plot using 10;
else plot file2plot every ::processed_lines-lines_from_the_end_of_file using
10
#plot file2plot using 10

set origin 0,0.25
set size 1,0.05
if (processed_lines<lines_from_the_end_of_file) plot file2plot using 11;
else plot file2plot every ::processed_lines-lines_from_the_end_of_file using
11
#plot file2plot using 11

set origin 0,0.20
set size 1,0.05
if (processed_lines<lines_from_the_end_of_file) plot file2plot using 12;
else plot file2plot every ::processed_lines-lines_from_the_end_of_file using
12
#plot file2plot using 12

set origin 0,0.15
set size 1,0.05
if (processed_lines<lines_from_the_end_of_file) plot file2plot using 13;
else plot file2plot every ::processed_lines-lines_from_the_end_of_file using
13
#plot file2plot using 13

set origin 0,0.10
set size 1,0.05
if (processed_lines<lines_from_the_end_of_file) plot file2plot using 14;
else plot file2plot every ::processed_lines-lines_from_the_end_of_file using
14
plot file2plot using 14

# update variables
processed_lines=processed_lines+lines_per_second_received

# rest for 1 second
pause 1

# repeat plotting process
reread





One thing wich I cannot figure out is how many lines I am sending to the PC
via USART.

Maybe there is a way in a GNUPLOT script to plot the data from the file like
1/4 from the end of file ??

That would be the best in this case.

Anyway below I am enclosing a picture of the plot which I would like to
obtain 

http://www.nabble.com/file/p15839729/plot.png 

Additionally, maybe you have other methods for visualization. I would like
to scrool screen to see all signals.

I also posted this thread on:

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=417656#417656
the same post on www.avrfreaks.net 

Thanks in advance for various solutions and your help 


Adam - if...@o2...
-- 
View this message in context: http://www.nabble.com/GNUPLOT-script---plotting-data-in-real-time-with-scrolling-tp15839729p15839729.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

Re: POV-Ray Terminal

[Daniel F. <boy...@gm...>]

Hello,

Is it a lot of work to get a working POV-ray terminal for splot? I  
agree with Timothée that a pseudo-3D plot command could be  
accomplished, by adding in a depth dimension.

Cheers,

Dan
  

Re: Plan for incremental release of version 4.2.3

[Ethan A M. <merritt@u.washington.edu>]

On Monday 03 March 2008 19:49, you wrote:
> 
> From the below, the mouse zooming of volatile data will not be inculded in 4.2.3
> because it is an experimental trail on the cvs version.  Right?

Correct.
 
> I would like to confirm it as an octave mingw and cygwin maintainer.

So you are in a very good position to tell the rest of us when the
volatile data code seems to be stable.  If the Octave community is
happy with the code that is in cvs, we can queue it for inclusion in
the release after 4.2.3, whenever that happens.

	Ethan
 

> 
> Regards
> 
> Tatsuro
> 
> --- Ethan Merritt <merritt@u.washington.edu> wrote:
> 
> > It's been 1 year since the 4.2 release and 6 months since the 4.2.2 
> > incremental release (4.2 patchlevel 2).
> > 
> > I am thinking to release 4.2.3 (4.2 patchlevel 3) some time in the
> > next couple of weeks.  The list of accumulated changes as shown
> > in the NEWS file is appended below. Apart from some trivial new
> > features, this mostly consists of fixes for platform-specific
> > configuration issues and terminal driver bugs.  
> > 
> > In particular, this release should now self-install on OSX 10.4
> > (OSX 10.5 is still a sore point) and various platforms not using
> > the ./configure script.  It also contains the recent fix for pm3d
> > and polygon-fill support in the cgm terminal driver, broken since
> > 4.0.
> > 
> > If there is anything else you think should be included, please
> > speak up.  There are for example four recent patches to the cvs
> > development version that also apply against 4.2 and could go in
> > if wanted:
> > 
> >    cgm_rgb              Approximate RGB colors for cgm terminal
> > 			by using the web_color_rgbs from bitmap.c
> >    inline_readline      Read inline data from '-' via readline()
> >    2xbinary             allow more than 2 binary files in a single
> > 			plot command
> >    xtic_rotate_42       better estimation of space for rotated tic labels
> > 
> > 
> > 	Ethan
> > 
> > 
> > New features, changes and fixes in gnuplot version 4.2.3
> > ===========================================================
> > * NEW options front and back to "set colorbox"
> > * NEW character encoding support for emf and pdf terminals
> > * NEW "format" keyword for "set tics" and "set {x|y|...}tics"
> > * NEW allow user to set colorbar label rotatation if the bar is vertical
> > * FIX allow tic format to be given as a string variable
> > * FIX handling of negative screen coordinates on ia64, PPC
> > * FIX direction of y axis in graph coords for "set view map"
> > * FIX minitics in log scale
> > * FIX minor bugfixes to terminals fig, emf, post, svg, x11
> > * FIX cgm terminal now produces correct pm3d and pattern fill output
> > * FIX protect against overly long font names in gd, svg
> > * FIX infinite loop from x11 plot window resizing under ion, fluxbox
> > * FIX never estimate zero size for a non-empty string
> > * FIX discard degenerate polygons during hidden3d processing
> > * FIX segfault if replot is called while terminal type is unknown
> > * FIX segfault if locale obtained by getenv() is freed
> > * FIX discard axis ticks read from previous data file
> > * FIX Do not clip image against Z range in 3D splot with "set view map"
> > * FIX off-by-one error in implicit column 0 for binary data files
> > * FIX splot was trashing the default clipping boundaries for 2D plots
> > * CHANGE tweak installation scripts for OSX nt cyg dj2 mgw
> > * CHANGE install Xresource file as Gnuplot, not Gnuplot.app-defaults
> > * CHANGE Remove limitation of 10 args max to internal function sprintf()
> > * CHANGE Bring emf point types into conformity with other terminals
> > 
> > -- 
> > Ethan A Merritt
> > 
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> > 
> 
> 
> --------------------------------------
> Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar
> http://pr.mail.yahoo.co.jp/toolbar/
> 

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: cbfix

[Dr. J. Z. <joh...@ze...>]

Hi,

attached is the trivial patch.

-- 
Dr. Johannes Zellner <joh...@ze...>

2008/3/4, Petr Mikulik <mi...@ph...>:
> > the plot -- which is easily be done by "set autoscale cbfix". I heared
>  > this question about 10 or 15 times the last years. Having autoscaling
>  >
>
> > >> Having autoscaling switched on for all axes by default (so the
>  > >> default for all axes is the same) might be esthetically and
>  > >> conceptionally "correct" but it is counterintuitive.
>
>
> It's a good idea and I also propose to switch "set autoscale cbfix" by
>  default. Colours are used for visualization, so it's really wrong to have
>  them rounded down&up. Looking to other software, e.g. Matlab, the range is
>  "fixed". Actually I really don't like to use always the "fix" setting...
>
>  Why it has not been done until know? Nobody came with this idea!
>
>  It won't hurt older scripts, I guess that everybody is using "set autoscale
>  fix" for images and similar, or sets cbrange explicitly.
>
>  Johannes, can you prepare a patch for both 4.2 and cvs and test it?
>
>
>  > I am for breaking backward compatibility if it helps usability, since it
>  > can be easily fixed by putting the old setting into ~/.gnuplotrc.
>
>
> Exactly.
>
>  ---
>
> PM
>

Re: Plan for incremental release of version 4.2.3

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

Hello

> There was some discussion on pgnuplot recently ... are some fixes needed?

Those were for using pgnuplot from octave.  
I do not think that fixes are needed to the pgnuplot at least at the moment.

Regards

Tatsuro 

--------------------------------------
Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar
http://pr.mail.yahoo.co.jp/toolbar/

Re: gnuplot c++ interface segfaulting

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

On Tue, Mar 4, 2008 at 1:45 AM, Ethan Merritt wrote:
> On Monday 03 March 2008 16:30, Mojca Miklavec wrote:
>  >
>  > A minimal example includes downloading this code:
>  >      http://cheminfo.informatics.indiana.edu/~rguha/code/cc++/gnuplot_i++.tgz
>  > (from http://jijo.cjb.net/)
>  > and unzipping, making it and running an example
>  >
>  > > cd gnuplot_i++
>  > /tmp/gnuplot_i++> make
>  > g++ -c -ggdb -DDEBUGGA  example.cc
>  > g++ -c -ggdb -DDEBUGGA  gnuplot_i.cc
>  > g++ -o example -ggdb example.o gnuplot_i.o -lstdc++
>  > /tmp/gnuplot_i++> ./example
>
>  I may be missing something, but what makes you think this fault
>  involves gnuplot?  It's the example.cc program that is faulting, isn't it?

The issue has been solved in the meantime (with help of the author).

I have really thought that there is some problem with readline
library, but the problem was some missing
   #if defined(APPLE)
in the example.cc indeed.

Sorry for the noise.

Mojca

Re: cbfix

[Petr M. <mi...@ph...>]

> the plot -- which is easily be done by "set autoscale cbfix". I heared
> this question about 10 or 15 times the last years. Having autoscaling
>
> >> Having autoscaling switched on for all axes by default (so the
> >> default for all axes is the same) might be esthetically and
> >> conceptionally "correct" but it is counterintuitive.

It's a good idea and I also propose to switch "set autoscale cbfix" by 
default. Colours are used for visualization, so it's really wrong to have 
them rounded down&up. Looking to other software, e.g. Matlab, the range is 
"fixed". Actually I really don't like to use always the "fix" setting...

Why it has not been done until know? Nobody came with this idea!

It won't hurt older scripts, I guess that everybody is using "set autoscale 
fix" for images and similar, or sets cbrange explicitly.

Johannes, can you prepare a patch for both 4.2 and cvs and test it?

> I am for breaking backward compatibility if it helps usability, since it
> can be easily fixed by putting the old setting into ~/.gnuplotrc.

Exactly.

---
PM

Re: gnuplot c++ interface segfaulting

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

On Tue, Mar 4, 2008 at 1:45 AM, Ethan Merritt wrote:
> On Monday 03 March 2008 16:30, Mojca Miklavec wrote:
>  >
>  > A minimal example includes downloading this code:
>  >      http://cheminfo.informatics.indiana.edu/~rguha/code/cc++/gnuplot_i++.tgz
>  > (from http://jijo.cjb.net/)
>  > and unzipping, making it and running an example
>  >
>  > > cd gnuplot_i++
>  > /tmp/gnuplot_i++> make
>  > g++ -c -ggdb -DDEBUGGA  example.cc
>  > g++ -c -ggdb -DDEBUGGA  gnuplot_i.cc
>  > g++ -o example -ggdb example.o gnuplot_i.o -lstdc++
>  > /tmp/gnuplot_i++> ./example
>
>  I may be missing something, but what makes you think this fault
>  involves gnuplot?  It's the example.cc program that is faulting, isn't it?

Yes, but that "example" calls gnuplot. It's probably the communication
that causes problems. I do not say that there are problem in gnuplot
itself (the library could/should be improved/fixed, I guess), but it's
weird that it works for others and not for me.

I have sent this message to both the author and gnuplot list - in the
hope that either will be able to find some solution.

>  > *** example of gnuplot control through C++ ***
>  >
>  > Segmentation fault
>  >
>  > ------
>  >
>  > If I run gdb, then I get a problem in fputs reported:
>  >
>  > Program received signal EXC_BAD_ACCESS, Could not access memory.
>  > Reason: KERN_INVALID_ADDRESS at address: 0x2f706dac
>  > 0x9002990c in fputs ()
>
>  That's not nearly enough information.
>  Do one or both of the following:
>
>  1) Make sure the program is compiled with the -g option
>    Run under gdb as before
>    When is faults, type   "where"   and inspect the resulting call chain

(gdb) where
#0  0x9002990c in fputs ()
#1  0x00007230 in Gnuplot::cmd (this=0xbfffefb0, cmdstr=@0xbffef00c)
at gnuplot_i.cc:1186
#2  0x00007bcb in Gnuplot::set_title (this=0xbfffefb0,
title=@0xbfffefd4) at gnuplot_i.cc:569
#3  0x0000235a in main (argc=1, argv=0xbffff2bc) at example.cc:48

I have seen that place in the source before, but it really seems to be
the communication problem (fputs, or maybe just an unproperly
initialized stream to writo to). I don't know how to interpret these
C++ debug messages.

1186        fputs( (cmdstr+"\n").c_str(), this->gnucmd );
(gdb) step
std::operator+<char, std::char_traits<char>, std::allocator<char> >
(__lhs=@0xbffef00c, __rhs=0xd580 "\n") at basic_string.h:2083
2083          basic_string<_CharT, _Traits, _Alloc> __str(__lhs);
(gdb)
2084          __str.append(__rhs);
(gdb)
0x0000e6b4      2085          return __str;
(gdb) p __str
$1 = {
  static npos = 4294967295,
  _M_dataplus = {
    <std::allocator<char>> = {
      <__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>},
    members of std::basic_string<char,std::char_traits<char>,std::allocator<char>
>::_Alloc_hider:
    _M_p = 0xbffeeefe "??\f???????(????"
  }
}
(gdb) step

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x2f706dac
0x9002990c in fputs ()


On someone else's machine (also Mac OS X Tiger) the same sequence of
commands results in:

(gdb) b Gnuplot::cmd
Breakpoint 1 at 0x7711: file gnuplot_i.cc, line 1178.
(gdb) r
Starting program: /Users/arthur/mojca/gnuplot/test/gnuplot_i++/example
Reading symbols for shared libraries . done
*** example of gnuplot control through C++ ***


Breakpoint 1, Gnuplot::cmd (this=0xbffff1a0, cmdstr=@0xbffef1fc) at
gnuplot_i.cc:1178
1178        if( !(this->valid) )
(gdb) n
1186        fputs( (cmdstr+"\n").c_str(), this->gnucmd );
(gdb) step
std::operator+<char, std::char_traits<char>, std::allocator<char> >
(__lhs=@0xbffef1fc, __rhs=0xe274 "\n") at
/usr/include/c++/4.0.0/bits/basic_string.h:2083
2083          basic_string<_CharT, _Traits, _Alloc> __str(__lhs);
(gdb) p __str
$1 = (basic_string<char,std::char_traits<char>,std::allocator<char> >
&) @0xbffef10c: {
 static npos = 4294967295,
 _M_dataplus = {
   <allocator<char>> = {
     <new_allocator<char>> = {<No data fields>}, <No data fields>},
   members of basic_string<char,std::char_traits<char>,std::allocator<char>
>::_Alloc_hider:
   _M_p = 0x622f7773 <Address 0x622f7773 out of bounds>
 }
}
(gdb) step
2084          __str.append(__rhs);
(gdb) p __str
$2 = (basic_string<char,std::char_traits<char>,std::allocator<char> >
&) @0xbffef10c: {
 static npos = 4294967295,
 _M_dataplus = {
   <allocator<char>> = {
     <new_allocator<char>> = {<No data fields>}, <No data fields>},
   members of basic_string<char,std::char_traits<char>,std::allocator<char>
>::_Alloc_hider:
   _M_p = 0x30035c "set title \"Slopes\""
 }
}
(gdb) continue
Continuing.
*** plotting slopes
y = x

Breakpoint 1, Gnuplot::cmd (this=0xbffff1a0, cmdstr=@0xbffef1fc) at
gnuplot_i.cc:1178
1178        if( !(this->valid) )
(gdb) quit

>  2) Run the program under valgrind:
>    valgrind --tool=memcheck --leak-check=yes --num-callers=20 --leak-resolution=med --log-file=valgrind your-normal-command-line-goes-here
>    and inspect the resulting valgrind log file

valgrind doesn't seem to exist for mac, although it's currently the
highest on their priority list.

Mojca

Re: [Gnuplot-info] Problem with date format

[Thomas S. <t.s...@fz...>]

Hans-Bernhard Bröker-2 wrote:
> Thomas Sefzick wrote:
>> ...it's not so easy to repair...
>
> Nor was it easy to get working to the extent it does.  Calendars are a 
> major pain in the lower back.

i agree, it took me some hours just to get a rough idea of what the code
is doing.

>> BUT 'time_tic_just' is called for each tic, adjusting the tic to a
>> grid based on 'timelevel[axis]' 
>
> ... and just in case somebody wonders about that: yes, it is necessary. 
> That's what you get for pretending that a month were an equidistant 
> tick interval that can be sequenced, miniticked, and so on.  Well, it's 
> not, and so all major ticks have to be adjusted to actually fit on the 
> scale.
>
> I think the proper patch would involve a routine that works much like 
> quantize_time_tics(), but leaves alone the input 'tics'.

like it's done now - the only disadvantage is that 'quantize_time_tics()'
does too much, it sets 'timelevel[axis]' in a way that max. 12 or 20
tics are allowed, without changing the user-specified tics intervall (the
change is done inside 'quantize_time_tics()' and returned, but not used in
calling routine).

some simpler algorithm would be sufficient:

------------------------------------- snip
---------------------------------------------
--- axis.c.orig	2007-12-19 21:11:08.000000000 +0100
+++ axis.c	2008-03-03 20:51:18.000000000 +0100
@@ -795,8 +795,15 @@
      * effect, it defines timelevel[axis]. */
     /* HBB 20011204: moved this up --- round_outward() needs
      * timelevel[axis], too */
-    if (this->is_timedata && ticdef->type == TIC_SERIES)
-	quantize_time_tics(axis, tic, fabs(this->max - this->min), 20);
+    if (this->is_timedata && ticdef->type == TIC_SERIES) {
+	if      (tic >= 365*24*60*60.) timelevel[axis] = TIMELEVEL_YEARS;
+	else if (tic >=  28*24*60*60.) timelevel[axis] = TIMELEVEL_MONTHS;
+	else if (tic >=   7*24*60*60.) timelevel[axis] = TIMELEVEL_WEEKS;
+	else if (tic >=     24*60*60.) timelevel[axis] = TIMELEVEL_DAYS;
+	else if (tic >=        60*60.) timelevel[axis] = TIMELEVEL_HOURS;
+	else if (tic >=           60.) timelevel[axis] = TIMELEVEL_MINUTES;
+	else                           timelevel[axis] = TIMELEVEL_SECONDS;
+    }
 
     if (autoextend_min)
 	this->min = round_outward(axis, ! (this->min < this->max), this->min);
------------------------------------- snip
---------------------------------------------

this patch doesn't seem to break compatibility, at least the only official
example i could find (in 'help set xtics') works.

the patch doesn't cover strange cases like '60 days tic intervals', but
these intervals do not fit into our calendar anyway.

would it be a good idea to extend the list of gnuplot-defined variables
by YEAR_SEC, MON_SEC, WEEK_SEC, DAY_SEC ?
it would make specifying the tics interval in 'set xtics' easier.

-- 
View this message in context: http://www.nabble.com/Re%3A--Gnuplot-info--Problem-with-date-format-tp15817386p15825322.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

Re: Plan for incremental release of version 4.2.3

[Petr M. <mi...@ph...>]

> It's been 1 year since the 4.2 release and 6 months since the 4.2.2 
> incremental release (4.2 patchlevel 2).

Good idea.

> If there is anything else you think should be included, please
> speak up.  There are for example four recent patches to the cvs
> development version that also apply against 4.2 and could go in
> if wanted:
> 
>    cgm_rgb              Approximate RGB colors for cgm terminal
> 			by using the web_color_rgbs from bitmap.c
>    inline_readline      Read inline data from '-' via readline()
>    2xbinary             allow more than 2 binary files in a single
> 			plot command
>    xtic_rotate_42       better estimation of space for rotated tic labels

I agree with all.


There was some discussion on pgnuplot recently ... are some fixes needed?

---
PM

Re: Plan for incremental release of version 4.2.3

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

Dear Ethan Merritt

It's a good news.

Thank you for your every efforts for the gnuplot.!!!!! 

>From the below, the mouse zooming of volatile data will not be inculded in 4.2.3
because it is an experimental trail on the cvs version.  Right?

I would like to confirm it as an octave mingw and cygwin maintainer.

Regards

Tatsuro

--- Ethan Merritt <merritt@u.washington.edu> wrote:

> It's been 1 year since the 4.2 release and 6 months since the 4.2.2 
> incremental release (4.2 patchlevel 2).
> 
> I am thinking to release 4.2.3 (4.2 patchlevel 3) some time in the
> next couple of weeks.  The list of accumulated changes as shown
> in the NEWS file is appended below. Apart from some trivial new
> features, this mostly consists of fixes for platform-specific
> configuration issues and terminal driver bugs.  
> 
> In particular, this release should now self-install on OSX 10.4
> (OSX 10.5 is still a sore point) and various platforms not using
> the ./configure script.  It also contains the recent fix for pm3d
> and polygon-fill support in the cgm terminal driver, broken since
> 4.0.
> 
> If there is anything else you think should be included, please
> speak up.  There are for example four recent patches to the cvs
> development version that also apply against 4.2 and could go in
> if wanted:
> 
>    cgm_rgb              Approximate RGB colors for cgm terminal
> 			by using the web_color_rgbs from bitmap.c
>    inline_readline      Read inline data from '-' via readline()
>    2xbinary             allow more than 2 binary files in a single
> 			plot command
>    xtic_rotate_42       better estimation of space for rotated tic labels
> 
> 
> 	Ethan
> 
> 
> New features, changes and fixes in gnuplot version 4.2.3
> ===========================================================
> * NEW options front and back to "set colorbox"
> * NEW character encoding support for emf and pdf terminals
> * NEW "format" keyword for "set tics" and "set {x|y|...}tics"
> * NEW allow user to set colorbar label rotatation if the bar is vertical
> * FIX allow tic format to be given as a string variable
> * FIX handling of negative screen coordinates on ia64, PPC
> * FIX direction of y axis in graph coords for "set view map"
> * FIX minitics in log scale
> * FIX minor bugfixes to terminals fig, emf, post, svg, x11
> * FIX cgm terminal now produces correct pm3d and pattern fill output
> * FIX protect against overly long font names in gd, svg
> * FIX infinite loop from x11 plot window resizing under ion, fluxbox
> * FIX never estimate zero size for a non-empty string
> * FIX discard degenerate polygons during hidden3d processing
> * FIX segfault if replot is called while terminal type is unknown
> * FIX segfault if locale obtained by getenv() is freed
> * FIX discard axis ticks read from previous data file
> * FIX Do not clip image against Z range in 3D splot with "set view map"
> * FIX off-by-one error in implicit column 0 for binary data files
> * FIX splot was trashing the default clipping boundaries for 2D plots
> * CHANGE tweak installation scripts for OSX nt cyg dj2 mgw
> * CHANGE install Xresource file as Gnuplot, not Gnuplot.app-defaults
> * CHANGE Remove limitation of 10 args max to internal function sprintf()
> * CHANGE Bring emf point types into conformity with other terminals
> 
> -- 
> Ethan A Merritt
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 


--------------------------------------
Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar
http://pr.mail.yahoo.co.jp/toolbar/

pm3d palette question

[Philipp K. J. <ja...@ie...>]

Here is my question (in short):
Is it possible to adjust the slice of the spectrum
shown in the colorbox without affecting the mapping
of colors to z-values?

Here is what I try to do:

Say, I want to plot some data, the values of which
are in the range [0:100], and I want to show ALL 
the values, therefore: set zrange [0:100]

Now I have a very skewed palette, like so:
set palette defined ( 0 'red', 1 'white', 100 'blue' )

For convenience, the index in the colorbox maps
directly to the z-value.

Now I want to show in the colorbox only those colors
that map to z-values between 0 and 10, without
affecting the mapping!

Is there a way to do this?

Using set cbrange [0:10] will not do it, because this
affects the mapping. It will associate "blue" with the
z-value 10 and adjust all the intermediate values
accordingly. That's not what I am trying to do.

Any suggestions?

Best,

		Ph.

Re: gnuplot c++ interface segfaulting

[Ethan M. <merritt@u.washington.edu>]

On Monday 03 March 2008 16:30, Mojca Miklavec wrote:
> 
> A minimal example includes downloading this code:
>      http://cheminfo.informatics.indiana.edu/~rguha/code/cc++/gnuplot_i++.tgz
> (from http://jijo.cjb.net/)
> and unzipping, making it and running an example
> 
> > cd gnuplot_i++
> /tmp/gnuplot_i++> make
> g++ -c -ggdb -DDEBUGGA  example.cc
> g++ -c -ggdb -DDEBUGGA  gnuplot_i.cc
> g++ -o example -ggdb example.o gnuplot_i.o -lstdc++
> /tmp/gnuplot_i++> ./example

I may be missing something, but what makes you think this fault
involves gnuplot?  It's the example.cc program that is faulting, isn't it?


> *** example of gnuplot control through C++ ***
> 
> Segmentation fault
> 
> ------
> 
> If I run gdb, then I get a problem in fputs reported:
> 
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_INVALID_ADDRESS at address: 0x2f706dac
> 0x9002990c in fputs ()

That's not nearly enough information.
Do one or both of the following:

1) Make sure the program is compiled with the -g option
   Run under gdb as before
   When is faults, type   "where"   and inspect the resulting call chain

2) Run the program under valgrind:
   valgrind --tool=memcheck --leak-check=yes --num-callers=20 --leak-resolution=med --log-file=valgrind your-normal-command-line-goes-here
   and inspect the resulting valgrind log file



-- 
Ethan A Merritt 

Re: Plan for incremental release of version 4.2.3

[Ralf J. <jue...@cs...>]

Ethan,

It's great you're planning to do a 4.2.3 release
before the next major release! While I generally use
the cvs version on my box, our sysadmins will not
deploy cvs builds of anything.

I am gradually transitioning to passing all data
binary, so all things binary are dear to my heart.
+1 for 2xbinary.

Ralf


On Mon, 3 Mar 2008, Ethan Merritt wrote:

> It's been 1 year since the 4.2 release and 6 months since the 4.2.2
> incremental release (4.2 patchlevel 2).
>
> I am thinking to release 4.2.3 (4.2 patchlevel 3) some time in the
> next couple of weeks.  The list of accumulated changes as shown
> in the NEWS file is appended below. Apart from some trivial new
> features, this mostly consists of fixes for platform-specific
> configuration issues and terminal driver bugs.
>
> In particular, this release should now self-install on OSX 10.4
> (OSX 10.5 is still a sore point) and various platforms not using
> the ./configure script.  It also contains the recent fix for pm3d
> and polygon-fill support in the cgm terminal driver, broken since
> 4.0.
>
> If there is anything else you think should be included, please
> speak up.  There are for example four recent patches to the cvs
> development version that also apply against 4.2 and could go in
> if wanted:
>
>   cgm_rgb              Approximate RGB colors for cgm terminal
> 			by using the web_color_rgbs from bitmap.c
>   inline_readline      Read inline data from '-' via readline()
>   2xbinary             allow more than 2 binary files in a single
> 			plot command
>   xtic_rotate_42       better estimation of space for rotated tic labels
>
>
> 	Ethan
>
>
> New features, changes and fixes in gnuplot version 4.2.3
> ===========================================================
> * NEW options front and back to "set colorbox"
> * NEW character encoding support for emf and pdf terminals
> * NEW "format" keyword for "set tics" and "set {x|y|...}tics"
> * NEW allow user to set colorbar label rotatation if the bar is vertical
> * FIX allow tic format to be given as a string variable
> * FIX handling of negative screen coordinates on ia64, PPC
> * FIX direction of y axis in graph coords for "set view map"
> * FIX minitics in log scale
> * FIX minor bugfixes to terminals fig, emf, post, svg, x11
> * FIX cgm terminal now produces correct pm3d and pattern fill output
> * FIX protect against overly long font names in gd, svg
> * FIX infinite loop from x11 plot window resizing under ion, fluxbox
> * FIX never estimate zero size for a non-empty string
> * FIX discard degenerate polygons during hidden3d processing
> * FIX segfault if replot is called while terminal type is unknown
> * FIX segfault if locale obtained by getenv() is freed
> * FIX discard axis ticks read from previous data file
> * FIX Do not clip image against Z range in 3D splot with "set view map"
> * FIX off-by-one error in implicit column 0 for binary data files
> * FIX splot was trashing the default clipping boundaries for 2D plots
> * CHANGE tweak installation scripts for OSX nt cyg dj2 mgw
> * CHANGE install Xresource file as Gnuplot, not Gnuplot.app-defaults
> * CHANGE Remove limitation of 10 args max to internal function sprintf()
> * CHANGE Bring emf point types into conformity with other terminals
>
> -- 
> Ethan A Merritt
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

gnuplot c++ interface segfaulting

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

Hello,

someone working on windows has sent me some code which apparently
worked there, but is crashing/segfaulting on my mac.

I'm using Mac OS X Tiger 10.4, with gnuplot compiled from CVS
approximately 2 weeks ago (but the same problem happens with the
version provided by fink, which is 4.2 patchlevel 2). (It might have
something to do with readline perhaps?)

A minimal example includes downloading this code:
     http://cheminfo.informatics.indiana.edu/~rguha/code/cc++/gnuplot_i++.tgz
(from http://jijo.cjb.net/)
and unzipping, making it and running an example

> cd gnuplot_i++
/tmp/gnuplot_i++> make
g++ -c -ggdb -DDEBUGGA  example.cc
g++ -c -ggdb -DDEBUGGA  gnuplot_i.cc
g++ -o example -ggdb example.o gnuplot_i.o -lstdc++
/tmp/gnuplot_i++> ./example
*** example of gnuplot control through C++ ***

Segmentation fault

------

If I run gdb, then I get a problem in fputs reported:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x2f706dac
0x9002990c in fputs ()


Any idea about what could go wrong?

Thanks a lot,
    Mojca

Re: [Gnuplot-info] Problem with date format

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

Thomas Sefzick wrote:
> ...it's not so easy to repair...

Nor was it easy to get working to the extent it does.  Calendars are a 
major pain in the lower back.

Roughly said, the automatic routines handling time/date tic placement 
are best left to their own devices.  Forcing your own tic interval on 
them may work --- but it's very hard to make any guarantees there.

> BUT 'time_tic_just' is called for each tic, adjusting the tic to a
> grid based on 'timelevel[axis]' 

... and just in case somebody wonders about that: yes, it is necessary. 
  That's what you get for pretending that a month were an equidistant 
tick interval that can be sequenced, miniticked, and so on.  Well, it's 
not, and so all major ticks have to be adjusted to actually fit on the 
scale.

I think the proper patch would involve a routine that works much like 
quantize_time_tics(), but leaves alone the input 'tics'.

Plan for incremental release of version 4.2.3

[Ethan M. <merritt@u.washington.edu>]

It's been 1 year since the 4.2 release and 6 months since the 4.2.2 
incremental release (4.2 patchlevel 2).

I am thinking to release 4.2.3 (4.2 patchlevel 3) some time in the
next couple of weeks.  The list of accumulated changes as shown
in the NEWS file is appended below. Apart from some trivial new
features, this mostly consists of fixes for platform-specific
configuration issues and terminal driver bugs.  

In particular, this release should now self-install on OSX 10.4
(OSX 10.5 is still a sore point) and various platforms not using
the ./configure script.  It also contains the recent fix for pm3d
and polygon-fill support in the cgm terminal driver, broken since
4.0.

If there is anything else you think should be included, please
speak up.  There are for example four recent patches to the cvs
development version that also apply against 4.2 and could go in
if wanted:

   cgm_rgb              Approximate RGB colors for cgm terminal
			by using the web_color_rgbs from bitmap.c
   inline_readline      Read inline data from '-' via readline()
   2xbinary             allow more than 2 binary files in a single
			plot command
   xtic_rotate_42       better estimation of space for rotated tic labels


	Ethan


New features, changes and fixes in gnuplot version 4.2.3
===========================================================
* NEW options front and back to "set colorbox"
* NEW character encoding support for emf and pdf terminals
* NEW "format" keyword for "set tics" and "set {x|y|...}tics"
* NEW allow user to set colorbar label rotatation if the bar is vertical
* FIX allow tic format to be given as a string variable
* FIX handling of negative screen coordinates on ia64, PPC
* FIX direction of y axis in graph coords for "set view map"
* FIX minitics in log scale
* FIX minor bugfixes to terminals fig, emf, post, svg, x11
* FIX cgm terminal now produces correct pm3d and pattern fill output
* FIX protect against overly long font names in gd, svg
* FIX infinite loop from x11 plot window resizing under ion, fluxbox
* FIX never estimate zero size for a non-empty string
* FIX discard degenerate polygons during hidden3d processing
* FIX segfault if replot is called while terminal type is unknown
* FIX segfault if locale obtained by getenv() is freed
* FIX discard axis ticks read from previous data file
* FIX Do not clip image against Z range in 3D splot with "set view map"
* FIX off-by-one error in implicit column 0 for binary data files
* FIX splot was trashing the default clipping boundaries for 2D plots
* CHANGE tweak installation scripts for OSX nt cyg dj2 mgw
* CHANGE install Xresource file as Gnuplot, not Gnuplot.app-defaults
* CHANGE Remove limitation of 10 args max to internal function sprintf()
* CHANGE Bring emf point types into conformity with other terminals

-- 
Ethan A Merritt

Re: cbfix

[Micha W. <mw...@gm...>]

Hans-Bernhard Bröker schrieb:

>> Having autoscaling switched on for all axes by default (so the
>> default for all axes is the same) might be esthetically and
>> conceptionally "correct" but it is counterintuitive.
> 
> A note of clarification: it's not actually autoscaling that's getting
> in your way there.  It's auto-extension.  Which only happens if both 
> auto-scaling and auto-ticking are in operation.
> 
>> I would guess that it's far above 90% of cases where the colorbox
>> range should be "cbfix".  My feeling is that the default 
>> autoscaling for the colorbox is rarely wanted and used. Therefore
>> I'd suggest to turn the default to "set autoscale cbfix" (even
>> though this breaks backwards compatibility.
> 
> I'm against breaking backward compatibility for an issue that can 
> trivially be fixed by putting a line in your ~/.gnuplotrc (or other 
> platform's equivalent)

I am for breaking backward compatibility if it helps usability, since it
can be easily fixed by putting the old setting into ~/.gnuplotrc.

Re: make of gnuplot cvs djgpp failed (Newly imported Bug??)

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

Hello Ethan 

Your patch works fine!!
Thanks!!

I will distribute the binary on my web.

Tatsuro
--- Ethan A Merritt <merritt@u.washington.edu> wrote:

> On Sunday 02 March 2008 18:15, Tatsuro MATSUOKA wrote:
> > 
> > I have attemted to gnuplot cvs (2008-03-02) on the djgpp.
> > 
> > gcc -c -DHAVE_CONFIG_H -O2 -g  -I. -DHELPFILE=\"gnuplot.gih\" command.c
> > command.c:1337: error: conflicting types for 'refresh_request'
> > command.c:1332: error: previous implicit declaration of 'refresh_request' was he
> 
> Please try the 2-line fix below, or get the patched command.h file
> from cvs.
> 
> --- gnuplot/src/command.h   2007-09-01 08:45:21.000000000 -0700
> +++ gnuplot-fix/src/command.h       2008-03-02 19:34:20.000000000 -0800
> @@ -145,6 +145,8 @@
>  #ifdef USE_MOUSE
>  void bind_command __PROTO((void));
>  void restore_prompt __PROTO((void));
> +#endif
> +#ifdef VOLATILE_REFRESH
>  void refresh_request __PROTO((void));
>  #endif
>  void call_command __PROTO((void));
> 
> 
> 	Ethan
> 
> 
> 
> 
> 
> 
> 
> > re
> > make.exe: *** [command.o] Error 1
> > make.exe: Leaving directory `d:/usr/Tatsu/djgpphome/gnuplotcvs/gnuplot/src'
> > 
> > The error seems to be confiliction in terms of "refresh_request".
> > 
> > My trying comes from only curiosity so that the reply is not urgent but
> > the problem seem to be Bug newly imported bug.
> > 
> > Regards
> > 
> > Tatsuro
> > 
> > --------------------------------------
> > Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar
> > http://pr.mail.yahoo.co.jp/toolbar/
> > 
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> > 
> 
> -- 
> Ethan A Merritt
> Biomolecular Structure Center
> University of Washington, Seattle 98195-7742
> 


--------------------------------------
Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar
http://pr.mail.yahoo.co.jp/toolbar/

Re: make of gnuplot cvs djgpp failed (Newly imported Bug??)

[Ethan A M. <merritt@u.washington.edu>]

On Sunday 02 March 2008 18:15, Tatsuro MATSUOKA wrote:
> 
> I have attemted to gnuplot cvs (2008-03-02) on the djgpp.
> 
> gcc -c -DHAVE_CONFIG_H -O2 -g  -I. -DHELPFILE=\"gnuplot.gih\" command.c
> command.c:1337: error: conflicting types for 'refresh_request'
> command.c:1332: error: previous implicit declaration of 'refresh_request' was he

Please try the 2-line fix below, or get the patched command.h file
from cvs.

--- gnuplot/src/command.h   2007-09-01 08:45:21.000000000 -0700
+++ gnuplot-fix/src/command.h       2008-03-02 19:34:20.000000000 -0800
@@ -145,6 +145,8 @@
 #ifdef USE_MOUSE
 void bind_command __PROTO((void));
 void restore_prompt __PROTO((void));
+#endif
+#ifdef VOLATILE_REFRESH
 void refresh_request __PROTO((void));
 #endif
 void call_command __PROTO((void));


	Ethan







> re
> make.exe: *** [command.o] Error 1
> make.exe: Leaving directory `d:/usr/Tatsu/djgpphome/gnuplotcvs/gnuplot/src'
> 
> The error seems to be confiliction in terms of "refresh_request".
> 
> My trying comes from only curiosity so that the reply is not urgent but
> the problem seem to be Bug newly imported bug.
> 
> Regards
> 
> Tatsuro
> 
> --------------------------------------
> Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar
> http://pr.mail.yahoo.co.jp/toolbar/
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742