gnuplot development

I too had once imagined a library, mostly on the suggestion from someone else.  But as time goes by the more I think gnuplot is fine the way it is as a script interpretter.  Ethan mentioned the data/speed thing, which is true for large data sets.

I mean, I'm not against the idea of a library, header files, etc. (have to figure out how header files will be organized and where to break up routines), but I think it would be wiser to add/fix features to the point of having a very mature, robust system.  The combination of the two (scriptable and compilable library) is just too much to deal with on a part time basis.

Dan


Ethan Merritt 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.
> 
> 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.
> 
> 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.
>    
> I would be much more interested in proposals to extend gnuplot in
> the other direction, allowing it to call user-provided application
> code.  One example of this kind of thinking is patchset #588805
> (the oldest patch still active on our tracker). 
> 
> 	Ethan
> 
> 
> 
> 
> 
> 
>>"longer term
>>
>>- break it into four layers:
>>  : low level graphics  (some of term.c)
>>  : plotting code, reading the setshow.h global variables
>>  : parsing code - read a string, and parse and execute it
>>  : front end, interact with terminal / gui"
>>
>>So, I think I'll try to work on this. I have a couple of milestones in
>>mind, starting from the rewrite of the term->options functions so that the
>>parser is not called from the terminals. Then maybe extract an API for the
>>set/show functions to separate them from the parsing code.
>>
>>Well, that's it. Don't forget to comment on the modular architecture, and
>>thanks for reading.
>>
>>Best regards,
>>
>>Timothée
> 
> 


-- 

Dan Sebald
phone: 608 256 7718
email: daniel DOT sebald AT ieee DOT org
URL: http://webpages DOT charter DOT net/dsebald/

On Thursday 08 March 2007 14:35, Timoth=E9e Lecomte wrote:
> > 4) Mousing support for multiplot mode
>=20
> 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.  =20

On the other hand, you may get zooming for free in svg, because the
viewer handles it. ... assuming that we get mousing to work in
svg at all.

But I really have not looked at the mousing code of the other
mousing terminals, so I can't say whether the x11 solution applies
to them as well.  =20


> >> 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.
>=20
> 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.


> >> What I implement in the plugin1.diff and plugin2.diff is the an
> >> in-between
> >> interactive structure:
> >> term->inter->waitforinput
> >> term->inter->put_tmptext
> >> term->inter->set_ruler
> >> term->inter->set_cursor
> >> term->inter->set_clipboard
> >>
> >> so that non-interactive terminals just have term->inter =3D 0, making =
it
> >> easier to extend the terminal API for interactive commands.
> >
> > Yes, that's a bit cleaner.
> > But it's not like we extend the terminal API every week.
>=20
> S you would suggest that I add term->raise_term_window directly in
> struct termentry ?

Not at all. I was just commenting that extending the terminal
API doesn't happen very often, so it doesn't seem like a high
priority to rearrange things to make it easier.  Nice, but not
high priority.

> term->inter->raise_term_window()

> > 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 comma=
nd
> > 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.
>=20
> 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=20
driver didn't work.

=2D-=20
Ethan A Merritt

On Thursday 08 March 2007 15:44, Ethan Merritt wrote:
> On Thursday 08 March 2007 14:35, Timoth=E9e Lecomte wrote:
> > > 4) Mousing support for multiplot mode
> >=20
> > This one is probably more difficult than it seems.
>=20
> At least in x11 it should not be fairly easy.

Bleah.  Make that "should be fairly easy".

=2D-=20
Ethan A Merritt            Courier Deliveries: 1959 NE Pacific
Dept of Biochemistry
Health Sciences Building
University of Washington - Seattle WA 98195-7742

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

> 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
> gnuplot-beta@...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

> 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

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

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

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

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

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

>  On Thursday 08 March 2007 04:53, Timothée Lecomte wrote:

