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

Re: what's up with SourceForge

[Hans-Bernhard B. <br...@ph...>]

On Mon, 3 May 2004, James R. Van Zandt wrote:

> BTW when I do "cvs update" I get several complaints like this:
> 
> cvs update: conflict: tutorial/Makefile.in is modified but no longer
> in the repository

Then you must have neglected to update in ages.  tutorial/Makefile.in
has been removed from the repository since January 2003.

> What's the best way of getting rid of them?  

Delete all files you get this complaint about, then run

	cvs update
	./prepare

> I.e. how to I accept the
> deletion of a file from the repository?  Should I just delete the line
> in tutorial/CVS/Entries that starts out with "/Makefile.in" ?

No.  Never muck with CVS' private files unless you absolutely have to.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: unexpected "replot" in "pause mouse"

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

> Summary:
>
> The extra replot in mouse.c was my attempt to handle "pause mouse"
> in a terminal-independent fashion.  Without it there were indeed
> problems with term->waitforinput().
>
> Petr points out that X11 is still the only terminal supporting
> pause for mouse (I thought windows and/or os2 did also but I was
> wrong).  So I will pull this code out of mouse.c and handle it directly
> in x11.trm.  This avoids the replot, and introduces no new problems
> that I can see.

I'm sorry I always complain a bit ... some eaten chars again ... this works
when pasting the text from clipboard by mouse:

plot x
pause mouse
plot 1-x

but this eats one character:


plot x
pause -1
plot 1-x


> It does mean, however, that equivalent code will be needed
> in other terminal drivers if and when they choose to support
> pause for mouse.

It should be anyway, as they use different technology for pausing (hotkey
in menu, message box, etc).

Petr

Re: Fun with VMS, TBOOLEAN, macro definitions and DECC

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

On Monday 03 May 2004 10:22 pm, Lucas Hart wrote:
>
> What VMS and CRTL version do you have and do you generate DESCRIP.MMS
> or BUILD.COM?

OpenVMS 6.1-1h2
DEC C V5.0-003
I can't remember where to find a separate CRTL version.
I told it @CONFIGURE.VMS DECC COM 

> > This syntax doesn't work because of the trailing semicolons.
> > I propose to replace it with the standard work-around:
> > #define GO(x) \
> > do {...} while (0)
>
> A simpler fix is
>   if (something) {
>     PRINT0(...);
>   } else if (something) {
>     PRINT1(...);
>   }

The drawback there is that you have to know that PRINTn() is a macro
rather than a function in order to write correct C code.  The form I
gave is preferable because once the macro is defined correctly then
you don't have to worry about it elsewhere in the code.
Also, changing the macro affects only the VMS build,
whereas changing code elsewhere potentially affects all platforms.

I made this change in cvs.

> > Sure enough - both set.c and unset.c try to call strdup() directly
> > rather than going through gp_strdup().  That fails if the system does
> > not provide strdup().

Now fixed in cvs.

> I fixed that by making the add_history() call in show.c conditional on
>    #ifdef READLINE
> as it is in command.c

Right. I have fixed that one in cvs also.

> Try putting
> #define HAVE_TIME_T_IN_TIME_H 1
> in config.h.
>
> Haven't assembled my source code changes into a patch file yet :-(

I'm not going to touch the VMS configuration files per se;  my VMS machine
is old and hardly maintained, and I'm not about to spend any time on 
figuring out why it has configuration problems.  I am more interested in it
as just another quirky platform that reveals fixable coding errors.  A couple
of the TBOOLEAN error messages reveal actual code errors, for instance
(arithmetic tests against 0 or 1 rather than logical tests).  I am collecting
these for a general code cleanup pass later on.

-- 
Ethan A Merritt
Department of Biochemistry & Biomolecular Structure Center
University of Washington, Seattle

Re: Fun with VMS, TBOOLEAN, macro definitions and DECC

[<ha...@on...>]

On Mon, May 03, 2004 at 05:48:58PM -0700, Ethan Merritt wrote:
> Disclaimer:
> I had never built, nor run, gnuplot under VMS until today.
> I was just curious, and this is what I found.

I'm working on updating CONFIGURE.VMS to gnuplot v4.0.0 and have
encountered the same behaviour that you report.  I want to make
make sure my build fixes are incorporated into the script rather 
than only as edits to my working config.h, so the configuration 
script is not quite ready for testing.

