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

[Fwd: Re: gnuplot numerical errors on Intel MacBook]

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

> >
> > Chris, is there a tgamma on your system?
>
> Yes, there is.  I am not entirely sure how to test it for correctness, but I
> managed to cobble it into the configure script to at least see if it was
> there.

OK, thanks.  You could attempt a patch but it probably is a bit tricky because it appears gnuplot's gamma is based off the log gamma function, not the true gamma function.  Although not too difficult, proper fix would require some extensive rearranging of defines and is better left to Ethan or Hans.

Attached is a quick hack to see if the tgamma() function might work for you.  This works for me.  By experimenting and changing the tgamma() to gamma() I see that, yes, gamma() on my system is actually log gamma.

Dan

Re: gnuplot numerical errors on Intel MacBook

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

Ethan Merritt wrote:
> On Monday 25 September 2006 01:08 pm, Hans-Bernhard Br=F6ker wrote:
>=20
>>CM wrote:
>>
>>>I suppose this means that the next question from gnuplot's side of
>>>things is "Should we fiddle with auto configuration to work around
>>>this?"
>>
>>No.  The next question from our side is: when will Apple fix this bug
>>in their implementation of gamma()?  Only if the answer to that is
>>something equivalent to "never" it makes sense to discuss
>>workarounds.
>=20
>=20
> Yes, but...
> The state of gamma function implementations has changed a bit since
> gnuplot was first designed.  Here is an excerpt from the current
> documentation:
>=20
> HISTORY
>   4.2BSD had a gamma() that computed ln(|Gamma(|x|)|), leaving  the  si=
gn
>   of  Gamma(|x|) in the external integer signgam.  In 4.3BSD the name w=
as
>   changed to lgamma(), and the man page promises
>      "At some time in the future the name gamma will be rehabilitated
>      and used for the Gamma function"
>   This  did  indeed  happen  in  4.4BSD, where gamma() computes the Gam=
ma
>   function (with no effect on signgam).  However, this came too late, a=
nd
>   we now have tgamma(), the "true gamma" function.
>=20
>=20
> The point being that since about 1999 many systems have had a third
> option, tgamma(), in addition to the gamma() and lgamma() functions
> that gnuplot's autoconfigure checks for.  The syntax and usage of
> tgamma(), if present, may be more reliable than those of gamma().

Oy, tgamma?  Well, it may make life simpler if tgamma is ubiquitous.  Her=
e is what I get on whatever is on FC3:

configure:7256: checking for gamma
[snip]
configure:7344: result: yes
configure:7256: checking for lgamma
[snip]
configure:7344: result: yes
configure:7256: checking for tgamma
[snip]
configure:7344: result: yes
configure:7256: checking for foogamma
[long snip]
configure:7344: result: no

Chris, is there a tgamma on your system?

Dan

Re: gnuplot numerical errors on Intel MacBook

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

On Monday 25 September 2006 01:08 pm, Hans-Bernhard Br=F6ker wrote:
> CM wrote:
> > I suppose this means that the next question from gnuplot's side of
> > things is "Should we fiddle with auto configuration to work around
> > this?"
>
> No.  The next question from our side is: when will Apple fix this bug
> in their implementation of gamma()?  Only if the answer to that is
> something equivalent to "never" it makes sense to discuss
> workarounds.

Yes, but...
The state of gamma function implementations has changed a bit since
gnuplot was first designed.  Here is an excerpt from the current
documentation:

HISTORY
  4.2BSD had a gamma() that computed ln(|Gamma(|x|)|), leaving  the  sign
  of  Gamma(|x|) in the external integer signgam.  In 4.3BSD the name was
  changed to lgamma(), and the man page promises
     "At some time in the future the name gamma will be rehabilitated
     and used for the Gamma function"
  This  did  indeed  happen  in  4.4BSD, where gamma() computes the Gamma
  function (with no effect on signgam).  However, this came too late, and
  we now have tgamma(), the "true gamma" function.


The point being that since about 1999 many systems have had a third
option, tgamma(), in addition to the gamma() and lgamma() functions
that gnuplot's autoconfigure checks for.  The syntax and usage of
tgamma(), if present, may be more reliable than those of gamma().


=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: gnuplot numerical errors on Intel MacBook

[<br...@ph...>]

