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

Re: Library version of gnuplot [was: gnuplot projects, terminal modules]

[Jonathan T. <jt...@ae...>]

On Fri, 9 Mar 2007, Timothée Lecomte wrote:
> Currently, it's tricky to include a gnuplot graph in a data acquisition
> program (I mean in the same window, of course), it's unnatural to use
> gnuplot from another language than gnuplot native one (think python,
> ruby),

I do this latter thing quite often from Perl, with (I think) no particular
difficulty:  My Perl program generates/manipulates some data files,
generates a gnuplot script which references those data files, then
invokes gnuplot on that script.  Admittedly, these aren't _interactive_
plots (they're typically 'set term postscript' followed by invoking
ps2pdf) -- I've never tried invoking an interactive gnuplot terminal
from a program.

I could certainly _imagine_ a direct gnuplot-api, sort of like there's
a Perl/Tk binding to the Tk widget set (the "Tk" in "Tk/TCL"), and I
have no objection if people want to build such a thing.


> it's very difficult to build a useful general-purpose GUI on
> top of gnuplot (think xgfe)

I've long wanted to build (probably using Perl/Tk) a "movie gnuplot":
a GUI to make it easier to generate sequences of gnuplot commands which
iterate through the frames of a movie.  Right now I use a custom-written
Perl program to generate the gnuplot script for each movie, which is
++clumsy.

ciao,

-- 
-- "Jonathan Thornburg -- remove -animal to reply" <jt...@ae...>
   School of Mathematics, U of Southampton, England
   "Washing one's hands of the conflict between the powerful and the
    powerless means to side with the powerful, not to be neutral."
                                      -- quote by Freire / poster by Oxfam

Cairo-PNG

[Peter D. <pc...@wi...>]

     The  wxt  terminal  looks  great,  by the way; Timothée
Lecomte mentioned, however, back in 2005* that:

     [The  wxt  terminal]  could also be reused to give
     ps/psf/png/... outputs easily.

Is anyone working on antialiased PNG output via Cairo/Pango?

Best, Peter

───────────
  * http://lists.freedesktop.org/archives/cairo/2005-November/005647.html

Re: gnuplot and DISPLAY

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

Daniel J Sebald wrote:

> Allin, please try the following patch and rebuild gnuplot to see if this 
> fixes matters.

I put the patch (and variation of it) on SourceForge.  I'm fairly certain it's the solution.  The routine X11_update_opts() checks for valid X11_ipc.  X11_send_endianess() should be doing the same.

Thanks Allin,

Dan

Re: gnuplot and DISPLAY

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

Daniel J Sebald wrote:
> Ethan A Merritt wrote:
> 
>>On Thursday 08 March 2007 21:59, Daniel J Sebald wrote:
>>
>>
>>>Oh yeah, I see now.  That isn't the same error message as 
>>>when gnuplot can't find gnuplot_x11.  gnuplot_x11 is the one having 
>>>problems opening the X display.  Is there some way for Allin to 
>>>confirm that the version of gnuplot_x11 for 4.2 was installed properly 
>>>and it is not the 4.0 version of gnuplot_x11?    
>>
>>
>>Doesn't matter.  No matter how badly gnuplot_x11 dies, it shouldn't
>>do more than generate an error message on the gnuplot end.
>>Apparently that's not the case, but I haven't yet understood the
>>failure path.
> 
> 
> Yeah, that's right.  Well, there are a number of conditional compiles in X11_init() that would explain that behavior.  There appears to be only one "graceful" exit out of gnuplot from that point:
> 
> 
> 	if (fork() == 0) {
> 	    /* child */
> [snip]
> 	    fprintf(stderr,"Expected X11 driver: %s\n",X11_full_command_path);
> 	    perror("Exec failed");
> 	    fprintf(stderr,"See 'help x11' for more details\n");
> 	    exit(EXIT_FAILURE);
> 	}
> 
> But that set group of error messages isn't appearing in Allin's strace.
> 
> Might it be that fork() is coming back nozero and gnuplot attempts sending through the pipe and the OS doesn't like that so kills the process?

Yes, I think it is something along that line.  The only difference between 4.0 and 4.2 is the addition of the following at the end of X11_init():

#if defined(WITH_IMAGE) || defined(BINARY_X11_POLYGON)
    X11_send_endianess();
#endif

which sends a few characters through the pipe.  This code probably shouldn't be run unless there is a valid pipe.

Probably on your system Ethan and mine this is handled more gracefully.

Allin, please try the following patch and rebuild gnuplot to see if this fixes matters.

Dan

Re: gnuplot and DISPLAY

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

Daniel J Sebald wrote:

> Yeah, that's right.  Well, there are a number of conditional compiles
> in X11_init() that would explain that behavior.

I meant to say *none* of the conditional compiles would explain the strace sequence Allin reports.

Dan

Re: gnuplot and DISPLAY

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

Ethan A Merritt wrote:
> On Thursday 08 March 2007 21:59, Daniel J Sebald wrote:
> 
>>Oh yeah, I see now.  That isn't the same error message as 
>>when gnuplot can't find gnuplot_x11.  gnuplot_x11 is the one having 
>>problems opening the X display.  Is there some way for Allin to 
>>confirm that the version of gnuplot_x11 for 4.2 was installed properly 
>>and it is not the 4.0 version of gnuplot_x11?    
> 
> 
> Doesn't matter.  No matter how badly gnuplot_x11 dies, it shouldn't
> do more than generate an error message on the gnuplot end.
> Apparently that's not the case, but I haven't yet understood the
> failure path.