What VMS and CRTL version do you have and do you generate DESCRIP.MMS 
or BUILD.COM?

> 
> %%%%%%%%% Unhappy TBOOLEANs
> 
> $ cc /DEFINE=(NO_GIH,HAVE_CONFIG_H,DECCRTL)/INCLUDE=[-]/PREFIX=ALL axis.c
> 
>     TBOOLEAN checkrange;
> .............^
> %CC-W-PROMOTMATCHW, In the definition of the function "axis_unlog_interval",
> the promoted type of checkrange is incompatible with the type of the corresponding
> parameter in a prior declaration.
> at line number 188 in file $DISK1:[MERRITT.GNUPLOT.SRC]AXIS.C;1
> 

Do you have stdbool.h?  If so, define HAVE_STDBOOL in config.h

Question: why is _Bool defined as unsigned char in syscfg.h? 
My understanding is that C99 types it as unsigned int, which DECC
appears to expect.

> %%%%%%%%%%% Bad macro syntax in x11.trm
> 
> And this one in x11.trm, which must not have been tested in ages:
> 
> #define GO(x) \
> { \
>    char buffer[512]; int status; struct iosb iosb;\
>    [lots of complicated stuff]
>    if((status & SS$_NORMAL) != SS$_NORMAL) exit(status); \
>  }
> 
> #define PRINT0(fmt)          GO( (buffer, fmt) )
> #define PRINT1(fmt,p1)       GO( (buffer, fmt,p1) )
> 
> 
> if (something)
> 	PRINT0(...);
> else if (something)
> 	PRINT1(...);
> 
> This syntax doesn't work because of the trailing semicolons.
> I propose to replace it with the standard work-around:
> #define GO(x) \
> do {...} while (0)
> 

A simpler fix is 
  if (something) {
    PRINT0(...); 
  } else if (something) {
    PRINT1(...);
  }

> %%%%%%%%%%%%% failure to use local routines if necessary
> 
> %LINK-W-NUDFSYMS, 2 undefined symbols:
> %LINK-I-UDFSYM,         ADD_HISTORY 
> %LINK-I-UDFSYM,         STRDUP 
> %LINK-W-USEUNDEF, undefined symbol STRDUP referenced
>         in psect $LINK$ offset %X00000C50
>         in module SET file $DISK1:[MERRITT.GNUPLOT.SRC]SET.OBJ;1
> %LINK-W-USEUNDEF, undefined symbol ADD_HISTORY referenced
>         in psect $LINK$ offset %X00001490
>         in module SHOW file $DISK1:[MERRITT.GNUPLOT.SRC]SHOW.OBJ;1
> %LINK-W-USEUNDEF, undefined symbol STRDUP referenced
>         in psect $LINK$ offset %X000006D0
>         in module UNSET file $DISK1:[MERRITT.GNUPLOT.SRC]UNSET.OBJ;1
> 
> Sure enough - both show.c and unset.c try to call strdup() directly
> rather than going through gp_strdup().  That fails if the system does
> not provide strdup().
> 

Yes - presumably an oversight.

> I don't know what the problem is with add_history() in show.c;
> the same function call seems to have been resolved correctly at
> other call sites.
> 

I fixed that by making the add_history() call in show.c conditional on 
   #ifdef READLINE
as it is in command.c
   
> %%%%%%%%%%%%%%  various type checking
> 
> The type of time_t seems to have been picked up incorrectly.
> This results in many warning messages, but it may well be due
> to my extremely minimal VMS configuration.
> 

Try putting 
#define HAVE_TIME_T_IN_TIME_H 1
in config.h.

Haven't assembled my source code changes into a patch file yet :-(

-- Lucas Hart                 <ha...@on...>

Whats up with SourceForge (again)

[<ha...@on...>]

- Using ViewCVS to access the gnuplot branch gives a Python error 
  (the faq banch is OK)
- archives of the gnuplot-beta and gnuplot-bugs mail lists are not 
  current

-- Lucas Hart                  <ha...@on...>

Re: what's up with SourceForge

[James R. V. Z. <jr...@co...>]

Hans-Bernhard Broeker <br...@ph...> wrote:
>I.e. working copies checked out from cvs.gnuplot.sourceforge.net
>before, you'll have to move over to cvs.sourceforge.net.

I suggest this one-liner:

