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

Re: PM3D postscript microgaps vanished from 4.0 to 4.1...

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

> a newsgroup poster just found out a problem with (at least) post.trm pm3d
> output exposed by turning on antialiasing (type 'a' in gv or ghostview)
> --- there's a Moir'e pattern of very thin (single-pixel) white lines
> exposed at the border between neighboring rectangles of pm3d plots.

It was always like that -- happens if you set option "Graphics Alpha" to 4
bits (in gsview, I don't know how to change it in gv).


> just an lucky side-effect of Ethan's changes to support pattern fills for
> term->polygon().
>
> Looking at the generated postscript, it seems as if the only significant
> difference between 4.0.2 and 4.1 is the order of output points, and, of
> course, the PostScript macro being used:
>
> ---------4.0: ---------------
> .3293 g 5148 927 N 0 -114 114 0 0 114 h
> .3148 g 5033 927 N 0 -114 115 0 0 114 h
> .2934 g 4918 927 N 0 -114 115 0 0 114 h
>
> /h {rlineto rlineto rlineto fill} bind def
>
> ---------4.1: ---------------
> .3293 g 5148 927 N 0 114 V 114 0 V 0 -114 V 1.0 PolyFill
> .3148 g 5033 927 N 0 114 V 115 0 V 0 -114 V 1.0 PolyFill
> .2934 g 4918 927 N 0 114 V 115 0 V 0 -114 V 1.0 PolyFill


That's the new postscript code in 4.1?! I don't like it, sorry! It breaks
compatibility with all those pm3dConvert* scripts, and puts a lot of
"useless characters" into maps. I'm against this change!

The syntax
   .3293 g 5148 927 N 0 -114 114 0 0 114 h

is intended to produce line as short as possible and I insists it stays like
that. (My demo example of a non-grid reciprocal space reflectivity maps
using "pm3d map" contains 40000 points and I don't wish to have any increase
of the postscript file size.)


I.e., "pm3d map" should not be interfered by PolyFill. Why did this happen?
Isn't this bug?


(Anyway, why to write "1.0 PolyFill" and not "1 PolyFill"? Please keep
postscript file as short as possible.)

---
PM

PM3D postscript microgaps vanished from 4.0 to 4.1...

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

Hello, all,

a newsgroup poster just found out a problem with (at least) post.trm pm3d
output exposed by turning on antialiasing (type 'a' in gv or ghostview)  
--- there's a Moir'e pattern of very thin (single-pixel) white lines
exposed at the border between neighboring rectangles of pm3d plots.  The
colour scale box displays incorrectly in both 4.0.2 and 4.1, as soon as 
antialiasing is turned on: there's a rather visible ripple in it.

To give you something to look at: the seventh plot of 'pm3d.dem' exposes
the problem.

At 64x magnification (in gv) of 4.0.2 output it becomes obvious that
ghostscript leaves thin white margins between any two polygons --- whether
they appear at normal display scales or not is a spatial aliasing effect.

Mysteriously, although there's no ChangeLog entry pointing to a bug having
been found and fixed in this area --- it seems like this difference is
just an lucky side-effect of Ethan's changes to support pattern fills for
term->polygon().

Looking at the generated postscript, it seems as if the only significant
difference between 4.0.2 and 4.1 is the order of output points, and, of
course, the PostScript macro being used:

---------4.0: ---------------
.3293 g 5148 927 N 0 -114 114 0 0 114 h
.3148 g 5033 927 N 0 -114 115 0 0 114 h
.2934 g 4918 927 N 0 -114 115 0 0 114 h

/h {rlineto rlineto rlineto fill} bind def

---------4.1: ---------------
.3293 g 5148 927 N 0 114 V 114 0 V 0 -114 V 1.0 PolyFill
.3148 g 5033 927 N 0 114 V 115 0 V 0 -114 V 1.0 PolyFill
.2934 g 4918 927 N 0 114 V 115 0 V 0 -114 V 1.0 PolyFill

/V {rlineto} bind def

/PolyFill {
  gsave
  /Fillden exch def
  currentrgbcolor
  /ColB exch def /ColG exch def /ColR exch def
  /ColR ColR Fillden mul Fillden sub 1 add def
  /ColG ColG Fillden mul Fillden sub 1 add def
  /ColB ColB Fillden mul Fillden sub 1 add def
  ColR ColG ColB setrgbcolor
  fill grestore } def
------- end excerpts ------

Expanding the macros a bit, this becomes

4.0:  .3293 g 5148 927 N 0 -114 114 0 0 114 rlineto rlineto rlineto fill
4.1:  .3293 g 5148 927 N 0 114 rlineto 114 0 rlineto 0 -114 rlineto \
         [... colour stuff ...] fill

Now, I'm certainly no PostScript guru, but to my understanding, the
above should render the same result.



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

Re: Bugs in lisp sections of ./prepare and make

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

 
> brogar [62] automake --version
> automake (GNU automake) 1.4-p6
 
 This is the problem. The 1.4-pN releases were intermediate releases, and
 they have in fact introduced more problems than they solved. In any case,
 at this point, 1.4 is well outdated.

Re: 'with pixels' (was Re: Engines are started; ...)

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

Hans-Bernhard Broeker wrote:

>> So I don't see how
>>     plot 'data' binary with lines
>> is supposed to work unambiguously.
>>   
>
>
> The same way it always did.  Actually, I think 'binary' with no using
> spec should probably be reserved to mean the old gnuplot binary format,
> if only for backward compatibility.
>

That's the way it is currently programmed.  Binary files for "plot" (as 
opposed to "splot") weren't implemented, so in that case the patch 
complains that more information in a "using" field is required.  That 
could be changed so that gnuplot binary defaults.