>
>>
>>> What I implement in the plugin1.diff and plugin2.diff is the an
>>> in-between
>>> interactive structure:
>>> term->inter->waitforinput
>>> term->inter->put_tmptext
>>> term->inter->set_ruler
>>> term->inter->set_cursor
>>> term->inter->set_clipboard
>>>
>>> so that non-interactive terminals just have term->inter = 0, making it
>>> easier to extend the terminal API for interactive commands.
>>
>> Yes, that's a bit cleaner.
>> But it's not like we extend the terminal API every week.
>
> So you would suggest that I add term->raise_term_window directly in
> struct termentry ?
>
> In that case, my point is that:
> - if I add it to the bottom, then it's one more #ifdef USE_MOUSE
> - if I add it inside the current #ifdef USE_MOUSE, I have to add one '0'
> manually to all drivers

Well, let's forget this idea of term->inter->...
I can actually add term->raise_term_window just inside the existing #ifdef
USE_MOUSE ... #endif, and I can introduce the following:

#define EMPTY_MOUSE_ENTRIES \
#ifdef USE_MOUSE \
0, 0, 0, 0, 0, 0, \
#endif


So that non-mouseable terminals will just use NO_MOUSE_ENTRIES, and it
will be much easier to add new mousing commands in the future.

Does that sound right ?

Best regards,

Timothée

Timothée Lecomte wrote:
>>  On Thursday 08 March 2007 04:53, Timothée Lecomte wrote:
>>     
>
>   
>>>> What I implement in the plugin1.diff and plugin2.diff is the an
>>>> in-between
>>>> interactive structure:
>>>> term->inter->waitforinput
>>>> term->inter->put_tmptext
>>>> term->inter->set_ruler
>>>> term->inter->set_cursor
>>>> term->inter->set_clipboard
>>>>
>>>> so that non-interactive terminals just have term->inter = 0, making it
>>>> easier to extend the terminal API for interactive commands.
>>>>         
>>> Yes, that's a bit cleaner.
>>> But it's not like we extend the terminal API every week.
>>>       
>> So you would suggest that I add term->raise_term_window directly in
>> struct termentry ?
>>
>> In that case, my point is that:
>> - if I add it to the bottom, then it's one more #ifdef USE_MOUSE
>> - if I add it inside the current #ifdef USE_MOUSE, I have to add one '0'
>> manually to all drivers
>>     
>
> Well, let's forget this idea of term->inter->...
> I can actually add term->raise_term_window just inside the existing #ifdef
> USE_MOUSE ... #endif, and I can introduce the following:
>
> #define EMPTY_MOUSE_ENTRIES \
> #ifdef USE_MOUSE \
> 0, 0, 0, 0, 0, 0, \
> #endif
>
>
> So that non-mouseable terminals will just use NO_MOUSE_ENTRIES, and it
> will be much easier to add new mousing commands in the future.
>
> Does that sound right ?
>
> Best regards,
>
> Timothée
>   

Ok, that's done:
http://sourceforge.net/tracker/index.php?func=detail&aid=1677582&group_id=2055&atid=302055
Comments ?

Best regards,

Timothée

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" <jthorn@...>
   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

> >> > 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.

I think so. And it does not depend on x11 at all.

> > The difficult part would be to do something like zooming a subplot;
> > as currently implemented, that would require going back to the

Yes, that's impossible .. unless the whole output of "save ..." just after 
the plot is stored internally.


> 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.

Will the "raise" command keep raising all windows of wxt and/or of x11?
And which one will it choose when currently there is e.g. "set term post"?

---
PM

>> >> > 4) Mousing support for multiplot mode
>> >>
>> >> This one is probably more difficult than it seems.
>> >
>> > The difficult part would be to do something like zooming a subplot;
>> > as currently implemented, that would require going back to the
>
> Yes, that's impossible .. unless the whole output of "save ..." just after
> the plot is stored internally.

Not only 'save', but also the input data, which is not available anymore
in case of a pipe for example. We would need some cache layer in between
the parser and the terminals. Doesn't it exist for pm3d quadrangles
already ?

>
>
>> 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.
>
> Will the "raise" command keep raising all windows of wxt and/or of x11?
> And which one will it choose when currently there is e.g. "set term post"?

It affects the current terminal only, so it won't do anything if the
current terminal is postscript for example. When I say 'current terminal',
it includes all windows for an interactive terminal. I think it's clear
when you look at the function primitive:

term->raise_termwindow(int w /* windows number */,
                       TBOOLEAN raise /* raise or lower*/,
                       TBOOLEAN all /* all windows or only the given
number */)

As an example:

set term x11 0
plot x
set term x11 1
plot x
set term wxt 0
plot x
set term wxt 1
plot x
set term plot; raise # nothing happens
set term wxt; raise # all wxt windows is raised.
set term wxt; raise 1 # wxt window n°1 is raised
set term wxt; raise 0 # wxt window n°0 is raised
set term wxt 0; raise 1 # wxt window n°1 is raised
set term x11; raise 0 # x11 window n°0 is raised
set term x11; raise 1 # x11 window n°1 is raised
set term x11 0; raise 1 # x11 window n°1 is raised

Does that sound right to you ?

Timothée

On Thursday 15 March 2007 02:44, Petr Mikulik wrote:
> 
> > > The difficult part would be to do something like zooming a subplot;
> > > as currently implemented, that would require going back to the
> 
> Yes, that's impossible .. unless the whole output of "save ..." just after 
> the plot is stored internally.

It is not impossible.  In fact SVG can already do it, because the
SVG viewer is responsible for the zooming.  It does not recalculate 
the axis positions and relabel them, of course, but it does give you
an zoomed-in view of the original plot. The same thing could be done
in x11 if we decide it's worth it.

Furthermore, it would be possible to do a more efficient job
of "replot" in the core code that would benefit all terminals.
Perhaps I am overlooking something, but I don't see any hard
requirement to re-read the original data from a file on each
replot command.  Yes, this is sometimes exactly what you want
because you know the data has changed.  But more often you
just want to redraw the plot with a different plot option,
or zoom or view angle.  In these cases there should be enough,
or almost enough, information already stored in the data structures
from the previous plot.  Why re-read the data file when it is
just storing the same information all over again?  This would in
particular be of  plot '-', where it is very annoying to type in
the same data all over again.  

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

On Thursday 15 March 2007 04:02, Timoth=E9e Lecomte wrote:
> It affects the current terminal only, so it won't do anything if the
> current terminal is postscript for example. When I say 'current terminal',
> it includes all windows for an interactive terminal.

It is slightly more complicated for x11.  The "raise" command can only
affect x11 windows opened by the current instance of gnuplot_X11.
It is possible, although unusual, to have multiple active instances of
gnuplot_x11, each managing a separate set of display windows.

If we wanted to make this truly general, we would have to keep a=20
table mapping previous x11 plot commands to the x11 window ID that=20
they were assigned.  That could be done, but it would be a big
headache and I don't recommend it.

	Ethan=20


> I think it's clear=20
> when you look at the function primitive:
>=20
> term->raise_termwindow(int w /* windows number */,
>                        TBOOLEAN raise /* raise or lower*/,
>                        TBOOLEAN all /* all windows or only the given
> number */)
>=20
> As an example:
>=20
> set term x11 0
> plot x
> set term x11 1
> plot x
> set term wxt 0
> plot x
> set term wxt 1
> plot x
> set term plot; raise # nothing happens
> set term wxt; raise # all wxt windows is raised.
> set term wxt; raise 1 # wxt window n=B01 is raised
> set term wxt; raise 0 # wxt window n=B00 is raised
> set term wxt 0; raise 1 # wxt window n=B01 is raised
> set term x11; raise 0 # x11 window n=B00 is raised
> set term x11; raise 1 # x11 window n=B01 is raised
> set term x11 0; raise 1 # x11 window n=B01 is raised
>=20
> Does that sound right to you ?

=2D-=20
Ethan A Merritt

> Furthermore, it would be possible to do a more efficient job
> of "replot" in the core code that would benefit all terminals.
> Perhaps I am overlooking something, but I don't see any hard
> requirement to re-read the original data from a file on each
> replot command.  Yes, this is sometimes exactly what you want
> because you know the data has changed.  But more often you
> just want to redraw the plot with a different plot option,
> or zoom or view angle.  In these cases there should be enough,
> or almost enough, information already stored in the data structures
> from the previous plot.  Why re-read the data file when it is
> just storing the same information all over again?  This would in
> particular be of  plot '-', where it is very annoying to type in
> the same data all over again.  