CM wrote:
> I suppose this means that the next question from gnuplot's side of 
> things is "Should we fiddle with auto configuration to work around this?"

No.  The next question from our side is: when will Apple fix this bug
in their implementation of gamma()?  Only if the answer to that is 
something equivalent to "never" it makes sense to discuss workarounds.

Re: Mirroring of binaries, was: New German gnuplot-book available

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

>>  	http://gnuplot.sourceforge.net/help.html
>> ... to be mirrored by gnuplot.info soon.
>
> Have you ever noticed, that the binaries of 4.1 are different on
> http://gnuplot.info/development/binaries/ and
> http://gnuplot.sourceforge.net/development/binaries/?
>
> Sometime ago it took me several time to find the newest binaries (again)
> until I saw that there was a difference between the two locations...

You are right, those directories differ, I haven't noticed that. Thus, could 
the maintainer of the mirroring fix this problem?

---
PM

Re: gnuplot, wxWidgets and distributions

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

Timoth=E9e Lecomte wrote:
> Petr Mikulik wrote:
>  =20
>> Does it now work in Wine?
>>  =20
>>    =20
> I have not tried for a while. I remember reading that gtk apps don't=20
> work with wine (see http://bugs.winehq.org/show_bug.cgi?id=3D3915 for=20
> example). It may be from the same kind of reason.

Hey, I also just realized I was using pango 1.10.2 that has problems as=20
we recently noticed with Richard Henwood. I should try again with 1.10.3=20
on Windows.

Timoth=E9e

Re: gnuplot numerical errors on Intel MacBook

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

Joe Koski wrote:

> My total knowledge of this subject consists of owning a copy of Abramowitz
> and Stegun, so please excuse me it the following is a red herring.
> 
> On his daily blog on the g95 website, g95.sourceforge.net, Andy Vaught wrote
> =====================
> September 6
> Bill McKie pointed out that x86/OSX wasn't trapping overflows during real
> exponentiation. It turns out that OSX uses the MMX unit to do exponentiation
> instead of the x87. So I added code to set the bits for MMX traps. Not only
> does the MMX exponentiation use about six times the code that the x87 uses,
> but it turns out that OSX doesn't handle traps from the MMX unit correctly
> either, reporting only a generic floating point exception. To add insult to
> injury, it takes about 3/4 of second (!) to process a floating point
> exception on OSX, be it x86 or powerpc.
> 
> September 13
> The origin of this problem was detecting overflow during exponentiation on
> OSX/386, which uses the SSE unit to do the math. I ran a speed test
> comparing exponentiation using the SSE unit with x87, and the x87 is 25%
> faster, and delivers a more accurate result because the intermediate
> quantities are carried to 64 bits in the mantissa. So the solution is not to
> bend over backwards for the SSE unit, but rather use the x87 for
> exponentiation where it is available.
> =====================

Wonder why they would choose that?  The extra instructions to set up the MMX registers only pays off, I think, when one actually uses the multiple registers.  For a single computation, the more general and common approach would be better...  They aren't expecting an MMX version of gnuplot, I hope.  ;-)

Dan

Re: gnuplot numerical errors on Intel MacBook

[Joe K. <jko...@co...>]

on 9/24/06 5:23 PM, Hans-Bernhard Br=F6ker at br...@ph...
wrote:

> CM wrote:
>=20
>> configure:8573: checking whether signgam is declared
>> configure:8607: gcc -c -g -O2   -I/usr/X11R6/include conftest.c >&5
>> configure:8613: $? =3D 0
>> configure:8620: test -z "$ac_c_werror_flag" || test ! -s conftest.err
>> configure:8623: $? =3D 0
>> configure:8630: test -s conftest.o
>> configure:8633: $? =3D 0
>> configure:8645: result: yes
>>=20
>> Is this what you expected?
>=20
> Not really.  What this set of observations means is that the signgam
> aspect of the gamma() implementation on Intel Macs is rather
> interestingly broken.  That's about as far as gnuplot's end of the
> problem can be traced.  For the rest you'll have to bring this to the
> attention of Mac experts, or maybe Apple themselves.  It might be some
> unwanted side effect of someone's try to make gamma() thread-safe.
>=20
My total knowledge of this subject consists of owning a copy of Abramowitz
and Stegun, so please excuse me it the following is a red herring.

