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

Re: gnuplot projects, terminal modules

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

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

Re: gnuplot projects, terminal modules

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

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

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

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

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/

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

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

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


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

Also note that Mathemetica, Matlab, etc. are more for repetitive
simulation/analysis tools. 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.


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

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

This one is interesting. At least I see that what I wrote with GLib for my
terminals-as-plugins could be done from scratch ;)

Best regards,

Timothée


>
> 	Ethan
>

Re: gnuplot projects, terminal modules

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

 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):

Thanks for participating in the discussion !


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

One interesting quote from Lars's list in the TODO file:

"- better documentation format; get rid of the doc2xxx utils
  [SGML. SGML. SGML]"

Maybe localization could be an additional motivation for this.


>
> 2) Transparency
> 	- mostly done, but needs to be implemented in win, aqua, [others?]
>
> 3) Mousing support for SVG
>
> 4) Mousing support for multiplot mode

This one is probably more difficult than it seems.


<...>


>
>> First, I'd like to see the terminal module architecture that I proposed
>> as
>> a patch in sourceforge to settle:
>> https://sourceforge.net/tracker/?func=detail&atid=302055&aid=1571443&group_id=2055
>
> 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. I
understood that some people were not liking to have the core have many
dependencies, so that's a way to overcome that. It may make
packagers/distributions' life easier too.

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

S 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


>
>> And in plugin2.diff, I move the ugly terminal-specific code in
>> raise_lower_command() (command.c) to where it belongs, in the terminals.
>> This is done by introducing:
>>
>> 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 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 miwing 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

>
>> the patch "[ 1474309 ] Bind <space> to builtin_raise in mouse.c".
>> Instead
>> of moving the "raise console" code into the core, it could be moved to a
>> dummy terminal (like estimate.trm), which would be built as a module.
>> Voilà! No more code duplication without adding a Xlib dependency on the
>> core !
>
> But that isn't going to make it any easier to figure how to do it in the
> first place.  Also, does this mean you are thinking that one
> terminal driver would call into another terminal driver?  Or is this
> an alternative to the term->inter->raise_term_window() mechanism you
> just mentioned above?

So, that's point 1 in the above enumeration. It is not terminal-specific,
so it shouldn't be in the terminal code as it is now. The problem is that
it can only be done by linking to Xlib (from a Unix environment, of
course), and it was objected that we don't want to add a dependency on
Xlib to the core.


>
>> What are my other short-term projects ?
>> - commit the cairopdf terminal, eventually replacing the current pdf
>> terminal. It is really working nicely.
>
> Absolutely.  This will be really great.  The main hangup is the same
> as for the initial wxt terminal introduction - it isn't straightforward
> to build it on most machines yet, because the cairo library requirement
> is too bleeding edge.  But that's not a problem in the longer term.

Right. I plan to commit it soon, just after a couple a cleanups here and
there.


>> Another interesting comment was the lack of
>> a powerful and broadly available (i.e. for many languages) plotting
>> library.
>
> There's a reason for that.  Such libraries are not very useful,
> and tend to die a lingering death from lack of users.
> Additional comments in a separate post.

Ok, let's discuss it in the separate post.

Thank you again for your comments.

Timothée

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

Re: gnuplot projects, terminal modules

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

On Thursday 08 March 2007 04:53, Timoth=E9e Lecomte wrote:
> Dear gnuplot enthusiasts,
>=20
> 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)

> First, I'd like to see the terminal module architecture that I proposed as
> a patch in sourceforge to settle:
> https://sourceforge.net/tracker/?func=3Ddetail&atid=3D302055&aid=3D157144=
3&group_id=3D2055

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.

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

> And in plugin2.diff, I move the ugly terminal-specific code in
> raise_lower_command() (command.c) to where it belongs, in the terminals.
> This is done by introducing:
>=20
> 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 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.

> the patch "[ 1474309 ] Bind <space> to builtin_raise in mouse.c". Instead
> of moving the "raise console" code into the core, it could be moved to a
> dummy terminal (like estimate.trm), which would be built as a module.
> Voil=E0! No more code duplication without adding a Xlib dependency on the
> core !

But that isn't going to make it any easier to figure how to do it in the
first place.  Also, does this mean you are thinking that one
terminal driver would call into another terminal driver?  Or is this
an alternative to the term->inter->raise_term_window() mechanism you
just mentioned above?

