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

RE: wxwidgets terminal

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

> I did a wxGnuplot class inside a threaded C++ wxSimulator, with a
"wxTerm" providing the familiar gnuplot command line; worked fine. Only
significant problem was that a simulator can really only have a single
active plot, since some of the core gnuplot data is still global.  If
these were wrapped in a struct, each plot could have its own gnuplot
"data struct", and we could steer any number of
> wxGnuplot panels.

That single plot is a normal way, as multiple plot windows from a single
gnuplot session are available only for X11 terminal. How would the
simulator work under native Windows or OS/2 terminals?

If it was under X11, have you used the new feature of an x11 handle from
sourceforge patches? This patch waits for confirmation that it works.

Similar "problem" with one active window is also e.g. under Octave. Once
has to run several instances of gnuplot. Works fine.

---
PM

Re: linetype palette

[Aapo L. <aap...@gm...>]

On Tue, 2005-06-14 at 17:53 +0200, Johannes Zellner wrote:
> something bad happened with "linetype palette", see the attached files.
> The good one was generated with gnuplot 4.0 and something like
> "plot 'tmp.dat' u 1:2:3 w p lt pal". The bad one was generated by the
> latest gnuplot from cvs with the same command. Apparently "linetype
> palette" doesn't work any more :-(

Hmm, I cannot reproduce the problem, "linetype palette" works just fine.
BTW, what do you mean by 'plot' command?  You should use 'splot', at
least my Gnuplot says

---- clip ----
gnuplot> plot 'tmp.dat' u 1:2:3 w p lt pal
         2D plots cannot color by Z value; please use splot instead
---- clap ----

Why doesn't your Gnuplot say the same?  What kind of output does
"splot sin(0.01*x*y) w p lt pal" give to you?

						Aapo

-- 
Aapo Lankinen <aap...@gm...>

Re: linetype palette

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

On Tuesday 14 June 2005 08:53 am, Johannes Zellner wrote:
> something bad happened with "linetype palette", see the attached files.
> The good one was generated with gnuplot 4.0 and something like
> "plot 'tmp.dat' u 1:2:3 w p lt pal". The bad one was generated by the
> latest gnuplot from cvs with the same command.

Works fine here.  Attached is the output from 
splot 'silver.dat' u 1:2:3 w p lt pal pt 7 ps 5


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

linetype palette

[Johannes Z. <joh...@ze...>]

Hello,

something bad happened with "linetype palette", see the attached files.
The good one was generated with gnuplot 4.0 and something like
"plot 'tmp.dat' u 1:2:3 w p lt pal". The bad one was generated by the
latest gnuplot from cvs with the same command. Apparently "linetype
palette" doesn't work any more :-(

-- 
Johannes

Re: gnuplot slow on BIG files

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

 
> > Careful what you ask for, there --- the chief proponent of Amiga has 
> > been Lars. ;-)
> 
> Google does not seem to find any evidence for an Amiga build 
> newer than version 3.7.1 and most of the "AMINET" mirrors are no
> longer responding.
 
 No, aminet is alive and kicking. But the last version I uploaded is
 3.7.1.

> Lars - was version 4.0 ever built and tested on Amiga?
 
 Not sure, I'd need to check my machine at home.

 Getting the sources over is a tad difficult. My Amiga is not networked,
 and I only have a 33k modem. Hhm, I'll have to check whether we have a
 Sun QIC tape drive here at work, that would help a lot.

 That said, gnuplot 4 will probably build with the Amiga version of gcc.
 I will check it, give me a few days.

Re: wxwidgets terminal

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

Nigel Nunn wrote:

>Hi Timothee, Petr, Hans-Bernhard,
> =20
>
>>The attractiveness of the wx widget is that is NOT GPL, thus it=20
>>can be used in open source as well as for commercial applications.
>>   =20
>>
>
>I did a wxGnuplot class inside a threaded C++ wxSimulator, with a
>"wxTerm" providing the familiar gnuplot command line; worked fine.
>Only significant problem was that a simulator can really only have=20
>a single active plot, since some of the core gnuplot data is still
>global.  If these were wrapped in a struct, each plot could have=20
>its own gnuplot "data struct", and we could steer any number of=20
>wxGnuplot panels.  Tim, sounds like a worthwhile project.
>
>Nigel
> =20
>
Thanks for supporting me ! I might need your experience some day...