Yeah, that's right.  Well, there are a number of conditional compiles in X11_init() that would explain that behavior.  There appears to be only one "graceful" exit out of gnuplot from that point:


	if (fork() == 0) {
	    /* child */
[snip]
	    fprintf(stderr,"Expected X11 driver: %s\n",X11_full_command_path);
	    perror("Exec failed");
	    fprintf(stderr,"See 'help x11' for more details\n");
	    exit(EXIT_FAILURE);
	}

But that set group of error messages isn't appearing in Allin's strace.

Might it be that fork() is coming back nozero and gnuplot attempts sending through the pipe and the OS doesn't like that so kills the process?

Dan

Re: gnuplot and DISPLAY

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

On Thursday 08 March 2007 21:59, Daniel J Sebald wrote:
> 
> Oh yeah, I see now.  That isn't the same error message as 
> when gnuplot can't find gnuplot_x11.  gnuplot_x11 is the one having 
> problems opening the X display.  Is there some way for Allin to 
> confirm that the version of gnuplot_x11 for 4.2 was installed properly 
> and it is not the 4.0 version of gnuplot_x11?    

Doesn't matter.  No matter how badly gnuplot_x11 dies, it shouldn't
do more than generate an error message on the gnuplot end.
Apparently that's not the case, but I haven't yet understood the
failure path.

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

Re: gnuplot and DISPLAY

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

Ethan A Merritt wrote:

> The thing is, I still don't quite understand why Allin is
> seeing this problem.  The original bug report was due
> to incomplete installation;  gnuplot was built to default to
> X11, but the X11 driver (gnuplot_x11) had not actually been
> installed.  The problem arose because gnulot tried to open a
> pipe to gnuplot_x11, but gnuplot_x11 wasn't there. This
> is a different case entirely.

Oh yeah, I see now.  That isn't the same error message as when gnuplot can't find gnuplot_x11.  gnuplot_x11 is the one having problems opening the X display.  Is there some way for Allin to confirm that the version of gnuplot_x11 for 4.2 was installed properly and it is not the 4.0 version of gnuplot_x11?

Dan

Re: gnuplot and DISPLAY

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

On Thursday 08 March 2007 19:35, Allin Cottrell wrote:
> >  bash-3.1$ echo "show term" | GNUTERM=dumb gnuplot_4.2
> >
> >     terminal type is dumb feed  79 24
> 
> Yes, that works fine, only you have to parse the response; the 
> exit status seems to be OK regardless of the GNUTERM setting.

Were you expecting an error exit status?  Why?

I would not have expected an error exit from your original
test run on gnuplot version 4.0 either.
Failing to find a terminal is not a fatal error.
It just returns you to the gnuplot command prompt.
So when would you ever see an error exit?


-- 
Ethan A Merritt

Re: gnuplot and DISPLAY

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

On Thursday 08 March 2007 19:51, Daniel J Sebald wrote:
> Ethan A Merritt wrote:
> > On Thursday 08 March 2007 19:32, Daniel J Sebald wrote:
> > 
> >>Recall there was a bit of a discussion about the x11 terminal 
> >>looking for the location of gnuplot_x11 at start up, i.e., 
> >>part of x11's initialization but since x11 is the default terminal
> > 
> > Yes, but this patch was supposed to fix it:
> > 
> > 2006-11-05 
> 
> That rings a bell...  That was only a few months ago?

Right. It wasn't found/reported/whatever until Nov 06 in the
main cvs branch.  We had already frozen the code for 4.2
at that point.  I don't specifically recall making a decision,
but I guess my feeling was that something that went unnoticed
or at least un-complained-about during 3 years of development
was not a release-critical bug.  Especially since there are
obvious work-arounds if needed.  

Plus, it's the sort of "fix" that could easily break as many
corner cases as it fixes. Even now that the fix has been in 
CVS for 3 months, I wouldn't bet a large amount that it hasn't
broken some corner case that nobody has noticed/reported yet.

The thing is, I still don't quite understand why Allin is
seeing this problem.  The original bug report was due
to incomplete installation;  gnuplot was built to default to
X11, but the X11 driver (gnuplot_x11) had not actually been
installed.  The problem arose because gnulot tried to open a
pipe to gnuplot_x11, but gnuplot_x11 wasn't there. This
is a different case entirely.

Allin:  I don't understand why you see this failure mode.
The strace output you posted showed that it *did* find gnuplot_x11,
but gnuplot_x11 couldn't open DISPLAY.
That's annoyng, but it shouldn't be a fatal error for gnuplot
proper. If I test it deliberately, I get this:

bash-3.1$ DISPLAY=junk:0
bash-3.1$ gnuplot_4.2

        G N U P L O T
        Version 4.2 patchlevel 0
        last modified March 2007
        System: Linux 2.6.12-24mdksmp

        Copyright (C) 1986 - 1993, 1998, 2004, 2007
        Thomas Williams, Colin Kelley and many others

        Type `help` to access the on-line reference manual.
        The gnuplot FAQ is available from
                http://www.gnuplot.info/faq/

        Send comments and help requests to  <gnu...@li...>
        Send bug reports and suggestions to <gnu...@li...>