On his daily blog on the g95 website, g95.sourceforge.net, Andy Vaught wrot=
e
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
September 6
Bill McKie pointed out that x86/OSX wasn't trapping overflows during real
exponentiation. It turns out that OSX uses the MMX unit to do exponentiatio=
n
instead of the x87. So I added code to set the bits for MMX traps. Not only
does the MMX exponentiation use about six times the code that the x87 uses,
but it turns out that OSX doesn't handle traps from the MMX unit correctly
either, reporting only a generic floating point exception. To add insult to
injury, it takes about 3/4 of second (!) to process a floating point
exception on OSX, be it x86 or powerpc.

September 13
The origin of this problem was detecting overflow during exponentiation on
OSX/386, which uses the SSE unit to do the math. I ran a speed test
comparing exponentiation using the SSE unit with x87, and the x87 is 25%
faster, and delivers a more accurate result because the intermediate
quantities are carried to 64 bits in the mantissa. So the solution is not t=
o
bend over backwards for the SSE unit, but rather use the x87 for
exponentiation where it is available.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
So the Intel Mac does math somewhat differently than its Windows cousins.
This may or may not be relevant here, but I just thought I'd point it out.

Joe

Re: gnuplot numerical errors on Intel MacBook

[CM <mon...@gm...>]

I suppose this means that the next question from gnuplot's side of things i=
s
"Should we fiddle with auto configuration to work around this?"

On 9/24/06, Hans-Bernhard Br=F6ker <br...@ph...> wrote:
>
> CM wrote:
>
> > configure:8573: checking whether signgam is declared
> > configure:8607: gcc -c -g -O2   -I/usr/X11R6/include conftest.c >&5
> > configure:8613: $? =3D 0
> > configure:8620: test -z "$ac_c_werror_flag" || test ! -s conftest.err
> > configure:8623: $? =3D 0
> > configure:8630: test -s conftest.o
> > configure:8633: $? =3D 0
> > configure:8645: result: yes
> >
> > Is this what you expected?
>
> Not really.  What this set of observations means is that the signgam
> aspect of the gamma() implementation on Intel Macs is rather
> interestingly broken.  That's about as far as gnuplot's end of the
> problem can be traced.  For the rest you'll have to bring this to the
> attention of Mac experts, or maybe Apple themselves.  It might be some
> unwanted side effect of someone's try to make gamma() thread-safe.
>
>
>
>


--=20
:(){ :|:&};:

Re: gnuplot numerical errors on Intel MacBook

[<br...@ph...>]

CM wrote:

> configure:8573: checking whether signgam is declared
> configure:8607: gcc -c -g -O2   -I/usr/X11R6/include conftest.c >&5
> configure:8613: $? = 0
> configure:8620: test -z "$ac_c_werror_flag" || test ! -s conftest.err
> configure:8623: $? = 0
> configure:8630: test -s conftest.o
> configure:8633: $? = 0
> configure:8645: result: yes
> 
> Is this what you expected?

Not really.  What this set of observations means is that the signgam 
aspect of the gamma() implementation on Intel Macs is rather 
interestingly broken.  That's about as far as gnuplot's end of the 
problem can be traced.  For the rest you'll have to bring this to the 
attention of Mac experts, or maybe Apple themselves.  It might be some 
unwanted side effect of someone's try to make gamma() thread-safe.

Re: gnuplot numerical errors on Intel MacBook

[CM <mon...@gm...>]

On 9/24/06, Hans-Bernhard Br=F6ker <br...@ph...> wrote:
>
> CM wrote:
>
> > No, that's not what I'm seeing.  I'm seeing a graph with dotted lines
> > but no function output.  I have posted one more picture, this time the
> > result of running
> >
> > plot [1:2] gamma(x)
> >
> > It's rather interesting, and I'm afraid not terribly enlightening.
>
> Actually, it is.  It matches my original guess perfectly.  It shows
> exactly what you would get if signgam is random garbage, which just so
> happens to equal -5.58e8.  This is because the implementation of the
> user-visible function gamma() is internally:
>
>         double gamma(gamma x) {
>              return exp(GAMMA(x)) * signgam;
>          }
>
> [see specfun.c:f_gamma()], where GAMMA is either lgamma(), gamma(), or
> gnuplot's own lngamma(), depending on availability.  The correct values
> of gamma(1) and gamma(2) are 1.0, yours are -5.58e08, but other than
> that, the shape is quite right.  I get exactly your plot, but for
>
>       plot [1:2] -5.58e8*gamma(x)
>
> Please check your config.log's lines about signgam.