Dan

Re: Bugs in lisp sections of ./prepare and make

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

On Tuesday 13 July 2004 05:45 pm, Hans-Bernhard Broeker wrote:
> > brogar [62] automake --version
> > automake (GNU automake) 1.4-p6
> 
> that automake version is quite old (July 2002).  Current is 1.8.5 (release
> May 2004). I've now idea why Mandrake would have such an outdated version
> of automake only.

Indeed.  I have no idea either.
So now I installed an rpm for Polish(ed) Linux which I find to be in general
highly compatible with Mandrake
	automake-1.8.3-1.noarch.rpm

WIth this in place the ./prepare; ./configure sequence completes
successfully, although there are some strange warning along the way.
I could try to find an even newer one, but so long as it works....

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

Re: Bugs in lisp sections of ./prepare and make

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

On Tue, 13 Jul 2004, Ethan Merritt wrote:

[...]
> mv Makefile.amt Makefile.am
> automake: configure.in: required file `../config.guess' not found
> automake: configure.in: required file `../config.sub' not found

Automake complained, and 

> brogar [62] automake --version
> automake (GNU automake) 1.4-p6

that automake version is quite old (July 2002).  Current is 1.8.5 (release
May 2004). I've now idea why Mandrake would have such an outdated version
of automake only.

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

Re: Bugs in lisp sections of ./prepare and make

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

Here's my output:
brogar [59] cvs -z3 checkout gnuplot
cvs checkout: Updating gnuplot
U gnuplot/.cvsignore
U gnuplot/BUGS
[big snip]
U gnuplot/tutorial/tutorial.tex
cvs checkout: Updating gnuplot/win
brogar [60] cd gnuplot
brogar [61] ./prepare
rm -f Makefile.am Makefile.amt
sed -n '1,/^##m4-files-begin/p' Makefile.am.in > Makefile.amt
echo EXTRA_DIST = README Makefile.am.in buildvms.com config.* \
  djconfig.sh make_vms.com term_pc.h makefile.* | fmt | \
  (tr '\012' @; echo) |sed 's/@$/%/;s/@/ \\@/g' |tr @% '\012 ' >> Makefile.amt
