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

Re: gnuplot latex documentation error with (MiKTeX 22.7)

[Ethan A M. <me...@uw...>]

On Thursday, 25 August 2022 21:06:33 PDT Tatsuro MATSUOKA via gnuplot-beta wrote:
> I have a situation to make gnuplot.pdf on windows (MinGW-w64) with MiKTeX 22.7
> 
> ************************************************************************************************.
>   :
>   :
> LaTeX Warning: Reference `set label' on page 70 undefined on input line 6036.
> 
> 
> LaTeX Warning: Reference `hypertext' on page 70 undefined on input line 6059.
> 
> 
> 
> pdfTeX warning: pdflatex.exe (file ./figure_labels2.pdf): PDF inclusion: found
> PDF version <1.7>, but at most version <1.5> allowed
> 
> ! LaTeX Error: Unicode character ∙ (U+2219)
>                not set up for use with LaTeX.


U+2219 is \bullet in LaTeX.
Perhaps the unicode support package included with MiKTeX 22.7 is incomplete?
The file .../texmf-dist/tex/generic/unicode-data/UnicodeData.txt
should contain a line

2219;BULLET OPERATOR;Sm;0;ON;;;;;N;;;;;


As a work-around, this thread 
  https://tex.stackexchange.com/questions/598469/package-inputenc-error-unicode-character-%E2%88%99-u2219

suggests it may be possible to say
    \usepackage{newunicodechar}
    \newunicodechar{^^^^2219}{\cdot}

but I think it would be better to figure out what is wrong with the MiKTeX
installation.


	Ethan

gnuplot latex documentation error with (MiKTeX 22.7)

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

I have a situation to make gnuplot.pdf on windows (MinGW-w64) with MiKTeX 22.7

************************************************************************************************.
  :
  :
LaTeX Warning: Reference `set label' on page 70 undefined on input line 6036.


LaTeX Warning: Reference `hypertext' on page 70 undefined on input line 6059.



pdfTeX warning: pdflatex.exe (file ./figure_labels2.pdf): PDF inclusion: found
PDF version <1.7>, but at most version <1.5> allowed

! LaTeX Error: Unicode character ∙ (U+2219)
               not set up for use with LaTeX.

See the LaTeX manual or LaTeX Companion for explanation.
Type  H <return>  for immediate help.
 ...

******************************************************************************************************


I have not met such error on MiKTeX 22.3.

Any suggestions are welcome.

Tatsuro 

Re: xyplane tics too large with orthogonal splot views

[Ethan A M. <me...@uw...>]

On Thursday, 11 August 2022 15:06:40 PDT Dima Kogan wrote:
> Hi. I just made some 3D plots from an orthogonal side view (set view
> 90,0). This has special-case logic in gnuplot to treat it like a 2D plot
> in some ways. It looks like the logic isn't completely right, though,
> and the tics on the xy plane end up larger than they should. And the
> tics appear on both sides of the plane, which isn't obviously right. Can
> somebody please take a look?

I think there is not an easy fix for this.
The original code assumes that the vertical axis is "y" just
about everywhere, and calculates various scale factors using
that assumption. A complete fix would have to handle all the
various possible projections and rotations as special cases
wherever it makes a difference.

Possibly the odd placement of mirrored tics can be repaired,
or tic mirroring ignored in this projection.  I'll look at that.

But the tic length - meh. You can fix it for any given plot using
"set xtic scale" so IMHO it's not a high priority to rework all the code
just for that. But if someone is inspired to do so, fine - go for it.
I suggest that you file this as a bug report on the tracker so it
isn't forgotten.

	Ethan

Re: xyplane tics too large with orthogonal splot views

[Ethan A M. <me...@uw...>]

On Thursday, 11 August 2022 18:10:44 PDT Dima Kogan wrote:

> > It's also a bit weird that "set xyplane at <foo>" is actually
> > acting as if it were "set xrange [ low : high + foo ].
> > I worry that setting <foo> to anything other than zero may
> > have other unexpected side effects.
> > 
> >         Ethan

> Something is being strangely proportional. If
> I make the same plot, but do so interactively, (without "set terminal"
> or "set output"), then I see the length of the tics change as I
> interactively move the xyplane (shift+button2+drag up/down).

That would be an example of "unexpected side effects" :-)

I think the tic lengths are changing due to the changing aspect ratio
of the plot.  I see the same effect just by changing the window size
by dragging a corner with the mouse.

There does seem to be a difference between gnuplot 4 and gnuplot 5,
so the change/bug/quirk/whatever probably dates back a few years.
I'll have a look but I'm working on other things right now.

	Ethan

Re: xyplane tics too large with orthogonal splot views

[Dima K. <gn...@di...>]

Thanks for looking, Ethan. Something is being strangely proportional. If
I make the same plot, but do so interactively, (without "set terminal"
or "set output"), then I see the length of the tics change as I
interactively move the xyplane (shift+button2+drag up/down).

Re: xyplane tics too large with orthogonal splot views

[Ethan A M. <me...@uw...>]

On Thursday, 11 August 2022 15:06:40 PDT Dima Kogan wrote:
> Hi. I just made some 3D plots from an orthogonal side view (set view
> 90,0). This has special-case logic in gnuplot to treat it like a 2D plot
> in some ways. It looks like the logic isn't completely right, though,
> and the tics on the xy plane end up larger than they should. And the
> tics appear on both sides of the plane, which isn't obviously right. Can
> somebody please take a look?

I'll have a look.

Meanwhile as you probably found, you can "fix" the output with

    set xtics nomirror scale 0.5

It's also a bit weird that "set xyplane at <foo>" is actually
acting as if it were "set xrange [ low : high + foo ].
I worry that setting <foo> to anything other than zero may
have other unexpected side effects.

	Ethan

> This happens with the latest gnuplot in git.
> 
> The script appears below, and the result is attached.
> 
> Thanks!
> 
> 
> 
> set view 90,0
> set xyplane at -0.1
> set xtics 0.5
> set ytics 0.5
> set view equal xyz
> set xlabel "x"
> set ylabel "y"
> set zlabel "z"
> 
> set terminal png size 600,1000
> set output "/tmp/tics-too-big.png"
> splot '-'   using 1:2:3:4:5:6 notitle with vectors , \
>       '-'   using 1:2:3:4:5:6 notitle with vectors
> 0.0 0.0 0.0 0.3333335701378377 0.0 0.0
> 0.0 0.0 0.0 0.0 0.3333335701378377 0.0
> 0.0 0.0 0.0 0.0 0.0 0.6666671402756754
> e
> -1.487915757943345 -0.8842424394390623 4.822904587742955 0.3295936234755228 -0.004829189464130801 0.04955795873753832
> -1.487915757943345 -0.8842424394390623 4.822904587742955 0.0054208354243061585 0.33327029824180776 -0.0035765673425567357
> -1.487915757943345 -0.8842424394390623 4.822904587742955 -0.09899347227801636 0.008684749800146774 0.6592191922953985
> e
> set output
> 
> 
> 