configure:8573: checking whether signgam is declared
configure:8607: gcc -c -g -O2   -I/usr/X11R6/include conftest.c >&5
configure:8613: $? =3D 0
configure:8620: test -z "$ac_c_werror_flag" || test ! -s conftest.err
configure:8623: $? =3D 0
configure:8630: test -s conftest.o
configure:8633: $? =3D 0
configure:8645: result: yes

Is this what you expected?

The true test would be that while gamma() is wrong, lgamma() plots
> correctly.


Aha.  Yes.  lgamma does, in fact, do the right thing.

- C

Re: gnuplot, wxWidgets and distributions

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

Petr Mikulik wrote:
>>>>>> - write a plugin interface to gnuplot, so that the wxWidgets is
>>>>>> dynamically loadable and can be distributed separately
>>>>>>            =20
>>>>> That would be the best.
>>>>>
>>>>>          =20
>>>> Technically the best, but arguably not for the user, since he would =
have=20
>>>> to find it in the distribution package manager...
>>>>        =20
>>> If the plugin finds wxWidgets missing, it can show an appropriate hin=
t what=20
>>> to install in addition.
>>>      =20
>> I think that such a static message will soon be considered annoying.
>>    =20
>
> I don't think so. User will either install those libs, or stop using=20
> "set term wx".
>  =20
Oh, so you say the wxWidgets terminal should always be listed in 'set=20
term', but show a message when the plugin is not found ?
>
>  =20
>>> How to package wxgnuplot.exe (?) for Windows? I guess it will be ship=
ped=20
>>> with the necessary libs, thus in a separate package gp420win32wx.zip =
(?).
>>>      =20
>> wgnuplot.exe can be compiled with wxWidgets support, and we'll have to=
 ship=20
>> the necessary dlls (cairo, pango, freetype) with it.
>>    =20
>
> What is the current status on running it on different Windows versions?
>  =20
I don't know since I only have Windows XP on my machine. I hope it is ok=20
since the whole Windows concept is binary compatibility.
> Does it now work in Wine?
>  =20
I have not tried for a while. I remember reading that gtk apps don't=20
work with wine (see http://bugs.winehq.org/show_bug.cgi?id=3D3915 for=20
example). It may be from the same kind of reason.

> What happens if those additional dll's are missing (user copied only=20
> wgnuplot.exe)?
>  =20

Right now, wgnuplot.exe refuses to start with a nice warning=20
"libsomething.dll is missing".

Best regards,

Timoth=E9e

Re: gnuplot numerical errors on Intel MacBook

[<br...@ph...>]

CM wrote:

> No, that's not what I'm seeing.  I'm seeing a graph with dotted lines 
> but no function output.  I have posted one more picture, this time the 
> result of running
> 
> plot [1:2] gamma(x)
> 
> It's rather interesting, and I'm afraid not terribly enlightening.

Actually, it is.  It matches my original guess perfectly.  It shows
exactly what you would get if signgam is random garbage, which just so 
happens to equal -5.58e8.  This is because the implementation of the 
user-visible function gamma() is internally:

	double gamma(gamma x) {
             return exp(GAMMA(x)) * signgam;
         }

[see specfun.c:f_gamma()], where GAMMA is either lgamma(), gamma(), or 
gnuplot's own lngamma(), depending on availability.  The correct values 
of gamma(1) and gamma(2) are 1.0, yours are -5.58e08, but other than 
that, the shape is quite right.  I get exactly your plot, but for

      plot [1:2] -5.58e8*gamma(x)

Please check your config.log's lines about signgam.

The true test would be that while gamma() is wrong, lgamma() plots 
correctly.

Re: gnuplot numerical errors on Intel MacBook

[CM <mon...@gm...>]