sed -n '/^##m4-files-end/,$p' Makefile.am.in >> Makefile.amt
chmod a-w Makefile.amt
mv Makefile.amt Makefile.am
rm -f Makefile.am Makefile.amt
sed -n '1,/^##m4-files-begin/p' Makefile.am.in > Makefile.amt
echo EXTRA_DIST = Makefile.am.in *.bor *.cor *.dat *.dem *.fnc *.inc \
  sound.par sound2.par start.par webify.pl *.rot | fmt | \
  (tr '\012' @; echo) | sed 's/@$/%/;s/@/ \\@/g' | tr @% '\012 ' \
  >> Makefile.amt
sed -n '/^##m4-files-end/,$p' Makefile.am.in >> Makefile.amt
chmod a-w Makefile.amt
mv Makefile.amt Makefile.am
rm -f Makefile.am Makefile.amt
sed -n '1,/^##m4-files-begin/p' Makefile.am.in > Makefile.amt
echo EXTRA_DIST = README Makefile.am.in *.m4 | fmt | \
  (tr '\012' @; echo ) \
  |sed 's/@$/%/;s/@/ \\@/g' |tr @% '\012 ' \
  >> Makefile.amt
sed -n '/^##m4-files-end/,$p' Makefile.am.in >> Makefile.amt
chmod a-w Makefile.amt
mv Makefile.amt Makefile.am
rm -f Makefile.am Makefile.amt
sed -n '1,/^##trm-files-begin/p' Makefile.am.in > Makefile.amt
echo CORETERM = *.trm | fmt | (tr '\012' @; echo) \
  |sed 's/@$/%/;s/@/ \\@/g' | tr @% '\012 ' \
  >> Makefile.amt
sed -n '/^##trm-files-end/,$p' Makefile.am.in >> Makefile.amt
chmod a-w Makefile.amt
mv Makefile.amt Makefile.am
rm -f Makefile.am Makefile.amt
sed -n '1,/^##plt-files-begin/p' Makefile.am.in > Makefile.amt
echo PLT_FILES = *.plt | fmt | (tr '\012' @; echo ) \
  |sed 's/@$/%/;s/@/ \\@/g;' | tr @% '\012 ' >> Makefile.amt
sed -n '/^##plt-files-end/,$p' Makefile.am.in >> Makefile.amt
chmod a-w Makefile.amt
mv Makefile.amt Makefile.am
automake: configure.in: required file `../config.guess' not found
automake: configure.in: required file `../config.sub' not found

Some part of the preparation process failed.
Please refer to INSTALL for details 

brogar [61] autoconf --version
autoconf (GNU Autoconf) 2.59
Written by David J. MacKenzie and Akim Demaille.

brogar [62] automake --version
automake (GNU automake) 1.4-p6

brogar [63] ls -ld co*
drwxr-xr-x  3 merritt 25  4096 Jul 13 14:20 config
-rw-r--r--  1 merritt 25 12217 Jul 13 14:20 config.hin
-rwxr-xr-x  1 merritt 25 30815 Jul  8 17:25 configure.in
-rwxr-xr-x  1 merritt 25 20472 Jan  7  2004 configure.vms


So I have a somewhat older version of automake, although
it seems to be the newest one available as an rpm.

I'll try building a newer version and report back.

Meanwhile, here is the tail end of the output from make:

makeinfo -I. ./gnuplot.texi --no-split --output=gnuplot.info
make[2]: Leaving directory `/home/merritt/cvs/gnuplot-cvs/docs'
Making all in lisp
make[2]: Entering directory `/home/merritt/cvs/gnuplot-cvs/lisp'
/bin/sh ./../mkinstalldirs /usr/local/share/emacs/site-lisp
mkdir -p -- /usr/local/share/emacs/site-lisp
mkdir: cannot create directory `/usr/local/share/emacs': Permission denied
make[2]: *** [install-els] Error 1
make[2]: Leaving directory `/home/merritt/cvs/gnuplot-cvs/lisp'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/merritt/cvs/gnuplot-cvs'
make: *** [all-recursive-am] Error 2

Re: 'with pixels' (was Re: Engines are started; ...)

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

On Tue, 13 Jul 2004, Ethan Merritt wrote:

