Menu
▾
▴
gnuplot-beta
|
From: <tim...@en...> - 2006-06-08 07:46:13
|
Petr Mikulik wrote: > Enabling history file by default: > > =20 >> No, I was thinking the same thing a few days ago, tired of having to a= dd=20 >> --enable-history-file for each ./configure >> =20 > > Ok, so history file has been enabled by default. > > > Now: What about enabling GNU readline by default as well? > > It would save ordinary people to think about adding --with-readline=3Dg= nu ...=20 > while gnuplot binary package distributors can do whatever they think is= =20 > legal. This readline has now more features then gnuplot's readline. > =20 I agree that it would save work but the answer is no for the moment=20 because of the licence incompatibility. Let's discuss the licence at the time of the next release with the=20 copyright owners, as concluded in a discussion on this list a few months=20 ago. Timoth=E9e |
|
From: Petr M. <mi...@ph...> - 2006-06-08 07:58:33
|
>> Now: What about enabling GNU readline by default as well? >> > I agree that it would save work but the answer is no for the moment because > of the licence incompatibility. There is no problem with the license until you distribute the binary. Which normal users don't. --- PM |
|
From: Bastian M. <bma...@we...> - 2006-06-08 13:23:17
|
As a side note: an autoconf'd version of libedit is available at http://www.thrysoee.dk/editline/ It has a BSD style license and is actively maintained. The last time I tried (~1yr ago) it required very little work to replace GNU readline in gnuplot. Right now I do not have the time to work on it though. Petr Mikulik wrote: >>> Now: What about enabling GNU readline by default as well? >>> >> I agree that it would save work but the answer is no for the moment be= cause=20 >> of the licence incompatibility. >=20 > There is no problem with the license until you distribute the binary. W= hich=20 > normal users don't. --=20 Bastian M=E4rkisch Physikalisches Institut, Universit=E4t Heidelberg |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-06-08 16:17:49
|
On Thursday 08 June 2006 12:58 am, Petr Mikulik wrote: > >> Now: What about enabling GNU readline by default as well? > > > > I agree that it would save work but the answer is no for the moment > > because of the licence incompatibility. > > There is no problem with the license until you distribute the binary. > Which normal users don't. That is correct. It seems reasonable to me that ./configure can just test for gnu readline and include it unless explicitly disabled by the person doint the build. Normal users building from source have no license issues. Distributions can make their own call about whether they feel constrained by the license and want to instead use the built-in via ./configure --with-readline Last I checked, about half of the distros did and the other half didn't -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
|
From: <tim...@en...> - 2006-06-08 16:50:35
|
Ethan Merritt wrote: > On Thursday 08 June 2006 12:58 am, Petr Mikulik wrote: > =20 >>>> Now: What about enabling GNU readline by default as well? >>>> =20 >>> I agree that it would save work but the answer is no for the moment >>> because of the licence incompatibility. >>> =20 >> There is no problem with the license until you distribute the binary. >> Which normal users don't. >> =20 > > That is correct. It seems reasonable to me that ./configure=20 > can just test for gnu readline and include it unless explicitly > disabled by the person doint the build. Normal users building > from source have no license issues. Distributions can make their > own call about whether they feel constrained by the license > and want to instead use the built-in via=20 > ./configure --with-readline > Last I checked, about half of the distros did and the other > half didn't > =20 I would prefer the opposite reasoning : gnuplot is distributed mainly in=20 binary form by distributions. To avoid them legal issues (even if it is=20 likely that nobody will complain in a court), it is better to default to=20 the choice that legally works in any situation. I am sure a packager=20 prefers working on a program that does require a minimum of customization. How many users are really compiling gnuplot from source regularly ?=20 Sourceforge says there are more than 10000 downloads per months for=20 gnuplot-4.0 , but I am pretty sure most of them are downloads of the=20 Windows binary version. Others, like me, probably add "--prefix=3D/home/user" or something like=20 that each time they compile gnuplot, and "--with-readline=3Dgnu" takes=20 just a few more milliseconds. "--enable-history-file" is a different=20 issue : it is about enabling a worthwhile feature that has absolutely no=20 objection. I like Bastian's idea to use a BSD-licensed equivalent, if it is=20 maintained and broadly available. Otherwise it is gnuplot's license that=20 needs some more attention. It is a matter of honesty. Best regards, Timoth=E9e |
|
From: Bastian M. <bma...@we...> - 2006-06-08 19:08:24
|
Timoth=E9e Lecomte wrote: > I like Bastian's idea to use a BSD-licensed equivalent, if it is=20 > maintained and broadly available. Otherwise it is gnuplot's license tha= t=20 > needs some more attention. It is a matter of honesty. The discussion about readline/libedit has come up in the past already - s= ee e.g. http://search.gmane.org/?query=3Dlibedit&group=3Dgmane.comp.graphics.gnup= lot.devel - so it wasn't my idea. But it has been on my todo-list for a while now. = ;-) I did a quick and dirty test if gnuplot/libedit may be compiled using cygwin. Here're some observations: command.c (restore_prompt()): rl_forced_update_display() is not supported by libedit gp_hist.h: have to include <editline/readline.h> instead of <readline/history.h> history.c (write_history_list()): history_list() is not supported by libedit mouse.c (alert()): rl_ding() is not supported by libedit plot.c: have to include <editline/readline.h> instead of <readline/tilde.h> variable rl_complete_with_tilde_expansion is not available (main()) readline.h: include <editline/readline.h> instead of <readline/readline.h> Most of the changes needed to get it compiling are really minor. But there're some problems: * The missing rl_forced_update_display() causes some text display problem= s. * It is not clear (to me) if the lack of rl_complete_with_tilde_expansion= is one * write_history_list() has to be rewritten using the available functions * some of the functions in libedit are stubs only and I haven't checked i= f gnuplot uses any of these (see editline/readline.h) * on my box not all keys worked as expected (might be a configuration pro= blem on my side though) Bastian |
|
From: Daniel J S. <dan...@ie...> - 2006-06-09 06:50:43
|
Timoth=E9e Lecomte wrote: > I would prefer the opposite reasoning : gnuplot is distributed mainly i= n=20 > binary form by distributions. To avoid them legal issues (even if it is= =20 > likely that nobody will complain in a court), it is better to default t= o=20 > the choice that legally works in any situation. I am sure a packager=20 > prefers working on a program that does require a minimum of customizati= on. >=20 > How many users are really compiling gnuplot from source regularly ?=20 Probably a lot; because it is so easy and fast to compile. > I like Bastian's idea to use a BSD-licensed equivalent, if it is=20 > maintained and broadly available. Otherwise it is gnuplot's license tha= t=20 > needs some more attention. It is a matter of honesty. Well, the license thing we've talked about at length. I still don't see = why so many people put so much effort into programming gnuplot, yet the l= icense issue gets little attention. Dan |