I have almost written my terminal, at least with the mandatory functions=20
to make gnuplot access it. I just implemented those calls and simulate=20
gnuplot action with some menus (_move, _vector, _graphics, etc).

My next step is to make it work *inside* gnuplot, which should not be a=20
big problem, as I have prepared myself to call the wxwidgets library=20
without building a whole application, in the same way as Videolan or=20
Bochs, which both use it as a gui plugin. I have to declare some=20
remaining variables, and pay attention to those 'extern "C" ' magic words=
 !

I will continue and keep sending news to the list.

Timoth=C3=A9e Lecomte

Re: gnuplot slow on BIG files

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

On Monday 13 June 2005 01:14 am, Hans-Bernhard Broeker wrote:
> Ethan Merritt wrote:
> 
> > Let's also issue a call to any Amiga users, and if none turn up
> > let's remove all the special casing for Amiga as well.
> 
> Careful what you ask for, there --- the chief proponent of Amiga has 
> been Lars. ;-)

Google does not seem to find any evidence for an Amiga build 
newer than version 3.7.1 and most of the "AMINET" mirrors are no
longer responding.

Lars - was version 4.0 ever built and tested on Amiga?


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

Re: [ gnuplot-Bugs-1217701 ] Locale settings not initialized properly

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

On Monday 13 June 2005 10:33 am, Hans-Bernhard Broeker wrote:
> Ethan Merritt wrote:
> 
> > It would have to be a very fine-grained switch, bracketing each
> > scanf/printf call.  For instance a plot command like
> > 	plot 'foo' using 1:2:(sprintf(format,column(3))) with labels
> > will be mixing scanf and sprintf during the parsing of every data line.
> > 
> > Could be done, but I can already hear screams about the performance
> > hit :-)
> 
> Well, since we wouldn't be forcing anyone to use any locale setting at 
> all, and the default should be "all locales are 'C', so no setlocale() 
> calls needed", I consider that a negligible risk.

I've uploaded a patchset to SourceForge that implements
	set decimalsign { <value> | {locale {<LOC>}}

My thought is that people can try this out and report back whether
there is a need to separate out the input and output locales.

By the way, it may be obvious but let me state it explicitly:

The existing `set locale` command only affects LC_TIME, the format used
for time/date strings.

The new command options to `set decimalsign` only affect LC_NUMERIC,
the format conventions used by the C library for scanf and printf.

Neither of these affects LC_CTYPE, which controls the character set
and font encoding.



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

Re: gnuplot slow on BIG files

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

On Monday 13 June 2005 01:14 am, Hans-Bernhard Broeker wrote:
> Ethan Merritt wrote:
> 
> Actually, it's *exactly* the OS bugs we have to code around.  All other 
> bugs can reasonably be avoided by asking people to upgrade some tool, 
> library or whatnot, or maybe by replacing buggy OS-supplied tools by 
> free replacements. 

There you have just described exactly the situation for OSK.
There was apparently a buggy, proprietary clib that gnuplot was
coded to work around. Since 1994, OSK has had the option of using
gcc/glibc intead.  So why should we continue to carry around a
work-around hack for a library that hasn't been needed since 1994?

> But neither we nor the typical user is in a position  
> to upgrade an OS just to be able to run gnuplot on it.

Several of the odd-ball machines I have in the lab were purchased
solely in order to support the software requirments of a particular
application or set of applications.  The world has changed; application
program requirements drive both hardware and OS purchasing decisions.

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

Re: [ gnuplot-Bugs-1217701 ] Locale settings not initialized properly

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

Ethan Merritt wrote:

> It would have to be a very fine-grained switch, bracketing each
> scanf/printf call.  For instance a plot command like
> 	plot 'foo' using 1:2:(sprintf(format,column(3))) with labels
> will be mixing scanf and sprintf during the parsing of every data line.
> 
> Could be done, but I can already here the screams about the performance
> hit :-)

