Re: Lengthy discussion about datafile.c...

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

On Saturday 14 August 2004 11:56 am, Daniel J Sebald wrote:
> Hope this doesn't sound like a lecture, but I want to discuss how to
> keep datafile.c clean and prevent the evolution of convoluted code that
> is starting to occur with that file.

[snip lengthy rant, some of which is on target, some not]

Didn't we already have this discussion a few months ago?
I proposed that the whole notion of tracking input data by how
many columns were read in has outlived its usefulness.
I think we should get rid of max_cols and all the various
tests that depend on it, and instead pass explicit information
about the requested input data.  Hans-Bernard disagreed.

> df_open(int max_using, int plot_mode)

Like that, yes, except that 
(1) I think max_using is not necessary or desirable, and 
(2) I proposed passing a pointer to the whole plot
structure rather than passing only the plot style.

> While on this topic of df_readline, I wonder if introducing too much
> "plot dependent" stuff into df_readline is a good idea.

And that was Hans-Bernard's counterargument.

> For example, 
> with the histogram tics, this kind of line seems like it shouldn't be in
> a file-reading routine:
>
>              add_tic_user(axis,temp_string,xpos,0);
>
> Is there some way to move this functionality outside of df_readline()
> back into plot2d.c?

Why?  It is not specific to 2D plots.  But anyway, the answer is no.
The information being processed, the tic labels, are not specific to 
the current plot; they are a property of the axis.  The code belongs
in axis.c, which is where it is currently.  But still you have to call it
from somewhere, and I maintain the logical place (maybe the only
possible place) is the point at which you obtain the information.
That is set.c in the case of axis tic info coming from a "set [xyz]tics"
command, and datafile.c in the case of tic info read in from a file.

> I pose this question because I've been trying to make the case that
> df_readascii() and df_readbinary(), or whatever, should be transparent
> to the calling routine.  If functionality like above keeps being added
> to df_readascii (df_readline) then soon the situation arises where
> certain types of plots can't be done simply because the data comes from
> a binary data file.

If that is indeed true then I have reservations about introducing binary
input at all.  Are you saying that it will not be possible to read strings
in from a binary file, so that the new "plot with labels" and 
"using ...:xticlabels(<col>)" will not work?  If so, then the functionality
has already diverged.  And if the two modes have different capabilities
then all the more reason to keep them separate in the code as well.

> Ethan, what is the minimal amount of information that you would need
> coming back from df_readline() to implement headers from files?  If
> df_readline() were equipped with a char pointer for which df_readline
> could realloc() memory and assign a string, would that do it?

That's what it does now. Because plot->title is not visible from
inside df_readline (which actually I would prefer), the title is allocated
and a pointer to it is stored in a static variable. A helper routine 
df_set_key_title() is later called from get_data(), which is indeed in 
plot2d.c.  No global variables are involved.

> That is, I might propose
>              add_tic_user(axis,temp_string,xpos,0);
> could be moved to plot2d.c. 

You are confusing plot titles and axis tic labels.  The two things are
quite different.  One is a specific property of the current plot,
the other is not.

I know, you are going to point to a single place where the histogram 
code stuffs a plot title into an axis tic label.  I'm not terribly happy
about that either, but let's split that off into a totally separate 
discussion that only applies to stacked histograms.

> PS:  I've concluded that moving df_readbinary() to another file would
> require the sharing of too many "local" variables.

I don't agree.  Most of those local variables are indeed local.
They should not *need* to be shared.

> So I'm thinking that 
> just putting it to the bottom of datafile.c is best... that's actually
> where it probably should be organized anyway.

All right.  Do that as a first step.  At least it may disentangle the
code paths enough that I can do an xxdiff between the new and
old versions to see what you are actually changing.  Right now
it's such a tangle that I don't have an overall sense of what is
shared and what isn't.