-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
MS 357742,   University of Washington, Seattle 98195-7742

xyplane tics too large with orthogonal splot views

[Dima K. <gn...@di...>]

Hi. I just made some 3D plots from an orthogonal side view (set view
90,0). This has special-case logic in gnuplot to treat it like a 2D plot
in some ways. It looks like the logic isn't completely right, though,
and the tics on the xy plane end up larger than they should. And the
tics appear on both sides of the plane, which isn't obviously right. Can
somebody please take a look?

This happens with the latest gnuplot in git.

The script appears below, and the result is attached.

Thanks!



set view 90,0
set xyplane at -0.1
set xtics 0.5
set ytics 0.5
set view equal xyz
set xlabel "x"
set ylabel "y"
set zlabel "z"

set terminal png size 600,1000
set output "/tmp/tics-too-big.png"
splot '-'   using 1:2:3:4:5:6 notitle with vectors , \
      '-'   using 1:2:3:4:5:6 notitle with vectors
0.0 0.0 0.0 0.3333335701378377 0.0 0.0
0.0 0.0 0.0 0.0 0.3333335701378377 0.0
0.0 0.0 0.0 0.0 0.0 0.6666671402756754
e
-1.487915757943345 -0.8842424394390623 4.822904587742955 0.3295936234755228 -0.004829189464130801 0.04955795873753832
-1.487915757943345 -0.8842424394390623 4.822904587742955 0.0054208354243061585 0.33327029824180776 -0.0035765673425567357
-1.487915757943345 -0.8842424394390623 4.822904587742955 -0.09899347227801636 0.008684749800146774 0.6592191922953985
e
set output

x11 plotting into an existing window behaves badly if the window doesn't (yet) exist

[Dima K. <gn...@di...>]

Hi. I'm using the x11 terminal to plot into an existing window:

  set terminal x11 window XID

Overall it works really well. I'm seeing an issue when the requested
window doesn't exist: gnuplot simply ignores the request, and pops up a
new X window, as usual. This is never what the user intends, I think.

A less made-up scenario is what I actually encountered when trying to
use this feature: I made a new window, and asked gnuplot to plot into
it. This didn't work because my new target window hasn't been created
YET.

Trying to debug this, I added some more diagnostics to gplt_x11.c
(attached; these should be good-enough to merge). I see that the
failing sequence is:

- in pr_window() gplt_x11.c calls XGetWindowAttributes() on the
  requested window. This is the first time gnuplot does anything with
  the requested window

- If the window already exists, this succeeds, and we continue, happily.
  If not, the error handler is invoked instead. Here's the diagnostic
  output produced with DEBUG:

    gplt_x11.c:1655 psp->external_container = 0x2400005
    gplt_x11.c:6679 (pr_window) 
    gplt_x11.c:6683 was asked to plot externally...
    gplt_x11.c:4354 Received X error:  error_code=BadWindow request_code=X_GetWindowAttributes minor_code=0
    gplt_x11.c:7230 Add plot to remove FIFO queue called.
    gplt_x11.c:7269   -> Added an element to FIFO queue.
    gplt_x11.c:6692 making plot window
    gplt_x11.c:4354 Received X error:  error_code=BadWindow request_code=X_CreateWindow minor_code=0
    gplt_x11.c:7230 Add plot to remove FIFO queue called.
    gplt_x11.c:4354 Received X error:  error_code=BadWindow request_code=X_ChangeWindowAttributes minor_code=0
    gplt_x11.c:7230 Add plot to remove FIFO queue called.
    gplt_x11.c:7269   -> Added an element to FIFO queue.
    gplt_x11.c:4354 Received X error:  error_code=BadWindow request_code=X_ChangeProperty minor_code=0
    gplt_x11.c:7230 Add plot to remove FIFO queue called.
    gplt_x11.c:4354 Received X error:  error_code=BadWindow request_code=X_ChangeProperty minor_code=0
    gplt_x11.c:7230 Add plot to remove FIFO queue called.
    gplt_x11.c:4354 Received X error:  error_code=BadWindow request_code=X_ChangeProperty minor_code=0
    gplt_x11.c:7230 Add plot to remove FIFO queue called.
    gplt_x11.c:4354 Received X error:  error_code=BadWindow request_code=X_ChangeWindowAttributes minor_code=0
    gplt_x11.c:7230 Add plot to remove FIFO queue called.
    gplt_x11.c:4354 Received X error:  error_code=BadWindow request_code=X_ChangeWindowAttributes minor_code=0
    gplt_x11.c:7230 Add plot to remove FIFO queue called.
    gplt_x11.c:6795 term_number is -1
    gplt_x11.c:4778 Cursors reset
    gplt_x11.c:7321 Processed element in remove FIFO queue.
    gplt_x11.c:1209 Delete plot -1
    gplt_x11.c:1233 Destroy window 0x36000fe
    gplt_x11.c:7321 Processed element in remove FIFO queue.
    gplt_x11.c:7063 psp->external_container = None
    ...

  The line numbers are off, since I had some extra diagnostic code. We
  do see that X errors are received for every request that touches the
  not-yet-existing window, the error handler does some complex thing I
  don't yet understand, and eventually we psp->external_container =
  None, i.e. we give up on plotting to the requested window, and create
  a new one, as usual.


Would it not make more sense for gplt_x11 to retry
XGetWindowAttributes() call until the requested window exists? I'm not
familiar with Xlib error handling, and this doesn't look completely
trivial, so I wanted to ask here first. Anybody here have experience
with Xlib, and suggestions on the "right" way to implement that?

Thanks

Re: Gnuplot Version 5.4.4 Release

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

I have uploaded windows binary packages.

Tatsuro