Well, since we wouldn't be forcing anyone to use any locale setting at 
all, and the default should be "all locales are 'C', so no setlocale() 
calls needed", I consider that a negligible risk.

Re: [ gnuplot-Bugs-1217701 ] Locale settings not initialized properly

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

On Monday 13 June 2005 01:02 am, Hans-Bernhard Broeker wrote:
> Ethan Merritt wrote:
> 
> > I was under the impression that there is no way of separating the locale
> > used for input (e.g. scanf) from the locale used for output (e.g. printf).
> > Do you know otherwise?
> 
> Well, we know when we're doing what, so we could conceivably switch 
> between the two at the correct times during the process.  Worst thing 
> that could happen is slightly unexpected error messages in input locale 
> rather than output locale, if they are printed during datafile reading.

It would have to be a very fine-grained switch, bracketing each
scanf/printf call.  For instance a plot command like
	plot 'foo' using 1:2:(sprintf(format,column(3))) with labels
will be mixing scanf and sprintf during the parsing of every data line.

Could be done, but I can already here the screams about the performance
hit :-)

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

RE: wxwidgets terminal

[Nigel N. <nN...@au...>]

DQpIaSBUaW1vdGhlZSwgUGV0ciwgSGFucy1CZXJuaGFyZCwNCg0KPiBUaGUgYXR0cmFjdGl2ZW5l
c3Mgb2YgdGhlIHd4IHdpZGdldCBpcyB0aGF0IGlzIE5PVCBHUEwsIHRodXMgaXQgDQo+IGNhbiBi
ZSB1c2VkIGluIG9wZW4gc291cmNlIGFzIHdlbGwgYXMgZm9yIGNvbW1lcmNpYWwgYXBwbGljYXRp
b25zLg0KDQpJIGRpZCBhIHd4R251cGxvdCBjbGFzcyBpbnNpZGUgYSB0aHJlYWRlZCBDKysgd3hT
aW11bGF0b3IsIHdpdGggYQ0KInd4VGVybSIgcHJvdmlkaW5nIHRoZSBmYW1pbGlhciBnbnVwbG90
IGNvbW1hbmQgbGluZTsgd29ya2VkIGZpbmUuDQpPbmx5IHNpZ25pZmljYW50IHByb2JsZW0gd2Fz
IHRoYXQgYSBzaW11bGF0b3IgY2FuIHJlYWxseSBvbmx5IGhhdmUgDQphIHNpbmdsZSBhY3RpdmUg
cGxvdCwgc2luY2Ugc29tZSBvZiB0aGUgY29yZSBnbnVwbG90IGRhdGEgaXMgc3RpbGwNCmdsb2Jh
bC4gIElmIHRoZXNlIHdlcmUgd3JhcHBlZCBpbiBhIHN0cnVjdCwgZWFjaCBwbG90IGNvdWxkIGhh
dmUgDQppdHMgb3duIGdudXBsb3QgImRhdGEgc3RydWN0IiwgYW5kIHdlIGNvdWxkIHN0ZWVyIGFu
eSBudW1iZXIgb2YgDQp3eEdudXBsb3QgcGFuZWxzLiAgVGltLCBzb3VuZHMgbGlrZSBhIHdvcnRo
d2hpbGUgcHJvamVjdC4NCg0KTmlnZWwNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyAN
ClRoaXMgbWVzc2FnZSBpcyBpbnRlbmRlZCBmb3IgdGhlIGFkZHJlc3NlZSBuYW1lZCBhbmQgbWF5
IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCANCnByaXZpbGVnZWQgaW5mb3JtYXRpb24uIElmIHlv
dSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgcGxlYXNlIG5vdGUgdGhhdCANCmFueSBm
b3JtIG9mIGRpc3RyaWJ1dGlvbiwgY29weWluZyBvciB1c2Ugb2YgdGhpcyBjb21tdW5pY2F0aW9u
IG9yIHRoZSBpbmZvcm1hdGlvbiANCmluIGl0IGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1h
eSBiZSB1bmxhd2Z1bC4gSWYgeW91IHJlY2VpdmUgdGhpcyBtZXNzYWdlIGluIGVycm9yLCANCnBs
ZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB0aGUgc2VuZGVyLiAgDQpLZWVwIHVwIHRvIGRhdGUg
d2l0aCB3aGF0J3MgaGFwcGVuaW5nIGluIEF1c3RyYWxpYW4gc3BvcnQuIFZpc2l0IHd3dy5hdXNw
b3J0Lmdvdi5hdSANCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg==