Terminal type set to 'wxt'
gnuplot> set term x11
Terminal type set to 'x11'
Options are '0'
gnuplot> _X11TransSocketINETConnect() can't get address for junk:6000: Name or service not known

gnuplot: unable to open display 'junk:0'
gnuplot: X11 aborted.

gnuplot> set term png
Terminal type set to 'png'
Options are 'nocrop font verdana 12 '
     

So yes, a bad DISPLAY setting causes gnuplot_x11 to exit.
But the gnuplot session proper is still active and responsive.
So I still can't reproduce Allin's exact problem. 

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

Re: gnuplot and DISPLAY

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

On Thu, 8 Mar 2007, Daniel J Sebald wrote:

> I'll make a guess, based upon this comment:
>
>> Yes.  It would be sufficient to pass in  GNUTERM=png
>> (or GNUTERM=<anything but x11> for that matter).
>
> Recall there was a bit of a discussion about the x11 terminal 
> looking for the location of gnuplot_x11 at start up, i.e., part 
> of x11's initialization but since x11 is the default terminal, 
> ostensibly at start up.  If the x11 terminal cannot find 
> gnuplot_x11, gnuplot exits.

That sounds right.  This works fine, I now see:

waverley:~$ echo "set term png" | \
   GNUTERM=dumb gnuplot && echo "OK"
OK

But here's the partial "strace" outpuy from my original command:

getuid32()                              = 501
setuid32(501)                           = 0
brk(0)                                  = 0x8150000
brk(0x8171000)                          = 0x8171000
pipe([3, 4])                            = 0
pipe([5, 6])                            = 0
clone(
gnuplot: unable to open display ''
gnuplot: X11 aborted.
child_stack=0, 
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidp
tr=0xb79b3908) = 560
--- SIGCHLD (Child exited) @ 0 (0) ---
close(4)                                = 0
close(5)                                = 0
fcntl64(6, F_GETFL)                     = 0x1 (flags O_WRONLY)
fstat64(6, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0
xb7f97000
_llseek(6, 0, 0xbf944474, SEEK_CUR)     = -1 ESPIPE (Illegal seek)
write(6, "BSR\n", 4)                    = -1 EPIPE (Broken pipe)
--- SIGPIPE (Broken pipe) @ 0 (0) ---
+++ killed by SIGPIPE +++

Allin Cottrell

Re: gnuplot and DISPLAY

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

Ethan A Merritt wrote:
> On Thursday 08 March 2007 19:32, Daniel J Sebald wrote:
> 
>>Recall there was a bit of a discussion about the x11 terminal 
>>looking for the location of gnuplot_x11 at start up, i.e., 
>>part of x11's initialization but since x11 is the default terminal
> 
> 
> Yes, but this patch was supposed to fix it:
> 
> 2006-11-05 

That rings a bell...  That was only a few months ago?

Dan

Re: gnuplot and DISPLAY

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

On Thu, 8 Mar 2007, Ethan A Merritt wrote:

> On Thursday 08 March 2007 18:27, Allin Cottrell wrote:
>>
>> echo "set term png" | `which gnuplot` 2>/dev/null && \
>> gnuplot_png=yes
>>
>> This has worked with versions of gnuplot up to 4.0.  I have just
>> updated to version 4.2.0 and it now fails, if the command is not
>> run with the X11 display set.
>
> I can't reproduce this.
>
>  bash-3.1$ unset DISPLAY
>  bash-3.1$ echo "set term png" | gnuplot_4.2 2>/dev/null && png42=yes
>  bash-3.1$ echo $png42
>  yes

Hmm, I'll try running that on the target machine the next time I'm 
there.  Remotely, via ssh, I'm still getting what I described. 
Here's a little more detail (plain "gnuplot" is version 4.2.0):

waverley:~$ echo "set term png" | \
     /usr/local/bin/gnuplot-4.0 && echo "OK"
OK
waverley:~$ echo "set term png" | \
    /usr/local/bin/gnuplot && echo "OK"

gnuplot: unable to open display ''
gnuplot: X11 aborted.

> Let's try to pin down exactly what causes the failure.

Yes, I'd like to do that, will try some more testing.

>> Can anyone suggest a workaround for this?  Thanks.
>
> Yes.  It would be sufficient to pass in  GNUTERM=png
> (or GNUTERM=<anything but x11> for that matter).
>
>  bash-3.1$ echo "show term" | GNUTERM=dumb gnuplot_4.2
>
>     terminal type is dumb feed  79 24

Yes, that works fine, only you have to parse the response; the 
exit status seems to be OK regardless of the GNUTERM setting.

Allin Cottrell

Re: gnuplot and DISPLAY

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

On Thursday 08 March 2007 19:32, Daniel J Sebald wrote:
> 
> Recall there was a bit of a discussion about the x11 terminal 
> looking for the location of gnuplot_x11 at start up, i.e., 
> part of x11's initialization but since x11 is the default terminal

Yes, but this patch was supposed to fix it:

2006-11-05 
        * src/term.c (init_term): Normally we initialize the default terminal
        immediately on program entry. However, if the default is x11 then defer
        initialization until an actual plot command.  This mitigates problems
        if gnuplot_x11 cannot be started normally, and allows the user to select
        a different driver in the case that x11 is the default but is broken.
        Bug #1530601

Looks like the patch didn't actually get applied to the 4.2 branch.
Oops.


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

Re: gnuplot and DISPLAY

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

Ethan A Merritt wrote:
> On Thursday 08 March 2007 18:27, Allin Cottrell wrote:
> 
>>echo "set term png" | `which gnuplot` 2>/dev/null && \
>>gnuplot_png=yes
>>
>>This has worked with versions of gnuplot up to 4.0.  I have just 
>>updated to version 4.2.0 and it now fails, if the command is not 
>>run with the X11 display set.
> 
> 
> I can't reproduce this.
> 
>   bash-3.1$ unset DISPLAY
>   bash-3.1$ echo "set term png" | gnuplot_4.2 2>/dev/null && png42=yes
>   bash-3.1$ echo $png42
>   yes
> 
> 
>>With previous gnuplot versions it was not necessary that the 
>>DISPLAY variable be set to something valid for X11.
> 
> 
> Let's try to pin down exactly what causes the failure.


I'll make a guess, based upon this comment:
 
> Yes.  It would be sufficient to pass in  GNUTERM=png
> (or GNUTERM=<anything but x11> for that matter).

Recall there was a bit of a discussion about the x11 terminal looking for the location of gnuplot_x11 at start up, i.e., part of x11's initialization but since x11 is the default terminal, ostensibly at start up.  If the x11 terminal cannot find gnuplot_x11, gnuplot exits.

Dan

Re: gnuplot and DISPLAY

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

On Thursday 08 March 2007 18:27, Allin Cottrell wrote:
> 
> echo "set term png" | `which gnuplot` 2>/dev/null && \
> gnuplot_png=yes
> 
> This has worked with versions of gnuplot up to 4.0.  I have just 
> updated to version 4.2.0 and it now fails, if the command is not 
> run with the X11 display set.

I can't reproduce this.

  bash-3.1$ unset DISPLAY
  bash-3.1$ echo "set term png" | gnuplot_4.2 2>/dev/null && png42=yes
  bash-3.1$ echo $png42
  yes

> With previous gnuplot versions it was not necessary that the 
> DISPLAY variable be set to something valid for X11.

Let's try to pin down exactly what causes the failure.
 
> Can anyone suggest a workaround for this?  Thanks.

Yes.  It would be sufficient to pass in  GNUTERM=png
(or GNUTERM=<anything but x11> for that matter).

  bash-3.1$ echo "show term" | GNUTERM=dumb gnuplot_4.2

     terminal type is dumb feed  79 24


-- 
Ethan A Merritt

Re: Blue Sky project OLPC [ was Re: gnuplot projects, terminal modules]

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

On Thursday 08 March 2007 18:29, Daniel J Sebald wrote:
> Ethan A Merritt wrote:
> > Several people here have expressed interest in a gnuplot GUI.
> > My first reaction was "who would want one?", but the coincidental
> > arrival of the OLPC invitation may have answered the question.
> > 
> > So here's the challenge:
> >   - design a GUI for gnuplot usable by school-age kids to explore
> >     math and functions.  Probably using GTK+
> 
> What school age?  3rd-6th?  

It's not entirely clear to me what age ranges the OLPC adopters will 
target.  It may vary from country to country.  I wouldn't rule out 
these things being used through high school.

> Are you thinking something where the student types a function 
> in a box and the plot appears?  

That, and buttons to plot data from files.  Think of a class project
to measure things and type the measurements into a file.   The kids
could then call up the gnuplot GUI, use a file browser to select the
data file, and use GUI buttons to play around with averaging, smoothing,
histogramming, etc.  Swap data files by wifi with your friends, plot
them in different colors, and so on.  Basically an all-in-one tool
useful for learning experimental science, maths, and statistics.

An even more integrated GUI could allow data entry from the
clipboard.  Then you could pull up a Wikipedia page with data of
some sort in a browser window,  select it with the mouse, and
tell gnuplot to plot it.

> Then they hit a button that will print out their plot on a printer?   

The OLPC laptops have no output other than screen and wifi.

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

gnuplot and DISPLAY

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

Hello,

I've been calling gnuplot from my program, gretl, to generate 
graphs, for quite some time now.  Since I require that gnuplot be 
able to generate PNG output, I have a configure check in my 
program for this, namely

echo "set term png" | `which gnuplot` 2>/dev/null && \
gnuplot_png=yes

This has worked with versions of gnuplot up to 4.0.  I have just 
updated to version 4.2.0 and it now fails, if the command is not 
run with the X11 display set.  With a non-X11 enabled ssh 
connection, I get:

waverley:~$ echo "set term png" | /usr/local/bin/gnuplot
   gnuplot: unable to open display ''
   gnuplot: X11 aborted.

With previous gnuplot versions it was not necessary that the 
DISPLAY variable be set to something valid for X11.

Can anyone suggest a workaround for this?  Thanks.

-- 
Allin Cottrell
Department of Economics
Wake Forest University, NC

Re: Blue Sky project OLPC [ was Re: gnuplot projects, terminal modules]

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

Ethan A Merritt wrote:
> The OLPC project (One Laptop Per Child) is inviting contributed
> software suitable for educational use on the OLPC platform.
> 	http://wiki.laptop.org/Software
> 
> I note with interest that the prefered software API is via the
> Pango/Cairo/GTK+ library layer.
> 
> Several people here have expressed interest in a gnuplot GUI.
> My first reaction was "who would want one?", but the coincidental
> arrival of the OLPC invitation may have answered the question.
> 
> So here's the challenge:
>   - design a GUI for gnuplot usable by school-age kids to explore
>     math and functions.  Probably using GTK+
>   - provide a single terminal driver based on Pango/Cairo 
>   - make the existing gnuplot components modular enough that
>     we can select a set of configuration options suitable for
>     the OLPC platform (366 MHz Geode, 128 MB, custom display)

What school age?  3rd-6th?  Are you thinking something where the student types a function in a box and the plot appears?  Then they hit a button that will print out their plot on a printer?

Dan

Blue Sky project OLPC [ was Re: gnuplot projects, terminal modules]

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

The OLPC project (One Laptop Per Child) is inviting contributed
software suitable for educational use on the OLPC platform.
	http://wiki.laptop.org/Software

I note with interest that the prefered software API is via the
Pango/Cairo/GTK+ library layer.

Several people here have expressed interest in a gnuplot GUI.
My first reaction was "who would want one?", but the coincidental
arrival of the OLPC invitation may have answered the question.

So here's the challenge:
  - design a GUI for gnuplot usable by school-age kids to explore
    math and functions.  Probably using GTK+
  - provide a single terminal driver based on Pango/Cairo 
  - make the existing gnuplot components modular enough that
    we can select a set of configuration options suitable for
    the OLPC platform (366 MHz Geode, 128 MB, custom display)

Even if this never ends up as a standard OLPC app, I think the
constraints make an interesting project.  In particular I think
that GUI design can only work if you have a clear target user
group, and elementary maths education would be a good target to
aim for.    

(certainly a GUI is of no use for the stuff I use gnuplot for :-)
  

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

Re: gnuplot projects, terminal modules

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

Ethan Merritt wrote:
> On Thursday 08 March 2007 04:53, Timothée Lecomte wrote:
> 
>>Dear gnuplot enthusiasts,
>>
>>Since 4.2 is out, I would like to start discussing some things I have in
>>mind for 4.3/4.4.
> 
> 
> My list (in no particular order):
> 
> 1) Continued work on internationalization
> 	- better use and documentation of LOCALE settings
> 	- support UTF-8 in as many terminal types as possible
> 	- better mechanism for integrating and maintaining localized documentation
> 
> 2) Transparency
> 	- mostly done, but needs to be implemented in win, aqua, [others?]
> 
> 3) Mousing support for SVG
> 
> 4) Mousing support for multiplot mode
> 
> 5) generate and plot 3D isosurface from 4D data
>    color-mapping a 5th value onto that surface gets us up to 5D data
> 	- splot "4D-data" using 1:2:3:4 with isosurface at <value>
> 	- splot "5D-data" using 1:2:3:4:5 with isosurface at <value>
> 
> Other projects that I'd like to see done, but I'm not the best person to
> evaluate or coordinate it:
> 
> 1) Updates to the "fit" subsystem
> 	-  1294507    Fitting using CERN Minuit routines
> 	-  1445064    Gnuplot fitting improvements
> 
> 2) Fix up the "history" command (Dan Sebald was working on this)