> On Tuesday 13 July 2004 06:59 am, Petr Mikulik wrote:
> > > > Requirement for using specifiers always for plot ... binary would be rather
> > > > cumbersome. Current syntax is OK, e.g.
> > > > 	plot 'x.edf' binary with image
> > 
> > What's the problem with the above simple command? Why to do anything more?
> 
> I thought the binary mode was intended to handle all plot types,
> not just the new "with image".  Or have I got that wrong?
> If indeed it is to handle all plot styles, then it suffers from the same
> ambiguities as the non-binary form of plot commands.
> Simplest case:
> 	plot 'data' using 0:5 with lines	# y value is found in col 2
> 	plot 'data' using 5 with lines  # same y value is now found in col 1

That particular ambiguity could be fixed trivially in get_data().  All it
would take would be to convert 'using 5' into 'using 0:5' before any of
the datafile.c functions were even called.  The truly tricky ones are to
be found elsewhere, though:  acsplines, errorbars dy vs. ymin:max, and
explicit colour columns.

In a nutshell, we may already have piled too many new features on top of
the existing code base --- the foundation is starting to crumble.

> So I don't see how
> 	plot 'data' binary with lines
> is supposed to work unambiguously.

The same way it always did.  Actually, I think 'binary' with no using
spec should probably be reserved to mean the old gnuplot binary format,
if only for backward compatibility.

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

Re: Bugs in lisp sections of ./prepare and make

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

On Tue, 13 Jul 2004, Ethan Merritt wrote:

> This has hit both my existing systems (which had been happily 
> running Mandrake 9.2 for quite a while), and two brand-new
> newly-installed Mandrake 10.0 systems.  So while it may be a
> Mandrake configuration problem, it is not a question of out-of-date
> versioning.  Also, it *had* been working until recently on the older
> systems, and then something must have changed on the gnuplot
> side that caused it to no longer work.

That's almost certainly not the case.  The main reason being that
essentially all relevant files haven't been touched at all for several
weeks, AFAICS.  prepare itself hasn't changed since January 2004,
and the last modifications inside lisp were at the time of the 4.0.0
release.

What's more, I can't seen to even see why it's even trying to create a
config.guess file in the first place.  I'm looking at a readily configured
source tree (on Cygwin, if it matters), and there's neither a config.guess
nor a config.sub file in sight.  Actually, the only mentions of
config.guess in the entire tree are in the configure scripts (generated by
autoconf 2.59 and automake 1.7.9), which say:

ac_config_guess="$SHELL $ac_aux_dir/config.guess"

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

Re: Bugs in lisp sections of ./prepare and make

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

On Tuesday 13 July 2004 10:54 am, Lars Hecking wrote:
>  
>  Maybe your build environment is out of date? I cannot reproduce it.
>
> > However, I still have the problem from some time back
> > that the lisp target in the default make sequence tries to
> > write files to
> > 	/usr/share/emacs/site-lisp
>  
>  Another indication that your build environment, specifically automake,
>  may be out of date.

This has hit both my existing systems (which had been happily 
running Mandrake 9.2 for quite a while), and two brand-new
newly-installed Mandrake 10.0 systems.  So while it may be a
Mandrake configuration problem, it is not a question of out-of-date
versioning.  Also, it *had* been working until recently on the older
systems, and then something must have changed on the gnuplot
side that caused it to no longer work.

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

Re: Bugs in lisp sections of ./prepare and make

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

 
> Starting from a fresh download of the CVS source, I see
> ./prepare
> [various stuff]
> automake: configure.in: required file `../config.guess' not found
> automake: configure.in: required file `../config.sub' not found
> Some part of the preparation process failed.
> Please refer to INSTALL for details.
> 
> This failure comes specifically from the line
> 	cd lisp && aclocal && automake && autoconf
> 
> This problem is overcome by doing
> 	touch ./config.guess ./config.sub; ./prepare
 
 Maybe your build environment is out of date? I cannot reproduce it.

> However, I still have the problem from some time back
> that the lisp target in the default make sequence tries to
> write files to
> 	/usr/share/emacs/site-lisp
 
 Another indication that your build environment, specifically automake,
 may be out of date.