Mousing in 3D -- rotating by mouse -- does not reread the data, but uses 
those in the memory. It would be useful for those "-" to do the same.

Thus there could be two replots, e.g. replot and Replot, where the second 
would not reread the data from disk.

---
PM

I went through the octave-help archive and a message (see its copy at the 
bottom) says that mousing (zooming, and also hotkeys) does no longer work 
with octave 2.9.10. I had a look what this octave version is doing by:

	octave> gnuplot_binary('tee a.log | gnuplot');

and there appears:

plot "-" using ($1):($2) title "" with lines linestyle 1;
-20 -20
-19 -19
-18 -18

Therefrom, octave does no longer use temporary data files but switched to 
inline data. That's a nice improvement. Unfortunately, gnuplot ignores 
"replot" for plots with "-", and consequently mousing+hotkeys do not work.

Thus, it looks like a strong demand to gnuplot developers to implement 
replot for "-". This matter was discussed recently, see below...

Note: 3D plots, e.g.
	octave> mesh(hilb(9))
which produces
	splot "-" using ($1):($2):($3) title "" with line palette;
	1 1 1
	1 2 2
can be rotated by mouse, because gnuplot reuses the loaded 3D data in
this case; but hotkeys do not work again.


Does somebody know how to implement it? (Me not.)

---
PM



On Thu, 15 Mar 2007, Petr Mikulik wrote:

> > Furthermore, it would be possible to do a more efficient job
> > of "replot" in the core code that would benefit all terminals.
> > Perhaps I am overlooking something, but I don't see any hard
> > requirement to re-read the original data from a file on each
> > replot command.  Yes, this is sometimes exactly what you want
> > because you know the data has changed.  But more often you
> > just want to redraw the plot with a different plot option,
> > or zoom or view angle.  In these cases there should be enough,
> > or almost enough, information already stored in the data structures
> > from the previous plot.  Why re-read the data file when it is
> > just storing the same information all over again?  This would in
> > particular be of  plot '-', where it is very annoying to type in
> > the same data all over again.  
> 
> Mousing in 3D -- rotating by mouse -- does not reread the data, but uses 
> those in the memory. It would be useful for those "-" to do the same.
> 
> Thus there could be two replots, e.g. replot and Replot, where the second 
> would not reread the data from disk.

===

According to:
http://www.cae.wisc.edu/pipermail/help-octave/2007-April/003542.html

>gnuplot zoom not functioning anymore in octave 2.9.10
>John W. Eaton jwe at bevo.che.wisc.edu
>Wed Apr 4 09:33:03 CDT 2007
>| until version 2.9.9, it was possible to enable zoom with the
>| "set mouse" command (e.g. in ~/.gnuplot). After changing to
>| version 2.9.10, this does not function anymore.
>
>It still works for me with gnuplot 4.0.
>
>With gnuplot 4.2 I can rotate and zoom 3d plots, but zooming 2d plots
>does not work for me when gnuplot is called from Octave.  It does work
>when I run gnuplot directly.  I don't know what the proper fix is.  In
>any case, the changes you make with the mouse will still not be
>reflected in the axes settings seen by Octave as the communication
>with gnuplot is still a simple one way pipe.
>
>jwe

There are a number of patches on SourceForge ready for consideration in CVS.  If
someone wants to review them they can.  Or, if you want me to move them in, give
me a password (or temporary password if S.F. has such a thing).


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

Fixes issues such as a help line longer than the space reserved in memory for a 
command line.


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

I think it is correct, others may not.  It appears to work on Linux and Mac and 
I'm fairly confident it won't cause any problems.


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

This is an outright bug fix.  Should have gone in 4.2.


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

Full implementation of mouse/clipboard behavior consistent with the vast
majority of X applications.


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

Do something like

if (i_tic == i_end) {
   if (last_tic < end_range)
     draw_tic;
}

instead of

while (first_tic + delta_tic + delta_tic + ... + delta_tic < end_range)
   draw_tic;

The second approach is susceptible to rounding, the first isn't.