Re: gnuplot slow on BIG files

[Robert H. <en...@no...>]

> I propose that our guiding principle should be:
> 
>  Support for obsolete platforms will be frozen at the last
>  gnuplot release for which there was evidence of an active user
>  community. People running archaic hardware should not be surprised
>  if they have to run less than state-of-the-art software on it.
> 

s/evidence of an active user community/a developer/ ?

I think that every additional platform adds a "cost" to the maintenance
and development of gnuplot. For many platforms that cost is low -
perhaps a few tweaks to Makefiles etc., or a platform specific terminal
driver that otherwise doesn't get in anybody's way.

How many of the #ifdef'ed features are "optional" because of lack of
support on various platforms, and how many because they are considered
"experimental"?

egrep -h "#if[n]{0,1}def" `find . -name "*.[ch]"` | sed -e
"s/#ifn*def//" -e "s/\/\*.*//" | sort | uniq -c | sort -n

I imagine there are quite a few cases which do not see any testing...

Rob

-- 
Robert Hart <en...@no...>
University of Nottingham


This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Re: gnuplot slow on BIG files

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

> (Sorry, Petr, but one person doesn't make a community for OS/2).

Because the gnuplot for OS/2 is working well :-) There are 3 active people.
Actually, I have some fresh patches to apply.

---
PM

Re: gnuplot slow on BIG files

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

Ethan Merritt wrote:
> On Saturday 11 June 2005 03:53 am, Robert Hart wrote:

>>You seem to be implying that we shouldn't be making any kinds of changes
>>to the core of gnuplot without being sure they will work on all of the
>>platforms that gnuplot has *historically* supported.

> We dropped support of 16-bit DOS when we released version 4.0.

Out of nothing but pure necessity combined with lack of user interest.
Since then, I've made progress in reviving it.  It takes some drastic 
measures to get there, though: not only will the postscript text blocks 
have to be moved to separate files, but I'd actually have to split 
graphics.c in half, because that module in itself is too large to be 
compiled on 16-bit platforms already.

> Furthermore, we knew how to fix the build problems but chose not to.

We knew how to fix some of them, not all.

> Let's also issue a call to any Amiga users, and if none turn up
> let's remove all the special casing for Amiga as well.

Careful what you ask for, there --- the chief proponent of Amiga has 
been Lars. ;-)

>  Support for obsolete platforms will be frozen at the last
>  gnuplot release for which there was evidence of an active user
>  community. People running archaic hardware should not be surprised
>  if they have to run less than state-of-the-art software on it.

"evidence of an active user community" would be a *very* strict 
criterion.  By that count, we'ld not be supporting anything but Linux, 
Windows and maybe MacOS X.  (Sorry, Petr, but one person doesn't make a 
community for OS/2).

> At worst that would fail to handle the Fortran D/Q format
> case.  This also is clearly an OS bug, and not something we
> should have to code around.

Actually, it's *exactly* the OS bugs we have to code around.  All other 
bugs can reasonably be avoided by asking people to upgrade some tool, 
library or whatnot, or maybe by replacing buggy OS-supplied tools by 
free replacements.  But neither we nor the typical user is in a position 
to upgrade an OS just to be able to run gnuplot on it.