for x in `find . -name Root`; do \
  sed s/cvs.gnuplot.sourceforge.net/cvs.sourceforge.net/ $x > foo && \
  mv foo $x; done


BTW when I do "cvs update" I get several complaints like this:

cvs update: conflict: tutorial/Makefile.in is modified but no longer
in the repository

What's the best way of getting rid of them?  I.e. how to I accept the
deletion of a file from the repository?  Should I just delete the line
in tutorial/CVS/Entries that starts out with "/Makefile.in" ?

       - Jim Van Zandt

Fun with VMS, TBOOLEAN, macro definitions and DECC

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

Disclaimer:
I had never built, nor run, gnuplot under VMS until today.
I was just curious, and this is what I found.

%%%%%%%%% Unhappy TBOOLEANs

$ cc /DEFINE=(NO_GIH,HAVE_CONFIG_H,DECCRTL)/INCLUDE=[-]/PREFIX=ALL axis.c

    TBOOLEAN checkrange;
.............^
%CC-W-PROMOTMATCHW, In the definition of the function "axis_unlog_interval",
the promoted type of checkrange is incompatible with the type of the corresponding
parameter in a prior declaration.
at line number 188 in file $DISK1:[MERRITT.GNUPLOT.SRC]AXIS.C;1

    TBOOLEAN upwards;           /* extend upwards or downwards? */
.............^
%CC-W-PROMOTMATCHW, In the definition of the function "round_outward",
the promoted type of upwards is incompatible with the type of the corresponding
parameter in a prior declaration.
at line number 747 in file $DISK1:[MERRITT.GNUPLOT.SRC]AXIS.C;1

... and so forth in many other places.

%%%%%%%%%%% Bad macro syntax in x11.trm

And this one in x11.trm, which must not have been tested in ages:

#define GO(x) \
{ \
   char buffer[512]; int status; struct iosb iosb;\
   [lots of complicated stuff]
   if((status & SS$_NORMAL) != SS$_NORMAL) exit(status); \
 }

#define PRINT0(fmt)          GO( (buffer, fmt) )
#define PRINT1(fmt,p1)       GO( (buffer, fmt,p1) )


if (something)
	PRINT0(...);
else if (something)
	PRINT1(...);

This syntax doesn't work because of the trailing semicolons.
I propose to replace it with the standard work-around:
#define GO(x) \
do {...} while (0)

%%%%%%%%%%%%% failure to use local routines if necessary

%LINK-W-NUDFSYMS, 2 undefined symbols:
%LINK-I-UDFSYM,         ADD_HISTORY 
%LINK-I-UDFSYM,         STRDUP 
%LINK-W-USEUNDEF, undefined symbol STRDUP referenced
        in psect $LINK$ offset %X00000C50
        in module SET file $DISK1:[MERRITT.GNUPLOT.SRC]SET.OBJ;1
%LINK-W-USEUNDEF, undefined symbol ADD_HISTORY referenced
        in psect $LINK$ offset %X00001490
        in module SHOW file $DISK1:[MERRITT.GNUPLOT.SRC]SHOW.OBJ;1
%LINK-W-USEUNDEF, undefined symbol STRDUP referenced
        in psect $LINK$ offset %X000006D0
        in module UNSET file $DISK1:[MERRITT.GNUPLOT.SRC]UNSET.OBJ;1

Sure enough - both show.c and unset.c try to call strdup() directly
rather than going through gp_strdup().  That fails if the system does
not provide strdup().

I don't know what the problem is with add_history() in show.c;
the same function call seems to have been resolved correctly at
other call sites.

%%%%%%%%%%%%%%  various type checking

The type of time_t seems to have been picked up incorrectly.
This results in many warning messages, but it may well be due
to my extremely minimal VMS configuration.

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: [ gnuplot-Feature Requests-927249 ] Allow filledcurve color to based on whether above/below axis

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

> I had in mind a further extension to allow both
> 	plot sin(x) with filledcurve below y1=f(x)
> 	plot 'data' using 1:2 with filledcurve above y1=f(x)
>
> But your suggestion above is a better idea, at least for
> the data case, because it uses existing function evaluation
> code:
> 	plot 'data' using 1:2:(f($1)) with filledcurve
>
> That leaves a few questions:
>
> Do we allow "above" and "below" in this case?

Yes

> I think it reasonable that
> 	plot 'data' using 1:2:(f($1)) with filledcurve above
> would fill only those areas where $2 > f($1)