> ----- Original Message -----
> Date: 2022/07/18 月 12:32
> Subject: Gnuplot Version 5.4.4 Release
> 
> 
> Release 5.4.4 is now available for download from SourceForge
> 
> Thanks to everyone who tested prior release and to everyone who sent
> bug reports or suggested changes.
> 
> Source tarball
> 
>     https://sf.net/projects/gnuplot/files/gnuplot/5.4.4/gnuplot-5.4.4.tar.gz
> 
> Release notes (10-Jul-2022)
> 
> This release contains bug fixes and a few changes back-ported from the
> development version.  Probably the most noticeable is modification to
> make page layout of 3D plots after "set view map; splot ..." more like
> the corresponding page layout of 2D plots, including display of x2 and y2
> axis labels.
> 
> Changes in 5.4.4
> ================
> * NEW plots can use arrow styles that specify "lc rgb variable" 
> * CHANGE make page layout of "set view map; splot" more like that of "plot"
> *        - honor "set rmargin" and "set tmargin" Bug #2484
> *        - display x2label and y2label Bug #2484
> *        - revised placement of color box Bug #2484
> *        - reconcile linked axis data and tic ranges Bug #2483
> *        - apply "set key invert" to splot Bug #2381
> * CHANGE cairo terminals: increase internal oversampling factor Bugs #2499 #2369
> * CHANGE fig: restore terminal option "pointsmax <N>" Bug #2509
> * CHANGE always add a space between items in a "print" command Bug #2488
> * CHANGE consistent ordering of input columns for "plot ... ps var pt var" Bug #2524
> * CHANGE gnuplot -c script.gp A B -C ... will pass A B -C ... without interpretation
> * CHANGE stricter error checks when promoting string to numeric value Bug #2527
> * CHANGE report GPVAL_TERM_XMIN and friends as floating point values
> * FIX handle combination of axis properties logscale + autoscale + reverse Bug #2347
> * FIX mis-handled arguments at start-up of "gnuplot -c script arg1 ..." Bug #2493
> * FIX windows: redirected output of printf() Bug #2490
> * FIX allow variable point style and point type in plot "with yerrorbars"
> * FIX plots "with labels point pt variable" were off-by-one in choosing point type
> * FIX contour "with labels" from binary data
> * FIX x/y fractional coordinate mouse readout for nonlinear axes Bug #2526
> * FIX Support combination of "set surface explicit; set hidden3d" Bug #2521
> 
> 
>         happy gnuplotting,
> 
>                 Ethan 
> 
> 
> 
> 
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: Gnuplot Version 5.4.4 Release

[Dima K. <gn...@di...>]

Ethan A Merritt <me...@uw...> writes:

> Release 5.4.4 is now available for download from SourceForge

Thanks for working on this, Ethan!

Gnuplot Version 5.4.4 Release

[Ethan A M. <me...@uw...>]

Release 5.4.4 is now available for download from SourceForge

Thanks to everyone who tested prior release and to everyone who sent
bug reports or suggested changes.

Source tarball

    https://sf.net/projects/gnuplot/files/gnuplot/5.4.4/gnuplot-5.4.4.tar.gz

Release notes (10-Jul-2022)

This release contains bug fixes and a few changes back-ported from the
development version.  Probably the most noticeable is modification to
make page layout of 3D plots after "set view map; splot ..." more like
the corresponding page layout of 2D plots, including display of x2 and y2
axis labels.

Changes in 5.4.4
================
* NEW plots can use arrow styles that specify "lc rgb variable" 
* CHANGE make page layout of "set view map; splot" more like that of "plot"
*        - honor "set rmargin" and "set tmargin" Bug #2484
*        - display x2label and y2label Bug #2484
*        - revised placement of color box Bug #2484
*        - reconcile linked axis data and tic ranges Bug #2483
*        - apply "set key invert" to splot Bug #2381
* CHANGE cairo terminals: increase internal oversampling factor Bugs #2499 #2369
* CHANGE fig: restore terminal option "pointsmax <N>" Bug #2509
* CHANGE always add a space between items in a "print" command Bug #2488
* CHANGE consistent ordering of input columns for "plot ... ps var pt var" Bug #2524
* CHANGE gnuplot -c script.gp A B -C ... will pass A B -C ... without interpretation
* CHANGE stricter error checks when promoting string to numeric value Bug #2527
* CHANGE report GPVAL_TERM_XMIN and friends as floating point values
* FIX handle combination of axis properties logscale + autoscale + reverse Bug #2347
* FIX mis-handled arguments at start-up of "gnuplot -c script arg1 ..." Bug #2493
* FIX windows: redirected output of printf() Bug #2490
* FIX allow variable point style and point type in plot "with yerrorbars"
* FIX plots "with labels point pt variable" were off-by-one in choosing point type
* FIX contour "with labels" from binary data
* FIX x/y fractional coordinate mouse readout for nonlinear axes Bug #2526
* FIX Support combination of "set surface explicit; set hidden3d" Bug #2521


        happy gnuplotting,

                Ethan 

Re: Beta-testing version of 5.4.4

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

Thank you for your effort.

I did test build 5.4.4beta source on Windows (mingw64) and build and all.dem checks did well
I also confirmed bug #2532 was corrected on 5.4.3 on windows(mingw64).

Tatsuro

----- Original Message -----

From: "Ethan A Merritt" 
To: "Gnuplot Beta" 
Date: 2022/07/11 月 04:36
Subject: Beta-testing version of 5.4.4


I have placed a tarball for a beta-test version of gnuplot 5.4.3 on SourceForge.
Please report any problems,

There is nothing special in this minor release.
It mostly consists of small fixes back-ported from the development version.
The most visible change is that auto-layout of 3D plots after "set view map"
is more similar to the auto-layout of 2D plots, including display of x2 and y2
axis labels if they are present.
 
For a slightly more complete list of changes see the Release Notes.

 https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/gnuplot-5.4.4beta.tar.gz

My plan is to announce the 5.4.4 release in a week or so.

       happy gnuplotting,

               Ethan



_______________________________________________
gnuplot-beta mailing list
gnu...@li...
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Beta-testing version of 5.4.4

[Ethan A M. <me...@uw...>]

I have placed a tarball for a beta-test version of gnuplot 5.4.3 on SourceForge.
Please report any problems,

There is nothing special in this minor release.
It mostly consists of small fixes back-ported from the development version.
The most visible change is that auto-layout of 3D plots after "set view map"
is more similar to the auto-layout of 2D plots, including display of x2 and y2
axis labels if they are present.
 
