Re: Directory restructuring

[John Darrington]

On Sat, Feb 04, 2006 at 07:40:17PM -0800, Ben Pfaff wrote:

     > 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.

Yes, it would be mundane and boring work.
     
     Also, not every message is an error, so we'd have to agree on a
     convention to pass up messages that are not errors.

If we have a "severity" of each error, then a "message which is not an
error" is simply an error with a severity of zero.
     
     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.
     

I'd have to think about the implications of that. If we use a queue,
then it needs to be a priority queue, so that error more serious
messages  get priority over the trivial ones.  I've worked on systems
in the past, where if a small fault develops, 250 warning dialog
boxes popup.  I think with this kind of system, we'd run the risk of
somthing similar happening.


     
     >      >   getl.c:    This is just a pain, which keeps biting me whenever 
I kick it.
     >
     > 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.
     
     
     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".

That sounds like a good idea to me.  There is also
getl_reading_script() which is called from data-in.c

     > 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.

I moved chart.[ch] from src/output/charts to src/output which gets rid of 
a dependency, and I think it's the correct thing to do.  Chart.c defines
the interface for a chart, the same as tab.c defines the interface for
a table.  So its logical that they belong in the same place.  Many of
the files in src/output/chart certainly need to be generalised so they
can be used from different commands, but I think that's a job for
another day.
     

     
     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?

No.  I think you've covered all that I spotted.


J'

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://pgp.mit.edu or any PGP keyserver for public key.

pgpe58Z9Ckfv1.pgp
Description: PGP signature