Ys

> What exactly should be filled if f(x) is undefined at a given x?
> Or in the case of two datasets, what if one of the datasets
> has a missing value?

It should be equivalent to the case when the y-axis point (like $2 above)
data point is undefined or missing.


---
PM

Re: unexpected "replot" in "pause mouse"

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

On Monday 03 May 2004 03:38 am, Hans-Bernhard Broeker wrote:
>
> IIRC it's one of the many disguises the buffering / select() problem in
> X11_waitforinput() shows it self in.

Summary:

The extra replot in mouse.c was my attempt to handle "pause mouse"
in a terminal-independent fashion.  Without it there were indeed 
problems with term->waitforinput().

Petr points out that X11 is still the only terminal supporting
pause for mouse (I thought windows and/or os2 did also but I was
wrong).  So I will pull this code out of mouse.c and handle it directly
in x11.trm.  This avoids the replot, and introduces no new problems
that I can see.

It does mean, however, that equivalent code will be needed 
in other terminal drivers if and when they choose to support
pause for mouse.

Change made in CVS on 3 May 2004.

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: unexpected "replot" in "pause mouse"

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

> You probably remember that there were many, many problems
> with replot and mouse clicks over the last year.  The line you are
> complaining about was added to fix some of these problems.

yes, it comes in circles ... I wish it will converge...

> > - In Octave, I have to write
> > 	graw('pause mouse\n\n');
> >   instead of
> > 	graw('pause mouse\n');
> >   otherwise first character from the next command is eaten.
>
> Now that is a real problem, which I thought had been fixed.
> Is this before or after you removed the replot command?

After

> > The "replot" should go away, as it is an unexpected feature.
>
> But what does it harm?  If you can figure out a way to remove
> it that doesn't introduce worse problems, then fine.

It could react to interactive vs non-interactive mode of gnuplot.
(Your new patch is also OK.)


It harms because I'm using "ginput.m" under Octave (as on Octave www site).
I need to get 4 coordinates from a color map, one pair of coordinates after
another -- and it's awfully slow and boring when gnuplot redraws the map
after each click.