> What are my other short-term projects ?
> - commit the cairopdf terminal, eventually replacing the current pdf
> terminal. It is really working nicely.

Absolutely.  This will be really great.  The main hangup is the same
as for the initial wxt terminal introduction - it isn't straightforward
to build it on most machines yet, because the cairo library requirement
is too bleeding edge.  But that's not a problem in the longer term.

> Another interesting comment was the lack of
> a powerful and broadly available (i.e. for many languages) plotting
> library.=20

There's a reason for that.  Such libraries are not very useful,
and tend to die a lingering death from lack of users.
Additional comments in a separate post.

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

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

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

On Thursday 08 March 2007 04:53, Timoth=E9e Lecomte wrote:

> Another interesting comment was the lack of=20
> 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=20
sufficiently important we could implement it anyhow, admittedly in an
OS-specific manner, by shared memory regions.

=46urthermore, if you look at the most powerful visualization tools,=20
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.
  =20
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).=20

	Ethan





>=20
> "longer term
>=20
> - 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"
>=20
> 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.
>=20
> Well, that's it. Don't forget to comment on the modular architecture, and
> thanks for reading.
>=20
> Best regards,
>=20
> Timoth=E9e

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

gnuplot projects, terminal modules

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

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.

First, I'd like to see the terminal module architecture that I proposed as
a patch in sourceforge to settle:
https://sourceforge.net/tracker/?func=detail&atid=302055&aid=1571443&group_id=2055

There is a preliminary step chich is the acceptance of the first two
patches (plugin1.diff and plugin2.diff) which rework the interactive
commands of the terminal structure in order to make it more extensible.

Currently, we have:
term->waitforinput
term->put_tmptext
term->set_ruler
term->set_cursor
term->set_clipboard

This is a nice interface for mousing-related commands, but as it was
pointed out earlier, it is not easily extensible to new commands, since
new entries have to be addded at the end of the term structure, and this
can painful to maintain with the large amount of terminals that we have.
Petr (if I remember correctly) proposed to add something like:

term->interactive("some command")

and it was objected that it adds another parsing layer...

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.

And in plugin2.diff, I move the ugly terminal-specific code in
raise_lower_command() (command.c) to where it belongs, in the terminals.
This is done by introducing:

term->inter->raise_term_window

I'd really like to commit this code, not to have to maintain it for too long.

Then there is the modular terminal architecture that may deserve some more
discussion. It's implemented in plugin5.diff and I'd be pleased to listen
to your comments. See the patch page for details.


What are my other short-term projects ?
- commit the cairopdf terminal, eventually replacing the current pdf
terminal. It is really working nicely.
- after the modular terminal architecture has settled, I'd like to finish
the patch "[ 1474309 ] Bind <space> to builtin_raise in mouse.c". Instead
of moving the "raise console" code into the core, it could be moved to a
dummy terminal (like estimate.trm), which would be built as a module.
Voilà! No more code duplication without adding a Xlib dependency on the
core !