Re: [ gnuplot-Bugs-1217701 ] Locale settings not initialized properly

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

Ethan Merritt wrote:

> I was under the impression that there is no way of separating the locale
> used for input (e.g. scanf) from the locale used for output (e.g. printf).
> Do you know otherwise?

Well, we know when we're doing what, so we could conceivably switch 
between the two at the correct times during the process.  Worst thing 
that could happen is slightly unexpected error messages in input locale 
rather than output locale, if they are printed during datafile reading.

Re: wxwidgets terminal

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

> Somebody else had the same idea recently.  But there's a significant
> obstacle, esp. in the way you plan on doing it: licensing.  wxwidgets is
> GPLed, gnuplot's license is deemed not sufficiently compatible with GPL
> to allow linking GPLed libraries into it.  At least not in distributed
> binaries, by the interpretation of the legalese as seen by the Debian team.

The attractiveness of the wx widget is that is NOT GPL, thus it can be used
in open source as well as for commercial applications.

> Not really.  At least the actual terminal API functions (i.e. those that

The question is whether the terminal should be managed via pipes (as X11 or
OS/2), i.e. an independent executable, or to be linked with gnuplot itself
(like Windows).

---
PM

Re: gnuplot slow on BIG files

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

On Saturday 11 June 2005 03:53 am, Robert Hart wrote:
> You seem to be implying that we shouldn't be making any kinds of changes
> to the core of gnuplot without being sure they will work on all of the
> platforms that gnuplot has *historically* supported.

We dropped support of 16-bit DOS when we released version 4.0.
And that's an OS that everyone has heard of, and many of us probably
still have distro floppies for it gathering dust in a file drawer.
Furthermore, we knew how to fix the build problems but chose not to.

I have no problem with that; I think dropping it was the right thing
to do.  But then why go even one step out of our way to avoid maybe,
possibly, triggering a bug on a totally obscure OS that no-one has
heard of?  It's absurd!  If OSK or some other relic of an OS has a bug
in a system library, let someone who cares about that OS fix it.

Robert hit the nail on the head when he quoted the recent article
on "the burden of (extreme) minority architectures on open source
software".  I regret even wasting the time it took to track down
the fact that this bug probably disappeared when gcc/glibc was ported
to OSK *eleven years ago*! If someone is still using a pre-1994 buggy
libc on OSK, too bad for them.

Let's drop any special-casing for OSK right now.

Let's also issue a call to any Amiga users, and if none turn up
let's remove all the special casing for Amiga as well.

I'd be willing to bet that the Next/OpenStep special-case
PostScript drivers are no longer worth keeping either, in the sense
that they don't support the features added since version 3.7 so
it would be pointless for anyone using them to upgrade to a newer
gnuplot.

I propose that our guiding principle should be:

 Support for obsolete platforms will be frozen at the last
 gnuplot release for which there was evidence of an active user
 community. People running archaic hardware should not be surprised
 if they have to run less than state-of-the-art software on it.

> The fact is:
> a) we've checked this on all the platforms we have access to.

Err. That's not quite true.  I checked half a dozen platforms,
but I could double or triple that if it were strictly necessary.
And I did so before the 4.0 release, at least to the extent of
building from source and running "make check".

> FYI: Known strtod bugs, I can find:
>
> On mac OSX, "NaN" is not recognised.

We test for it elsewhere, so I don't think this would affect us.
But that is clearly an OSX bug.  Let them fix it.

> Under Solaris 2.4, strtod returns the wrong value for the
> terminating character under some conditions.

At worst that would fail to handle the Fortran D/Q format
case.  This also is clearly an OS bug, and not something we
should have to code around.

> Also, on Compaq's Tru64 Unix 5.0,
> strtod(" ") returns 0.0 instead of a failure to convert.

That could, indeed, have been a problem. On the other hand, the 
existing non-scanf code paths in datafile.c strip away leading whitespace
so it would not in fact have bitten us.  Anyhow, it seems to have been
fixed, or at least my lab machines running Tru64 do not behave that way.

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

