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

updated faq

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

I've modified faq.tex on sourceforge:
- Added questions about pm3d, mousing and hotkeys.
- Added and modified various questions related to the forthcoming
  gnuplot 4.0.
- Various small or large changes and fixes, e.g. URLs.

Please have a look too.

There are definitely some URLs that needs to prove whether they exists.

There is a (for me) "strange section" on pgm, pbm et al formats and
utilities.
Maybe it needs a rewrite?

---
Petr Mikulik

Re: tic marks for transformed axes

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

On Sat, 20 Dec 2003, Jim Van Zandt wrote:

> 
> At present, gnuplot only knows about linear and log axes, and with a
> log axis only the powers of 10 are labeled.  

Powers of the logarithm base, to be precise.  Try 'set log x 2.0'
once in a while...  But in general, you're right.  See my long-open
bug report "short log axes get bad autotics" on SF.

> I'd like to generalize this, at least for the equivalent of "probability
> paper" and "weibull plots", and preferably for any reasonable
> user-supplied function. 

"Reasonable" being as subjective and volatile a quality as it is, that's
indeed a noble quest you've set out on ;-)

>  - Don't allow tic labels to overlap.

This is already quite hard to do, in general.  Note that for quite a
subset of drivers, including the entire PostScript and TeX family, gnuplot
has no real idea at all how large a given tic label is actually going to
be on output.

> 1. Provide for user mini-tics.  Currently the user can provide tic marks
> with a command like
>   set ytics ("bottom" 0, "" 10, "top" 20) 
> 
> However, only full size tic marks can be generated by this mechanism.
> I propose a patch below that will generate a minitic for a null label
> "".  The user can still get a full size tic with no label by putting
> one or more spaces in the label string.

While I do like the general idea of allowing user-placed minitics, I
strongly dislike that syntax.  Making a distinction between '' and ' '
is bound to counter-intuitive to almost every single non-guru user of
gnuplot out there.

Here's a possible alternative, which would also allow for a possible
extension to more than 2 kinds of tics in the future:

	set xtics ("bottom" 0 0, "" 10 0, "" 13 2, \
                   "here" 14 1, "top" 20)

which would express that there are labelled major (level-0) tics at
0 and 20, an unlabelled major at 10, an unlabelled sub-minor tic at 13,
and a labelled minor tic (level 1)  at 14.

> I propose that this part (only) be integrated into gnuplot version 4.0.

> The algorithm is more complicated than I like, but I could not get any
> of the simpler things I tried to work.  There are still some cases
> that don't come out right.

I supsected as much, having fought with the time/date variety of this
problem a while ago, and having tried to solve the "generalized axis
mapping" problem.

The best I could come up with was to have the user specify a
transformation function from plotted values to some artificial scale, then
use an improved version of the normal, linear auto-ticking algorithm on
that axis.  Whenever the auto-ticking algorithm working on the transformed
scale determines an interval smaller than, say, 1.0, or a user-choosable
threshold, tics would be placed equidistant in the real coordinates, 
per integer interval of the transformed scale.  That'd imitate what the
current logscaled autoticking in gnuplot docs, but extend sensibly to
short-range log axes and hopefully to transformed axes, too.

> I propose leaving "logscale" alone, but adding a "transform" option to
> xtics as follows:
> 
>        set xtics {axis | border} {{no}mirror} {{no}rotate {by <ang>}}
>                  {  autofreq
>                   | <incr>
>                   | <start>, <incr> {,<end>}
>                   | ({"<label>"} <pos> {,{"<label>"} <pos>}...)
>                   | transform <function> }
>                  { font "name{,<size>}" }
>                  { textcolor <colorspec> }

No. If we do add axis transformation, it really must be applied not only
to the tics, but to the plotted data, too, so this option has no business
hiding itself under the coat of 'set xtics'.  This really should become a
new command 'set transform {x|y|x2|y2|z|c} <function>', and 'set log x'
would then internally be mapped to 'set transform x log10(x)'

Re: filledboxes in CGM terminal

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

> I implemented filledboxes in the CGM terminal.  May I eliminate this
> item from the TODO file?

Sure.

Re: Please use this bug report instead... thanks.

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

John W. Eaton wrote:

>On  4-Jul-2003, Daniel J Sebald <dan...@ie...> wrote:
>  
>
<snip>