On 9/24/06, Ethan A Merritt <merritt@u.washington.edu> wrote:
>
> On Saturday 23 September 2006 11:12 pm, CM wrote:
> > Also please look in the file config.h created while preparing
> > > the cvs distribution and tell us whether HAVE_LGAMMA is defined or
> > > commented out.
> >
> > HAVE_LGAMMA is defined to be 1, not commented out.
>
> Hmm. Well, you can probably get a working gamma function by
> replacing this line with
>   #undef HAVE_LGAMMA
>   #undef HAVE_GAMMA
> and then rebuilding the program. (Do not re-run ./configure)


 Yay!  It *mostly* works, now.  It seems to be plotting the right function,
but emits the error message:

lngamma singularity error

Unfortunately, that won't help us figure out what is
> going wrong with the normal configure+build process.
>
> I've CC'ed this to Per Persson, who is our Mac expert.
> This is a PPC MacBook?


No, it's an Intel machine.  (As far as I know, it is universally true that
PowerBook == PPC and MacBook == Intel).

Let me know what I can do to help.


> Has anyone seen numerical errors on the MacBook line of computers?  I have
> > tried both gnuplot 4.0 and 4.1 (compiled from source, not the mac
> package),
> > and in each case the result of
>
> > plot gamma(x)
>
> > is very, very wrong.  Has anyone else seen this?  I searched the
> archives
> > for this list and didn't see anything relevant.
>
>
>
> --
> Ethan A Merritt
> Biomolecular Structure Center
> University of Washington, Seattle 98195-7742
>



-- 
:(){ :|:&};:

Re: gnuplot, wxWidgets and distributions

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

Ethan A Merritt wrote:
> On Sunday 24 September 2006 11:48 am, Timoth=E9e Lecomte wrote:
>  =20
>>>> - write a plugin interface to gnuplot, so that the wxWidgets is
>>>> dynamically loadable and can be distributed separately
>>>>        =20
>>> That would be the best.
>>>  =20
>>>      =20
>> Technically the best, but arguably not for the user, since he would ha=
ve=20
>> to find it in the distribution package manager...
>>    =20
>
> I don't think that by itself is a problem. People are used to downloadi=
ng
> and installing extension plugins for their web browser, video/audio plu=
gins
> for their media player, filter plugins for their word processor, etc.
> They should be able to handle terminal plugins for gnuplot.
>  =20

Of course, they can, but do they really want ? When you want to do=20
scientific work, you already spend so much time learning languages for=20
computation purposes (whether it is C, C++, Fortran, Python, Octave or=20
whatever) that you are pleased when something works directly. There are=20
few exceptions. The best program is the one that gives 90% of its full=20
power with the default installation.

Octave people are currently implementing a "package manager", because=20
they have so many additional and less tested code in Octave Forge that=20
they need a plugin system to make them easily available.

Firefox as a browser made part of its success with the extensions, but=20
it's because they have a well-thought distribution system for them,=20
because the original application is very good, and because the community=20
is vary active writing those extensions. Ultimately, interesting=20
extensions are cleaned/rewritten and integrated.

That's not really the case for gnuplot. We are currently discussing=20
plugins because of dependencies issues. vlc (a media player) is another=20
example of application based on plugins, and like gnuplot it is to make=20
backend support more flexible. The main one is in wxWidgets by the way.=20
But even if the app is architectured around these plugins, in practise=20
it is simply distributed with the few main backends and that's all.

In our case, I do think wxWidgets is a well-thought dependency. Gtk=20
would have been a good choice too, though, and has the big advantage to=20
be very widely distributed on Linux. That's why I was offering to work=20
on that if needed.

If we choose to implement plugins, we should provide distribution=20
guidelines. For example, we can encourage distributions to install by=20
default the full package, but to allow (if they want) the user to=20
install stripped-down versions. That's what Debian is is doing right=20
now: there's one package with the x11 binary (gnuplot-x11) and one with=20
the gnuplot binary (gnuplot-nox), but the default 'gnuplot' package just=20
installs the two of them. Somebody who only wants the core can install=20
gnuplot-nox manually.

Maybe we can satisfy Fedora that way, maybe not. I'm quite sure the=20
trend is not to multiply packages. And I would like to see full packages=20
distributed anyway.

> I think the bigger hurdle is portability.  Implementing a plugin system
> for linux would be easy.  But we'd have to do it all over again for=20
> Solaris, OSF, Irix, Windows, OSX, etc.  Or perhaps there is a=20
> multi-platform plugin infrastructure that I am unaware of?
>  =20

 From the GModule documentation in GLib=20