What are my long-term projects ?
In a release article for 4.2 that was published in a french web site
(http://linuxfr.org/2007/03/07/22168.html), the most frequent comment was
that a GUI would be appreciated as an alternative to the
script/command-line interface. 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:

"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

Re: [slightly OT] plotting a (pm3d) closed surface with arbitrary vertices

[<HBB...@t-...>]

Dr. Johannes Zellner wrote:

> What I'd need now, is to invalidate the data outside some distance to
> the data points. 

Sorry, no can do.  You must have seen me state this before: gnuplot is a 
plotting program, not a general-purpose number crunching engine.  There 
are limits to what it'll do, and you've just hit one.

 > Suppose I've data whithin a banana shape in x, y and
> like to have colored pm3d rectangles only when x, y are near the banana
> (which is defined by the scatter x, y data points).

In its general case it's already a surprisingly tricky task to come up 
with a usable formal definition of such "banana shapes" that computers 
can test, much less generate by themselves.

Re: [slightly OT] plotting a (pm3d) closed surface with arbitrary vertices

[Dr. J. Z. <joh...@ze...>]

Hans-Bernhard,

Thanks!
This was indeed what I was looking for and it works already pretty well.
What I'd need now, is to invalidate the data outside some distance to
the data points. Suppose I've data whithin a banana shape in x, y and
like to have colored pm3d rectangles only when x, y are near the banana
(which is defined by the scatter x, y data points).
Maybe you've a quick solution for this problem as well? ;-)

-- 
Johannes

On Tue, Mar 06, 2007 at 10:36:00PM +0100, Hans-Bernhard Bröker wrote:
> Dr. Johannes Zellner wrote:
> > Any ideas how to get a real closed surface? -- I guess I'd need
> > something like a function which searches the closest vertices (in x, y)
> > and then connects the vertices by triangular surfaces.
> 
> What you're looking for is (a variation of) 'set dgrid3d'.  I'm slightly 
> worried you didn't manage to find that in the documentation by yourself.
> 
> 
> -------------------------------------------------------------------------
> 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: 4.2 Release plans - Last chance for comments

[<HBB...@t-...>]

Lucas Hart wrote:
> My recollection is that the tracker is preferred, is it?

Yes.  It has its own kind of gotchas, but it's a lot more organized, and 
easier to manage than an unstructure mailing list.

> The "Bugs" text is also somewhat misleading as one does not need 
> to upload a file in order to submit a report 

Well, most bug reports actually do need a file: the exact command 
sequence, e.g., or the data being used.  As is,m I have to answer the 
majority of reports with a request for missing information.

Re: status of xgfe (x11 front end for GnuPlot)

[Glenn B. <gbb...@ve...>]

On Monday 05 March 2007 11:11 pm, you wrote:
> On Monday 05 March 2007 17:59, Glenn Burkhardt wrote:
> > I'm interested in reviving 'xgfe'.
> >
> > The link on http://www.gnuplot.info/links.html to
> > http://home.flash.net/~dmishee/xgfe/xgfe.html is stale, but I've been
> > able to find a copy of version 2.1 somewhere, and, after a few changes,
> > have it working on a "modern" system.
>
> There seems to be a recent version (last updated 2 weeks ago) on
> http://www.freshports.org/math/xgfe
>

This is the same as the 1998 edition I'm working from.  Thanks.

> > And, second, is 'xgfe' the best starting point for my little project?
>
> I was hoping someone would make the button/widget bar on the new wxt
> terminal user-extensible.  Perhaps via a configuration file that one each
> line lists an icon URL and a corresponding gnuplot command line.  Or
> perhaps via an extension to the "bind" command that creates a button in
> addition to a hot key:
>   bind button "set style fill transparent solid 0.5" icon
> "~/icon/transp.png"

I'll see what I can do.  I'm much more familar with Qt than wxGTK.

Re: [slightly OT] plotting a (pm3d) closed surface with arbitrary vertices

[<HBB...@t-...>]

Dr. Johannes Zellner wrote:
> Any ideas how to get a real closed surface? -- I guess I'd need
> something like a function which searches the closest vertices (in x, y)
> and then connects the vertices by triangular surfaces.

What you're looking for is (a variation of) 'set dgrid3d'.  I'm slightly 
worried you didn't manage to find that in the documentation by yourself.

[slightly OT] plotting a (pm3d) closed surface with arbitrary vertices

[Dr. J. Z. <joh...@ze...>]

Hello,

forgive me, this is OT, but I guess the guys at this list might be
able to give me help.

I frequently like to splot a (pm3d) surface for which I have arbitrary
x, y, z vertices. The surface is usually well-behaved in a sense that
it's smooth, w/o singularities and has only long-range (low frequency)
changes.

As first approximation -- and this is the best I have -- I use 'splot
with points' using 'linetype pal' to get colors and I use pretty large
point sizes to get part of the surface "covered".

Any ideas how to get a real closed surface? -- I guess I'd need
something like a function which searches the closest vertices (in x, y)
and then connects the vertices by triangular surfaces.

Any hints much appreciated.

-- 
Johannes

Re: gnuplot.info and www.gnuplot.info

[Clark G. <ga...@di...>]

pending dns update.

Also, several files still have absolute URLs pointing to sourceforge. I
noticed a bunch in the demo_4.3, but there are probably others. Please
ensure that the URLs that should be local (i.e. all of them) do not have
absolute references.

--ckg

On Tue, 6 Mar 2007 13:58:14 +0100 (CET), "Timoth=E9e Lecomte"
<tim...@en...> said:
> Dear all,
>=20
> I ahev just noticed that http://gnuplot.info does not give the same as
> http://www.gnuplot.info, in particular it's datd May 2006.
>=20
> Clark, could it be fixed ?
>=20
> Thank you very much,
> Best regards,
>=20
> Timoth=E9e
>=20

gnuplot.info and www.gnuplot.info

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

Dear all,

I ahev just noticed that http://gnuplot.info does not give the same as
http://www.gnuplot.info, in particular it's datd May 2006.

Clark, could it be fixed ?

Thank you very much,
Best regards,

Timothée

Re: status of xgfe (x11 front end for GnuPlot)

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

 
> There seems to be a recent version (last updated 2 weeks ago) on
> http://www.freshports.org/math/xgfe
>  
> > And, second, is 'xgfe' the best starting point for my little project?
 
 ISTR that xgfe went unmaintained for a long time and effectively stopped
 being compilable with newer versions of gcc (as the C++ standard was
 settling). There is another frontend called qgfe, based on xgfe, but I
 don't think it has seen any work on it in the past 3-4 years either.

Re: 4.2 Release plans - Last chance for comments

[<ha...@on...>]

On Sun, Mar 04, 2007 at 12:37:33PM +0100, Hans-Bernhard Br?ker wrote:
>
> "Seeking assistance" is about usage problems, so it should not point 
> directly to the bug tracker.  "Bugs" is where it should be mentioned, 
> and is.
> 

gnuplot.doc says

1 gnuplot
...
2 Seeking-assistance
...
 Bug reports and code contributions should be mailed to:
        gnu...@li...
...
1 Bugs
 Please e-mail bug reports to the gnuplot-bugs mailing list.
 Or upload the report to the gnuplot web site on SourceForge.
 ...  See `Seeking-assistance`

My recollection is that the tracker is preferred, is it?

One can also take the point of view that "seeking assistance" is 
the place one looks for contact information and that the function
of "Bugs" is primarily to list bugs known at release.  In any case, 
contact information is currently in both sections but inconsistent.

The "Bugs" text is also somewhat misleading as one does not need 
to upload a file in order to submit a report and it does not 
mention the bug tracker (nor does it give the list address), 
perhaps something like, for both, 
  Bug reports and code contributions should be mailed to:
      gnu...@li...
  or, preferably, submitted using the bug tracker at the 
  gnuplot web site on SourceForge

- Lucas Hart

Re: status of xgfe (x11 front end for GnuPlot)

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

On Monday 05 March 2007 17:59, Glenn Burkhardt wrote:
> I'm interested in reviving 'xgfe'.
> 
> The link on http://www.gnuplot.info/links.html to 
> http://home.flash.net/~dmishee/xgfe/xgfe.html is stale, but I've been able to 
> find a copy of version 2.1 somewhere, and, after a few changes, have it 
> working on a "modern" system.

There seems to be a recent version (last updated 2 weeks ago) on
http://www.freshports.org/math/xgfe
 
> And, second, is 'xgfe' the best starting point for my little project?

I was hoping someone would make the button/widget bar on the new wxt terminal
user-extensible.  Perhaps via a configuration file that one each line lists
an icon URL and a corresponding gnuplot command line.  Or perhaps via an
extension to the "bind" command that creates a button in addition to
a hot key:
  bind button "set style fill transparent solid 0.5" icon "~/icon/transp.png"

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

status of xgfe (x11 front end for GnuPlot)

[Glenn B. <gbb...@ve...>]

I'm interested in reviving 'xgfe'.  I've been using the Win32 front end at the 
office, and it would be nice to have equivalent, or better, functionality on 
my Linux system.

The link on http://www.gnuplot.info/links.html to 
http://home.flash.net/~dmishee/xgfe/xgfe.html is stale, but I've been able to 
find a copy of version 2.1 somewhere, and, after a few changes, have it 
working on a "modern" system.

So, my question is, does anyone know how to contact the author (David Ishee), 
to find out if I'm working with the most current version, and what he'd like 
to do with whatever changes I make?

And, second, is 'xgfe' the best starting point for my little project?

Thanks.

Re: 4.2 Release plans - Last chance for comments

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

 
> The last known employer for Thomas Williams is Pixar, is that right?
>  Calling there is easy enough too.
 
 Yep.

 He did give me a personal email address, but the last time I emailed,
 it bounced with "mailbox full". Alex Woo suggests "He's probably in a
 resort somewhere after selling off his Pixar holdings". ;)

Re: 4.2 Release plans - Last chance for comments

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

Lars Hecking wrote:
> Daniel J Sebald writes:
> [...] 
> 
>>Yes, and if one is able to reach him, it would be good to discuss some
>>way of resolving the License issues...  I could try contacting the Colin
>>Kelly at that Callwave company to see if he is the other half of the
>>original copyright holders.  However, any identifiable info about Kelly
>>that Thomas Williams could provide would help, e.g., a college he may
>>have been attending or worked for at the time.
> 
>  
>  As the person attached to this project who has been in touch with
>  Tom Williams most recently, I would like to say this:
> 
>   - There is no communication channel to Thomas Williams right now.
>   - Colin Kelley has been "lost in cyberspace" for the better part of the past
>     decade. Possibly two decades.
>   - If we could somehow establish contact with Colin, I would appreciate it.

Reading this bit from FAQ:

"   The following quote comes from Thomas Williams:

     I was taking a differential equation class and Colin was taking
     Electromagnetics, we both thought it'd be helpful to visualize the"

suggests Colin may have been in either physics or electrical engineering.  The Colin Kelley of the Callwave company has a BSEE so that agrees.  Maybe that is him; still seems a few years too young.  I'll try contacting Callwave monday.


>   - Every time I have been in touch with Thomas Williams about a new release,
>     he was always very supportive. While, as a copyright holder, he has

The last known employer for Thomas Williams is Pixar, is that right?  Calling there is easy enough too.


There is also John Campbell http://jan.ucc.nau.edu/jdc/ who would be second generation.  He might have some info on Williams and Kelley, but I doubt it.

We should generate a plot showing a time line of people, version releases and new features.  :-)