>| the gnuplot group has discussed. I guess the main
>| issue to Octave developers might be "how could
>| such a thing work nicely through a pipe".
>
>Sorry for not responding until now.
>

That's fine John.  I see that the Octave developers have been doing a 
lot of stuff lately.

>I think image overlays on graphs might be interesting.  Binary data
>transer to gnuplot would also be nice, as would the elimination of
>temporary files.
>

I'm uploading a PDF version of the demo that goes along with the "with 
image" patch that is at Gnuplot's SourceForge site to my web page. 
 (Let's hope it all fits in my web space...)  If the file makes it, go 
to the web page listed below after removing the spaces I put in the 
address.  Look under "gnuplot stuff" and then look for the file 
"image.pdf"...  OK, it just finished transferring and is complete.

I and, I think, a lot of the Gnuplot list people using Octave don't like 
the temporary file solution either.

>Regarding elimination of temporary files, there were some problems
>with that when I tried it, related to the requirement that subsequent
>replot commands also need to pass the data back to gnuplot and Octave
>is not set up to handle that.
>

Yes, that is an issue.  This is something that has been discussed 
several times on the list.  Gnuplot's current paradigm is a "terminal". 
 Some have suggested having something more object oriented where all 
information necessary for replotting is kept internal to Gnuplot. 
 However, that is just an idea and if it were to happen it would be 
rather far down the road I think.

>Do you know if there will ever be another gnuplot release?  (I know,
>you could ask the same about Octave.)  It's easier for a package like
>Octave to use the new features of gnuplot if they appear in a released
>version.
>

Yes, the trend appears to be a non beta version, 4.0, in the near 
future.  The developers are putting a lot of work into seeking out any 
remaining problems.  Images and binary data will be after 4.0 because 
that is quite a bit of new syntax and hasn't been tested by too many 
developers, although some of the developers have added features such as 
PDF/PNG drivers and EDF data file access.

>Finally, do you think there will ever be a reasonably clean C
>interface to the gnuplot internals?  It would certainly be better than
>working through a pipe.  Alternatively, is there a reliable way to
>query gnuplot about its internal state from an external program?  It
>would be very useful if Octave could ask gnuplot what the current
>setting of the terminal type is, for example.  I'd rather not have to
>rely on parsing potentially arbitrary text output since that could
>easily change from version to version and then my output parser would
>quit working properly.
>
>If you have other ideas or questions, post them to the help-octave,
>octave-graphics, or octave-maintainers mailing list(s) as you feel
>appropriate.
>
>Thanks,
>
>jwe
>

Regarding the first issue of a C interface, my guess would be no.  The 
syntax is more the standard in Gnuplot, and from what I've observed of 
the code it doesn't resemble a library-like construction.  Personally, I 
don't find the pipe interface to be too bad, given that I have used 
Gnuplot for my own unrelated GUI program.  Oh BTW, the upcoming Gnuplot 
release should have the X11 sixteen plot limit removed, and there will 
be a way to label the window and a way to close a window.

I'm carbon copying to the gnuplot discussion list.  Someone there might 
know about the internal state issue.  I've read it discussed a few times 
but I hadn't paid too close attention.

Regards,

Dan

-- 

Dan Sebald
email: daniel . sebald @ ie ee . o rg
URL: ht tp://acer-access.c om/~dsebald @ acer-access.c om/

tic marks for transformed axes

[Jim V. Z. <jr...@co...>]

At present, gnuplot only knows about linear and log axes, and with a
log axis only the powers of 10 are labeled.  I'd like to generalize
this, at least for the equivalent of "probability paper" and "weibull
plots", and preferably for any reasonable user-supplied function.
I've written a function that attempts to place tics according to these 
rules:

 - Place no tics or minitics outside the range specified by the user.

 - Don't allow tic labels to overlap.

 - Choose the "simplest" tics to label (i.e. those with the fewest
   significant digits).

 - Subject to the above, place tics with approximately even density.

 - Ensure the value corresponding to each minitic is obvious.

 - Subject to the above, place enough minitics that the user can
   easily interpolate to find the value for any point on the graph.

I propose a four-step implementation process:

1. Provide for user mini-tics.  Currently the user can provide tic marks
with a command like
  set ytics ("bottom" 0, "" 10, "top" 20) 

However, only full size tic marks can be generated by this mechanism.
I propose a patch below that will generate a minitic for a null label
"".  The user can still get a full size tic with no label by putting
one or more spaces in the label string.

I propose that this part (only) be integrated into gnuplot version 4.0.

2. Algorithm.  I have written a function to generate labels, tics, and
minitics for an axis that has undergone a user-supplied transform, and
a driver program with several transforms builtin, including log,
normal probability, and weibull probability.  The driver program
writes out tic mark generating commands (as above).  One example is
appended below.  Please apply the patch to see the full effect.  For
some other examples and the program sources, see
  http://jrv.oddones.org

The algorithm is more complicated than I like, but I could not get any
of the simpler things I tried to work.  There are still some cases
that don't come out right.

With the external program, a user can get a correctly labeled plot,
but she must include the transformation in the plot command.  For
example:

  set logscale x 10
  set xlabel "yield strength, kg/mm^2"
  set ylabel "unreliability"
  set yrange [ -4.80000 : 2.00000 ] noreverse nowriteback
  set label "see: http://www.reliasoft.com/newsletter/2q2001/classic_weibull.htm" \
  	at graph .98,.1 right
  load 'steel.tic'
  plot 'steel.dat' u ($3-38.57):(log(log(1/(1-$1/390))))


3. Decide on command syntax.

The current commands for specifying axes are:

       set logscale <axes> <base>
       unset logscale <axes>
       set xtics {axis | border} {{no}mirror} {{no}rotate {by <ang>}}
                 {  autofreq
                  | <incr>
                  | <start>, <incr> {,<end>}
                  | ({"<label>"} <pos> {,{"<label>"} <pos>}...) }
                 { font "name{,<size>}" }
                 { textcolor <colorspec> }
       unset xtics

I propose leaving "logscale" alone, but adding a "transform" option to
xtics as follows:

       set xtics {axis | border} {{no}mirror} {{no}rotate {by <ang>}}
                 {  autofreq
                  | <incr>
                  | <start>, <incr> {,<end>}
                  | ({"<label>"} <pos> {,{"<label>"} <pos>}...)
                  | transform <function> }
                 { font "name{,<size>}" }
                 { textcolor <colorspec> }

The function must have exactly one variable.

So as an alternative to the above, the user could write
  f(x) = log10(x)
  set xtics transform f
  g(y) = log(log(1/(1-y)))
  set ytics transform g

  plot 'steel.dat' u ($3-38.57):($1/390)

which would use the new algorithm to place minitics, regular tics, and
labels on both axes

4. Integration.  I have not looked into this.  


The patch for user-specified minitics follows.

		- Jim Van Zandt



--- ./src/axis.c-orig	Thu Feb  6 21:23:31 2003
+++ ./src/axis.c	Thu Feb  6 21:42:48 2003
@@ -888,16 +888,20 @@
 
 	    if (!inrange(internal, internal_min, internal_max))
 		continue;
-
+	    /* use supplied format if any.  If nothing is supplied, use
+             * default format. 
+	     */
 	    if (axis_array[axis].is_timedata)
 		gstrftime(label, 24, mark->label ? mark->label : ticfmt[axis], mark->position);
 	    else
 		gprintf(label, sizeof(label), mark->label ? mark->label : ticfmt[axis], log10_base, mark->position);
-
-	    (*callback) (axis, internal, label, lgrd);
+	    /* if supplied format is empty, generate unlabeled minitic */
+	    (*callback) (axis, internal, 
+			 mark->label ? (mark->label[0] ? label : 0) : label,
+			 lgrd);
 	}
 