[ gnuplot-Bugs-1534367 ] too much expansion in FindHelp
[ gnuplot-Bugs-1525665 ] help has problems with

I believe this one is ready to go.  I recall some problems I had with a robust minor adjustment to the existing algorithm.  But then I think a did an overhaul of the general strategy for history and left it in a state I thought made sense and worked well.

Here are other items...


[ gnuplot-Patches-1566782 ] use tgamma for GAMMA() and lgamma for LNGAMMA()

I believe this works well.  Configuration goes with a library version of the routine tgamma/lgamma then falls back on gnuplot's version.  There is even use of gamma/lgamma if the global variable is valid.  I think I've cleared up the confusion with the use of that global variable and all systems are covered including MacOS (a user said it works).  Some argued there is a bug in implementations of this, but I still am not convinced the standard calls out for use of the global variable.  I think it works.


[ gnuplot-Patches-1589067 ] Alpha Channel images

People want this.  Doesn't seem difficult.  Just need time to work on it.  Ethan has it pretty much figured out and put together a patch.


term->clip_region (or whatever)

Ethan suggested a clip region for the terminal.  Lines/images/polygons/etc would then be clipped to this region.  That would move an extraneous set of coordinates from the term->image function.


[ gnuplot-Patches-1636431 ] Allow hidden3d with pm3d and rename to 'tileline' option

This patch was simply a means of improving the sorting depth approach to hidden surface elements which is only an estimate.  I don't think this patch itself will yield too much.  However, I think there is a TODO item here and that is to utilize the hidden mesh code in combination with the pm3d elements.  I think this might fit together better and more easily than people realize.  There would be a couple things:

1) Clean up the current hidden 3D code.  I see little vestigial bits of lines and corners in some of the hidden 3D examples.

2) After that, then come up with a robust hidden surface routine (in the above patch are some short 3D matrix inverse and hyperplane routines that could be useful), and then overlay the hidden 3D mesh.


[ gnuplot-Bugs-1488168 ] z_floor and z_ceiling based on xyplane.absolute

This is an outright bug fix.  It should have gone in 4.2 had there been a little time to review it.  The only thing required is a reviewer to say "Hey, I don't like that nonlinear mouse movement behavior, I'd rather it be linear", or "Nonlinear is better than linear."