For a slightly more complete list of changes see the Release Notes.

  https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/gnuplot-5.4.4beta.tar.gz

My plan is to announce the 5.4.4 release in a week or so.

        happy gnuplotting,

                Ethan

Re: Beta-testing version of 5.4.4

[Ethan A M. <me...@uw...>]

On Sunday, 10 July 2022 11:33:13 PDT Ethan A Merritt wrote:
> I have placed a tarball for a beta-test version of gnuplot 5.4.3 on SourceForge.
                                                                            
                              meh, that shoud of course read "gnuplot 5.4.4"

> Please report any problems,
> 
> There is nothing special in this minor release.
> It mostly consists of small fixes back-ported from the development version.
> The most visible change is that auto-layout of 3D plots after "set view map"
> is more similar to the auto-layout of 2D plots, including display of x2 and y2
> axis labels if they are present.
>  
> For a slightly more complete list of changes see the Release Notes.
> 
>   https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/gnuplot-5.4.4beta.tar.gz
> 
> My plan is to announce the 5.4.4 release in a week or so.
> 
>         happy gnuplotting,
> 
>                 Ethan

Re: ABI mismatch erorr on wxt terminal on the current msys2-windows build (GCC 12) and workaound

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

----- Original Message -----
Date: 2022/05/27 金 02:24
Subject: Re: ABI mismatch erorr on wxt terminal on the current msys2-windows build  (GCC 12) and workaound


On Wednesday, 25 May 2022 22:03:57 PDT Tatsuro MATSUOKA wrote:
> I updated msys2-mingw64 recently and GCC is upgraded to version 12.
> I tried to build gnuplot for windows using GCC 12 and tried to use the wxt terminal.
> gnuplot> set terminal wxt
> gnuplot> pl x
>
> Error windows poped up.
> URL of the Screenshot http://tmacchant33.starfree.jp/Files/wxt_ABI_mismatch.png
>
> Fatal Error
> Mismatch between the program and library build version
> detected.
> The library used 3.0(wchar_t,complier with C++ ABI 1016, wx
> containers, compatible with 2.8),
> and your program used 3.0 (wchr_t,compiler with C++ ABI
> 1017, wx containers, compatible with 2.8).

That is an unfortunate bug/mis-design introduced by the some runtime library support.
I do not know whether something in gcc 12 is the cause, or whether the change from
gcc 11 to gcc 12 coincidentally happened at the same time.

I now get similar error messages when running programs compiled before the change
For example:
 [] gnuplot_5.2.8 -e 'plot x' 
 Warning: Mismatch between the program and library build versions detected. 
 The library used 2.8 (no debug,Unicode,compiler with C++ ABI 1014,wx containers,compatible with 2.6), 
 and your program used 2.8 (no debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible with 2.6).
 [] gnuplot_5.4.2 -e 'plot x'   
 Warning: Mismatch between the program and library build versions detected. 
 The library used 3.0 (wchar_t,compiler with C++ ABI 1014,wx containers,compatible with 2.8), 
 and wxNet used 3.0 (wchar_t,compiler with C++ ABI 1013,wx containers,compatible with 2.8).
These executables were built in 2019 and 2021. The C compiler used at the
time would not have been gcc 12. The programs executed correctly when they were
built and continue to execute correctly now.
But now they emit this annoying warning message.
 
 > Workaround is to insert " #define __GXX_ABI_VERSION 1016"
> at the top of src/wxt_gui.cpp
> --- a/src/wxterminal/wxt_gui.cpp   2022-05-26 12:37:23.464908700 +0900
> +++ b/src/wxterminal/wxt_gui.cpp   2022-05-26 13:10:10.970037600 +0900
> @@ -88,6 +88,8 @@
>  * or multi-threaded operation.
>  */
> 
> +/* avoid mismatch message C++ ABI number*/
> +#define __GXX_ABI_VERSION 1016

I don't think that is a good idea.

That work-around is likely to work only on a machine that happens to use
that specific version of the runtime library.
As soon as you run the executable on a machine with a newer or older runtime
then it will probably complain about a mismatch between 1016 and some other
version number.  I'm pretty sure it is the warning message that is bogus,
not the program.

Having said that, however, your report claims a fatal error. My machines
are only printing this as a warning. Perhaps the mismatch between versions
1016 and 1017 really is more serious?  But then hiding it by lying about the
true version would not fix it. The program may crash later on when it hits the
incompatible ABI feature, whatever that is.

I found some reports on the web that suggest the true problem is an improper
configuration flag used to build the wxgtk library. However, that doesn't make
sense to me, since the error message has only started to appear recently
even though both the wxgtk library and the executable that links to it are
several years old. I suspect rather that the linker/loader has become overly
paranoid about comparing compiler versions reported by libraries and programs.
I do not know how to fix that.

   Ethan

Today I updated the msys2-mingw64. The wxWidgets package was updated.
The new wxWidgets libraries seemed to be re-built with gcc-12.
The ABI mismatch issue is disappeared.

Thank you for your detailed comments and explanations.

Tatsuro

Re: ABI mismatch erorr on wxt terminal on the current msys2-windows build (GCC 12) and workaound

[Ethan A M. <me...@uw...>]

On Wednesday, 25 May 2022 22:03:57 PDT Tatsuro MATSUOKA wrote:
> I updated msys2-mingw64 recently and GCC is upgraded to version 12.
> I tried to build gnuplot for windows using  GCC 12 and tried to use the wxt terminal.
> gnuplot> set terminal wxt
> gnuplot> pl x
> 
> Error windows poped up.
> URL of  the Screenshot http://tmacchant33.starfree.jp/Files/wxt_ABI_mismatch.png
> 
> Fatal Error
> Mismatch between the program and library build version 
> detected.
> The library used 3.0(wchar_t,complier with C++ ABI 1016, wx
> containers, compatible with 2.8),
> and your program used 3.0 (wchr_t,compiler with C++ ABI
> 1017, wx containers, compatible with 2.8).

That is an unfortunate bug/mis-design introduced by the some runtime library support.
I do not know whether something in gcc 12 is the cause, or whether the change from
gcc 11 to gcc 12 coincidentally happened at the same time. 