[ 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.  Will X ever change this? 
  I doubt it.  The most I could offer is to somehow check if the outside 
application has relenquished the mouse and if not issue an error.


[ gnuplot-Patches-1531560 ] recursive history warning instead of error

Issue a warning rather than an error so that the rest of the line may be 
executed, e.g.,

gnuplot> history !his; show style;
^
warning: ignoring recursive history command
Data are plotted with points...


[ gnuplot-Patches-1723798 ] Multiplot palette X11, bug [ 1447277 ]

Allows multiple palettes on a multiplot X11 window, a long desired fix.


[ gnuplot-Patches-1725993 ] Alternate Hidden3d Edge Segmentation

Fixes a bug reported on SourceForge.  Very big patch.  No noticable change in 
speed.  If someone wants to fix the bug another way, feel free.


[ 1727198 ] Hidden lines: Degenerate polygons creating problems

Fixes a bug reported on SourceForge.  User reported hidden lines appearing on a 
globe.  The lines were part of the north pole in which four sided polygons were 
degenerate as triangles.  Hence internally triangles with two sides the same 
were the problem spot.  The patch simply tosses out such polygons.


[ gnuplot-Bugs-1728063 ] hidden lines, scale assertion failure

Replace an assertion statement in the QUADTREE version with a simple range 
limit.  Hidden line removal slows down if user pushes surface out past the plot 
view, but that is a minor consequence.  (Better than your program quitting on you.)


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

This one isn't ready to go, but we should address this at some point.  An 
interesting side note is that Octave considered storing its stem plot data as a 
series of data for which a "missing" value is used to create a discontinuous 
space.  That is, there is three ways of doing this:

1) Use gnuplot's "stem".
2) Draw a bunch of individual lines with "plot" for each line.
3) Draw a series of data with every third entry "missing" thus leaving the third 
line blank.

Turns out that 3 sort of fits the way Octave stores data.


Dan

On Wednesday 30 May 2007 11:38, Daniel J Sebald wrote:
> 
> [ gnuplot-Bugs-1534367 ] too much expansion in FindHelp
> [ gnuplot-Bugs-1525665 ] help has problems with
> [ gnuplot-Patches-1531560 ] recursive history warning instead of error

I agree these are relatively high priority.
They almost went into 4.2, but were held out because bugs
turned up at the last minute.  IOW they are not quite working yet.
I would very much like to see them cleaned up, thoroughly tested,
and added to CVS.

Please combine them into a single patch set against current source
and let's give them a workout to shake out any remaining bugs.

> [ gnuplot-Patches-1566782 ] use tgamma for GAMMA() and lgamma for LNGAMMA()
> 
> I think it is correct, others may not.  It appears to work on Linux and Mac and 
> I'm fairly confident it won't cause any problems.

It was never broken on linux, and I believe it is no longer needed
on OSX either.  So the risk of breaking some minor platform seems larger
than the benefit to any known system.  Please correct me if I'm wrong.

> [ gnuplot-Bugs-1488168 ] z_floor and z_ceiling based on xyplane.absolute 
> This is an outright bug fix.  Should have gone in 4.2.

Do you want to take this one Petr?
You had said earlier you would move it into CVS.
 
> [ gnuplot-Patches-1523316 ] improved CLIPBOARD and PRIMARY per X conventions
> 
> Full implementation of mouse/clipboard behavior consistent with the vast
> majority of X applications.

???  Not as seen here.  I have had no problems with the current implementation.
That doesn't make your fix wrong, but I don't understand what problem is fixing.
 
> [ gnuplot-Bugs-1004754 ] Tics and grid slightly outside border

I think this is a non-issue, and we should drop this one entirely.

> [ gnuplot-Patches-1027032 ] Connect gnuplot_x11 to exterior application
> window
> 
> Works as far as I know.

Doesn't work here.  I'd like it if it *did* work, but it doesn't.
My recollection is that it tripped over some contradictory requirements
for window management by Tk/Tcl, GTK, etc.

> [ gnuplot-Patches-1723798 ] Multiplot palette X11, bug [ 1447277 ]
> Allows multiple palettes on a multiplot X11 window, a long desired fix.