[ gnuplot-Patches-1523316 ] improved CLIPBOARD and PRIMARY per X conventions

This one I think is a big winner.  There's a bit of code there, but it is a full implementation of mouse/clipboard behavior consistent with the vast majority of X applications.


[ gnuplot-Bugs-1004754 ] Tics and grid slightly outside border

This was a case where a double tic would appear at the end of an axis because of rounding effects.  I believe the approach I used works well, but people didn't seem to buy it.  It's rather simple really: "integerize" the tics rather than looping until the tic value falls out of range.  That is, because of the integer nature we can tell when we are at the end of the range, i.e., the last possible tic.  Then if at the last tic we test

  last_tic < end_range

rather than the current approach (i.e., effect of looping)

  first_tic + delta_tic + delta_tic + ... + delta_tic < end_range

The second approach is susceptible to rounding, the first isn't.  I.e., the existing problem is that last_tic is greater than end_range (and the tic shouldn't be printed), but first_tic + delta_tic + ... + delta_tic is less than end_range (and the tic ends up being printed).


[ gnuplot-Patches-1508316 ] Allow multiple strings to signify "missing"

This code could be used.  (There is a demo which illustrates different behavior.)  I think mostly though this is about coming up with coherent method of handling these "data special exceptions" that was never formally considered, i.e., I think it used to be what you get is what you get.


[ gnuplot-Patches-1027032 ] Connect gnuplot_x11 to exterior application window

Works as far as I know.  X11 has an issue whereby two resources both controlling the mouse in a window will cause an error.


Allow multiple palettes on a multiplot X11 window

This is that problem where someone plotted a multiplot having two different palettes.  It works on all terminals except X11.  An X11 window only allows one palette.  I think the best way to deal with this is to have individual X11 windows for the subplots that lies on top of the base plot X window.  That way each window can have its own subplot and its own palette.


Review the image placement

We should review how image places the start of the bounding box and possibly make it consistent with any existing conventions.  It may be off by half a pixel.  Petr suggested possibly having an option so images can have the position in the center of the pixel or the lower left corner.  After addressing that, then go through each of the terminals and verify consistency, e.g., GIF, etc.


Unify plot layout for 2D and 3D

This was discussed with Mike Sutton on the list.  A bit of work.


Place all plot information in structures

Hans suggested this a long time ago so that multiplots and all plot may be redrawn freely.  (One utility I know of simply launches multiple versions of gnuplot to hold information unique to individual plots.)


Probably forgot some...

Dan

Re: Library version of gnuplot [was: gnuplot projects, terminal modules]

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

On Thursday 08 March 2007 16:18, Timoth=E9e Lecomte wrote:
> What I want is, for example, an app based on cairo, where I have a cairo
> context 'cr' where I could start plotting with something like:
>=20
> gnuplot_context * gnuplot_cairo_create_context(cr);
> gnuplot_set_borders(gnuplot_context,...);
> gnuplot_set_axis(gnuplot_context,...);
> gnuplot_plot(gnuplot_context, data);

You only think you want this :-)

It does not avoid having to learn gnuplot, because the only way to
understand what gnuplot_set_borders(gnuplot_context,...) actually does
is to understand the underlying gnuplot command "set borders ...".
So instead of simplifying things, it actually makes it more complex.
Now you have to understand both the gnuplot behaviour, and whatever
idiosyncracies or variants are introduced by the binding layer.
Then if you want to do the same thing tomorrow from python or
perl, you have to learn a whole new set of bindings with their
own idiosyncracies.

Perhaps it is also a matter of taste.  I find the code fragment
above harder to read than, say,

print GNUPLOT <<END
  set term wxt
  set borders 31
  set xrange [0:10]
  plot '-'
END

This way the only language-dependent bits are the statements that
wrap the piped sequence of commands.

=2D-=20
Ethan A Merritt

Re: Library version of gnuplot [was: gnuplot projects, terminal modules]

[<tim...@en...>]

> Timothée Lecomte wrote:
>>>On Thursday 08 March 2007 04:53, Timothée Lecomte wrote:
>>>
>>>
>>>>Another interesting comment was the lack of
>>>>a powerful and broadly available (i.e. for many languages) plotting
>>>>library. I think gnuplot could be modified to achieve this goals if its
>>>>parser was written as a layer above a real API. It looks like it is
>>>> what
>>>>can be found in the TODO file:
>>>
>>>In my long-ago days, pre-gnuplot, I did a *lot* of programming with
>>>graphics libraries, and to a lesser degree extending and maintaining
>>>the libraries themselves.  I cannot begin to tell you how much relief
>>>I felt at being able to ditch all that and instead use a scriptable
>>>tool like gnuplot.   So my extensive experience with both approaches
>>>leads me to believe that this desire for a library version is
>>> mis-placed.
>>>It *sounds* reasonable, but when you actually try to use it you find
>>>out that from a programming perspective it is a worse alternative than
>>>a scripted interface.
>>
>>
>> You're probably right, you have much more experience than me in that
>> domain.
>> However, what I tend to see is that a 'libgnuplot' written in C could
>> have
>> bindings to whatever scripting language, including the fashioned python,
>> ruby, and friends.
>
> Don't pipes work in all languages?

Pipes are very different from bindings in my opinion. You still have to
learn and use gnuplot syntax.