I now get similar error messages when running programs compiled before the change
For example:
  [] gnuplot_5.2.8 -e 'plot x' 
  Warning: Mismatch between the program and library build versions detected. 
  The library used 2.8 (no debug,Unicode,compiler with C++ ABI 1014,wx containers,compatible with 2.6), 
  and your program used 2.8 (no debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible with 2.6).
  [] gnuplot_5.4.2 -e 'plot x'    
  Warning: Mismatch between the program and library build versions detected. 
  The library used 3.0 (wchar_t,compiler with C++ ABI 1014,wx containers,compatible with 2.8), 
  and wxNet used 3.0 (wchar_t,compiler with C++ ABI 1013,wx containers,compatible with 2.8).
These executables were built in 2019 and 2021.  The C compiler used at the
time would not have been gcc 12. The programs executed correctly when they were
built and continue to execute correctly now.
But now they emit this annoying warning message.


> Workaround is to insert " #define __GXX_ABI_VERSION 1016" 
> at the top of src/wxt_gui.cpp
> --- a/src/wxterminal/wxt_gui.cpp	2022-05-26 12:37:23.464908700 +0900
> +++ b/src/wxterminal/wxt_gui.cpp	2022-05-26 13:10:10.970037600 +0900
> @@ -88,6 +88,8 @@
>   * or multi-threaded operation.
>   */
>  
> +/* avoid mismatch message C++ ABI number*/
> +#define __GXX_ABI_VERSION 1016

I don't think that is a good idea.

That work-around is likely to work only on a machine that happens to use
that specific version of the runtime library.
As soon as you run the executable on a machine with a newer or older runtime
then it will probably complain about a mismatch between 1016 and some other
version number.   I'm pretty sure it is the warning message that is bogus,
not the program.

Having said that, however, your report claims a fatal error.  My machines
are only printing this as a warning.  Perhaps the mismatch between versions
1016 and 1017 really is more serious?   But then hiding it by lying about the
true version would not fix it. The program may crash later on when it hits the
incompatible ABI feature, whatever that is.

I found some reports on the web that suggest the true problem is an improper
configuration flag used to build the wxgtk library.  However that doesn't make
sense to me, since the error message has only started to appear recently
even though both the wxgtk library and the executable that links to it are
several years old.  I suspect rather that the linker/loader has become overly
paranoid about comparing compiler versions reported by libraries and programs.
I do not know how to fix that.

	Ethan

ABI mismatch erorr on wxt terminal on the current msys2-windows build (GCC 12) and workaound

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

I updated msys2-mingw64 recently and GCC is upgraded to version 12.
I tried to build gnuplot for windows using  GCC 12 and tried to use the wxt terminal.
gnuplot> set terminal wxt
gnuplot> pl x

Error windows poped up.
URL of  the Screenshot http://tmacchant33.starfree.jp/Files/wxt_ABI_mismatch.png

Fatal Error
Mismatch between the program and library build version 
detected.
The library used 3.0(wchar_t,complier with C++ ABI 1016, wx
containers, compatible with 2.8),
and your program used 3.0 (wchr_t,compiler with C++ ABI
1017, wx containers, compatible with 2.8).

Workaround is to insert " #define __GXX_ABI_VERSION 1016" 
at the top of src/wxt_gui.cpp


--- a/src/wxterminal/wxt_gui.cpp	2022-05-26 12:37:23.464908700 +0900
+++ b/src/wxterminal/wxt_gui.cpp	2022-05-26 13:10:10.970037600 +0900
@@ -88,6 +88,8 @@
  * or multi-threaded operation.
  */
 
+/* avoid mismatch message C++ ABI number*/
+#define __GXX_ABI_VERSION 1016
 
 /* define DEBUG here to have debugging messages in stderr */
 /* #define DEBUG */





Tatsuro

Re: Trouble with contours and binary arrays

[Dima K. <gn...@di...>]

Thank you very much Ethan. The contour label workaround is really
helpful. If you weren't concerned about breaking existing scripts, would
supporting generic 'using' expressions be a simple tweak, or would it
involve lots of code? It's really annoying that ascii arrays work the
way you'd expect, but binary ones don't. So maybe supporting both the
compatibility path and the "expected" path would still make sense.

Thanks

Re: Trouble with contours and binary arrays

[Ethan A M. <me...@uw...>]

On Monday, 16 May 2022 15:39:25 PDT Dima Kogan wrote:
> Hi. I'm having trouble with contoured plots, and I'm guessing there's at
> least one gnuplot bug here. Can I please get some pointers?
> 
[snip]
> 
> But if I add the transform, it is ignored by the contours. THIS doesn't work:
> 
>   set view map
>   set contour base
>   splot "sincos.float32" binary array=(90,100) format="%float" using ($1+100) with lines nosurface

I was focused on explaining why normal using specifiers don't work for
binary array data.

What I didn't think to point out was that for the specific case of a
constant offset, as in your example, you don't need a using specifier:

  splot "sincos.float32" binary array=(90,100) format="%float" origin=(0,0,100) with lines 

	Ethan

Re: Trouble with contours and binary arrays

[Ethan A M. <me...@uw...>]

On Monday, 16 May 2022 15:39:25 PDT Dima Kogμan wrote:
> Hi. I'm having trouble with contoured plots, and I'm guessing there's at
> least one gnuplot bug here. Can I please get some pointers?
> 
> I make a binary data file. This is an regular matrix of 32-bit floats:
> 
>   perl -E 'for $i (0..99) { for $j (0..89) { $f=sin($i/30.)+cos($j/5.); print pack("f",$f); }}' > /tmp/sincos.float32
> 
> For convenience I'm attaching this data.
> 
> I can successfully plot a heatmap:
> 
>   splot "sincos.float32" binary array=(90,100) format="%float" with image


[snip]


> Second issue. I'd like to plot boxed contour labels. This works OK with
> ASCII matrix data, but with binary data it doesn't work. I run this
> gunplot script:
> 
>   set view map
>   set contour base
>   splot "sincos.float32" binary array=(90,100) format="%float" with labels boxed nosurface
> 
> And I see this:
> 
>   "cmd" line 3: warning: Couldn't slurp 72000 bytes (return was 36000)
> 
>   splot "sincos.float32" binary array=(90,100) format="%float" with labels boxed nosurface
>                                                                                           ^
>   "cmd" line 3: All points x value undefined
> 
> For whatever reason it's trying to read 8 bytes per point instead of 4.
> Some brief debugging tells me it thinks there're two values to read from
> each point, when in reality there's just one.
> 
> Thoughts?


