Re: Directory restructuring

[Ben Pfaff]

I have little to add, so I'll just quote what I want to comment
on.

John Darrington <address@hidden> writes:

> On Sat, Feb 04, 2006 at 01:47:13PM -0800, Ben Pfaff wrote:
>      > 2. The files which I've left in src are those which are
>      > currently in the "too hard" basket.  This means:
>      >
>      >        error.c : Should really be in libpspp, but it has too many 
> dependencies.  
>      >                  IMHO this interface needs to be rethought anyway.
>      
>      I understand that it's not the right interface for the GUI to
>      use.  Can you explain other objections?  Do you have suggestions?
>
> Almost everything depends on error.c yet error.c depends upon
> src/output.  Not only is it not the "right" interface for the GUI,
> some circumstances which the command line interface considers "errors"
> are normal circumstances for the GUI.  For example, when a user is
> halfway through typing a date eg: "04-July-2001" at the point "04-J"
> the data-in function decides that it's an error. 
> My suggestion would go something like this:

[...]

> That way, the act of reporting the error is left to the user interface
> (command line or gui), whereas deciding what the errors are is left to
> the individual function.

This is going to be a bear to implement.  Via grep, it looks like
there are about 800 calls to msg() in the source tree.

Also, not every message is an error, so we'd have to agree on a
convention to pass up messages that are not errors.

I wonder whether it'd be better to do something, as a compromise
measure, that is less disruptive.  For example, msg() could
append messages to a global list and provide an interface to read
messages off the queue.  Errors would propagate upward through
existing means until a function was prepared to report them to the
user through the user interface, or to discard them.

>      >        main.[ch]: I don't know why we need a main.h ?
>      
>      main.c exports some interfaces?
>      
> I'm of the opinion, that main.c should be moved to src/ui

I took a closer look at what main.h exports.  start_interactive
is actually unused anywhere, so it can be deleted.  finished is
only used in command.c and main.c and could be implemented as
another CMD_* function return value.

terminate() is a different matter.  It has multiple callsites.
The ones in cmdline.c would be easy to eliminate, but I can't say
the same about those in error.c.  Then again, we have a bigger
problem with errors anyhow and we could probably fix this as part
of the error work.

>      >        getl.c:    This is just a pain, which keeps biting me whenever 
> I kick it.
>      
>      Maybe you can help me to understand.
>
>
> I'm confused as to the purpose of this file.  Lots of things depend
> upon it, (eg sfm-read ) when they don't seem to have anything to do
> with getting lines.

As a rule, they just want to report that an error occurred on the
current source line, e.g. this function in sfm-read.c that
reports a corrupt system file:

    /* Displays a corrupt sysfile error. */
    static void
    corrupt_msg (int class, const char *format,...)
    {
      struct error e;
      va_list args;

      e.class = class;
      getl_location (&e.where.filename, &e.where.line_number);
      e.title = _("corrupt system file: ");

      va_start (args, format);
      err_vmsg (&e, format, args);
      va_end (args);
    }

The call to getl_location() is the only dependency from that
file.  There's a variety of ways we could eliminate that,
e.g. add a flag to `struct error' that says "use the current
source line".

You're right: error handling is a mess.

>      It might be best to basically postpone dealing with vfm.
>
> Do you mean postpone it indefinately, or just for a few days?

Just for a few days.  I want to see how everything else works out
first.

I know how to eliminate most dependencies.  With vfm, I have
ideas, but it's hairy.

>      A few greps don't turn up any direct dependency from src/output
>      to src/math for me.  Can you elaborate on that?
>      
> src/output/chart/box-whisker depends on for example src/math/weighted_value.

Oh.  Would it make sense to break box-whisker plots into two
phases: one in which the necessary calculations are made and
another in which the calculated data is plotted?  The former
could go in src/math, the latter in src/output/charts.  Just a
thought--I don't have any idea how box-whisker plots are
structured.

>      > 10. src/output is depending on src/data which seems wrong.  I think
>      >     this is because the ascii driver needs a filename or something.
>      
>      src/output directly uses the following from src/data according to
>      a little bit of grepping:
>      
>              filename.?
>              mkfile.?
>              settings.?
>      
>                      These are general-purpose code, not data-specific,
>                      so I'd move them to libpspp.
>
> I tried this.  In the end I was forced to move *everything from
> src/data to libpspp.  Perhaps it will help if settings.c is split.

filename.? doesn't need anything from src/data except settings.h,
and that only for get_safer_mode().

mkfile.? doesn't need anything from src/data at all.

settings.? needs val.h for SYSMIS and format.h for fmt_spec.  We
could move get/set_blanks() into data-in.c and get/set_format()
into data-list.c, which are what actually use them.  They'll
still have a usage from set.q but that's okay, I think.
get/set_safer_mode() can go into libpspp.

Am I missing any dependencies?

> Perhaps you can look at glob.c and at point 6. (above).  I think I can
> do something better with output vs. output/charts.

OK.

> I suggest that you ftp or http a tarball back to me, and I'll
> aggregate the results this end.  

Will do.
-- 
"I admire him, I frankly confess it; and when his time comes
 I shall buy a piece of the rope for a keepsake."
--Mark Twain