Re: 'with pixels' (was Re: Engines are started; ...)

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

Ethan Merritt wrote:

>On Tuesday 13 July 2004 06:59 am, Petr Mikulik wrote:
>  
>
>>>>Requirement for using specifiers always for plot ... binary would be rather
>>>>cumbersome. Current syntax is OK, e.g.
>>>>	plot 'x.edf' binary with image
>>>>        
>>>>
>>What's the problem with the above simple command? Why to do anything more?
>>    
>>
>
>I thought the binary mode was intended to handle all plot types,
>not just the new "with image".  Or have I got that wrong?
>

You're correct.

>If indeed it is to handle all plot styles, then it suffers from the same
>ambiguities as the non-binary form of plot commands.
>Simplest case:
>	plot 'data' using 0:5 with lines	# y value is found in col 2
>	plot 'data' using 5 with lines  # same y value is now found in col 1
>
>If you omit the using spec, it is ambiguous where to find the y value.
>So I don't see how
>	plot 'data' binary with lines
>is supposed to work unambiguously.
>
>That said, I would be perfectly happy to restrict things so that
>binary mode does not permit an implicit x-val column. 
>

I can go either way on having or not having implicit columns.  If things 
were organized well in the code, and explained well in the 
documentation, defaults might be no problem.  If a table containing the 
default implicit values existed, it could probably be dumped to the 
screen in some fashion to help the user.  But this is all too much of a 
big step right now to ponder a nice set up.

This one example

plot 'x.edf' binary with image

is in fact a special case if the "auto" or "edf" file type is selected because column information will be had from the file itself.  This is a different issue requiring discussion, but it shows the potential to do such things.

Dan

Bugs in lisp sections of ./prepare and make

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

About the time the new branch was created, something broke in
./prepare

Starting from a fresh download of the CVS source, I see
./prepare
[various stuff]
automake: configure.in: required file `../config.guess' not found
automake: configure.in: required file `../config.sub' not found
Some part of the preparation process failed.
Please refer to INSTALL for details.

This failure comes specifically from the line
	cd lisp && aclocal && automake && autoconf

This problem is overcome by doing
	touch ./config.guess ./config.sub; ./prepare

However, I still have the problem from some time back
that the lisp target in the default make sequence tries to
write files to
	/usr/share/emacs/site-lisp

Since this is a system directory, the make fails for non-root users.
I have worked around the problem on my own machines by
giving myself write access to this directory, but that's an ugly hack.

Can someone who understands lisp + autoconf please
fix these problems?


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

Re: 'with pixels' (was Re: Engines are started; ...)

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

On Tuesday 13 July 2004 06:59 am, Petr Mikulik wrote:
> > > Requirement for using specifiers always for plot ... binary would be rather
> > > cumbersome. Current syntax is OK, e.g.
> > > 	plot 'x.edf' binary with image
> 
> What's the problem with the above simple command? Why to do anything more?

I thought the binary mode was intended to handle all plot types,
not just the new "with image".  Or have I got that wrong?
If indeed it is to handle all plot styles, then it suffers from the same
ambiguities as the non-binary form of plot commands.
Simplest case:
	plot 'data' using 0:5 with lines	# y value is found in col 2
	plot 'data' using 5 with lines  # same y value is now found in col 1

If you omit the using spec, it is ambiguous where to find the y value.
So I don't see how
	plot 'data' binary with lines
is supposed to work unambiguously.

That said, I would be perfectly happy to restrict things so that
binary mode does not permit an implicit x-val column. 

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

Re: 'with pixels' (was Re: Engines are started; ...)

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

> > Requirement for using specifiers always for plot ... binary would be rather
> > cumbersome. Current syntax is OK, e.g.
> > 	plot 'x.edf' binary with image
>
> Well, it turns out that this requirement causes significant design
> problems in the code.  We have to trade off between ease of the user
> interface and clear design of the code.  At the current stage, I would
> really favour the latter.

What's the problem with the above simple command? Why to do anything more?

Gnuplot is command-line driven, thus we should keep command as simple as
possible. Thus, I prefer the former (unless there are ambiguities, of
course).