Dan

Re: 4.2 Release plans - Last chance for comments

[<HBB...@t-...>]

... FYI, the News posting to our SF.net project site is done.

Announcement to freshmeat is also out (awaiting processing by their crew).

Re: 4.2 Release plans - Last chance for comments

[<HBB...@t-...>]

Ethan A Merritt wrote:
> On Sunday 04 March 2007 06:48, Hans-Bernhard Bröker wrote:
>> I'll delay posting the announcement until we've made up our minds about 
>> the slight glitch in version.c (RELEASE_VERSION should be set).  It's a 
>> lot easier to exchange the tarball while SourceForge's File Release 
>> System is still the only place it can be had

> Sorry for the glitch. I'm new at this.

So's just about everybody else.  Only Lars ever managed more than a 
single release.  As I said: this is what comes of releasing so seldom. 
We forget everything we learned by one release cycle before we do the 
next one.

> Shouldn't "make dist" set this flag from the makefile, rather
> than requiring one to edit the source code?

Not really.  'make dist' is supposed to make a tarball, regardless of 
whether that's a release or snapshot.

Lars put some tricks into the toplevel Makefile.maint.  I think 'make -f 
Makefile.maint rel-check' is more like what we should consider updating.

Thanks for all the hard work, and congratulations all around.

Re: 4.2 Release plans - Last chance for comments

[Per P. <per...@ma...>]

On Mar 4, 2007, at 02:56, Ethan A Merritt wrote:

> I'm CC'ing Per Persson in case he wants to post an announcement for  
> the
> Mac crowd.  Or perhaps that should wait until a Mac binary is  
> available?

I say let's wait for the binary installer. Shouldn't take too long  
since I already rehearsed creating a universal binary together with  
Mojca Miklavec and Jeremy Conlin. BTW, this time there will be two  
Mac binary releases; one for Mac OS X 10.1.x - 10.3.x (PPC only), and  
one for Mac OS X 10.4.x and up (Universal binary for PPC and Intel).

I'll be traveling March 9 - 18 and I feel a little uneasy releasing a  
Mac binary before the 19th in case there are any problems (unless  
Mojca and Jeremy are willing to fend off the mob until I get back ;-)

/Per