-	return;			/* NO MINITICS FOR USER-DEF TICS */
+	return;
 	/*}}} */
     }
 
--- docs/gnuplot.doc-orig	Sat Apr 12 10:08:42 2003
+++ docs/gnuplot.doc	Sat Apr 12 10:18:53 2003
@@ -4399,9 +4399,11 @@
  the same as `xy`).  The length of the string representing a tic mark (after
  formatting with 'printf') is restricted to 100 characters.  If the format
  string is omitted, the format will be returned to the default "%g".  For
- LaTeX users, the format "$%g$" is often desirable.  If the empty string "" is
- used, no label will be plotted with each tic, though the tic mark will still
- be plotted.  To eliminate all tic marks, use `unset xtics` or `unset ytics`.
+ LaTeX users, the format "$%g$" is often desirable.  If the format has
+ only a space " ", no label will be plotted with each tic, though the
+ tic mark will still be plotted.  An empty string "" will result in an
+ unlabeled minitic.  To eliminate all tic marks, use `unset xtics` or
+ `unset ytics`.
 
  Newline (\n) is accepted in the format string.  Use double-quotes rather than
  single-quotes to enable such interpretation.  See also `syntax`.
@@ -7861,9 +7863,11 @@
  non-numeric tic labels.  A set of tics is a set of positions, each with its
  own optional label.  Note that the label is a string enclosed by quotes.  It
  may be a constant string, such as "hello", may contain formatting information