---
PM

Re: Should 4.1 keep supporting pre-4.0 syntax?

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

> > > > Gnuplot version cycle is at about 5 years.
> > >
> > > Where did you pick up that number?
> >
> > Because that did happen. Releasing 3.7 has taken 5 years, and the same for
> > 4.0 (1999 -- 2004).
>
> That was pure coincidence.

One popular Czech movies says: "oops, it happens once per 10 years..." ....
"oops, it happens twice per 10 years..." ...


> > Them is for example me, or Daniel -- we managed to get imagegp.m to work
> > fine with Octave. Not having the compatibility would be a stop-point for
> > using both nice apps.
>
> No it wouldn't.  It would *only* mean that imagegp.m has to use a gnuplot
> 4.0 executable for as long as nobody gets round to teaching it to use
> 'unset' instead of 'set no...'.  Which I honestly can't believe to be
> all that complicated.

Octave has built-in command gset, e.g.
	gset log y
Thus you can do comfortably
	gset nolog

without any need for
	gunset log

You cannot define "function/command" gunset to be called
	gunset log
=> you can call it as function
	gunset('log')

It looks like "gset noXXX" => "graw('unset XXXX')" backwards (script...)
compatibility would have to be dereferred to Octave -- that's something I
really don't like.

---
PM

Re: String variables

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

On Tue, 13 Jul 2004, Dave Denholm wrote:

> There is another question : should that evaluate the expression
> (sprintf...) once and store the resulting string value in the label,
> or should it store the expression and re-evaluate it for every plot ?

Depends on where the expression appears, I should think.  If we only
provide string variables, but not string-valued expression available
everwhere, this question won't arise.  

Generally, it should work like it does with numeric expressions vs.  
user-defined variables now:

	myfunx(x)=x**2
	a = myfunc(2)
	myfunc(x)=x**3
	plot a, myfunc(x)

will plot a constant 2 (not 8), and x**3.  I.e. all expression remain
to be evaluated when the command they appear in is executed.

> Here the analogy would be that
> 
>   set label 1 sprintf( "After fitting, A = %3.2f, B = %3.2f", A, B)
> 
> evaluates it once and stores the result, but
> 
>   set label 1 (sprintf( "After fitting, A = %3.2f, B = %3.2f", A, B))
> 
> stores it as an expression.

We'll need a different syntax, but the feature itself would probably be a
good idea.  And not only for strings, either.  Something like '$()' to
signify 'late expansion' (i.e. only when the value is actually needed),
maybe.

> I wonder if the parser is going to need help for identifying string
> expressions.

Quite definitely it will.  Technically, we'll need to extend
the is_string() function in some tricky way.  So far, my vague idea
was to require string-valued expressions to always start with a
string constant, for its benefit.  I.e. we would have
	
	plot f(x)   # numeric expr. --> function
	plot 'file' # string --> file name
	plot ''+g(p,q)  # string --> computed filename

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

Re: 'with pixels' (was Re: Engines are started; ...)

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

On Tue, 13 Jul 2004, Petr Mikulik wrote:

> > The option of omitting the using specification is legacy behaviour of
> > gnuplot.  How about this proposal, then: require binary file always to
> > have using specifiers, and be done with that complication.
> >
> > > The question for me is should the user be required
> > > *always* to enter specifically how columns are to be used via "using"?
> 
> Requirement for using specifiers always for plot ... binary would be rather
> cumbersome. Current syntax is OK, e.g.
> 	plot 'x.edf' binary with image

Well, it turns out that this requirement causes significant design
problems in the code.  We have to trade off between ease of the user
interface and clear design of the code.  At the current stage, I would
really favour the latter.

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

Re: Should 4.1 keep supporting pre-4.0 syntax?

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

On Tue, 13 Jul 2004, Petr Mikulik wrote:

> > > Gnuplot version cycle is at about 5 years.
> >
> > Where did you pick up that number?
> 
> Because that did happen. Releasing 3.7 has taken 5 years, and the same for
> 4.0 (1999 -- 2004).

That was pure coincidence.  