>
>>>The only possible advantage I see is the speed with which very large
>>>data sets could be rendered.  In the case of a library you don't have to
>>>pipe the data between two separate executables.  But if that were
>>>sufficiently important we could implement it anyhow, admittedly in an
>>>OS-specific manner, by shared memory regions.
>>>
>>>Furthermore, if you look at the most powerful visualization tools,
>>>e.g. AVS, S+, Mathematica, you will notice they went the other direction
>>>entirely.  These are not libraries of routines that you call from
>>>an application program.  They are self-contained frameworks within
>>>which you can embed your application.
>>
>>
>> Maybe because to develop a business model around a proprietary plotting
>> library. Companies tend to sell complete solutions instead.
>
> That's a good point, but if you think in terms of unix, the system is
> designed as a bunch of utilities that intermix in various ways to suite
> the user's own creative perspective on things.
>
>
>> Also note that Mathemetica, Matlab, etc. are more for repetitive
>> simulation/analysis tools.
>
> Same with gnuplot.

Right, I was pointing out the other ones, below:
>
>
>> What I had in mind was more the experimental
>> side, with live acquisition and analysis. That's what LabView,
>> LabWindows
>> and other GPIB-oriented solutions (for those who don't know, GPIB is a
>> standardized bus for scientific data acquisition) are written for. Those
>> are basically programmation languages with graphic libraries, including
>> plotting libraries. And they seem to quite popular.
>
> That can be done with gnuplot through a pipe, I think.

True, but that's not a real binding.

>
>
>>>So my personal evaluation of the proposal to make gnuplot a callable
>>>library is that it would be a lot of work for almost no gain.
>>
>>
>> Reusability. That would be the key word in such a project. For gnuplot
>> features to be useful to more people, they have to be accessible in more
>> ways that they are today.
>> Currently, it's tricky to include a gnuplot graph in a data acquisition
>> program (I mean in the same window, of course),
>
> There is a patch on SourceForge whereby the parent application need simply
> pass an X window ID to gnuplot and the plot will be drawn in any window.
> There is a nice demo in which all *.dem files are listed in a window, then
> one clicks on the demo and it is run.  There was a small hang up on moving
> it into CVS; it had to do with the parent application and gnuplot both
> wanting control of the mouse.


That's what I call tricky.

What I want is, for example, an app based on cairo, where I have a cairo
context 'cr' where I could start plotting with something like:

gnuplot_context * gnuplot_cairo_create_context(cr);
gnuplot_set_borders(gnuplot_context,...);
gnuplot_set_axis(gnuplot_context,...);
gnuplot_plot(gnuplot_context, data);

>
>> it's unnatural to use
>> gnuplot from another language than gnuplot native one (think python,
>> ruby), and it's very difficult to build a useful general-purpose GUI on
>> top of gnuplot (think xgfe).
>
> Even this I'm not so sure of.  It is a matter of writing a object oriented
> terminal driver.  There is one based upon tkcanvas, but that was limited
> by the features of tkcanvas.  I think it is more a problem of the
> difficulty of implementing a GUI in general.  I assume you are talking
> about something where one can drag titles and annotation around using the
> mouse because that is the only sort of thing not really implemented.
>
> Dan

I'm not thinking of moving things in the graph (though that's another
interesting point of view), I'm thinking of a frontend to set up the plots
as you want them. Something like Origin maybe.

Best regards,

Timothée

Re: gnuplot projects, terminal modules

[<tim...@en...>]

> On Thursday 08 March 2007 14:35, Timothée Lecomte wrote:
>> > 4) Mousing support for multiplot mode
>>
>> This one is probably more difficult than it seems.
>
> At least in x11 it should not be fairly easy. Gnuplot_x11 already
> stores plot bounds and axis scaling information, used to echo back
> the mouse coordinates based on the current cursor coordinates in
> the window.  To make mouse coordinates work for multiplot, one just
> needs a  pre-test on the cursor coordinates to see which scaling
> table should be used.  So I think echoing the appropriate mouse
> coordinates for various subplots on the screen would be easy.
> The difficult part would be to do something like zooming a subplot;
> as currently implemented, that would require going back to the
> original plot command and the original data, both of which are
> long gone.

I was indeed thinking of getting original data, as this was what I was
told before. I am thinking of overlapping multiplots too.

>
>
>> >> First, I'd like to see the terminal module architecture that I
>> proposed
>> >
>> > Is there any technical benefit to this work?
>> > I have the impression, perhaps incorrect, that it is being entirely
>> > driven by distaste for linking to libreadline.
>>
>> This has nothing to do with readline, it's for the _terminal_, like wxt
>> or
>> gd, to be built as external modules and to be loaded at run-time.
>
> Ah. Light dawns. I totally mis-understood.  Sorry.
> OK, I'll have a look at it.

No problem.