(And thus also -- I'm looking forward for the updated "with image" patch...)

> - If you control-C out of 'pause mouse' then subsequent
>   commands generate a "mousing not active" error message

---
PM

Re: unexpected "replot" in "pause mouse"

[Hans-Bernhard B. <br...@ph...>]

On Sun, 2 May 2004, Ethan A Merritt wrote:

> >   otherwise first character from the next command is eaten.
> 
> Now that is a real problem, which I thought had been fixed.

IIRC it's one of the many disguises the buffering / select() problem in
X11_waitforinput() shows it self in.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: unexpected "replot" in "pause mouse"

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

On Sunday 02 May 2004 08:10 am, Petr Mikulik wrote:
> The reason is in mouse.c:
>
>  /* Terminate via replot if we are in 'pause mouse' */
>  /* FIXME EAM: untested for mouse devices other than X11 */
>  if (paused_for_mouse) {
>     paused_for_mouse = FALSE;
>     do_string("replot");
>     fputc('\n', stderr);
>  }
>
> It works fine with the "replot" being removed;

You probably remember that there were many, many problems
with replot and mouse clicks over the last year.  The line you are
complaining about was added to fix some of these problems.
I don't claim that the fix is perfect, but removing it will re-introduce
other bad behaviour.

> however, under X11:
> 	gnuplot> pause mouse
>   does not return to the prompt "gnuplot> " afterwards

Yeah.  Exactly. And that's not the only consequence.

> - In Octave, I have to write
> 	graw('pause mouse\n\n');
>   instead of
> 	graw('pause mouse\n');
>   otherwise first character from the next command is eaten.

Now that is a real problem, which I thought had been fixed.
Is this before or after you removed the replot command?

> The "replot" should go away, as it is an unexpected feature.

But what does it harm?  If you can figure out a way to remove
it that doesn't introduce worse problems, then fine.  But just
commenting out the line of code causes at least these bad
side effects that I can remember.  There may well be others
I forgotten in detail.

- No prompt to tell the user that the mouse click has been 
  processed

- The missing prompt is diagnostic of a deeper problem, 
  that gnuplot itself does not yet realize the operation is
  finished.  For example, try '  load "mousevariables.dem"'
  and you will see that the demo fails unless you type
  extra carriage returns.

- If you control-C out of 'pause mouse' then subsequent
  commands generate a "mousing not active" error message

-- 
Ethan A Merritt
Department of Biochemistry & Biomolecular Structure Center
University of Washington, Seattle

unexpected "replot" in "pause mouse"

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

When using "mouse pause" in Octave together with the "ginput.m" routine
which waits for mouse clicks, I've noticed gnuplot redraws the plot after
each click.
I want to get rid of this -- mouse is not changing anything on the
plot, thus redraw is not necessary.

The reason is in mouse.c:

 /* Terminate via replot if we are in 'pause mouse' */
 /* FIXME EAM: untested for mouse devices other than X11 */
 if (paused_for_mouse) {
    paused_for_mouse = FALSE;
    do_string("replot");
    fputc('\n', stderr);
 }

It works fine with the "replot" being removed; however, under X11:
- running
	gnuplot> pause mouse
  does not return to the prompt "gnuplot> " afterwards

- In Octave, I have to write
	graw('pause mouse\n\n');
  instead of
	graw('pause mouse\n');
  otherwise first character from the next command is eaten.

Maybe both have the same reason?

The "replot" should go away, as it is an unexpected feature.


---
PM

Re: [ gnuplot-Feature Requests-927249 ] Allow filledcurve color to based on whether above/below axis

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

I'm switching this to the mailing list because it's much more convenient
for discussion than using the SourceForge  interface. 

On Friday 30 April 2004 10:52 am, Petr Milulik wrote:
>
> > 'set style function filledcurve'.
>
> No, this I would not support, currently you cannot use
> "using" for functions.
> However,
>    'a.dat' using 1:2:(sin($1))
> would work.

But currently you can do
	plot sin(x) with filledcurve y1=0.5

The existing patch extends this to
	plot sin(x) with filledcurve below y1=0.5

I had in mind a further extension to allow both
	plot sin(x) with filledcurve below y1=f(x)
	plot 'data' using 1:2 with filledcurve above y1=f(x)

But your suggestion above is a better idea, at least for 
the data case, because it uses existing function evaluation
code:
	plot 'data' using 1:2:(f($1)) with filledcurve

That leaves a few questions:

Do we allow "above" and "below" in this case?
I think it reasonable that
	plot 'data' using 1:2:(f($1)) with filledcurve above
would fill only those areas where $2 > f($1) 

What exactly should be filled if f(x) is undefined at a given x?
Or in the case of two datasets, what if one of the datasets
has a missing value?

> > By contrast, drawing a filled region bounded by two
> > arbitrary curves requires storing twice as much information
> > for the plot.
>
> I don't think that's difficult.

I agree.  I said it would be fairly easy. My only reservation was 
that it requires code changes in more places than the simpler
case of a bounding line.

	Ethan



> At graphics.c:1832:
>  for (i = 0; i < plot->p_count; i++) {
> there is
> 	x = map_x(plot->points[i].x);
> 	y = map_y(plot->points[i].y);
> so plotting wrt 3 columns would have
> 	y2 = map_y(plot->points[i].z);
> ...I think that parser for plotting wrt 3 columns puts the
> 3rd column number into z.
>
> Then the INRANGE/OUTRANGE cases would have to go in between
> crossing points in between those 2 curves using max(y,y2),
> and make a circle -- i.e., instead of finish_filled_curve(),
> it should do the 2nd round back using values min(y,y2).
>
>
> ----------------------------------------------------------------------
>
> Comment By: Ethan Merritt (sfeam)
> Date: 2004-04-30 16:06
>
> Message:
> Logged In: YES
> user_id=235620
>
> Petr wrote>
>
> > I would propose to submit it to cvs, as it is a valuable
> > feature for the curretion version of gnuplot.
>
> Hold off a bit. Steve claims to have found a case where my
> patch gets the sidedness wrong, although so far I have not
> been able to reproduce the problem. We're pursuing the
> discrepancy in private Email.
>
> >Another great enhancement would be
> >   plot 'a.dat' using 1:2:3 with filledcurve
> >where the filled area would be in between
> > y-points of columns 2 and 3.
>
> The ability to fill an area between two curves has been
> requested a number of times before. I thought there was an
> existing RFE here on SourceForge, but I can't see it now.
> Anyhow, this would be a much more extensive change than the
> simple bounding-line patch I gave here. The code to draw
> filled polygons bounded by a line was already present.  All
> I had to do was make sure that any line segment crossing the
> bounding line is broken into two pieces so that no single
> polygon ever spans both sides of the boundary.
>
> By contrast, drawing a filled region bounded by two
> arbitrary curves requires storing twice as much information
> for the plot.  As you show, it requires an additional input
> column. Or, I suppose, two bounding equations in the case of
> 'set style function filledcurve'.  This means that it is
> effectively a new plot style, and would require adding new
> code in a lot of places.  I think this would be fairly easy,
> but still it would be a bigger project than my simple patch
> here. Certainly it goes way beyond what could be considered
> a bug-fix for version 4.0
>
> So yeah, I agree it would be a very nice, fairly
> straightforward addition. But it can wait until the next
> round of development.
>
> ----------------------------------------------------------------------
>
> Comment By: Petr Mikulik (mikulik)
> Date: 2004-04-30 10:00
>
> Message:
> Logged In: YES
> user_id=31505
>
> I like this patch!
>
> I would propose to submit it to cvs, as it is a valuable
> feature for the curretion version of gnuplot.
>
> Another great enhancement would be
>    plot 'a.dat' using 1:2:3 with filledcurve
> where the filled area would be in between y-points of
> columns 2 and 3.
> Could you please try to implement this as well?
>
>
> ----------------------------------------------------------------------
>
> Comment By: Ethan Merritt (sfeam)
> Date: 2004-04-29 22:00
>
> Message:
> Logged In: YES
> user_id=235620
>
> Heh.  A minor, but dramatic, oversight on my part. Here's a
> revised patchset that might actually work.
>
> ----------------------------------------------------------------------
>
> Comment By: Steve Weiss (sweiss_1966)
> Date: 2004-04-29 15:11
>
> Message:
> Logged In: YES
> user_id=939458
>
> It's different, but not correct.  it looks like you figuring out
> the bounding area to fill, you draw a line from the current
> point to the previous data point as opposed to the current
> point to the previous point where the x-axis was crossed (if
> that makes sense).
>
> I have attached a sample image for you to look at.  Please let
> me know if you need a copy of my test script.
>
> Thanks for all the help!
> Steve
>
> ----------------------------------------------------------------------
>
> Comment By: Ethan Merritt (sfeam)
> Date: 2004-04-29 06:26
>
> Message:
> Logged In: YES
> user_id=235620
>
> Give this patchset a try. It adds new modifiers "above" and
> "below" to the filledcurve style. They apply only to the
> case of explicit bounds. For example:
>   plot 'data' with filledcurve above y1=3.4
>
> I have not done much testing of this code.  Please check
> whether it does what you want, and if so give it a thorough
> workout. In particular I did not do anything special for
> curves that go out of range. It may just work, or it may
> need special-case code added.
>
> ----------------------------------------------------------------------
>
> Comment By: Petr Mikulik (mikulik)
> Date: 2004-04-08 09:56
>
> Message:
> Logged In: YES
> user_id=31505
>
> Make your graph by plotting the same curve twice, and
> probably with this trick:
>
>   plot (f(x)>g(x) ? f(x) : 1/0)
>
>
> ----------------------------------------------------------------------
>
> You can respond by visiting:
> https://sourceforge.net/tracker/?func=detail&atid=352055&aid=927249&grou
>p_id=2055

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: docs/gpcard.tex

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

> 'x11' sets the TERM_INIT_ON_REPLOT flag, 'X11' doesn't.
>
> I see little reason to keep the terminal driver X11 itself at all.

Yes, as it is undocumented, hardly anybody can use it.

--
PM

Re: what's up with SourceForge

[Hans-Bernhard B. <br...@ph...>]

On Thu, 29 Apr 2004, Ethan Merritt wrote:

> Anyone know why attempting to access the cvs tree
> produces the following error?  This has been going
> on since yesterday, at least.
> 
> [~/cvs] cvs -z3 update gnuplot
> Cannot access /cvsroot/gnuplot/CVSROOT
> No such file or directory

Quoth "Site Status":

 2004-04-29 14:11:35 - Project CVS Service )   As of 2004-04-28 the CVS 
services will no longer function with the hostname of 
cvs.PROJECTNAME.sourceforge.net. You should change your CVS commands to 
use the host cvs.sourceforge.net and that should resolve any outstanding 
issues that you may have. This issue came about as a result of upgrading 
from BIND 8 to BIND 9 which doesn't allow for a wildcard in the middle of 
a hostname. 

I.e. working copies checked out from cvs.gnuplot.sourceforge.net before,
you'll have to move over to cvs.sourceforge.net.

I just did this:

  cvs -qz6 -d :ext:br...@cv...:/cvsroot/gnuplot up

in one of my working copies, and it appears to work.

As a longer-term solution, all CVS/Root files of the working copy will
have to be updated.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

what's up with SourceForge

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

Anyone know why attempting to access the cvs tree
produces the following error?  This has been going
on since yesterday, at least.

[~/cvs] cvs -z3 update gnuplot
Cannot access /cvsroot/gnuplot/CVSROOT
No such file or directory


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: docs/gpcard.tex

[Hans-Bernhard B. <br...@ph...>]

On Thu, 29 Apr 2004, Petr Mikulik wrote:

> ... still contains these two lines:
> 
> \key{X11 default display device}                {set term x11}
> \key{X11 multicolor point default device}       {set term X11}
> 
> Does somebody know what the 2nd line means? There is no difference nowadays
> I guess. 

If you look very closely, there is a minor difference between the two,
although that's probably unintentional (i.e. a bug in the source, not
in the docs):