> > least roughly up to date, is.  If they want to use bleeding-edge gnuplot
> > without taking proper care: fine, let them cut themselves.  Might teach
> > them a lesson.

> Them is for example me, or Daniel -- we managed to get imagegp.m to work
> fine with Octave. Not having the compatibility would be a stop-point for
> using both nice apps.

No it wouldn't.  It would *only* mean that imagegp.m has to use a gnuplot
4.0 executable for as long as nobody gets round to teaching it to use
'unset' instead of 'set no...'.  Which I honestly can't believe to be
all that complicated.

At the risk of sounding like my own echo: 4.1 is strictly work-in-progress
code at this time.  Nobody in their right mind should even think of using
this in production environments unless they're willing to update all other
parts equally quickly as gnuplot.

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

Re: String variables

[Dave D. <dde...@es...>]

Petr Mikulik <mi...@ph...> writes:

>> >     set label 1 sprintf( "After fitting, A = %3.2f, B = %3.2f", A, B)
>>
>> That one, mostly.  Generally, the "A = $A" syntax may seem simple, but
>> it's also of rather limited flexibility.
>>
>> This function-like syntax also extends more naturally to other operations
>> on strings (scanning a string, reading a string from an external file,
>> ...).  I think we can take a hint from Java, here: Strings are native
>> datatypes, but the only operator they support is '+' for concatenation.
>> Everything else is done by functions.
>
> I would also prefer this way of sprintf and '+' operator for strings.
>

There is another question : should that evaluate the expression
(sprintf...) once and store the resulting string value in the label,
or should it store the expression and re-evaluate it for every plot ?


Should both be supported ?

Eg  the plot ... using (expression)  broke backwards compatibility
because previously, 'using' expected a constant expression which gave
a column number.

As I'm sure you'll all remember, the brackets were a compromise. But
it's a bit ugly. There's nothing to say that the constant expression
could not contain brackets.


Here the analogy would be that

  set label 1 sprintf( "After fitting, A = %3.2f, B = %3.2f", A, B)

evaluates it once and stores the result, but

  set label 1 (sprintf( "After fitting, A = %3.2f, B = %3.2f", A, B))

stores it as an expression.


(I'm not suggesting this as a way forward - just hightlighting the
issue)


I wonder if the parser is going to need help for identifying string
expressions. gnuplot has always had a fairly lax syntax, with optional
bits of commands being detected automatically.

Eg

f(x,y)=sprintf( "After fitting, A = %3.2f, B = %3.2f", x,y)

set label 1 f(A,B)


Could so something like

 set label 1 """f(A,B)"""

which alerts the lexer that there's a string expression next.

Or I think tcl uses [...] to indicate an expression.


dd
-- 
Dave Denholm              <dde...@es...>       http://www.esmertec.com

Re: 'with pixels' (was Re: Engines are started; ...)

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

> The option of omitting the using specification is legacy behaviour of
> gnuplot.  How about this proposal, then: require binary file always to
> have using specifiers, and be done with that complication.
>
> > The question for me is should the user be required
> > *always* to enter specifically how columns are to be used via "using"?

Requirement for using specifiers always for plot ... binary would be rather
cumbersome. Current syntax is OK, e.g.
	plot 'x.edf' binary with image

---
PM

Re: Should 4.1 keep supporting pre-4.0 syntax?

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

> > Gnuplot version cycle is at about 5 years.
>
> Where did you pick up that number?

Because that did happen. Releasing 3.7 has taken 5 years, and the same for
4.0 (1999 -- 2004).

> > Well, Octave is a major application using gnuplot, and we should wait until
> > they get accustomed to new gnuplot
>
> Them getting accustomed is not the point --- them using our latest
> work-in-progress snapshot, while not willing to keep their own software at
> least roughly up to date, is.  If they want to use bleeding-edge gnuplot
> without taking proper care: fine, let them cut themselves.  Might teach
> them a lesson.

Them is for example me, or Daniel -- we managed to get imagegp.m to work
fine with Octave. Not having the compatibility would be a stop-point for
using both nice apps.