(http://developer.gnome.org/doc/API/2.0/glib/glib-Dynamic-Loading-of-Modu=
les.html):

"These functions provide a portable way to dynamically load object files=20
(commonly known as 'plug-ins'). The current implementation supports all=20
systems that provide an implementation of ||dlopen()|| (e.g. Linux/Sun),=20
as well as HP-UX via its ||shl_load()|| mechanism, and Windows platforms=20
via DLLs."

(OSX is just another Unix)

If we had to choose a general-purpose library to depend on, I think GLib=20
would be the best choice (then we also get a lot of other useful=20
cross-platform functions, such as threads).

> We discussed this issue briefly quite a while ago, with regard to patch
> #588805  	  external functions via plugins
>
> I like the idea of plugins, but implementation is non-trivial.
>  =20

Non-trivial, but it can be done cleanly with GLib. See=20
http://blog.eikke.com/index.php/ikke/2005/05/18/gmodules_are_fun for an=20
example.

>
> However, ...
> I can think of one more alternative.  If the wxt terminal code were
> broken out into a separate executable, equivalent to gnuplot_x11,=20
> then the core gnuplot binary would not need to be linked against
> pango/cairo/wxWidgets.   The extreme case of this would be=20
> teaching the wxt code to understand the same piped binary stream
> format that goes between gnuplot <---> gnuplot_x11.  Then we'd
> have a binary pipe API shared by multiple terminal types.
> The library dependencies would not pertain to the core gnuplot
> binary, only to the parallel helper programs.
>  =20

Pipes are probably as specific to the platforms as dynamic libraries=20
are. Moreover, they add an additional bottleneck (not that big if the=20
protocal is binary, I admit). Plugins are probably better. If we decide=20
to implement plugins, the x11 terminal could be a plugin without the=20
need to use pipes...

Anyway, although I see clearly the technical aspects, I'm still as much=20
puzzled about the _choices_ that we should make. Plugins or not ?
(if you have other reasons besides distributions concerns, please speak=20
up !)

Maybe the best is to see how the current implementation choice is=20
handled by distributions. Let's release 4.2 as it is, and give some time=20
to see what distributions do with it. If there's something wrong (if the=20
wxWidgets terminal is _never_ used for example), then we can still=20
address it later. The world won't crash because of it.

Best regards,

Timoth=E9e

Re: gnuplot numerical errors on Intel MacBook

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

On Saturday 23 September 2006 11:12 pm, CM wrote:
> Also please look in the file config.h created while preparing
> > the cvs distribution and tell us whether HAVE_LGAMMA is defined or
> > commented out.
> 
> HAVE_LGAMMA is defined to be 1, not commented out.

Hmm. Well, you can probably get a working gamma function by 
replacing this line with
  #undef HAVE_LGAMMA
  #undef HAVE_GAMMA
and then rebuilding the program. (Do not re-run ./configure)

Unfortunately, that won't help us figure out what is
going wrong with the normal configure+build process.

I've CC'ed this to Per Persson, who is our Mac expert.
This is a PPC MacBook?
 
> Has anyone seen numerical errors on the MacBook line of computers?  I have
> tried both gnuplot 4.0 and 4.1 (compiled from source, not the mac package),
> and in each case the result of

> plot gamma(x)

> is very, very wrong.  Has anyone else seen this?  I searched the archives
> for this list and didn't see anything relevant.



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

Re: gnuplot, wxWidgets and distributions

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

On Sunday 24 September 2006 11:48 am, Timoth=E9e Lecomte wrote:
> >> - write a plugin interface to gnuplot, so that the wxWidgets is
> >> dynamically loadable and can be distributed separately
> >
> > That would be the best.
> >  =20
> Technically the best, but arguably not for the user, since he would have=
=20
> to find it in the distribution package manager...

I don't think that by itself is a problem. People are used to downloading
and installing extension plugins for their web browser, video/audio plugins
for their media player, filter plugins for their word processor, etc.
They should be able to handle terminal plugins for gnuplot.

I think the bigger hurdle is portability.  Implementing a plugin system
for linux would be easy.  But we'd have to do it all over again for=20
Solaris, OSF, Irix, Windows, OSX, etc.  Or perhaps there is a=20
multi-platform plugin infrastructure that I am unaware of? =20

We discussed this issue briefly quite a while ago, with regard to patch
#588805  	  external functions via plugins