'x11' sets the TERM_INIT_ON_REPLOT flag, 'X11' doesn't.

> Should I remove it ... or write this instead:

Remove it.  While at it, I see little reason to keep the terminal driver
X11 itself at all.


-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

docs/gpcard.tex

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

... still contains these two lines:

\key{X11 default display device}                {set term x11}
\key{X11 multicolor point default device}       {set term X11}

Does somebody know what the 2nd line means? There is no difference nowadays
I guess. Should I remove it ... or write this instead:

\key{X11 display terminal}                {set term x11}


--
PM

<tab> key doesn't work in gnuplot command line

[Grigory R. <gr...@ms...>]

Dear developers.
I have always used gnuplot for scientific purposes. Recently I have installed
gnuplot 4.0. I often use commands plot "very_long_filename.dat", but in 4.0
<tab> key doesn't automatically insert file name, but in previous versions it
worked. Missing of this feature stops me from upgrading gnuplot on all computers
in our Institute Network. Please let me know about current state of this feature.

best regards,
Grigory Rubstov,
Institute for Nuclear Reasearch.

[Fwd: Re: configure handling of -lz is fishy]

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

Hans-Bernhard Broeker wrote:

>Hi, everybody,
>
>as I already discovered when I built the DJGPP binary package, and some
>users have begun discovering on other Unix platforms, the way our
>configure script handles -lz is broken in several interesting ways.
>
>Here's a crucial snippet from config.log (wrapped around manually)
>on a Linux box:
>
>configure:10544: checking for gdImagePng in -lgd
>configure:10574: gcc -o conftest -g -O2   -I/usr/X11R6/include  \
>   conftest.c -lgd  -lm   -ljpeg -lfreetype -lpng >&5
>[...]
>configure:10606: result: yes
>
>Note the absence of -lz in that test link.  It works nevertheless, but
>only because Linux has internal dependency tracking for shared libraries,
>so -lpng can instruct the linker to pull in -lz.
>