>> > Please remind me where we ended up in previous discussions.
>> > I thought this turned out to be something that cannot be done in the
>> > terminal driver at all, because at the time you want to issue the
>> command
>> > you may have a different terminal active.  I tried implementing it
>> x11,
>> > and what happened was the all the raise/lower events got queued up and
>> > executed in a batch the next time an x11 window pipe was the active
>> > input stream.  That's clearly no good.  I attempted to work around
>> > this with a patch to continue accepting input from the previous
>> > interactive terminal, but that didn't work very well either.
>>
>> You're mixing two opposite features:
>> 1- 'raise console (xterm, konsole, ...)' which is bound to the spacebar
>> in
>> any interactive terminal. This cannot be moved as a function in struct
>> termentry for the reason you just explained
>> 2- I'm talking about 'raise terminal (wxt, x11, ...)' which is the
>> 'raise'
>> or 'lower' command (see 'help raise'). It makes sense to have act on the
>> current active terminal, and to move the code to the terminal instead of
>> command.c
>
> No. I'm not talking about 'raise console' at all.  I don't care about
> that, and would never use it :-)
> I'm talking about the case where you have a dozen x11 windows on your
> screen
> with old plots in them, and you want to raise plot #5, but don't remember
> which window that is.  I gather from Petr's comments that this is typical
> in an Octave session.  How do you send a "raise" command to an existing
> x11 window when it's not the currently active terminal?  The current
> terminal may still be x11, but a different window.  Even worse if the
> current terminal is post or png or something like that.  I'm not saying
> it's impossible, but my simple-minding attempt to do it inside the x11
> driver didn't work.

Well, everything is already there, see 'help raise' (you can do 'raise 5'
to raise the 5th window).

Currently, if you do:

set term x11
plot x
set term wxt
plot x
raise # then both wxt and x11 windows are raised.

With my patch (whose first goal is to eradicate that ugly code from
command.c):


set term x11
plot x
set term wxt
plot x
raise # only wxt windows is raised.
set term x11
raise # only x11 windows is raised.

Simple, isn't it ;)

Timothée

>
> --
> Ethan A Merritt
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

Re: Library version of gnuplot [was: gnuplot projects, terminal modules]

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

Timothée Lecomte wrote:
>>On Thursday 08 March 2007 04:53, Timothée Lecomte wrote:
>>
>>
>>>Another interesting comment was the lack of
>>>a powerful and broadly available (i.e. for many languages) plotting
>>>library. I think gnuplot could be modified to achieve this goals if its
>>>parser was written as a layer above a real API. It looks like it is what
>>>can be found in the TODO file:
>>
>>In my long-ago days, pre-gnuplot, I did a *lot* of programming with
>>graphics libraries, and to a lesser degree extending and maintaining
>>the libraries themselves.  I cannot begin to tell you how much relief
>>I felt at being able to ditch all that and instead use a scriptable
>>tool like gnuplot.   So my extensive experience with both approaches
>>leads me to believe that this desire for a library version is mis-placed.
>>It *sounds* reasonable, but when you actually try to use it you find
>>out that from a programming perspective it is a worse alternative than
>>a scripted interface.
> 
> 
> You're probably right, you have much more experience than me in that domain.
> However, what I tend to see is that a 'libgnuplot' written in C could have
> bindings to whatever scripting language, including the fashioned python,
> ruby, and friends.

Don't pipes work in all languages?


>>The only possible advantage I see is the speed with which very large
>>data sets could be rendered.  In the case of a library you don't have to
>>pipe the data between two separate executables.  But if that were
>>sufficiently important we could implement it anyhow, admittedly in an
>>OS-specific manner, by shared memory regions.
>>
>>Furthermore, if you look at the most powerful visualization tools,
>>e.g. AVS, S+, Mathematica, you will notice they went the other direction
>>entirely.  These are not libraries of routines that you call from
>>an application program.  They are self-contained frameworks within
>>which you can embed your application.
> 
> 
> Maybe because to develop a business model around a proprietary plotting
> library. Companies tend to sell complete solutions instead.

That's a good point, but if you think in terms of unix, the system is designed as a bunch of utilities that intermix in various ways to suite the user's own creative perspective on things.


> Also note that Mathemetica, Matlab, etc. are more for repetitive
> simulation/analysis tools.

Same with gnuplot.


> What I had in mind was more the experimental
> side, with live acquisition and analysis. That's what LabView, LabWindows
> and other GPIB-oriented solutions (for those who don't know, GPIB is a
> standardized bus for scientific data acquisition) are written for. Those
> are basically programmation languages with graphic libraries, including
> plotting libraries. And they seem to quite popular.

That can be done with gnuplot through a pipe, I think.


>>So my personal evaluation of the proposal to make gnuplot a callable
>>library is that it would be a lot of work for almost no gain.
> 
> 
> Reusability. That would be the key word in such a project. For gnuplot
> features to be useful to more people, they have to be accessible in more
> ways that they are today.
> Currently, it's tricky to include a gnuplot graph in a data acquisition
> program (I mean in the same window, of course),

There is a patch on SourceForge whereby the parent application need simply pass an X window ID to gnuplot and the plot will be drawn in any window.  There is a nice demo in which all *.dem files are listed in a window, then one clicks on the demo and it is run.  There was a small hang up on moving it into CVS; it had to do with the parent application and gnuplot both wanting control of the mouse.

> it's unnatural to use
> gnuplot from another language than gnuplot native one (think python,
> ruby), and it's very difficult to build a useful general-purpose GUI on
> top of gnuplot (think xgfe).

Even this I'm not so sure of.  It is a matter of writing a object oriented terminal driver.  There is one based upon tkcanvas, but that was limited by the features of tkcanvas.  I think it is more a problem of the difficulty of implementing a GUI in general.  I assume you are talking about something where one can drag titles and annotation around using the mouse because that is the only sort of thing not really implemented.

Dan