Sorry, I haven't had time to look at this one yet.

> [ gnuplot-Patches-1725993 ] Alternate Hidden3d Edge Segmentation
> [ 1727198 ] Hidden lines: Degenerate polygons creating problems
> [ gnuplot-Bugs-1728063 ] hidden lines, scale assertion failure

I'll leave these to Hans-Bernhard, since he's far more familiar
with the code.  I will comment that gnuplat's hidden-line removal
plots have very different properties than solid rendering.  When you
render solids, omitting a facet is just about the worst thing you can do.
The missing facet is far more jarring than a mis-aligned edge.
But in the case of gnuplot, it is exactly the mis-aligned edges that
are noticeable.  We don't care if a facet is dropped.  So although
I have not delved into the code, I suspect that the most useful fix
is simply to increase the slop margin, and deliberately omit any
edges that are in the slop area.  

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

Veto.
There are more reasonable options.
1) Clean up your data files
2) Run it through general string handling:
    filter(x) =   (x eq "?") ? NaN : (x eq "junk") ? NaN : x
    plot "foo" using 1:(filter($2))
3) Clean up your data files

Consider the case where you have multiple data files,
each with its own idea of what is or is not a missing data flag.
You want the fix to be per-file, not global.

-- 
Ethan A Merritt

> > [ gnuplot-Bugs-1488168 ] z_floor and z_ceiling based on xyplane.absolute 
> > This is an outright bug fix.  Should have gone in 4.2.
> 
> Do you want to take this one Petr?
> You had said earlier you would move it into CVS.

Yes, the patch works fine.

---
PM

Ethan Merritt wrote:
> On Wednesday 30 May 2007 11:38, Daniel J Sebald wrote:
> 
>>[ gnuplot-Bugs-1534367 ] too much expansion in FindHelp
>>[ gnuplot-Bugs-1525665 ] help has problems with
>>[ gnuplot-Patches-1531560 ] recursive history warning instead of error
> 
> 
> I agree these are relatively high priority.
> They almost went into 4.2, but were held out because bugs
> turned up at the last minute.  IOW they are not quite working yet.
> I would very much like to see them cleaned up, thoroughly tested,
> and added to CVS.
> 
> Please combine them into a single patch set against current source
> and let's give them a workout to shake out any remaining bugs.

Will do.


>>[ gnuplot-Patches-1566782 ] use tgamma for GAMMA() and lgamma for LNGAMMA()
>>
>>I think it is correct, others may not.  It appears to work on Linux and Mac and 
>>I'm fairly confident it won't cause any problems.
> 
> 
> It was never broken on linux, and I believe it is no longer needed
> on OSX either.  So the risk of breaking some minor platform seems larger
> than the benefit to any known system.  Please correct me if I'm wrong.

I'm not familiar with OSX other than that user said it works correctly when it 
was needed at the time.  Have to ask the OSX user who had a problem on this one.


>>[ gnuplot-Patches-1523316 ] improved CLIPBOARD and PRIMARY per X conventions
>>
>>Full implementation of mouse/clipboard behavior consistent with the vast
>>majority of X applications.
> 
> 
> ???  Not as seen here.  I have had no problems with the current implementation.
> That doesn't make your fix wrong, but I don't understand what problem is fixing.

It's added features for the most part.  But still I think the existing 
implementation doesn't really place a plot in the X clipboard, and furthermore 
it doesn't properly handle Atom translation.  The existing "clipboard" was a 
hastily constructed version that was made to work for one app and assumed to be 
a full and proper implementation.  The documentation currently states that the 
plot automatically goes into the clipboard.  But try doing a cntrl-V inside 
something like oowriter or your favorite word processor.  Nothing happens. 
There are actually two different entities, clipboard and "selection".  Those 
both have to be handled in the proper X implementation.  There needs to be 
communication about what file formats gnuplot_x11 can provide to the application 
and then gnuplot_x11 has to respond with the proper file format when requested.

The only think is that I didn't know it was possible to interpret cntrl-? keys, 
so 'c' is what puts a plot into the clipboard.  I'll see if I can fix that up to 
the cntrl-c (copy)/cntrl-v (paste) convention.