Is there some way of deactivating this dependency/autolink feature? 
 That might prevent similar future unforeseen problems.

Dan





-- 

Dan Sebald
email: daniel DOT sebald AT ieee DOT org
URL: http://acer-access DOT com/~dsebald AT acer-access DOT com/

configure handling of -lz is fishy

[Hans-Bernhard B. <br...@ph...>]

Hi, everybody,

as I already discovered when I built the DJGPP binary package, and some
users have begun discovering on other Unix platforms, the way our
configure script handles -lz is broken in several interesting ways.

Here's a crucial snippet from config.log (wrapped around manually)
on a Linux box:

configure:10544: checking for gdImagePng in -lgd
configure:10574: gcc -o conftest -g -O2   -I/usr/X11R6/include  \
   conftest.c -lgd  -lm   -ljpeg -lfreetype -lpng >&5
[...]
configure:10606: result: yes

Note the absence of -lz in that test link.  It works nevertheless, but
only because Linux has internal dependency tracking for shared libraries,
so -lpng can instruct the linker to pull in -lz.

On platforms not supporting that trick, particularly those using static
libraries, this link will fail and thus the PNG part of the GD lib will
not be built --- you get the old PNG driver instead.

I thought it was Ethan who did this, but after discussing this in private
mail, I went back to check, and it seems it's Lars who last worked on this
(December 2002).  