This second issue is a simple bug.  The default number of input columns is taken as 2
(z value + label text) but for contour labels there is no separate second input column.
You can work around this by giving an explicit "using <foo>" in the splot command:

   splot "sincos.float32" binary array=(90,100) format="%float" using ("foo") with labels boxed nosurface

That gets you auto-generated labels that correspond to the input binary z values.
As before, however, those values are taken as-is.
You still cannot modify the z values via a using specifier.

	Ethan

Re: Trouble with contours and binary arrays

[Ethan A M. <me...@uw...>]

(apologies if you see this twice)

On Monday, 16 Mμay 2022 15:39:25 PDT Dima Kogan wrote:
> Hi. I'm having trouble with contoured plots, and I'm guessing there's at
> least one gnuplot bug here. Can I please get some pointers?
> 
> I make a binary data file. This is an regular matrix of 32-bit floats:
> 
>   perl -E 'for $i (0..99) { for $j (0..89) { $f=sin($i/30.)+cos($j/5.); print pack("f",$f); }}' > /tmp/sincos.float32
> 
> For convenience I'm attaching this data.
> 
> I can successfully plot a heatmap:
> 
>   splot "sincos.float32" binary array=(90,100) format="%float" with image
> 
> I can also transform the data and plot:
> 
>   splot "sincos.float32" binary array=(90,100) format="%float" using ($1+100) with image


Image data is treated as a special case, so keep that in mind as we continue through this.


> This all works. Without the transform, I can also plot contours:
> 
>   set view map
>   set contour base
>   splot "sincos.float32" binary array=(90,100) format="%float" with lines nosurface
> 
> But if I add the transform, it is ignored by the contours. THIS doesn't
> work:
> 
>   set view map
>   set contour base
>   splot "sincos.float32" binary array=(90,100) format="%float" using ($1+100) with lines nosurface
> 
> There's no error message. It just produces the untransformed data.


Let's simplify by  just plotting the surface rather than contouring.
We find that
*     splot "sincos.float32" binary array=(90,100) format="%float" with lines*
works as expected.


However
*     splot "sincos.float32" binary array=(90,100) format="%float" using ($1+100)*
seemingly ignores the using spec.  This is the same thing you ran into with contouring.


Why?  
The handling of binary array/matrix data is really weird.  
I hate it, but what happens is this:


1) The program uses the "binary array=(x,y)" clause to fill in the x and y coordinates


2) The program uses the plot type to fill in the z coordinate directly from the data
    provided by the format specifier "%float".


Now it gets weird


3) The program advances the count of data columns consumed by 2 ("plot") or 3 ("splot").


4) Only now does the program look at the using specifier.  But since it advanced the 
    column count in step (3), the column numbers in the using spec are now off by either
    2 or 3 depending on whether it's a "plot" or "splot" command.   
    This means that the operation ($1+100) is actually used to stuff data value 4
     rather than data value 1 (which is x) or z (which was stuffed in data value 3).


5) If there are additional using specs, they are used for data values 5, 6, ... and so on.


The upshot is that the using specifiers _can_ affect the plot, but not as x/y/z coordinates.
For instance you could do:


*    splot "sincos.float32" binary array=(90,100) format="%float" using ($1*$1) lc variable*


The x/y/z coordinates of the surface will be exactly the same as before.
However the variable color is taken from data value 4 so the using spec can now be seen
to have an actual effect.


Where does that leave us?
If we were designing the binary input code starting now, I would argue for
doing it very differently.  But redesign of the existing commands would completely
break backwards compatibility so I don't think that's an option.
Introducing a new binary input syntax in parallel while keeping the old 
one sounds just as unattractive.  So I am at a loss how to improve things.


The image handling code also plays fast and loose with the data columns,
although that is a separate code path.  It is not currently possible, for example,
to make a 3D histogram plot of the Green component of a color image.
Exactly analogous to your matrix contouring case, you cannot re-assign the
x/y/z coordinates based on image pixel values.


> Second issue. I'd like to plot boxed contour labels. 


I have not looked at this one yet.
It may or may not come down to the same thing.


    Ethan


> This works OK with
> ASCII matrix data, but with binary data it doesn't work. I run this
> gunplot script:
> 
>   set view map
>   set contour base
>   splot "sincos.float32" binary array=(90,100) format="%float" with labels boxed nosurface
> 
> And I see this:
> 
>   "cmd" line 3: warning: Couldn't slurp 72000 bytes (return was 36000)
> 
>   splot "sincos.float32" binary array=(90,100) format="%float" with labels boxed nosurface
>                                                                                           ^
>   "cmd" line 3: All points x value undefined
> 
> For whatever reason it's trying to read 8 bytes per point instead of 4.
> Some brief debugging tells me it thinks there're two values to read from
> each point, when in reality there's just one.
> 
> Thoughts?
> 
> Thanks!
> 
> 


-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
MS 357742,   University of Washington, Seattle 98195-7742

Re: Trouble with contours and binary arrays

[Ethan M. <eam...@gm...>]

On Monday, 16 Mμay 2022 15:39:25 PDT Dima Kogan wrote:
> Hi. I'm having trouble with contoured plots, and I'm guessing there's at
> least one gnuplot bug here. Can I please get some pointers?
> 
> I make a binary data file. This is an regular matrix of 32-bit floats:
> 
>   perl -E 'for $i (0..99) { for $j (0..89) { $f=sin($i/30.)+cos($j/5.); print pack("f",$f); }}' > /tmp/sincos.float32
> 
> For convenience I'm attaching this data.
> 
> I can successfully plot a heatmap:
> 
>   splot "sincos.float32" binary array=(90,100) format="%float" with image
> 
> I can also transform the data and plot:
> 
>   splot "sincos.float32" binary array=(90,100) format="%float" using ($1+100) with image

Image data is treated as a special case, so keep that in mind as we continue through this.

> This all works. Without the transform, I can also plot contours:
> 
>   set view map
>   set contour base
>   splot "sincos.float32" binary array=(90,100) format="%float" with lines nosurface
> 
> But if I add the transform, it is ignored by the contours. THIS doesn't
> work:
> 
>   set view map
>   set contour base
>   splot "sincos.float32" binary array=(90,100) format="%float" using ($1+100) with lines nosurface
> 
> There's no error message. It just produces the untransformed data.

Let's simplify by  just plotting the surface rather than contouring.
We find that
*     splot "sincos.float32" binary array=(90,100) format="%float" with lines*
works as expected.