Re: [ gnuplot-Bugs-1217701 ] Locale settings not initialized properly

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

On Saturday 11 June 2005 02:41 am, SourceForge.net wrote:
> >Comment By: Hans-Bernhard Broeker (broeker)
>
> I.e. we need a new command
>
>   set locale {input|output|both} <locale_name>
>
> (or equivalent additions to 'set style data' and 'set
> format'), and maybe even a per-file handling option in
> {s}plot to override this.

I was under the impression that there is no way of separating the locale
used for input (e.g. scanf) from the locale used for output (e.g. printf).
Do you know otherwise?

As to "set locale xx_YY.ZZ", we could create such a command easily.
But the documentation must be as clear as possible that such a command
will only *work* if the appropriate locale is already installed on the 
user's machine.

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

Re: wxwidgets terminal

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

Hans-Bernhard Broeker wrote:

> Timoth=C3=A9e Lecomte wrote:
>
>> Oh no ! I was aware of the non-GPL licence of gnuplot, but I have not=20
>> taken it into account when thinking of a wxwidgets terminal. So is=20
>> there any hope to use one of these wonderful gui toolkits like=20
>> wxwidgets, gtk, qt, etc. as terminals?
>
>
> I'm afraid not without violating either gnuplot's license or the GPL,=20
> as they both currently are.
>
A precision : wxwidgets is LGPL, not GPL. I'm not completely sure, but=20
it seems that it solves the license problem. Can you confirm by reading=20
the LGPL ? Here follows the piece of the license which is important :




*"6.* As an exception to the Sections above, you may also combine or=20
link a "work that uses the Library" [ A program that contains no=20
derivative of any portion of the Library, but is designed to work with=20
the Library by being compiled or linked with it ] with the Library to=20
produce a work containing portions of the Library, and distribute that=20
work under terms of your choice, provided that the terms permit=20
modification of the work for the customer's own use and reverse=20
engineering for debugging such modifications.

You must give prominent notice with each copy of the work that the=20
Library is used in it and that the Library and its use are covered by=20
this License. You must supply a copy of this License. If the work during=20
execution displays copyright notices, you must include the copyright=20
notice for the Library among them, as well as a reference directing the=20
user to the copy of this License. Also, you must do one of these things:

    * *a)* Accompany the work with the complete corresponding
      machine-readable source code for the Library including whatever
      changes were used in the work (which must be distributed under
      Sections 1 and 2 above); and, if the work is an executable linked
      with the Library, with the complete machine-readable "work that
      uses the Library", as object code and/or source code, so that the
      user can modify the Library and then relink to produce a modified
      executable containing the modified Library. (It is understood that
      the user who changes the contents of definitions files in the
      Library will not necessarily be able to recompile the application
      to use the modified definitions.)
    * *b)* Use a suitable shared library mechanism for linking with the
      Library. A suitable mechanism is one that (1) uses at run time a
      copy of the library already present on the user's computer system,
      rather than copying library functions into the executable, and (2)
      will operate properly with a modified version of the library, if
      the user installs one, as long as the modified version is
      interface-compatible with the version that the work was made with.
    * *c)* Accompany the work with a written offer, valid for at least
      three years, to give the same user the materials specified in
      Subsection 6a, above, for a charge no more than the cost of
      performing this distribution.
    * *d)* If distribution of the work is made by offering access to
      copy from a designated place, offer equivalent access to copy the
      above specified materials from the same place.
    * *e)* Verify that the user has already received a copy of these
      materials or that you have already sent this user a copy.

For an executable, the required form of the "work that uses the Library"=20
must include any data and utility programs needed for reproducing the=20
executable from it. However, as a special exception, the materials to be=20
distributed need not include anything that is normally distributed (in=20
either source or binary form) with the major components (compiler,=20
kernel, and so on) of the operating system on which the executable runs,=20
unless that component itself accompanies the executable.