I like the idea of plugins, but implementation is non-trivial.


However, ...
I can think of one more alternative.  If the wxt terminal code were
broken out into a separate executable, equivalent to gnuplot_x11,=20
then the core gnuplot binary would not need to be linked against
pango/cairo/wxWidgets.   The extreme case of this would be=20
teaching the wxt code to understand the same piped binary stream
format that goes between gnuplot <---> gnuplot_x11.  Then we'd
have a binary pipe API shared by multiple terminal types.
The library dependencies would not pertain to the core gnuplot
binary, only to the parallel helper programs.




=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: gnuplot, wxWidgets and distributions

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

>>>>> - write a plugin interface to gnuplot, so that the wxWidgets is
>>>>> dynamically loadable and can be distributed separately
>>>> 
>>>> That would be the best.
>>>> 
>>> Technically the best, but arguably not for the user, since he would have 
>>> to find it in the distribution package manager...
>> 
>> If the plugin finds wxWidgets missing, it can show an appropriate hint what 
>> to install in addition.
>
> I think that such a static message will soon be considered annoying.

I don't think so. User will either install those libs, or stop using 
"set term wx".


>> How to package wxgnuplot.exe (?) for Windows? I guess it will be shipped 
>> with the necessary libs, thus in a separate package gp420win32wx.zip (?).
>
> wgnuplot.exe can be compiled with wxWidgets support, and we'll have to ship 
> the necessary dlls (cairo, pango, freetype) with it.

What is the current status on running it on different Windows versions?
Does it now work in Wine?

What happens if those additional dll's are missing (user copied only 
wgnuplot.exe)?


---
PM

Re: gnuplot, wxWidgets and distributions

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

Petr Mikulik wrote:
>>> Solution (for any distribution) is a package with just a binary=20
>>> called "wxgnuplot".
>>>
>> You mean "just a library". There's no such binary with the wxWidgets=20
>> terminal right now.
>
> wxgnuplot =3D gnuplot binary with wx terminal compiled in

Ok.

>
>>>> - write a plugin interface to gnuplot, so that the wxWidgets is
>>>> dynamically loadable and can be distributed separately
>>>
>>> That would be the best.
>>>
>> Technically the best, but arguably not for the user, since he would=20
>> have to find it in the distribution package manager...
>
> If the plugin finds wxWidgets missing, it can show an appropriate hint=20
> what to install in addition.

I think that such a static message will soon be considered annoying.

>
>
> Actually, we have similar problems on other platforms. On Windows,=20
> there are:
>     wgnuplot.exe
>     wgnuplot_pipes.exe
> in gp400win32.zip, and
>     gnuplot.exe
> gp400win32x11.zip.
>
> How to package wxgnuplot.exe (?) for Windows? I guess it will be=20
> shipped with the necessary libs, thus in a separate package=20
> gp420win32wx.zip (?).

wgnuplot.exe can be compiled with wxWidgets support, and we'll have to=20
ship the necessary dlls (cairo, pango, freetype) with it.

Best regards,

Timoth=E9e

Re: gnuplot, wxWidgets and distributions

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

>> Solution (for any distribution) is a package with just a binary called 
>> "wxgnuplot".
>> 
> You mean "just a library". There's no such binary with the wxWidgets terminal 
> right now.

wxgnuplot = gnuplot binary with wx terminal compiled in

>>> - write a plugin interface to gnuplot, so that the wxWidgets is
>>> dynamically loadable and can be distributed separately
>> 
>> That would be the best.
>> 
> Technically the best, but arguably not for the user, since he would have to 
> find it in the distribution package manager...

If the plugin finds wxWidgets missing, it can show an appropriate hint what 
to install in addition.


Actually, we have similar problems on other platforms. On Windows, there 
are:
 	wgnuplot.exe
 	wgnuplot_pipes.exe
in gp400win32.zip, and
 	gnuplot.exe
gp400win32x11.zip.

How to package wxgnuplot.exe (?) for Windows? I guess it will be shipped 
with the necessary libs, thus in a separate package gp420win32wx.zip (?).

---
PM

Mirroring of binaries, was: New German gnuplot-book available

[Hardy G. <nt...@ma...>]