However
*     splot "sincos.float32" binary array=(90,100) format="%float" using ($1+100)*
seemingly ignores the using spec.  This is the same thing you ran into with contouring.

Why?  
The handling of binary array/matrix data is really weird.  
I hate it, but what happens is this:

1) The program uses the "binary array=(x,y)" clause to fill in the x and y coordinates

2) The program uses the plot type to fill in the z coordinate directly from the data
    provided by the format specifier "%float".

Now it gets weird

3) The program advances the count of data columns consumed by 2 ("plot") or 3 ("splot").

4) Only now does the program look at the using specifier.  But since it advanced the 
    column count in step (3), the column numbers in the using spec are now off by either
    2 or 3 depending on whether it's a "plot" or "splot" command.   
    This means that the operation ($1+100) is actually used to stuff data value 4
     rather than data value 1 (which is x) or z (which was stuffed in data value 3).

5) If there are additional using specs, they are used for data values 5, 6, ... and so on.

The upshot is that the using specifiers _can_ affect the plot, but not as x/y/z coordinates.
For instance you could do:

*    splot "sincos.float32" binary array=(90,100) format="%float" using ($1*$1) lc variable*

The x/y/z coordinates of the surface will be exactly the same as before.
However the variable color is taken from data value 4 so the using spec can now be seen
to have an actual effect.

Where does that leave us?
If we were designing the binary input code starting now, I would argue for
doing it very differently.  But redesign of the existing commands would completely
break backwards compatibility so I don't think that's an option.
Introducing a new binary input syntax in parallel while keeping the old 
one sounds just as unattractive.  So I am at a loss how to improve things.

The image handling code also plays fast and loose with the data columns,
although that is a separate code path.  It is not currently possible, for example,
to make a 3D histogram plot of the Green component of a color image.
Exactly analogous to your matrix contouring case, you cannot re-assign the
x/y/z coordinates based on image pixel values.


> Second issue. I'd like to plot boxed contour labels. 

I have not looked at this one yet.
It may or may not come down to the same thing.

	Ethan

> This works OK with
> ASCII matrix data, but with binary data it doesn't work. I run this
> gunplot script:
> 
>   set view map
>   set contour base
>   splot "sincos.float32" binary array=(90,100) format="%float" with labels boxed nosurface
> 
> And I see this:
> 
>   "cmd" line 3: warning: Couldn't slurp 72000 bytes (return was 36000)
> 
>   splot "sincos.float32" binary array=(90,100) format="%float" with labels boxed nosurface
>                                                                                           ^
>   "cmd" line 3: All points x value undefined
> 
> For whatever reason it's trying to read 8 bytes per point instead of 4.
> Some brief debugging tells me it thinks there're two values to read from
> each point, when in reality there's just one.
> 
> Thoughts?
> 
> Thanks!
> 
> 

Trouble with contours and binary arrays

[Dima K. <gn...@di...>]

Hi. I'm having trouble with contoured plots, and I'm guessing there's at
least one gnuplot bug here. Can I please get some pointers?

I make a binary data file. This is an regular matrix of 32-bit floats:

  perl -E 'for $i (0..99) { for $j (0..89) { $f=sin($i/30.)+cos($j/5.); print pack("f",$f); }}' > /tmp/sincos.float32

For convenience I'm attaching this data.

I can successfully plot a heatmap:

  splot "sincos.float32" binary array=(90,100) format="%float" with image

I can also transform the data and plot:

  splot "sincos.float32" binary array=(90,100) format="%float" using ($1+100) with image

This all works. Without the transform, I can also plot contours:

  set view map
  set contour base
  splot "sincos.float32" binary array=(90,100) format="%float" with lines nosurface

But if I add the transform, it is ignored by the contours. THIS doesn't
work:

  set view map
  set contour base
  splot "sincos.float32" binary array=(90,100) format="%float" using ($1+100) with lines nosurface

There's no error message. It just produces the untransformed data.



Second issue. I'd like to plot boxed contour labels. This works OK with
ASCII matrix data, but with binary data it doesn't work. I run this
gunplot script:

  set view map
  set contour base
  splot "sincos.float32" binary array=(90,100) format="%float" with labels boxed nosurface

And I see this:

  "cmd" line 3: warning: Couldn't slurp 72000 bytes (return was 36000)

  splot "sincos.float32" binary array=(90,100) format="%float" with labels boxed nosurface
                                                                                          ^
  "cmd" line 3: All points x value undefined

For whatever reason it's trying to read 8 bytes per point instead of 4.
Some brief debugging tells me it thinks there're two values to read from
each point, when in reality there's just one.

Thoughts?

Thanks!

Re: Weirdness in column specifications, column() vs dollar

[Juhász P. <pet...@gm...>]