It may happen that this requirement contradicts the license restrictions=20
of other proprietary libraries that do not normally accompany the=20
operating system. Such a contradiction means you cannot use both them=20
and the Library together in an executable that you distribute."



So it is possible to write a terminal which uses wxwidgets, as gnuplot=20
is open-source (although it's not gpl). We just have to notice in the=20
code that this LGPL library is used.

What do you think of it ?

Timoth=C3=A9e Lecomte

Re: wxwidgets terminal

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

Ga=EBl Varoquaux wrote:

>     By the way, I think there should be an alias for the default platfo=
rm
> dependent interactive terminal. Say I want to code a script (Octave for=

> instance, but it could as well be Gnuplot) that work under various
> platforms and switches terminals. If I want to switch back to the
> platform specific interactive terminal, how do I call it ?

"poll", as in

	set term poll

You'll want to look up the docs to see what I mean ;-)

Re: wxwidgets terminal

[V. <gae...@no...>]

On Sun, Jun 12, 2005 at 01:53:42PM +0200, Hans-Bernhard Broeker wrote:
> Even the current mouse support is running into considerable problems=20
> with remote-controlled gnuplot sessions.  That's why it's kept disabled=
=20
> by default in such cases.  Having a single instance of gnuplot try to=20
> serve two independently acting masters (octave and a human being, e.g.)=
=20
> simultaneously has to cause trouble.

    That's why a dedicated terminal would be very usefull. However have a
cross platform interactive terminal probably means either using a
toolkit, which does not seem compatible with gnuplot's current licence (a
pity) or using a dedicated terminal for the platform, wich basically
means reusing the current existing interactive terminals.
   =20
    Maybe what we need is more a API for interactive terminals ?

    By the way, I think there should be an alias for the default platform
dependent interactive terminal. Say I want to code a script (Octave for
instance, but it could as well be Gnuplot) that work under various
platforms and switches terminals. If I want to switch back to the
platform specific interactive terminal, how do I call it ?

--
    Ga=EBl

Re: wxwidgets terminal

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

Timoth=C3=A9e Lecomte wrote:

> Oh no ! I was aware of the non-GPL licence of gnuplot, but I have not=20
> taken it into account when thinking of a wxwidgets terminal. So is ther=
e=20
> any hope to use one of these wonderful gui toolkits like wxwidgets, gtk=
,=20
> qt, etc. as terminals?

I'm afraid not without violating either gnuplot's license or the GPL, as =

they both currently are.

> plot command with modified options. That's precisely what you've added =

> with the mouse support. I was dreaming of a terminal with other options=
=2E..

Even the current mouse support is running into considerable problems=20
with remote-controlled gnuplot sessions.  That's why it's kept disabled=20
by default in such cases.  Having a single instance of gnuplot try to=20
serve two independently acting masters (octave and a human being, e.g.)=20
simultaneously has to cause trouble.

Re: wxwidgets terminal

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

Hans-Bernhard Broeker wrote:

> Timoth=C3=A9e Lecomte wrote:
>
>> In order to make it more user friendly (but it already is, with a litt=
le
>> practice), I thought to write a terminal to wxwidgets=20
>> (hhtp://www.wxwidgets.org), a gui toolkit.=20
>
>
> Somebody else had the same idea recently.  But there's a significant=20
> obstacle, esp. in the way you plan on doing it: licensing.  wxwidgets=20
> is GPLed, gnuplot's license is deemed not sufficiently compatible with=20
> GPL to allow linking GPLed libraries into it.  At least not in=20
> distributed binaries, by the interpretation of the legalese as seen by=20
> the Debian team.

Oh no ! I was aware of the non-GPL licence of gnuplot, but I have not=20
taken it into account when thinking of a wxwidgets terminal. So is there=20
any hope to use one of these wonderful gui toolkits like wxwidgets, gtk,=20
qt, etc. as terminals ?

>
>> be something interesting to make 3rd-party software (like Octave,
>> or Maxima) reach a higher level of usablility.
>
>
> I don't think that adding a GUI to gnuplot will make it any more easy=20
> to use by external programs, who want to control gnuplot themselves,=20
> rather than let the user do it.  They already have enough control over=20
> gnuplot as it is --- the only major exception being that they can't=20
> swallow the gnuplot graph window into their own GUI yet, and that the=20
> Windows version offers no access to its command line output channel.

You're right when you say that external programs want first to control=20
gnuplot themselves. However, I think the user would be pleased to have a=20
little more interaction with the terminal without having to send a new=20
plot command with modified options. That's precisely what you've added=20
with the mouse support. I was dreaming of a terminal with other options...

In fact, I must admit that I had used gnuplot for months before=20
discovering the mouse support (in octave, it's not activated by default,=20
as explained in the gnuplot faq) ! That's why I want to design a more=20
intuitive terminal, regarding this point (toolbar, etc).

When reading the terminal readme and the corresponding API, I have been=20
impressed by its simplicity. As far as I understand, gnuplot owns an=20
entire abstract layer which give really simple drawing commands. It is=20
really ideal to use it with a gui library like wxwidgets.

>
>> But I have a question : wxwidgets is a library for C++, and gnuplot
>> is written in C. So, can I write a terminal for gnuplot in C++ ?
>
>
> Not really.  At least the actual terminal API functions (i.e. those=20
> that go into the termentry struct) have to be C functions, i.e. they=20
> have to be qualified 'extern "C"', in C++ terms.

It's precisely what I've learned on other pages. So the mix between C=20
and C++ should not be a problem, provided the extern "C" magic words.

> Trying to compile genuine, non-trivial C code with a C++ compiler is=20
> generally impossible, dangerous, or both.  It would cause a boatload=20
> of pain in the lower back to translate gnuplot to "C/C++", the strict=20
> common subset of both languages.

Ok, I understand.

I hope we could continue this discussion to find a solution, especially=20
about the license problem.

Timoth=C3=A9e Lecomte

Re: wxwidgets terminal

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

Timoth=C3=A9e Lecomte wrote:
> In order to make it more user friendly (but it already is, with a littl=
e
> practice), I thought to write a terminal to wxwidgets=20
> (hhtp://www.wxwidgets.org), a gui toolkit.=20

Somebody else had the same idea recently.  But there's a significant=20
obstacle, esp. in the way you plan on doing it: licensing.  wxwidgets is =

GPLed, gnuplot's license is deemed not sufficiently compatible with GPL=20
to allow linking GPLed libraries into it.  At least not in distributed=20
binaries, by the interpretation of the legalese as seen by the Debian tea=
m.

> be something interesting to make 3rd-party software (like Octave,
> or Maxima) reach a higher level of usablility.

I don't think that adding a GUI to gnuplot will make it any more easy to =

use by external programs, who want to control gnuplot themselves, rather =

than let the user do it.  They already have enough control over gnuplot=20
as it is --- the only major exception being that they can't swallow the=20
gnuplot graph window into their own GUI yet, and that the Windows=20
version offers no access to its command line output channel.

> But I have a question : wxwidgets is a library for C++, and gnuplot
> is written in C. So, can I write a terminal for gnuplot in C++ ?

Not really.  At least the actual terminal API functions (i.e. those that =

go into the termentry struct) have to be C functions, i.e. they have to=20
be qualified 'extern "C"', in C++ terms.

> Can gnuplot be compiled entirely with a C++ compiler (g++ in my
> case) ? Does somebody know a way to do it (I've not tried) ?

You certainly shouldn't have to do that, and no, it wouldn't work.
gnuplot is written in C. Trying to compile genuine, non-trivial C code=20
with a C++ compiler is generally impossible, dangerous, or both.  It=20
would cause a boatload of pain in the lower back to translate gnuplot to =

"C/C++", the strict common subset of both languages.

[In the interest of more fluent discussion, please subscribe to=20
gnuplot-beta if you're going to continue posting to it.]