I'm tempted to just check in the fix I used for the DJGPP build, but am a
little wary of interfering with the rather tricky way these tests are
written (caching and restoring the state of autoconf internal variable
like LIBS, e.g.).  

One more note: the way we use gdlib-config to override the $libgd_LIBS
*after* running the tests will almost certainly not achieve what's meant
to, either.  In particular, it doesn't correct the results of failed link
tests caused by failure to use it.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

branching (was Re: call: how many parameters?)

[Hans-Bernhard B. <br...@ph...>]

On Mon, 26 Apr 2004, Petr Mikulik wrote:
> 
> BTW, is there to be a split of source code branches into gnuplot 4.0.1 (for
> a potential bug-fix release) and gnuplot 4.1 with new cool features
> available at "Patches"?

At some point: sure.  I was hoping we could concentrate on post-release
bugfixes for a while before returning to feature additions and large-scale
code restructuring.

So: no new features to go into CVS before we branch off a 4.0 "stable"
version, please.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: call: how many parameters?

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

> > Currently, inside bla.gp called like
> >
> > 	call "bla.gp" one two 3 4
> >
> > it is not possible to determine how many parameters were passed into it.
> > The only way seems to be a global variable like
> >
> > 	params=4; call "bla.gp" one two 3 4
> >
> > and to use
> >
> > 	if (defined(params) && params==4) ...

> Why that complicated?  What's wrong with making the number of parameters
> the first parameter, i.e.
> 	call "bla.gp" 4 one two 3 4
> ?

That's complicated for users. You neither do this in your C programs.

> OTOH, what you really need would be a "was parameter number <n> passed
> in by the caller?" kind of test, i.e. the equivalent of the Bourne
> shell standard phrase
>
> 	if [ "x$5" != "x" ]

Here it will be    if ($# > 5) ...

> > I propose to add "variable"  $#  which will be set to number of available
> > $0, $1, ...
>
> Please keep in mind that '#' is our comment character.

So, I've done it, see the enclosed patch (it's very small). Seems to work
fine. (And it doesn't clash with # as comment char.)

I'll add it shortly, unless there are some complains. New section of NEWS is
to be added.


BTW, is there to be a split of source code branches into gnuplot 4.0.1 (for
a potential bug-fix release) and gnuplot 4.1 with new cool features
available at "Patches"?

---
PM

Re: gnuplot-4.0.0 fails to link on Digital UNIX V4.0E

[Hans-Bernhard B. <br...@ph...>]

On Sun, 25 Apr 2004, Ethan Merritt wrote:

> On Sunday 25 April 2004 12:56 pm, Hans-Bernhard Broeker wrote:
[...]
> > That's not the right way of fixing this, of course.  The actual
> > bug is in configure.in, where linking against -lgd and -lpng is
> > tested and the variables used in the link command are set up.
> >
> > Ethan: I'm CCing you on this because if memory serves, it was you who
> > claimed that the tests in their current shape are the only way to get
> > this to work on some platforms.  
> 
> I have vague recollections of saying that, but the only thing I can
> find in the mailing list archive (from Jan 2003) is a slightly 
> different issue. I was making the point that (at least under linux) 
> if ./configure tests for libpng and finds it, it will be finding the 
> most current installed version.  But this version may not
> match the one that, say, libgd was linked against.  In this case you get
> incompatibility warnings at link time.  So I was arguing against 
> specifying "-lpng -lz" explicitly if libgd was already being included.

And that argument, as far as I can recall, is the exact reason why -lz is
not currently appended to the link command line by the -lgd tests.  This
approach broke on at least 3 platforms by current count.  In fact, it'll
break all platforms with static libraries and those with shared libraries,
but without inter-library dependency support.

> Regardless of all that, the current report looks to me to be a different
> issue.  He had to change the order of the libraries in the link statement.
> Apparently ./configure places them in the wrong order.

> If I ever had a reason for wanting -lz to come before -lpng I can no longer
> remember what it might have been.  So if moving the tests on libz to after
> the png tests fixes the problem, I have no objection (but we should test
> it first, of course).

That cannot possibly work, I think.  We have to test for -lz first, then,
if that exists, use it in the -lpng and -lgd link tests.  

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.