Petr Mikulik wrote:
:
> Added to
>  	http://gnuplot.sourceforge.net/help.html
> ... to be mirrored by gnuplot.info soon.
:

Petr, you are talking about mirroring.  Have you ever noticed, that the 
binaries of 4.1 are different on 
http://gnuplot.info/development/binaries/ and 
http://gnuplot.sourceforge.net/development/binaries/?

Sometime ago it took me several time to find the newest binaries (again) 
until I saw that there was a difference between the two locations...

Hardy

Re: gnuplot, wxWidgets and distributions

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

Petr Mikulik wrote:
>>    Another solution (rather then rebuilding): two packages. One linked
>> to wxWidget, the other not. Debian currently has gnuplot-x11 and
>> gnuplot-nox.
>>    =20
>
> Solution (for any distribution) is a package with just a binary called=20
> "wxgnuplot".
>  =20
You mean "just a library". There's no such binary with the wxWidgets=20
terminal right now.
>  =20
>> - write a plugin interface to gnuplot, so that the wxWidgets is
>> dynamically loadable and can be distributed separately
>>    =20
>
> That would be the best.
>  =20
Technically the best, but arguably not for the user, since he would have=20
to find it in the distribution package manager...

Best regards,

Timoth=E9e

Re: gnuplot, wxWidgets and distributions

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

>    Another solution (rather then rebuilding): two packages. One linked
> to wxWidget, the other not. Debian currently has gnuplot-x11 and
> gnuplot-nox.

Solution (for any distribution) is a package with just a binary called 
"wxgnuplot".

> - write a plugin interface to gnuplot, so that the wxWidgets is
> dynamically loadable and can be distributed separately

That would be the best.

---
PM

Re: gnuplot, wxWidgets and distributions

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

Ethan A Merritt wrote:
> I can point out that Redhat has been shipping a minimally-configured=20
> and stripped down gnuplot
> package for a long time.  The current Redhat gnuplot rpm does not even=20
> link against libgd, thus they fail to include support for any of the=20
> gd-based terminals.=20
>
>  =20
>> I won't talk about other distributions, but the situation is probably=20
>> quite close to Fedora's.
>>    =20
>
> Not really.  For one thing, the move is in general towards distributing
> as a single DVD image rather than multiple CD images.  And at least in
> the case of Mandriva, which is where I have the most familiarity, there
> is no such distinction between 'core' and 'extra'.
> =20
>  =20
> (...)
> I find that in general the default packages and configuration on
> both RHEL and Fedora are not ideal for scientific lab use.  Both
> Suse and Mandriva are a better match out-of-the-box.  This comment
> is not intended as a slam against Redhat;  they have identified a
> target user community and designed their offerings accordingly.
> But labs like mine are apparently not in their target community,
> and the choices they make are often contrary to our needs.
>
> The truth is that we don't really know who exactly is the core user
> community for gnuplot. But at least among the developers it seems that
> scientific lab use predominates, and in my experience this means that
> Fedora core may not be as common as other linux distros.
>  =20
I have not seen any Linux distributions in the labs I have worked in, at=20
least none maintained by the tech staff. A few people had Fedora (in=20
California) and some Mandriva (in France). I am using a source-based=20
distribution, so I don't have any of there problems...

Anyway, I asked Suse and Mandriva people about gnuplot and wxWidgets.

In Suse, gnuplot is installed by default, and although wxWidgets is=20
probably not installed by default, it's there and ready. We may hope=20
they will keep gnuplot installed by default and ship it with the=20
wxWidgets terminal (wxGTK is something like 10MB).

In Mandriva, gnuplot is installed by default when you choose a profile=20
like "scientific workstation". wxWidgets is in their main repository.=20
There doesn't seem to be any problem here.

I guess we (I?) should not worry then. At least Suse and Mandriva are=20
very likely to ship the full-featured package.

As far as Debian is concerned, I'll assume they may build a third=20
package with wxWidgets given Ga=C3=ABl's report. Debian users are probabl=
y=20
not to be worried about.


Thank you for pointing out this difference between distributions. I=20
picked Fedora quite randomly.

Best regards,

Timoth=C3=A9e

Re: gnuplot, wxWidgets and distributions

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

    Another solution (rather then rebuilding): two packages. One linked
to wxWidget, the other not. Debian currently has gnuplot-x11 and
gnuplot-nox.

Ga=EBl