Menu
▾
▴
gnuplot-beta
|
From: <tim...@en...> - 2006-09-24 16:58:52
|
Dear all, I have discussed a little bit about Fedora developpers as I was thinking=20 about the way gnuplot 4.2 and the wxWidgets terminal would be=20 distributed. It seems to raise quite a bit of questioning. I won't talk about other distributions, but the situation is probably=20 quite close to Fedora's. Currently, gnuplot is distributed in Fedora "Core", it means that it is=20 the very first set of CDs, and it is in the most controlled part of the=20 distribution. It is a nice situation, since packages in the "Core" are=20 often judged of high quality and accessible to the largest set of users=20 (most Install parties do their stuff with the "Core" CDs only). However wxWidgets is not distributed in the "Core", but in "Extras". The=20 packages in this repository are said to receive a little less attention=20 (Extras is _really_ much bigger than Core), and they are often not=20 installed by default. There is little chance for wxWidgets to move from Extras to Core, given=20 that few applications use it (audacity, xmule). The consequence is that=20 gnuplot is likely to be distributed without the wxWidgets terminal, or=20 to go from Core to Extras. Either situation is not really good, given=20 that being in Core is a nice privilege that we may not want to lose, and=20 that the wxWidgets adds a valuable improvement to gnuplot. The other alternatives are: - static linking with wxWidgets. No, it's not possible. Fedora forbids it. - write a plugin interface to gnuplot, so that the wxWidgets is=20 dynamically loadable and can be distributed separately (in Extras). It's=20 far from being difficult (and probably a nice project for the future - I=20 am thinking of our problem about linking to X11 for the 'raise console'=20 key bindings), but it does not really solve the problem, since many=20 users will never know about the new terminal. - rewrite the terminal in GTK+2, which is included in the core of=20 virtually all distributions. GTK+2 is C, not C++ (I'm used to C++ now=20 !), and not as well supported on non-X11 platforms as wxWidgets is.=20 Fortunately, more than half of the code of the wxWidgets terminal is=20 already wxWidgets-agnostic (that's the cairo&pango part). The logic for=20 the rest can probably be kept, so it's somehow like a port.=20 Unfortunately this is still a lot of work to do. I do not know either if=20 we would want to have both a wxWidgets and a GTK terminal at the same tim= e. What do you think about that ? Best regards, Timoth=C3=A9e |
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-09-24 17:43:22
|
On Sunday 24 September 2006 09:57 am, Timoth=C3=A9e Lecomte wrote:
> I have discussed a little bit about Fedora developpers as I was thinking
> about the way gnuplot 4.2 and the wxWidgets terminal would be=20
> distributed. It seems to raise quite a bit of questioning.
I don't have any real solutions to this issue. But I can point out that
Redhat has been shipping a minimally-configured 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
> I won't talk about other distributions, but the situation is probably=20
> quite close to Fedora's.
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
> The other alternatives are:
> - static linking with wxWidgets. No, it's not possible. Fedora forbids it.
> - write a plugin interface to gnuplot, so that the wxWidgets is=20
> dynamically loadable and can be distributed separately (in Extras).
>=20
> What do you think about that ?
You left out the most obvious option, which is in fact the one you have
to use today to get a decent version of gnuplot going under either RHEL
or Fedora:
rpmbuild --rebuild gd-2.0.33-2.src.rpm
rpmbuild --rebuild gnuplot-4.0.0-11.src.rpm
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
=46edora core may not be as common as other linux distros.
=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742
|
|
From: Gael V. <gae...@no...> - 2006-09-24 17:48:19
|
Another solution (rather then rebuilding): two packages. One linked to wxWidget, the other not. Debian currently has gnuplot-x11 and gnuplot-nox. Ga=EBl |
|
From: Petr M. <mi...@ph...> - 2006-09-24 18:45:10
|
> 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 |
|
From: <tim...@en...> - 2006-09-24 18:49:24
|
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 |
|
From: Petr M. <mi...@ph...> - 2006-09-24 19:07:39
|
>> 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 |
|
From: <tim...@en...> - 2006-09-24 19:12:31
|
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 |
|
From: Petr M. <mi...@ph...> - 2006-09-24 19:20:45
|
>>>>> - 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 |
|
From: <tim...@en...> - 2006-09-24 21:37:37
|
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 |
|
From: <tim...@en...> - 2006-09-25 08:06:26
|
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 |
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-09-24 20:05:23
|
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 |
|
From: <tim...@en...> - 2006-09-24 21:15:36
|
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 |
|
From: <tim...@en...> - 2006-09-24 18:44:51
|
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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X