On Thu, 2022-03-10 at 20:42 -0800, Ethan A Merritt wrote:
> On Friday, 4 March 2022 00:17:15 PST Ethan A Merritt wrote:
> 
> > I dislike the idea of going back to either the original behaviour
> > (always skip input line if a column is NaN or missing) or the
> > version 5.2
> > behaviour (see Bug #2042).  
> > 
> > You have now pointed out the very real bug that one cannot use 
> > valid(N) in an expression containing $N because the entire
> > expression
> > will be skipped.
> > So I dislike the way it is now, also.
> > 
> > Possible options:
> > 
> > - Revert commit b8304eaf.  That would re-introduce Bug #2042 but
> > would
> >   allow use of valid() to avoid it.
> > 
> > - Better documentation. Trying to explain all this is probably much
> > too
> >   difficult, but we could at least warn that if you use valid(N)
> > then
> >   you must also use column(N) rather than $N.
> > 
> > - At the cost of some hackery, I could add a check for the valid()
> > function
> >   itself immediately before the check for $N added by the commit
> > shown above.
> >   The logic would be "if we see the user is doing their own
> > validity checks,
> >   we will not use the known-imperfect check that looks for $
> > signs".
> >   I could cook up a patch for that if you want to test it.
> 
> Eventually I realized that the valid() function goes all the way back
> to gnuplot version 3.something, and it always had the property that
> it couldn't catch "missing" values because they were discarded at an
> earlier stage of the input.
> 
> I have come around to thinking that the only major issue here
> is the one that Peter originally pointed out: that $N and column(N)
> are documented as being identical but they were not.
> 
> So commit c8d468de adds the same initial check to column(N) that
> already exists for $N.  In both cases if column N contains a 
> missing value flag then the data point is skipped prior to
> evaluation of the expression in the "using" specifier.
> So you cannot in practice catch such points by using 
>     valid(N) ? $N : <foo>

I still think that this behavior is hostile to the user - at least it's
consistently hostile now, I guess.

Maybe I'm overreacting, and for most use cases this is the sensible and
expected behavior. What prompted me to send in the original report is
that in my application the missing column was used deep inside a
sprintf for  a hypertext label, only visible on mouseover, and for the
longest time I couldn't understand why such an inconsequential part of
the using spec was causing part of the input to be silently dropped.

Anyway, thanks for looking into this.

best regards,
Peter Juhasz

Re: Weirdness in column specifications, column() vs dollar

[Ethan A M. <me...@uw...>]

On Friday, 4 March 2022 00:17:15 PST Ethan A Merritt wrote:

> I dislike the idea of going back to either the original behaviour
> (always skip input line if a column is NaN or missing) or the version 5.2
> behaviour (see Bug #2042).  
> 
> You have now pointed out the very real bug that one cannot use 
> valid(N) in an expression containing $N because the entire expression
> will be skipped.
> So I dislike the way it is now, also.
> 
> Possible options:
> 
> - Revert commit b8304eaf.  That would re-introduce Bug #2042 but would
>   allow use of valid() to avoid it.
> 
> - Better documentation. Trying to explain all this is probably much too
>   difficult, but we could at least warn that if you use valid(N) then
>   you must also use column(N) rather than $N.
> 
> - At the cost of some hackery, I could add a check for the valid() function
>   itself immediately before the check for $N added by the commit shown above.
>   The logic would be "if we see the user is doing their own validity checks,
>   we will not use the known-imperfect check that looks for $ signs".
>   I could cook up a patch for that if you want to test it.

Eventually I realized that the valid() function goes all the way back
to gnuplot version 3.something, and it always had the property that
it couldn't catch "missing" values because they were discarded at an
earlier stage of the input.

I have come around to thinking that the only major issue here
is the one that Peter originally pointed out: that $N and column(N)
are documented as being identical but they were not.

So commit c8d468de adds the same initial check to column(N) that
already exists for $N.  In both cases if column N contains a 
missing value flag then the data point is skipped prior to
evaluation of the expression in the "using" specifier.
So you cannot in practice catch such points by using 
    valid(N) ? $N : <foo>

There is a secondary issue as pointed out earlier in this thread
that if the "missing" column is referenced only indirectly then
the pre-evaluation check doesn't catch it.  I.e.
    N = 2
    filter(i) = (valid(i) ? column(i) : 0)
    plot FOO using 1:(filter(N))

This is way too complex for the parser to recognize that column 2
is special prior to evaluation (filter(N)), so in this case the
valid(i) test would do something.  But given that it would not do
anything on the less convoluted cases it would probably be a bad
idea to use it in a script.   Better to disable any "missing"
flag and then use "set datafile missing NaN" instead.

The same commit c8d468de replaces the internal handling of this
case to make it (I hope) more robust.

	Ethan

 









> 
> - Your notion of setting a default value for missing data is interesting.
>   I don't know quite where that would go.  A uniform default could be
>   done by something like
> 	set datafile missing "?" default FOO
>   But that is probably too global to be useful. You might want different
>   defaults for different columns and for different intput files.
> 
> 	still thinking
> 
> 		Ethan
> 
> On Thursday, 3 March 2022 14:41:50 PST Juhász Péter wrote:
> > On Wed, 2022-03-02 at 14:36 -0800, Ethan A Merritt wrote:
> > > On Wednesday, 2 March 2022 06:37:26 PST Peter Juhasz wrote:
> > > > On Wed, Mar 2, 2022 at 5:22 AM Ethan A Merritt <me...@uw...>
> > > > wrote:
> > > > 
> > > > > > Observations:
> > > > > > - it's as if the mere presence of a $X in the specification
> > > > > > causes the
> > > > > > datum to be marked as invalid, and dropped entirely, if column
> > > > > > X
> > > > > > doesn't contain data, no matter what the rest of the
> > > > > > specification is.
> > > 
> > > This is intentional.
> > > 
> > [... detailed explanation snipped ...]
> > 
> > This all sounds eminently horrible. I admit I never had to think into
> > the various edge cases like `column($2)` and so on, but even
> > acknowledging these, it seems to me that peeking ahead in the
> > expression and just throwing away the datum if a column happens to be
> > empty/invalid is an overly zealous, and in the end, suboptimal,
> > approach, because it throws away that datum even if the invalid value
> > ends up not influencing the result.
> > 
> > If I understand you correctly, my use case (plotting a dataset with a
> > potentially null column with a default value, so that a point is
> > plotted for every row) is supposed to be impossible, and the method
> > I've eventually stumbled on (`valid(N) ? column(N) : 0`) only works
> > because of an implementation detail (that peeking ahead for `column()`
> > was deemed too hard).
> > 
> > And even accepting all this, the fact remains that there is an
> > undocumented discrepancy in the user interface (`column(N)` vs `$N`
> > behaves differently, even though the documentation states that the
> > latter is just a shortcut to the former), and that all of this is not
> > easily discoverable and confusing to the user.
> > 
> > > 
> > > Any suggestions for improvement are welcome.
> > 
> > To try to be constructive:
> > 
> > - the state of affairs should be documented somewhere (though I'm not
> > sure under which keyword does it belong)
> > 
> > - perhaps there could be a separate, explicit function for plotting a
> > column with a default value. My subconcious is trying to suggest a
> > defined-or operator like perl's `//`, but I realise that that would not
> > help much with the problems that already exist on the level of
> > expression parsing. But perhaps a two-argument alternative to
> > `column(X)` could be added, one that allows a default value to be
> > specified, e.g. `defaultcolumn(1, 3.14)`, or just make `column` accept
> > an optional second argument, like `timecolumn` does.
> > 
> > I'm not sure how much value this second proposal would add, though,
> > since the `valid ? column : default` syntax does work, but perhaps a
> > separate explicit function would be useful if `column` was ever "fixed"
> > to behave like the dollar operator.
> > 
> > 
> > > 
> > >    cheers,
> > >            Ethan
> > > 
> > > 
> > 
> > best regards,
> > Peter Juhasz
> > 
> > 
> > 
> 
> 
> 


-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
MS 357742,   University of Washington, Seattle 98195-7742