Menu
▾
▴
gnuplot-beta
|
From: Hans-Bernhard B. <br...@ph...> - 2005-08-01 15:47:03
|
Ethan A Merritt wrote: > So you expect restoring from a saved file to do an implicit `reset`? > There has been no guarantee of this in the past that I know of. But it's implicit consequence of what "save" does: it save all the settings. All of them. So yes, loading that file again should restore them all, otherwise, we can't really say we "saved" them. > I think there are other bits of context as well that are not necessarily > restored to default state by executing a `save`d file. I think the code in 'save.c' actually goes to quite some length to make sure this doesn't happen. It took several iterations to get that right, too, as a quick look over the cvs log of save.c will reveal. |
|
From: <br...@ph...> - 2006-08-07 19:31:12
|
Timoth=E9e Lecomte wrote: > CVSROOT:=09/cvsroot/gnuplot > Module name:=09gnuplot > Repository:=09./ > Changes by:=09t...@sc....(none)=0906/08/0= 6 19:00:56 >=20 > Modified files: > =09./: ChangeLog INSTALL configure.in=20 >=20 > Log message: > =09Remove detection of libpng, useless since the png driver has bee= n removed. Thimo, are you *sure* this is a good idea? Are you sure there's no= =20 supported platform where libpng has to be searched and found for GD t= o=20 compile? |
|
From: <tim...@en...> - 2006-08-07 19:53:51
|
Hans-Bernhard Br=F6ker wrote:
> Timoth=E9e Lecomte wrote:
> =20
>> CVSROOT: /cvsroot/gnuplot
>> Module name: gnuplot
>> Repository: ./
>> Changes by: tle...@sc....(none) 06/08/06 19:00=
:56
>>
>> Modified files:
>> ./: ChangeLog INSTALL configure.in=20
>>
>> Log message:
>> Remove detection of libpng, useless since the png driver has been rem=
oved.
>> =20
>
> Thimo, are you *sure* this is a good idea? Are you sure there's no=20
> supported platform where libpng has to be searched and found for GD to=20
> compile?
> =20
I took some time before doing this and I think it's ok. Let me explain :
To compile GD itself, sure, libpng has to be searched for. Not only=20
libpng, but also zlib and libjpeg (note that gnuplot's ./configure=20
doesn't do anything for libjpeg).
Then, the code that I removed was really doing _nothing_.
libpng_CPPFLAGS was defined but never appended to CPPFLAGS, nor=20
exported for automake.
libpng_LDFLAGS was defined but never appended to LDFLAGS, nor=20
exported for automake.
HAVE_LIBPNG was defined but not used anywhere in the code since the=20
standalone png driver has been removed.
There was a step to check for the libpng version, but that's not=20
gnuplot's problem, it gd's problem.
Actually, I'm tempted to remove the test for zlib too, because it's gd's=20
problem too. The only problem when removing that one is when an old=20
version of gd (which doesn't have gdlib-config) is used.
Thanks for asking !
Best regards,
Timoth=E9e
|
|
From: Lars H. <lhe...@us...> - 2006-10-23 15:08:52
|
Timoth??e Lecomte writes: > CVSROOT: /cvsroot/gnuplot > Module name: gnuplot > Repository: gnuplot/m4/ > Changes by: tle...@sc....(none) 06/10/21 06:04:32 > > Modified files: > ./: Tag: branch-4-2-stable ChangeLog configure.in > gnuplot/m4/: Tag: branch-4-2-stable apple.m4 msdos.m4 next.m4 > > Log message: > Rework of the configure summary. This is less than useful. In its current state, it's a maintenance nightmare. |
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-10-23 17:19:54
|
On Monday 23 October 2006 08:08 am, Lars Hecking wrote: > Timoth??e Lecomte writes: > > Log message: > > Rework of the configure summary. > > This is less than useful. In its current state, it's a maintenance nightmare. Could you explain your objections, please? To me, the entire autoconfigure system is nightmare-ish. This particular addition to the script seems relatively straightforward and informative. It is true that when changing a configuration option one must also change the associated summary message, but that strikes me as a reasonable price. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Lars H. <lhe...@us...> - 2006-10-24 09:03:52
|
> It is true that when changing a configuration option one must also change > the associated summary message, but that strikes me as a reasonable price. I'm mainly refering to the lists of terminal drivers. This is just one more place that gets forgotten when e.g. new terminals are added. Just like them not being added in Makefiles (which I usually check and fix for releases). It would be better to generate such a list, rather than hardcoding it. |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-08-01 17:40:31
|
On Monday 01 August 2005 08:48 am, Hans-Bernhard Broeker wrote:
> Ethan A Merritt wrote:
> > So you expect restoring from a saved file to do an implicit `reset`?
> > There has been no guarantee of this in the past that I know of.
>
> But it's implicit consequence of what "save" does: it save all the
> settings. All of them. So yes, loading that file again should restore
> them all, otherwise, we can't really say we "saved" them.
In what way do you see this as different from the notion of
`reset, then apply explicit changes` ?
The latter approach is the one assumed by Petr's gpsavediff script,
for instance.
While we're on the topic, I have a related problem that I really don't
know how best to deal with. The "datastrings" and "histograms" modules
make heavy use of the ability to read tic-labels and key-titles from a
data file. Internally, these label structures are fed into the same
data structures that are loaded by explicit user commands like
set xtics ("foo" 1, "bar" 2, "etc" 3)
But this means that when you `save` the current state, you get a dump
of the most recent tic labels read from a data file. This is really
annoying if you don't remember to wipe the xtic entries clear, either
before saving or after restoring. What are your thoughts on this
issue?
--
Ethan A Merritt merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195
|
|
From: Hans-Bernhard B. <br...@ph...> - 2005-08-01 18:19:00
|
Ethan Merritt wrote:
> In what way do you see this as different from the notion of
> `reset, then apply explicit changes` ?
Not a lot. But that's partly missing the point: the concept of
"explicit changes" currently simply doesn't exist anywhere in save.c,
except your recent modification. It might be a good idea to keep in
mind should we ever want to re-write save_set() almost from scratch, but
for now, the strategy is: save all settings in a way that overwrites
whatever previous settings there were.
> While we're on the topic, I have a related problem that I really don't
> know how best to deal with. The "datastrings" and "histograms" modules
> make heavy use of the ability to read tic-labels and key-titles from a
> data file. Internally, these label structures are fed into the same
> data structures that are loaded by explicit user commands like
> set xtics ("foo" 1, "bar" 2, "etc" 3)
>
> But this means that when you `save` the current state, you get a dump
> of the most recent tic labels read from a data file. This is really
> annoying if you don't remember to wipe the xtic entries clear, either
> before saving or after restoring. What are your thoughts on this
> issue?
I see two major possibilities:
1) handle it the same way it's done for other things that change
dynamically during a plot, most notably the ranges: duplicate the key
data structures, prefix one with "set_", and copy the set_ versions into
the un-prefixed instance in axis.h:AXIS_INIT{2,3}D
2) move the labels found in the data file to some other place, and
change gen_tics and/or xtick{2,3}d_callback to use that instead of
normal ones.
|
