Menu
▾
▴
gnuplot-beta
|
From: Hans-Bernhard B. <br...@ph...> - 2004-07-08 10:34:23
|
On Sun, 4 Jul 2004, Ethan A Merritt wrote: [3 patches already in] Ethan: please close those patches in the patch tracker, then (including #482108). > I also have some largish patches corresponding to implementations > of several different flavors of user-accessible string variables. > These have been discussed off and on over the last year or so, > but I never sensed a real consensus as to which approach was > best. I think that means we'll need a summary of their differences to start off that discussion again. As far as I remember, there were several open issues we never decided upon conclusively: 1) how deep down into the expression evaluator do we put them, i.e. do we only need string-valued variables controlled by a 'set' or 'let' command of their own, or should 'string' become a third native type of expression, in addition to integer and complex, meaning that we could have string operators, string arguments and results in both internal and user-defined functions? 2) How to recognize usage of string variables in existing commands that currently rely on having "" or '' around strings? 3) As a follow-up to 2), how to expand variables into strings? Bash-like $var, or C-like sprintf() style? $ already being used for at least two entirely unrelated things in gnuplot, I would prefer the latter. > So -- who is next out of the gate? No takers, it seems. I take that to mean we can proceed to the "go through all entries in the SF.net patch tracker" stage. Also known as "fire at will". Except that Patches already assigned to someone should be left to that person. All discussion in this mailing list, please --- the patch tracker itself is too cumbersome for that. -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
|
From: Hans-Bernhard B. <br...@ph...> - 2004-07-08 17:24:49
|
On Thu, 8 Jul 2004, Daniel J Sebald wrote: > The patch I'm proposing is the "wth image", "with rgbimage", and "binary > datafile" stuff, but I should probably say a few things about it on the > list so people know what to expect. Fine with me. -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
|
From: Hans-Bernhard B. <br...@ph...> - 2004-07-08 17:24:50
|
On Thu, 8 Jul 2004, Ethan Merritt wrote: > On Thursday 08 July 2004 08:59 am, Daniel J Sebald wrote: > > > > I would be a taker, but I'm not sure Ethan has completed his changes. > > As I said, I have some more tweaks that I will feed in after testing. > But they are both localized and small, so I don't think that you should > hold off just because of that. > > > The patch I'm proposing is the "wth image", "with rgbimage", and "binary > > datafile" stuff, but I should probably say a few things about it on the > > list so people know what to expect. > > My main concern is that you carefully check that your patch does not > undo some of the code changes that my recent round of patches added. > > In fact, I suggest that is a general requirement for patches added in > this current round. Major changes on top of other major changes > are a bit tricky. Big patches should come with a demo/test-case so > that it is easy to verify it still works later on. For my recent patches > these are: > fillbetween.dem > datatstrings.dem > histograms.dem > histograms2.dem (currently shows a minor bug is present) Are they in 'all.dem' yet? Because if so, I would like to propose a regression test to be set up and be maintained from now on: for at least a select few terminal drivers that write multi-page output files, e.g. postscript and SVG, I think we should run a script like this in 'make check': set term postscript colour solid set output 'current.ps' load 'all.dem' ! diff -u current.ps regress.ps "regress.ps" would have to be maintained outside CVS, though --- It's way too large for regular processing by 'cvs update' and colleagues, esp. over a dial-up link. > We also might want a policy that new features default to > --enable-<feature> to insure that they are well-tested for compatibility. Agreed. People building from CVS right now, so soon after a public release, should get what they asked for: undiluted work-in-progress code. -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-07-08 17:38:04
|
On Thursday 08 July 2004 10:21 am, Hans-Bernhard Broeker wrote: > On Thu, 8 Jul 2004, Ethan Merritt wrote: > > Big patches should come with a demo/test-case so > > that it is easy to verify it still works later on. For my recent > > patches these are: > > fillbetween.dem > > datatstrings.dem > > histograms.dem > > histograms2.dem (currently shows a minor bug is present) > > Are they in 'all.dem' yet? Not yet, because... > > We also might want a policy that new features default to > > --enable-<feature> to insure that they are well-tested for > > compatibility. This policy is needed first. It doesn't currently work to test conditionally-compiled options in all.dem because the script can exit with an error if the option has not been configured. [I'd like to change that behaviour, but that's a whole other discussion] > Agreed. People building from CVS right now, so soon after a public > release, should get what they asked for: undiluted work-in-progress > code. OK. So I'll change the default to --enable-histograms and add all the demos to all.dem -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Daniel J S. <dan...@ie...> - 2004-07-08 18:47:02
|
Hans-Bernhard Broeker wrote: >>>The patch I'm proposing is the "wth image", "with rgbimage", and "binary >>>datafile" stuff, but I should probably say a few things about it on the >>>list so people know what to expect. >>> >>> >>My main concern is that you carefully check that your patch does not >>undo some of the code changes that my recent round of patches added. >> >>In fact, I suggest that is a general requirement for patches added in >>this current round. Major changes on top of other major changes >>are a bit tricky. Big patches should come with a demo/test-case so >>that it is easy to verify it still works later on. For my recent patches >>these are: >> fillbetween.dem >> datatstrings.dem >> histograms.dem >> histograms2.dem (currently shows a minor bug is present) >> I just confirmed that the patch doesn't alter any of your new additions. >>We also might want a policy that new features default to >>--enable-<feature> to insure that they are well-tested for compatibility. >> OK... BTW, currently the default for "histograms" is disabled. ... Well, here are some comments: 1) With contributions from Ethan and Per, there are a good number of drivers covered so far: x11, postscript family (postscript, epslatex, pstex), png, pdf, aqua. The one main one not covered is probably Windows in some form. However, the software should at least default to using filled polygons for that case if pm3d is available. 2) There are some messages in the patch that come up the first time a feature is used that eventually can be weeded out. For example, the first time an image is drawn in X11, information about the graphics display is put on the screen. This is in case someone runs across the situation where their color scheme looks incorrect. They can then pass that info along to me for a bug fix. 3) I think Petr and I have come up with a fairly good syntax for all the options to bring in raw data files. However, feedback is welcome. 4) I believe the code is clean, compact and efficient. Some of it may look bulky, like all the arrays constructed to extract the variable data size info from the compiler. However, once that is passed through the compiler, the result is a compact set of tables. But on the original note, I'm probably a weaker programmer than the group and with perhaps different style (although I've learned and adapted a lot), so if anyone someday realizes "hey that could be done better like this", feel free to alter things. Or if there is question, just ask. 5) In the reading of raw data, I've intermixed code in the "df_readline()" routine so that the changes I've made have a small probability of altering the way any file entry current behaved. However, I look at "df_readline()" as being the workhorse of the file reading routines. As such, it could maybe be cleaned up later on when all is said and done. In fact, I'm wondering if just a couple extra conditional statements within this routine could achieve reading "gnuplot binary" files so that a special routine for gnuplot binary is not needed. 6) There is one small detail within the software that I've left undone. It is the clipping of pixels for images that are skewed, drawn with polygons. That is, the pixels at the edges of the image which extend partial into a non-visible region are currently not clipped into 3 sided or 5 sided polygons as they should be. This happens when zooming. I thought it a bit tedious to go through that, not knowing if the arbitrary angle feature were to end up in the final product. After some evaluation if people think "let's keep that", then I can patch the fix. It shouldn't be that difficult. 7) I'll ask Petr to make the change in the source. But, I just noticed I left some "Enable ..." messages out of the config file. I'll add that quick. Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-07-08 19:04:32
|
On Thursday 08 July 2004 12:11 pm, Daniel J Sebald wrote: > pstex), png, pdf, aqua. The one main one not covered is probably > Windows in some form. However, the software should at least default to > using filled polygons for that case if pm3d is available. I plan to move the filled_polygon() code out of the PM3D #ifdefs, and make it dependent on USE_ULIG_FILLEDBOXES instead. I'll make this change one driver at a time. In most cases the existing term->fillbox() will then become a special-case wrapper that simply passes along a request for a 4-vertex polygon. Once the drivers are ready, I'll change the core routines to allow filledcurves and other options based on term->filled_polygon even in the absence of PM3D. But as you all know, I don't do Windows - so I leave that to someone else. > 5) In the reading of raw data, I've intermixed code in the > "df_readline()" routine so that the changes I've made have a small > probability of altering the way any file entry current behaved. > However, I look at "df_readline()" as being the workhorse of the file > reading routines. As such, it could maybe be cleaned up later on when > all is said and done. In fact, I'm wondering if just a couple extra > conditional statements within this routine could achieve reading > "gnuplot binary" files so that a special routine for gnuplot binary is > not needed. It would be nice to further clean up the code in df_readline(). But I think it is OK to start with a working version and use it for a baseline against which to compare the output of cleaned up versions. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Daniel J S. <dan...@ie...> - 2004-07-08 15:36:32
|
Hans-Bernhard Broeker wrote: >On Sun, 4 Jul 2004, Ethan A Merritt wrote: > > > >> So -- who is next out of the gate? >> >> > >No takers, it seems. I take that to mean we can proceed to the "go >through all entries in the SF.net patch tracker" stage. Also known as >"fire at will". Except that Patches already assigned to someone should be >left to that person. All discussion in this mailing list, please --- the >patch tracker itself is too cumbersome for that. > I would be a taker, but I'm not sure Ethan has completed his changes. I wanted to wait a bit for that to stabilize and be tested a bit. I've tried the changes he's made and they seem fine. The patch I'm proposing is the "wth image", "with rgbimage", and "binary datafile" stuff, but I should probably say a few things about it on the list so people know what to expect. Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-07-08 16:43:52
|
On Thursday 08 July 2004 08:59 am, Daniel J Sebald wrote: > > I would be a taker, but I'm not sure Ethan has completed his changes. As I said, I have some more tweaks that I will feed in after testing. But they are both localized and small, so I don't think that you should hold off just because of that. > The patch I'm proposing is the "wth image", "with rgbimage", and "binary > datafile" stuff, but I should probably say a few things about it on the > list so people know what to expect. My main concern is that you carefully check that your patch does not undo some of the code changes that my recent round of patches added. In fact, I suggest that is a general requirement for patches added in this current round. Major changes on top of other major changes are a bit tricky. Big patches should come with a demo/test-case so that it is easy to verify it still works later on. For my recent patches these are: fillbetween.dem datatstrings.dem histograms.dem histograms2.dem (currently shows a minor bug is present) We also might want a policy that new features default to --enable-<feature> to insure that they are well-tested for compatibility. Later on we can decide if some are too specialized or so big that they should require deliberate selection at ./configure time. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-07-08 20:12:25
|
On Thursday 08 July 2004 03:27 am,
Hans-Bernhard Broeker <br...@ph...> wrote:
>
> > I also have some largish patches corresponding to implementations
> > of several different flavors of user-accessible string variables.
> > These have been discussed off and on over the last year or so,
> > but I never sensed a real consensus as to which approach was
> > best.
>
> I think that means we'll need a summary of their differences to
> start off that discussion again. As far as I remember, there
> were several open issues we never decided upon conclusively:
I need to clean them up, modify them to apply against the current
cvs source, and generally re-familiarize myself with the code. Then
I'll update or replace the descriptions on SourceForge and post them
to the list as well.
> 1) how deep down into the expression evaluator do we put them, i.e. do
> we only need string-valued variables controlled by a 'set' or 'let'
> command of their own, or should 'string' become a third native type of
> expression, in addition to integer and complex, meaning that we could
> have string operators, string arguments and results in both internal and
> user-defined functions?
That would be the hard part, yes.
> 3) As a follow-up to 2), how to expand variables into strings?
> Bash-like $var, or C-like sprintf() style?
I don't quite see how the latter would work in general. Do you mean
set label 1 "After fitting, A = "+printf(A)+" B = "+ printf(B)
I find that incredibly ugly and unreadable compared to
set label 1 "After fitting, A = $A B = $B"
Or did you mean
set label 1 sprintf( "After fitting, A = %3.2f, B = %3.2f", A, B)
That variant does have the virtue of allowing format specifiers.
But I don't really see how either of these would work on the
command line. The existing "userstrings" patch allows
STYLE1 = "1:4 with lines lw 2"
plot 'datafile' using $STYLE1
or even
Source1 = " 'data1' using 1:4"
Source2 = " 'data2' using 2:3"
plot $Source1 with lines, $Source2 with points
How does printf/sprintf fit in here?
Admittedly the userstrings patch would probably better be
described as implementing macro definitions rather string variables,
but it raises the same issues of acceptable syntax.
> $ already being used for at
> least two entirely unrelated things in gnuplot
The primary use is for column numbers.
The second use I know about is for the command line
variables ($1, $2, $3...).
But of those are easily avoided simply by requiring that string
variables start with a letter, which we would want to do
anyhow to avoid parsing problems.
Are there any other uses?
> I would prefer the latter.
I prefer $, although I have no particular objection to
using some other symbol or syntax. There was an earlier
suggestion to use %(VARIABLE) instead of $VARIABLE.
Even so I agree that *if* we allow string functions, then
some equivalents to printf() and sprintf() need to be built in.
I never got as far as a solid implementation of string-valued
functions in my earlier attempts, however.
--
Ethan A Merritt merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195
|
|
From: Dave D. <dde...@es...> - 2004-07-08 20:40:54
|
Ethan Merritt <merritt@u.washington.edu> writes:
> On Thursday 08 July 2004 03:27 am,
> Hans-Bernhard Broeker <br...@ph...> wrote:
>>
>> > I also have some largish patches corresponding to implementations
>> > of several different flavors of user-accessible string variables.
>> > These have been discussed off and on over the last year or so,
>> > but I never sensed a real consensus as to which approach was
>> > best.
>>
>> I think that means we'll need a summary of their differences to
>> start off that discussion again. As far as I remember, there
>> were several open issues we never decided upon conclusively:
>> 1) how deep down into the expression evaluator do we put them, i.e. do
>> we only need string-valued variables controlled by a 'set' or 'let'
>> command of their own, or should 'string' become a third native type of
>> expression, in addition to integer and complex, meaning that we could
>> have string operators, string arguments and results in both internal and
>> user-defined functions?
> But I don't really see how either of these would work on the
> command line. The existing "userstrings" patch allows
>
> STYLE1 = "1:4 with lines lw 2"
> plot 'datafile' using $STYLE1
>
> or even
>
> Source1 = " 'data1' using 1:4"
> Source2 = " 'data2' using 2:3"
> plot $Source1 with lines, $Source2 with points
>
> How does printf/sprintf fit in here?
>
> Admittedly the userstrings patch would probably better be
> described as implementing macro definitions rather string variables,
> but it raises the same issues of acceptable syntax.
>
I see this as the crux of the issue. As you say, userstring patch is
really macros rather than full string variables. I spent a bit of time
thinking about "true" string expressions / variables a long time
ago. That would be my preference, though since the chances are I won't
have any time to implement anything, I don't want to push my views too
hard.
If I did have time, then my goal would be able to do something like
plot 'file' using (timecolumn("format, 1) + timecolumn("fmt", 3)):5
where (I hope it's obvious) timecolumn is a built-in function like
column() but which allows the format to be supplied as a parameter.
This fixes some of the problems with timefmt where only one format can
be specified, for example.
I would go as far as allowing user-defined functions which take and
return strings, etc. I had always assumed that STRING would become the
third type of a value.
String literals in expressions become a complication. (Assuming
expression evaluation is still as it was a few years ago.) My plan had
been to store a string table in an action table where the literals
go. This way, the literals last for as long as the action table lasts,
which may be brief for a temporary at, or for the duration of a plot
for a plot-using expression, or for the lifetime of a user-defined
function.
As is pointed out, this doesn't allow strings to be used as macros. My
suggestion was to provide an eval()-like command which evaluates
a string expression, then puts that back through the parser to
interpret it as a gnuplot command. Ugly, but...
And of course, a user-defined function could invoke eval() and really
make things complicated.
My only objection to the string-macros patch is that it would get
in the way of a "full" string-expression change later.
But anyway, it's a long time since I've been actively involved in
development, so I don't want to push my own opinions on this.
dd
--
Dave Denholm <dde...@es...> http://www.esmertec.com
|
×
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