Currently, I have no time to do pressure or coding on Octave sources to
change for the new syntax of gnuplot. Until someone implements this, and it
is released in Octave, then we can start to think about removing the
compatibility layer. Not before.

Thus, it needs "someone" to contribute the change for Octave, not "them".

---
PM

Re: String variables

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

> >     set label 1 sprintf( "After fitting, A = %3.2f, B = %3.2f", A, B)
>
> That one, mostly.  Generally, the "A = $A" syntax may seem simple, but
> it's also of rather limited flexibility.
>
> This function-like syntax also extends more naturally to other operations
> on strings (scanning a string, reading a string from an external file,
> ...).  I think we can take a hint from Java, here: Strings are native
> datatypes, but the only operator they support is '+' for concatenation.
> Everything else is done by functions.

I would also prefer this way of sprintf and '+' operator for strings.

---
PM

Re: [Fwd: Re: 'with pixels' (was Re: Engines are started; ...)]

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

Hans-Bernhard Broeker wrote:

>Not really.  The mess we're talking about here (the mapping from data
>values accessed a seris of 'using' specifiers to elements of 'struct
>coordinate' (x,y,z,ylow,...) is currently a two-part one: part one is that
>the number of specifiers changes the assignment from a position in the
>using spec sequence to struct elements (e.g. errorbars: 3 columns mean
>x:y:dy, 4 columns mean x:y:ylow:yhigh, i.e. the meaning of the third
>specifier depends on whether there's a forth one or not).  The *other*
>aspect of the mess is that users have to memorize the order of using spec
>for all plot styles.
>

Yes, I know.  That is somewhat of an inconvenience.

>>configuration inside a table.  That is, there is the enumeration for the 
>>PLOT_STYLE and one could build tables off of that.  
>>    
>>
>
>Or rather, I guess what we should consider is a re-organization of the
>entire way plot styles are handled.  The current 'enum with flags in'
>approach of defining plot style indices as magic numbers is of rather
>limited versatility, and more of a hack than a proper design.  
>
>Currently we have 9 switch() statements over the plot type, and about 90
>other comparisons of the plot_style field with particular types, scattered
>all across the 4 inner core modules (plot[23]d, graphics, graph3d) and
>several others.  I think this would all make a lot more sense if we
>collected at least all code governed by those switch()es, but possibly
>more, in one contiguous block of code *per plot style*.  I.e. all special
>code for handling the 'with yerrorbars' style should be in *one* place.
>

Better organization would be nice.  I thought more about what I wrote 
using lookup tables and concluded if one were to do all that work, maybe 
some other approaches would be even more worthwhile.  This is getting a 
ways ahead, but one idea might be to eliminate the unused columns of the 
style.  I can imagine a way to do it, but I think along the way you'd 
end up having to cast a pointer to the coordinate structure one is 
interested in.  That would make for ugly code.

Dan

Re: Should 4.1 keep supporting pre-4.0 syntax?

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

On Mon, 12 Jul 2004, Petr Mikulik wrote:

> Gnuplot version cycle is at about 5 years. 

Where did you pick up that number?  From where I stand, gnuplot has no
version cycle expressable in terms of time to speak of. And it hasn't had
one ever since Alex Woo's released his last 3.5 in 1993. Ever since the
3.6-beta phase, we've always stated that we do *not* plan ahead in terms
of time, but rather release when we think the stuff is ready.

> Well, Octave is a major application using gnuplot, and we should wait until
> they get accustomed to new gnuplot 

Them getting accustomed is not the point --- them using our latest
work-in-progress snapshot, while not willing to keep their own software at
least roughly up to date, is.  If they want to use bleeding-edge gnuplot
without taking proper care: fine, let them cut themselves.  Might teach
them a lesson.

> We could switch off the compatibility "by default" shortly before releasing
> the current cvs as gnuplot 4.1. But not before. (I could not test it, for
> example.)

I disagree.  Breaking down compatibility bridges is something that has to
be done *early* in a development cycle, like right now.  Shortly before an
actual release would IMHO be exactly the wrong time to make such
modifications.

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