- for converting the position into its label, such as "%3f clients", or may be
- empty, "".  See `set format` for more information.  If no string is given,
- the default label (numerical) is used.  In this form, the tics do not need to
+ for converting the position into its label, such as "%3f clients".  To get an
+ unlabeled minitic, use an empty string, "".  For an unlabeled normal
+ size tic, use a string with a space " ".  If no string is given, the
+ default label (numerical) is used.  See `set format` for more
+ information.  In this form, the tics do not need to
  be listed in numerical order.
 
  Examples:

filledboxes in CGM terminal

[Jim V. Z. <jr...@co...>]

I implemented filledboxes in the CGM terminal.  May I eliminate this
item from the TODO file?  Or, of course, if there's a problem with the
implementation please let me know.

		      - Jim Van Zandt


--- TODO-orig	2002-11-17 20:25:54.000000000 -0500
+++ TODO	2003-12-20 17:20:27.000000000 -0500
@@ -47,9 +47,6 @@
 Amiga:
   -- update its docs from docs/old/README.ami, then delete this file
 
-CGM:
-  -- implement filledboxes
-
 Emx:
   -- update its docs from docs/old/README.emx, then delete this file
 

Re: Contour lines not continuous

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

On Thursday 18 December 2003 17:15, Hans-Bernhard Broeker wrote:
> I've now created a new pair of routines
>
> polyline3d_start()    #may be renamed to *_move()
> polyline3d_next()     #may be renamed to *_vector()
>
> and use those in cntr3d_lines, instead of draw3d_line().=20
   [...]
> Besides the hidden3d limitation, all's looking fine so far.

Just as a point of reference, here are the output sizes of=20
postscript files produces by base 3.8k before your patch,
the current cvs version, and the current cvs version with
my patch for post.trm from the other day.

[47] wc *.ps
 107936  232574  860642 3.8j.ps
  63070  161130  566356 hbb.ps
  44492  133191  430013 hbb+eam.ps

Test command sequence was in each case:
  set term post color dash
  set output '...'
  load 'contours.dem'

I don't know if the patch to post.trm is fully safe,
but in any event this shows that there is some room
left to further optimize the postscript output over
and above the changes you made to the core routines.


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

Re: Fwd: 'x11 prints garbage to stdout on OS/2' solved now the history-bug

[Lars H. <lhe...@us...>]

> After starting gnuplot and 'plot x' I _sometimes_ get:
> 
> Terminal type set to 'pm'
> gnuplot> plot x
> gnuplot> gnuplot>
> 
>   instead of
> 
> Terminal type set to 'pm'
> gnuplot> plot x
> gnuplot>
> 
>   After getting the double (or sometimes triple or even more) prompt the
>  commandline-history no longer works. When entering Cursor-UP I get H
>  instead of the last command, Cursor-Left gives K, Cursor-Right gives M,
>  Cursor-Down gives P and Del gives S
 
 Could this be a case of broken readline library? As in

  http://sourceforge.net/tracker/index.php?func=detail&aid=608874&group_id=2055&atid=102055

Fwd: 'x11 prints garbage to stdout on OS/2' solved now the history-bug

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

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

Subject: 'x11 prints garbage to stdout on OS/2' solved now the history-bu=
g
Date: Fri, 19 Dec 2003 00:20:46 +0100 (CET)
From: "Franz Bakan" <fb...@gm...>
To: "gnuplot-beta" <gnu...@li...>
Cc: "Petr Mikulik" <mi...@ph...>, "Ethan Merritt" <merritt@u.=
washington.edu>