>>[ gnuplot-Bugs-1004754 ] Tics and grid slightly outside border
> 
> 
> I think this is a non-issue, and we should drop this one entirely.

It's still there.  This originated from Octave computing its axis limits with a 
bit of round off.  Try

set xrange [0:1.99805]
set grid
plot sin(x)
set xrange [0:2]
replot
set xrange [0:1.99805]
replot

and look to the right edge of the plot.  Basically, it addresses this FIXME in 
the code:

/* FIXME HBB 20010121: keeping adding 'step' to 'tic' is
* begging for rounding errors to strike us. */
/* HBB 20010410: ... and strike they did :-( */


>>[ gnuplot-Patches-1027032 ] Connect gnuplot_x11 to exterior application
>>window
>>
>>Works as far as I know.
> 
> 
> Doesn't work here.  I'd like it if it *did* work, but it doesn't.
> My recollection is that it tripped over some contradictory requirements
> for window management by Tk/Tcl, GTK, etc.

I'll have another look and see if there are any problems.


>>[ gnuplot-Patches-1725993 ] Alternate Hidden3d Edge Segmentation
>>[ 1727198 ] Hidden lines: Degenerate polygons creating problems
>>[ gnuplot-Bugs-1728063 ] hidden lines, scale assertion failure
> 
> 
> I'll leave these to Hans-Bernhard, since he's far more familiar
> with the code.  I will comment that gnuplat's hidden-line removal
> plots have very different properties than solid rendering.  When you
> render solids, omitting a facet is just about the worst thing you can do.
> The missing facet is far more jarring than a mis-aligned edge.
> But in the case of gnuplot, it is exactly the mis-aligned edges that
> are noticeable.  We don't care if a facet is dropped.  So although
> I have not delved into the code, I suspect that the most useful fix
> is simply to increase the slop margin, and deliberately omit any
> edges that are in the slop area.

Increasing the slop margin will probably make things worse.  There are two 
issues here that should be kept separate.  The alternate hidden3d issue (i.e., 
the bits and pieces) and the degenerate polygons.

The alternate hidden3d patch doesn't alter the EPSILON setting, and in fact, I 
avoid those EPSILON tests when they have no effect.  (I've noted in the code 
where they don't make a difference.)  Even the existing bug in the CVS code I 
doubt has anything to do with slop margin.  There appears to be a pattern 
whereby what bits and pieces (i.e., edge segments) that are left intersect 
precisely with one of the polygon vertices, but I'm not sure but I've offered a 
patch that works so I'm not inclined to figure it out.

The detailed explanation of the degenerate polygons is that sometimes the 4 
sided polygons turn out to be a triangle (or even share more similar vetices). 
In that case, some of the triangles making up that quadrangle are "degenerate", 
meaning that if v1, v2 and v3 are the triangles vertices, v1=v2 or v2=v3 or 
v3=v1.  But that is an infinitely thin slice and hence has no consequence if it 
is simply discarded.  However, if such a degenerate case is left, the existing 
code will try an create a plane equation describing the plane for such a 
degenerate triangle, but there is no unique, meaningful plane equation for two 
points.  Hence the orientation (probably random) incorrectly chooses the 
direction the plane faces and picks the wrong color for the line.  (The patches 
have some PNG examples attached.)


>>[ gnuplot-Patches-1508316 ] Allow multiple strings to signify "missing"
> 
> 
> Veto.
> There are more reasonable options.
> 1) Clean up your data files
> 2) Run it through general string handling:
>     filter(x) =   (x eq "?") ? NaN : (x eq "junk") ? NaN : x
>     plot "foo" using 1:(filter($2))
> 3) Clean up your data files
> 
> Consider the case where you have multiple data files,
> each with its own idea of what is or is not a missing data flag.
> You want the fix to be per-file, not global.

I'm fine with only one missing symbol.  However, there is still the issue of 
defining exactly how these behave in the code.  I included some demo plots in 
the patch to illustrate behavior for the two classes of points.  I think 
originally behavior was sort of left to the wind.

Dan