On Tue, 16 Dec 2003 17:10:28 -0800, Ethan Merritt wrote:
>
>I have added a command line option
>=09gnuplot -nofeedback
>that disables the feedback path which is causing problems.
>This is not an ideal fix, just a work-around.
>There is a corresponding XResource:
>=09gnuplot*feedback:=09off                 (or false)
>
>Please let me know if this successfully bypasses the
>symptoms you saw under os2.

This solves the problem also here  X11 terminal now works
again as desired. Tested with HOBX11 and XFree86-4.3.0.

The only problem on OS/2 that I can see now (and have allways
seen with gnuplot versions later then 3.7 is the
'command-line-history-problem'.
Probably a timing or synchronisation problem.

After starting gnuplot and 'plot x' I _sometimes_ get:

Terminal type set to 'pm'
gnuplot> plot x
gnuplot> gnuplot>

  instead of

Terminal type set to 'pm'
gnuplot> plot x
gnuplot>

  After getting the double (or sometimes triple or even more) prompt the
 commandline-history no longer works. When entering Cursor-UP I get H
 instead of the last command, Cursor-Left gives K, Cursor-Right gives M,
 Cursor-Down gives P and Del gives S

  Example:

Terminal type set to 'pm'
gnuplot> plot x
gnuplot> gnuplot> HKMPS


Backspace-Key is working correct (sometimes I have to hit it twice
to delete the 'HKMPS' characters but the rest of gnuplot works.

following plot or other commands work as desired but cursor-keys
are broken for the rest of the gnuplot session.

When the PM-Window is large, it's more likely that I see the bug.
When the PM-Window is small the bug is more rare.

Any idea what happens and how to resolve this bug?

Franz

Re: Contour lines not continuous

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

OK, let me expand on the details...

> The key difference is in graph3d.c:cntr3d_lines() and friends: in 3.7,
> they used clip_move() and clip_vector() to create (optionally
> clipped/broken) polylines.  In 3.8, we use draw3d_line directly, which
> does both a term->move() and term->vector(), usually.

> AFAICS, it was me who did that, as part of the big set of modifications
> done on the "axis branch".

Staring at the modifications in question for a while, I now
found/remembered the actual background of this.  It was me, indeed, and
it was part of the 'axis' branch, but the rationale was different than
I had first thought.

The real problem with the old cntr3d_line code was that it output the
lines in *2D* mode. clip_move() and clip_vector() are 2D functions, and on
top of everything else, they don't really implement the move()/vector()
semantics to create polylines.  Instead, the global flag suppressMove is
used for that.  The problems with that were that contour lines couldn't
be hidden in hidden3d mode, because the routine that drew them didn't
have the necessary 3D information any more.

I've now created a new pair of routines 

polyline3d_start()    #may be renamed to *_move()
polyline3d_next()     #may be renamed to *_vector()

and use those in cntr3d_lines, instead of draw3d_line().  If either the
'palette' line coloring option or hidden3d is in use, it still falls back
to the 3.8 behaviour, though.  Hidden3d just doesn't support polylines at
this time. For paletted lines, polyline support wouldn't make sense
anyway, so no harm done on that end.

Besides the hidden3d limitation, all's looking fine so far.  Some of you
PM3D experts should test this a bit more thoroughly though, so I'm
checking the current state of this in right away.

Happy holy days, y'all...

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

Re: Contour lines not continuous

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

On Thursday 18 December 2003 11:12, Ethan Merritt wrote:
>
> The attached quick patch seems to work, but I have not
> tested it on anything other than contours.dem

Oops. One more minor tweak is needed.
The following corrected patch correctly processes the example script
provided on the newsgroup.   In particular, the contour lines near the
plot origin are rendered in dash-dot modes as listed in the figure key.

HOWEVER - it does indeed reveal a problem, or at least a difference,
with the arrow style code as per the comment in post.trm.
Quick test:
=09set term post color dash
=09set output 'bug.ps'
=09load 'arrowstyle.dem'

You will see that the current 3.8k produces solid arrows everywhere,
whereas the patched version produces dotted arrows.

Then again, if you specifically ask for 'set term post dash', is this rea=
lly an error?


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
# This demo script triggers a bug in 3.8j such that contour lines
# do not get rendered with correct dash/dot values
set terminal postscript landscape enhanced color dashed
set pm3d at st
set border 4095
set surface
set samples 25
set isosamples 20
set ticslevel 0
set contour base
set cntrparam bspline
set view 0,0
set nosurface
set key screen 0.15,0.7 title "Contour" Right nobox
set title "surface and pm3d (surface and top) of radial sinc function"
splot [-15:15.01] [-15:15.01] [-0.2:1] \
  sin(sqrt(x**2+y**2)) / sqrt(x**2+y**2)=20


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

Re: Contour lines not continuous

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

On Thursday 18 December 2003 09:27, Hans-Bernhard Broeker wrote:
> In 3.8, we use draw3d_line directly, which
> does both a term->move() and term->vector(), usually.

Two comments:

(1)
In draw3d_line_unconditional(v1,v2,lp,linetype) we have the code lines:
=09term_apply_lp_properties(lp);
=09[...conditional code...]
=09(term->linetype)(linetype);
This can result in setting the line type twice, unnecessarily.

(2)
I believe that the current problem can be fixed in post.trm by checking
the current line properties before setting new ones.

Part of the problem is the following unfortunate hack, which broke a work=
ing
test on unnecessary line interruptions:
#if 0
    /*  In order to make 'PS_linewidth' work properly, I need to comment
     *  this line out.  Especially in combination with the line width
     *  extension of the `set arrow` command this is necessary.
     *  Can we live with that drawback?  (JFi)
     */
    if (PS_linetype_last =3D=3D linetype) return;
#endif

If the 'set arrow' code is causing problems, then let's fix it
there, not in the postscript driver.

The other half of the problem is that PS_linewidth makes no
such check at all.

PS_move and PS_vector look OK to me.

The attached quick patch seems to work, but I have not
tested it on anything other than contours.dem

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

Contour lines not continuous

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

Hello, 

some of you may have seen it over in the user list/newsgroup, but I think
this should be addressed here, too:

A user just found a problem with gnuplot-3.8 that has been sitting in
there for quite some time now:  contour lines are now drawn as individual
line segments, where 3.7 managed to long polylines (sometimes *too* long,
leading to its own kind of problems).  That's bad if the line type used is
patterned, because individual segments re-start the pattern each time,
rendering the pattern indecipherable.

The key difference is in graph3d.c:cntr3d_lines() and friends: in 3.7,
they used clip_move() and clip_vector() to create (optionally
clipped/broken) polylines.  In 3.8, we use draw3d_line directly, which
does both a term->move() and term->vector(), usually.

AFAICS, it was me who did that, as part of the big set of modifications
done on the "axis branch".

I guess this will have to be fixed, too, before a 4.0 becomes ready.
Looks like I just found something to do for the holy days.

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

Re: x11 prints garbage to stdout on OS/2

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

> When you say "everything works OK", does that mean that awk scripts now
> work al

X11 under OS/2 is working fine again.

awk is not working.

---
Petr Mikulik

Re: x11 prints garbage to stdout on OS/2

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

On Wednesday 17 December 2003 03:45, Petr Mikulik wrote:
> should be:
>
> #ifdef PIPE_IPC
>         if (ipc_back_fd >=3D 0)
>              X11_waitforinput();
> #endif
>
> and everything works OK in gnuplot versions up to yesterday.
>
> The patch commited by Ethan works fine as well.

My patch makes this whole section of code conditional
on ipc_back_fd - so yes, they would have the same effect.

When you say "everything works OK", does that mean
that awk scripts now work also?

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

Re: x11 prints garbage to stdout on OS/2

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

> Petr: you already added a good deal of #ifdef PIPE_IPCs around this
> in end of October 2003 (x11 reversions 1.82, 1.83), so it now looks like
> this:
>
> #ifdef USE_MOUSE
>     /* EAM June 2003 - Flush the set font command through the pipe */
>     /* to gnuplot_x11, then wait for it to return the resulting    */
>     /* font size information (v_char and h_char).                  */
>     if (!default_font_size_known) {
> #ifdef PIPE_IPC
>         IPC_LOCK = TRUE;
> #endif
>         X11_set_default_font();
>         FFLUSH();
> #ifdef PIPE_IPC
>         if (ipc_back_fd >= 0)
> #endif
>             X11_waitforinput();
>         default_font_size_known = TRUE;
> #ifdef PIPE_IPC
>         IPC_LOCK = FALSE;
> #endif
>     }
> #else
>     X11_set_default_font();
> #endif
>
> Petr: I guess you or Franz will have to single-step through this part
> and find out at exactly which part of it the garbage turns up.

Franz did it and there is his answer:

***

Delete

 X11_waitforinput();

in x11.trm  (line 1053 in 15/12/2003 sources)

and try again.
This works for me, but I don't know if it's the right fix.

***

Consequently, this piece of code:

#ifdef PIPE_IPC
         if (ipc_back_fd >= 0)
#endif
             X11_waitforinput();

should be:

#ifdef PIPE_IPC
        if (ipc_back_fd >= 0)
             X11_waitforinput();
#endif


and everything works OK in gnuplot versions up to yesterday.

The patch commited by Ethan works fine as well.

Thus, what should be the best version there?

---
Petr Mikulik

Re: x11 prints garbage to stdout on OS/2

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

On Tuesday 16 December 2003 10:34, Ethan Merritt wrote:
> My proposed non-fix remains to add a command line
> option disabling this feedback mechanism.

I have added a command line option
=09gnuplot -nofeedback
that disables the feedback path which is causing problems.
This is not an ideal fix, just a work-around.
There is a corresponding XResource:
=09gnuplot*feedback:=09off                 (or false)

Please let me know if this successfully bypasses the=20
symptoms you saw under os2.  As a bonus it should=20
also allow the earlier "lost characters" problem we saw
for awk scripts.

If this works, I will add suitable documentation for it.
We can chip away at  fixing the underlying problem later.

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

Re: x11 prints garbage to stdout on OS/2 - Re: problems compiling gnuplot (fwd)

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

On Tue, 16 Dec 2003, Ethan Merritt wrote:

> On Tuesday 16 December 2003 08:24, Petr Mikulik wrote:
> > Franz has found the patch which started to cause this problem.

So the change in question was the one that let gnuplot_x11 report back the
font size of the default font to gnuplot (grep for "EAM June 2003" in
x11.trm).

Petr: you already added a good deal of #ifdef PIPE_IPCs around this
in end of October 2003 (x11 reversions 1.82, 1.83), so it now looks like 
this:

#ifdef USE_MOUSE
    /* EAM June 2003 - Flush the set font command through the pipe */
    /* to gnuplot_x11, then wait for it to return the resulting    */
    /* font size information (v_char and h_char).                  */
    if (!default_font_size_known) {
#ifdef PIPE_IPC
        IPC_LOCK = TRUE;
#endif
        X11_set_default_font();
        FFLUSH();
#ifdef PIPE_IPC
        if (ipc_back_fd >= 0)
#endif
            X11_waitforinput();
        default_font_size_known = TRUE;
#ifdef PIPE_IPC
        IPC_LOCK = FALSE;
#endif
    }
#else
    X11_set_default_font();
#endif

Petr: I guess you or Franz will have to single-step through this part 
and find out at exactly which part of it the garbage turns up.

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

Re: x11 prints garbage to stdout on OS/2

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

[ resending the message with hopefully correct character encoding ]

On Tuesday 16 December 2003 06:52, Petr Mikulik wrote:
> There is a report, which I can confirm, that X11 terminal under OS/2
>
> - prints a lot of garbage onto the gnuplot xterm, or

I have no idea about this one, and no way of debugging it.
Could you at least establish whether it is gnuplot or gnuplot_x11
that produces this garbage?

> I *guess* there is some code using PIPE_IPC without #ifdef PIPE_IPC
> around it, and thus all the communication goes into the screen.

I don't think so, at least not in the x11.trm code.  This would cause a
severe error when the program tried to write to an invalid file descripto=
r.


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

Re: x11 prints garbage to stdout on OS/2

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

[ resending this message with (I hope) correct character encoding ]

On Tuesday 16 December 2003 08:24, Petr Mikulik wrote:
> Franz has found the patch which started to cause this problem.
> Ethan, can you please look at it?

I have no way of debugging anything under os2.
So unless you can find a similar failure that I can reproduce here,
I can't do much other than maybe disable the feedback altogether
with a command line option (see other message).

>
> 20. June 2003 works  and  21. June 2003 doesn't.
> So one of these patches are the culprit:
> From Changelog:
>
> 2003-06-20  Ethan Merritt  <merritt@u.washington.edu>
> 2003-06-19  Ethan Merritt  <merritt@u.washington.edu>

The details of this code were changed by later patches,
so this only point a finger at the entire feedback mechanism
for requesting font and sizing information.=20
My proposed non-fix remains to add a command line
option disabling this feedback mechanism.

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

Re: x11 prints garbage to stdout on OS/2 - Re: problems compiling gnuplot (fwd)

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

On Tuesday 16 December 2003 08:24, Petr Mikulik wrote:
> Franz has found the patch which started to cause this problem.
> Ethan, can you please look at it?

I have no way of debugging anything under os2.
So unless you can find a similar failure that I can reproduce here,
I can't do much other than maybe disable the feedback altogether
with a command line option (see other message).

>
> 20. June 2003 works  and  21. June 2003 doesn't.
> So one of these patches are the culprit:
> From Changelog:
>
> 2003-06-20  Ethan Merritt  <merritt@u.washington.edu>
> 2003-06-19  Ethan Merritt  <merritt@u.washington.edu>

The details of this code were changed by later patches,
so this only point a finger at the entire feedback mechanism
for requesting font and sizing information.=20
My proposed non-fix remains to add a command line
option disabling this feedback mechanism.

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

Re: color box positioning for splot

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

On Tue, 16 Dec 2003, Daniel J Sebald wrote:

[...]
> I was skeptical about finding a quick fix, but this is a worthy 
> improvement.  The graph brushes up against the colorbox in some views 
> (which is the same issue as with the key, I guess), but it will do.

Those views are mainly those where the z rotation is an odd multiple of
45 degrees, i.e. those where the 3D box has maximum width.  

If you don't like the current placement, you or Petr feel free to modify
the constants I put in there.  There's quite some space left between the
current position if the cbox and the right border of a default plot. May
the gods save us from users who 'set size 0.7,1', though...

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

Re: x11 prints garbage to stdout on OS/2

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

On Tuesday 16 December 2003 06:52, Petr Mikulik wrote:
> There is a report, which I can confirm, that X11 terminal under OS/2
>
> - prints a lot of garbage onto the gnuplot xterm, or

I have no idea about this one, and no way of debugging it.
Could you at least establish whether it is gnuplot or gnuplot_x11
that produces this garbage?

> I *guess* there is some code using PIPE_IPC without #ifdef PIPE_IPC
> around it, and thus all the communication goes into the screen.

I don't think so, at least not in the x11 code.  This would cause a
severe error when the program tried to write to an invalid file descripto=
r.

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

Re: News in gnuplot.doc

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

On Tuesday 16 December 2003 06:07, Petr Mikulik wrote:
> > > x11.trm: It may be worth to write into docs that piping with "set
> > > mouse" can be used only if pipe must be (un??)buffered, the externa=
l
> > > caller program must issue a command like setmode(????, O_????).
>
> That's it, I don't know exactly how is it now -- I think Ethan is the
> most informed in this matter. Can you please write a bit about that?

If I understood it well enough to document properly, I would have
fixed it :-)

All I know is that some callers have problems, but most do not.
Blaming the buffered/unbuffered state of the pipe is just a guess
based on Johannes' earlier comments in x11.trm, but I cannot
confirm this is the crucial difference.
=20
The same for your just-reported problem under OS2.  I have no
idea exactly what is different in the environment, but something
obviously is making the communication channel lose synchronization.

The best thing may be to add a -noXfeedback option to the
command line, and document that it should be used in case
of problems such as the ones seen with awk scripts or OS2.=20

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

Re: color box positioning for splot

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

Hans-Bernhard Broeker wrote:

>On Sun, 14 Dec 2003, Daniel J Sebald wrote:
>
>  
>
>>I don't have time to modify and test a quick fix for the colorbox. 
>>    
>>
>
>I did one and put it into CVS.  
>
>It works as announced in my original reply: it places the color box in
>exactly the position it has in default 'set view' settings, regardless of
>what the current view settings are.  This could have been done by
>resetting the view matrix to default, but I chose a more blunt way: ran
>the existing code in a debugger to step through map3d_xy when called from
>the colorbox generator, and wrote down the position of the color box in
>"view coordinates".  It's really a quick and dirty fix, but like all such,
>it works ;-)
>

I was skeptical about finding a quick fix, but this is a worthy 
improvement.  The graph brushes up against the colorbox in some views 
(which is the same issue as with the key, I guess), but it will do.

Doubting Daniel